From owner-ipng@sunroof.eng.sun.com Wed May 1 06:36:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41DZxrP008807; Wed, 1 May 2002 06:35:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41DZxZq008806; Wed, 1 May 2002 06:35: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.3+Sun/8.12.3) with ESMTP id g41DZurP008799 for ; Wed, 1 May 2002 06:35:56 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12824 for ; Wed, 1 May 2002 06:35:56 -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 HAA12266 for ; Wed, 1 May 2002 07:35:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g41DZrF04968 for ; Wed, 1 May 2002 16:35:53 +0300 Date: Wed, 1 May 2002 16:35:53 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, This is the new version of the draft. I've expanded the scope a bit, to mention problems with non-64 prefix lengths in general too, due to comments. One that's missing is that stateless address autoconfiguration doesn't work. Please see if the changes in the draft seem to be in conflict with your opinions. I intend to push this as personal submission to IESG for informational or BCP. -- 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 ---------- Forwarded message ---------- Date: Wed, 01 May 2002 07:25:55 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-02.txt 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-02.txt Pages : 5 Date : 30-Apr-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-02.txt [...] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 07:55:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41EtnrP008886; Wed, 1 May 2002 07:55:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41EtmEP008885; Wed, 1 May 2002 07:55: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.3+Sun/8.12.3) with ESMTP id g41EtjrP008878 for ; Wed, 1 May 2002 07:55:45 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03536 for ; Wed, 1 May 2002 07:55:46 -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 IAA20096 for ; Wed, 1 May 2002 08:55:39 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g41EtLO05518; Wed, 1 May 2002 17:55:21 +0300 Date: Wed, 1 May 2002 17:55:20 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: kempf@docomolabs-usa.com, , Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt In-Reply-To: <200204291152.HAA24778@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Apr 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Fast Router Advertisement > Author(s) : J. Kempf, M. Khalil, B. Pentland > Filename : draft-mkhalil-ipv6-fastra-00.txt > Pages : 3 > Date : 26-Apr-02 > > This document specifies an amendment to the router solicitation > handling procedures in RFC 2461 that allow for improved default > router aquisition performance when an active IP host moves from > one subnet to another. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-00.txt I'm not sure how this ended up Cc:'ed to ipng but anyway.. A few comments: 3.0 Processing Router Solicitations A router that is configured to provide fast RAs MUST maintain a counter, FastRACounter, of the fast RAs sent since the last unsolicited multicast RA was sent. when an RS is received, an RA MUST be sent immediately if: FastRACounter <= MAX_FAST_RAS ==> I think the wording should be much more clear on what exactly is a router configured to provide fast RAs, especially if it _MUST_ send fast RA's in contradiction to the current specification. A router SHOULD choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), otherwise the router MUST schedule a multicast Router Advertisement in accordance with RFC 2461. ==> Clarification: if the router would not schedule an RA by RFC 2461 (e.g. skip the scheduling to prevent DoS) ==> Using unicast was a MAY. I think there should be some discussion why this should be changed. When the multicast RA has been sent, FastRACounter MUST be reset to zero and processing for fast RAs recommences. [and] 4.0 Security Considerations This draft specifies a minor modification to RFC 2461. There are no considerations for this draft. ==> please have a look at: http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-05.txt At the very least, 100 Fast RA's per multicast unsolicited interval, the minimum decreased by MIPv6 to 0.05 seconds: potentially about 2,000 RA's from a router a second. Potential DoS? -- 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 May 1 09:05:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41G5NrP009213; Wed, 1 May 2002 09:05:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41G5NcL009212; Wed, 1 May 2002 09:05: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.3+Sun/8.12.3) with ESMTP id g41G5KrP009205 for ; Wed, 1 May 2002 09:05:20 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01756 for ; Wed, 1 May 2002 09:05:21 -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 KAA26648 for ; Wed, 1 May 2002 10:05:20 -0600 (MDT) Message-ID: <007601c1f129$c10ad3f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" , Cc: , References: Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt Date: Wed, 1 May 2002 09:03:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HI Pekka, > I'm not sure how this ended up Cc:'ed to ipng but anyway.. > IPNG would be the logical working group that would take it on I think, since it involves a change in RFC 2461. > A few comments: > > 3.0 Processing Router Solicitations > > A router that is configured to provide fast RAs MUST maintain a > counter, FastRACounter, of the fast RAs sent since the last > unsolicited multicast RA was sent. when an RS is received, an > RA MUST be sent immediately if: > > FastRACounter <= MAX_FAST_RAS > > ==> I think the wording should be much more clear on what exactly is a > router configured to provide fast RAs, especially if it _MUST_ send fast > RA's in contradiction to the current specification. > The previous paragraph states what a fast RA is namely: An RA that is immediately unicast to the sender rather than delayed is known as a "fast RA". As to what it means for a router to be configured to provide fast RAs, it means that the router disposes of RSs as described. I guess we could make that a little clearer. > A router SHOULD choose to unicast the response directly to the > soliciting host's address (if the solicitation's source address > is not the unspecified address), otherwise the router MUST schedule > a multicast Router Advertisement in accordance with RFC 2461. > > ==> Clarification: if the router would not schedule an RA by RFC 2461 > (e.g. skip the scheduling to prevent DoS) > I don't understand the problem. Are you concerned that the router will be bombarded by RSs with the unspecified address? RFC 2461 contains explicit instructions about the timing of multicast RAs, so I don't see what the threat is. > ==> Using unicast was a MAY. I think there should be some discussion why > this should be changed. > I suppose we could make it a MAY, but this draft is in the context of an enhancement to RFC 2461 and is, itself, a MAY. Within the context of this draft, it seems as if SHOULD should work, since it will remain MAY in the context of RFC 2461. > When the multicast RA has been sent, FastRACounter > MUST be reset to zero and processing for fast RAs recommences. > > [and] > > 4.0 Security Considerations > > This draft specifies a minor modification to RFC 2461. There are no > considerations for this draft. > > ==> please have a look at: > > http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-05.txt > > At the very least, 100 Fast RA's per multicast unsolicited interval, > the minimum decreased by MIPv6 to 0.05 seconds: potentially about 2,000 > RA's from a router a second. Potential DoS? > I'll check the reference, but I'm not sure I understand your point. An attacker can only force the router to send out up to FastRACounter unicast RAs before it rolls over to a multicast. We could increase the recommended default. We could add some adaptive logic which requires the router to continue using multicast for some period of time before rolling back to unicast, to limit the scope of a DoS attack. Since there is currently no security on ND, there is no way to check whether a host sending an RS is authorized to use the link. We should probably mention this in the Security Considerations section in any case. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 13:37:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41KborP010176; Wed, 1 May 2002 13:37:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41Kbn3G010175; Wed, 1 May 2002 13:37: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.3+Sun/8.12.3) with ESMTP id g41KbkrP010168 for ; Wed, 1 May 2002 13:37:46 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20080 for ; Wed, 1 May 2002 13:37:48 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24153 for ; Wed, 1 May 2002 14:37:47 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g41Kblp6029837 for ; Wed, 1 May 2002 13:37:47 -0700 (PDT) Received: from [171.71.119.70] (dhcp-171-71-119-70.cisco.com [171.71.119.70]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN77271; Wed, 1 May 2002 13:36:41 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: Date: Wed, 1 May 2002 13:38:09 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: Stateless DNS discovery draft Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's another attempt to clarify the "stateless"/"serverless"/ "third-party-serverless" issue. I'm not sure this will be any more successful than previous attempts, but it's worth a try. Please excuse the pedantic tone and the excruciating level of boring detail; a couple of folks have asked for exactly that. Note that I am speaking only as a working group member with a substantial personal interest in the success of IPv6, rather than making any "official pronouncements" as working group co-chair. In this first part, I try to avoid using the terms stateless, server- less, server, configuration, auto-configuration, and DHCP, because all of those are ambiguous, evidently. I'm also initially not talking about DNS discovery/configuration specifically, but rather the generic discovery/configuration problem. Before a network entity can use the services of, or communicate with, another network entity or set of entities, it often must obtain certain information about that entity or set of entities, for example its network address(es) and other parameters/properties of its service or application. To avoid further use of such tortured locution, let me adopt the following terms, which I hope are sufficiently un-burdened with overloaded semantics: - "seeker" is the entity that needs to acquire the information. - "target" is the entity or set of entities with whom the seeker wishes to communicate, or that offers the service the seeker wishes to use. - "needed info" is the information about the target needed by the seeker, in order to communicate with, or use the services of, the target. There is a wide variety of possible techniques that seekers could use to obtain the needed info, for example: manual-config: the seeker could be manually configured with the needed info. query-to-well-known-target-addr: the seeker could send a query message to a well-known (i.e., compiled-in, constant) address to which the target (and possibly others) listens, requesting the needed info from the target. The well-known address might be unicast, anycast, multicast, or broadcast, and of global or non- global scope. multicast-advert-from-target: the target could send periodic "advertisement" messages to a well-known broadcast or multicast address, to which the seeker listens to learn the needed info. unicast-push-from-target: the target could send an unsolicited unicast message to the seeker, "pushing" the needed info to the seeker. query-to-intermediary: the seeker could send a message to a third-party entity or set of entities -- an "intermediary" -- requesting the needed info. multicast-advert-from-intermediary: an intermediary could send periodic "advertisement" messages to a well-known broadcast or multicast address, to which the seeker listens to learn the needed info about the target. unicast-push-from-intermediary: an intermediary could send an unsolicited unicast message to the seeker, "pushing" the needed info to the seeker. run-app-over-well-known-target-addr: for some targets, for which the only needed info is a network address, it may (if certain other conditions are also met) be possible to simply make that address be a well-known one, effectively reducing the needed info to the null set. The seeker would simply send its service requests or other target-specific communication to that well-known address. I'm sure this isn't a complete list; if I left out a known technique, please let me know. Note that more than one technique may be employed for a given target. For example, in IPv6 Neighbor Discovery, a host learns the "needed info" to use the IP forwarding service of routers both by query-to- well-known-target-addr, i.e., sending router solicitations to the link-local, all-routers multicast address, and by multicast-advert- from-target, i.e., listening for router advertisements on the link-local, all-nodes multicast address. For the techniques that employ intermediaries, there arises the question: Q1: How does the intermediary obtain the needed info about the target, in order to provide it to seekers? For query-to-intermediary, there's also the question: Q2: How does the seeker obtain the needed info to communicate with the intermediary itself? For unicast-push-from-target and unicast-push-from-intermediary, there's the question: Q3: How does the target or intermediary obtain the needed info to send an unsolicited "push" message to the seeker, e.g., the seeker's address? The answer to all those questions is: one or more choices from the same set of techniques listed above. For example, in "classic" IPv4 DHCP or BOOTP usage -- which are examples of using query-to- intermediary for getting needed info about a target to a seeker -- the answers to questions Q1 and Q2 are: A1: the intermediary (DHCP or BOOTP server) uses manual-config or query-to-intermediary or unicast-push-from-intermediary, i.e., it gets the needed info from a human or another intermediary, such as a "provisioning" system. A2: the seeker (DHCP or BOOTP client) uses run-app-over-well- known-target-addr, i.e., it communicates with a DHCP or BOOT server at a well-known address: the IPv4 all-ones broadcast address. (A special-purpose forwarding service, in the form of DHCP or BOOTP relays, enables that communication to reach beyond a single link; I could further recurse here and talk about how the relays get *their* needed info, but I won't). I hope and expect that IPv6 will be used in many "unmanaged" environments, e.g., homes, small offices, vehicles, "body networks", etc., where there is no network management or operations staff. I also hope and expect that IPv6 will be held to a higher standard of fault tolerance than IPv4 has been to-date, as more of our day-to-day support infrastructure becomes dependent on IP communication, e.g., among kitchen appliances, entertainment systems, medical devices, and so on. Furthermore, many of the environments in which I expect IPv6 to be used will be highly volatile, topologically, due to ever increasing node and network mobility, environmental challenges, lack of professional network management, and just the sheer number of devices and communication links. In such unmanaged, volatile, but heavily IP-dependent environments, discovery/ configuration techniques that depend on intermediaries can have a number of serious drawbacks, compared to alternatives: (1) If an intermediary is not co-resident with (i.e., on the same node as) the target for which it is providing needed info, a failure of the node holding the intermediary, or of the path from a seeker to the intermediary, can prevent the seeker from communicating with the target, even though the target and a path to the target are up and running. If my home stereo system uses IPv6 to communicate with its speakers, I don't want failure of a separate "configuration server box" to prevent me from using my stereo (or force me to manually configure my stereo with the IPv6 addresses of the speakers), if that can be avoided. Note that even a co-resident intermediary can fail independently of the target, a hazard that can be reduced or eliminated by building the intermediary into the target process itself, at which point it is no longer an intermediary. However, a careful implementation of a co-resident intermediary service that, for example, uses a watchdog timer to restart an intermediary process if it fails, would probably suffice, if complete elimination of the intermediary is not possible for some reason. (2) If the way an intermediary obtains the needed info to hand out to seekers is via manual configuration, or via other intermediaries that are themselves manually configured, that creates the hazard that the configured info may be out-of-synch with reality. When that happens, the intermediary might tell a seeker to use a target that is no longer up, is no longer reachable, or no longer exists, or it might fail to tell a seeker the needed info to use a valid target that does exist and is up and reachable. Or another way to look at it is that manually-configured intermediaries impose a network management burden of having to update the intermediary before a new target can be used. If someone buys a new gadget for their home network -- say, an IP barometer -- the less manual configuration they have to do to be able to use it, the better -- preferably none. The inconsistencies that can arise in manually-configured intermediaries due to temporary failures of target nodes or paths to target nodes, or due to decommissioned targets, are less onerous, in that if the target service is available at more than one node, and if the intermediary supplied the needed info for all such nodes, the seeker itself can find a working and reachable instance of the target if there is one, simply by trying them all. However, that may well come at the cost of greater timeout delays and more network traffic than alternatives that don't entail the use of intermediaries. (And for intermediaries that do *not* obtain their needed info via manual configuration, but rather dynamically obtain it directly from the targets, e.g., using techniques like query-to-well-known-target-addr or multicast-advert-from- target, one must ask why not just have the seekers use those same techniques, and eliminate the unnecessary middlemen?) (3) If only a single intermediary is used to supply needed info to seekers of different kinds or instances of targets, and those different targets may reside on different nodes, it is not possible to make the single intermediary co-resident with all of them, thus causing the problem identified in point (1) above for at least some targets. (4) If in response to point (3) you then say, "OK, let's fix that by replicating the multi-target intermediary on all targets," you now have the problem of providing each replica with a copy of the same needed-info "database" (assuming any replica is allowed and required to provide the the needed info for any target), but if you do that replication of the database manually, you have now exacerbated the problem identified in point (2) above. And if the replicas each learn all the data automatically by polling or listening to the targets, again the question arises: why not just have the seekers do the polling or listening themselves? Now, with *all* that preamble, I think I can finally more precisely state what properties some of us (or, at least, I) are asking for, when we say we want a "stateless", or "serverless", or "third-party serverless" solution that IPv6 seekers can use for obtaining needed info about IPv6 targets: We would like a solution that does not *require* the use of intermediaries that: - are non-co-resident with targets, or - are manually configured, or - employ only a single intermediary to provide needed-info about multiple kinds or instances of targets, or - employ replicated intermediaries, any one of which is required to provide the same needed-info about the same multiple kinds or instances of targets. I don't believe we are asking for the impossible, because there are a number of solutions that don't have those properties, such as query-to- well-known-target-addr or multicast-advert-from-target. In this note, I don't want to argue the relative importance of those properties vs. other desirable properties, but am just trying to clarify what is being referred to by the shorthand "stateless" or "serverless". That this has sometimes been expressed imprecisely as "we don't want to depend on DHCP" is due to that fact that DHCP, *in the way it is widely and commonly used and understood*, is the most obvious example of -- and the obvious candidate for -- a solution that entails intermediaries that are non-co-resident with targets, that are manually configured (or indirectly manually configured via other intermediaries), and that either employ a single intermediary or multiple replicated intermediaries to provide needed info about multiple kinds or instances of targets. Clearly, it is possible to use DHCP-formatted messages in one of the techniques that do not use intermediaries, and the IPv6 DNS Discovery design team considered that as one of the many candidate solutions. However, it is not clear to me that that's what is being proposed by Ralph, Rob, and others who are advocating the sole use of DHCP for IPv6 DNS Discovery. If their proposal is to: - run a DHCP responder built into, or co-resident with, each target instance, - that does not have to be manually configured with information about other kinds or instances of targets, - that responds only on behalf of its corresponding target instance, and - that works properly if more than one such responder (for different kinds of targets) reside in the same node (e.g., a seeker won't reject more than one DHCP reply from the same node, thinking it's a duplicate or something), then great, that satisfies the desirable properties listed above (as could a number of other possible solutions, such as SLP or a pair of new ICMP messages). One minor issue that I did not see addressed by the DHCP-only advocates is whether their solution would continue to use a single well-known address for seeking info for all types of targets, or whether different well-known addresses could be used for different target types (e.g., one well-known multicast or anycast address for NTP config, another one for DNS config, another for cookie-of-the-day config, etc.) Allowing different query addresses for different services avoids disturbing more target nodes with query traffic than necessary, which would be important if it is going to be used in environments with many different types of targets and very many seekers. Though IPv6 will be used in many unmanaged environments, it will also be used in many managed environments as well (one hopes), in which it may be required or desired to support more complex or controlled configuration of nodes than the simple plug-and-play/zeroconf/ "automatically find and use a nearby instance of target X" approach supported by the automatic configuration techniques that do not depend on intermediaries. That's why we included support in IPv6 (specifically in the neighbor discovery protocol) to direct nodes to a "stateful" configuration service (read, intermediary), when that's desired by network managers. The configuration philosophy/goal embedded in the IPv6 design (as I understand it, and as I have conveyed to many others over the years of teaching tutorials about IPv6, and as I assumed was also understood by everyone else who was involved in fleshing out that design -- an assumption that I'm distressed to now learn is not valid) is: - By default, out of the box, IPv6 hosts (and someday maybe IPv6 routers, as well) are "plug-and-play", i.e., use robust, as-close-to-zeroconf-as-possible methods of learning the information they need to serve their purpose(s) on the network. (For IP-layer info, this is accomplished by so-called stateless address autoconf and other parts of the IPv6 neighbor discovery protocol.) - For environments where network management wants to override the default plug-and-play behavior, there is a mechanism for the network manager to interpose an intermediary in the configuration process. (This is accomplished by having the two bits in the router advertisement messages that tell hosts to use use a "stateful" configuration service for getting their own addresses and other needed info, respectively.) - For cases where neither the default plug-and-play behavior nor the intermediary-provided service yields the desired result, their is a mechanism for a node administrator to override both (i.e., manual configuration of the node itself). I think we should declare that DHCP is the protocol to use to invoke the services of the "stateful" configuration service. At the time the "use-stateful" bits were defined, we thought it was conceivable that DHCP might be superceded by a newer intermediary-based configuration service, but that hasn't happened, and in any case, we clearly can't use any intermediary until we define what protocol to use to talk to that intermediary, and DHCP is the obvious choice. As to what technique to use for robust plug-and-play autoconfiguration, intermediary-free-DHCP would be one candidate, as would SLP, ICMP extensions, etc. For those targets that can satisfy the conditions required to use the run-app-over-well-known-target-addr technique (i.e., only needed info is an address, any replica of the target will do, no more than one packet needed in each direction to invoke the service), that might be the best choice, because it eliminates unnecessary code in those target's implementations and reduces the number of packet exchanges required to use the target. Which brings me at last to *DNS* Discovery. I believe that DNS servers, as targets, satisfy the requirements needed to use the run-app-over- well-known-target-addr, and that indeed is the current "phase 1" proposal from the DNS Discovery design team. This is not "inventing yet another configuration/discovery protocol", it is doing without any configuration/discovery protocol at all, because the needed config info has been reduced to the null set. (Or another view is that it is taking advantage of the "discovery protocol" that is built into every IP routing protocol.) I think the "phase 2" info (default domain name, search list ) is not information "about the target" -- which has been the subject of this essay -- but rather information specific to the seeker, as has been pointed out by others on this list. For many hosts, especially in unmanaged environments, that info is not needed at all, or is part of the "personalization" that users normally do with their own devices (PC, laptop, cell phone, whatever). In a corporate environment in which uniform search lists are desired for some reason, those environments can use the O bit in router advertisements to tell hosts to use intermediary- based DHCP, and get it that way. If you've read this far, you must be a real glutton for punishment, so may be disappointed to know that I'm going to stop now, rather than spiralling even deeper by observing that DNS servers are themselves intermediaries, which it would be nice to avoid dependence on. That'll have to be a topic for another day. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 14:34:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LY3rP010309; Wed, 1 May 2002 14:34:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41LY20e010308; Wed, 1 May 2002 14:34: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.3+Sun/8.12.3) with ESMTP id g41LXxrP010301 for ; Wed, 1 May 2002 14:33:59 -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 OAA23245 for ; Wed, 1 May 2002 14:33:59 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29622 for ; Wed, 1 May 2002 14:33:59 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E38CA62D3; Wed, 1 May 2002 17:33:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 17:33:58 -0400 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: 1RE: Proposed IPv6 DNS Discovery Requirements Date: Wed, 1 May 2002 17:33:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84CB@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHwxPrIAp0i7LgMQ96E21ee3IsKdwAkig4A From: "Bound, Jim" To: , "Steve Deering" Cc: X-OriginalArrivalTime: 01 May 2002 21:33:58.0723 (UTC) FILETIME=[E73F7930:01C1F157] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g41LY0rP010302 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to second what Itojun says below. We cannot assume multicast for immediate deployment beyond the link. DHCPv6 relays will have to be deployed with hard config as they are in DHCPv4 today. My hope is we do really do Multicast beyond the link with IPv6 but it has not materialized yet even at the bake-offs. So saying use MLD is a non-starter from the base premise I support us doing this quickly if we can and that is Mobile Ipv6 Terminals are being deployed like very soon. As Itojun stated in other mail vendors will be forced to just provide hardcoded addresses or some other such mechanism. The projections for roll-out for IPv6 handheld devices in real production in Europe and Asia is as early as Q1 CY 2003. This is not test bed stuff folks but parts you will be able to buy. If we can't meet this deadline (and I don't think we can based on the strong positions on each side) then the vendors will have to develop a solution pretty soon that at least those who care can agree upon to ship IPv6. More on this anycast issue later. Thats a problem too. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, May 01, 2002 12:00 AM > To: Steve Deering > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Proposed IPv6 DNS Discovery Requirements > > > >(Now that I mention it, perhaps DHCP relays ought also to be replaced > >by the use of a well-known, site-local anycast address.) > > question i have is, can we really depend on > availability of multicast > routing infrastructure in a site. there are lots of > proposals that > assume it, however, implementation status is, i have to > say, rather > poor. > > itoun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 1 14:35:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LZsrP010326; Wed, 1 May 2002 14:35:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41LZsYh010325; Wed, 1 May 2002 14:35:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LZprP010318 for ; Wed, 1 May 2002 14:35:51 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06409 for ; Wed, 1 May 2002 14:35:50 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09141 for ; Wed, 1 May 2002 15:35:49 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 46FF05DD; Wed, 1 May 2002 17:35:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 17:35:48 -0400 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: Proposed IPv6 DNS Discovery Requirements Date: Wed, 1 May 2002 17:35:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84CC@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHw0rsxR4o0Vb47SlKfLZjqOauMqwAhT4bA From: "Bound, Jim" To: "Randy Bush" , Cc: "Rob Austein" , X-OriginalArrivalTime: 01 May 2002 21:35:49.0129 (UTC) FILETIME=[290E1790:01C1F158] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g41LZprP010319 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, > if you want to say "don't use for long-lived sessions," that is at > least honest and breaks nothing. but don't disable the major use > of the function as collateral civilian damage on your moral crusade. I could not parse your response? What does the above mean? Whats your message here? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 14:44:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LicrP010370; Wed, 1 May 2002 14:44:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41LibUF010369; Wed, 1 May 2002 14:44: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.3+Sun/8.12.3) with ESMTP id g41LiYrP010362 for ; Wed, 1 May 2002 14:44:34 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10276 for ; Wed, 1 May 2002 14:44:35 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13945 for ; Wed, 1 May 2002 15:44:33 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id DF2784B9C; Wed, 1 May 2002 17:44:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 17:44:32 -0400 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: 1RE: Proposed IPv6 DNS Discovery Requirements Date: Wed, 1 May 2002 17:44:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84CD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHwxPrIAp0i7LgMQ96E21ee3IsKdwAkig4AAACJ5zA= From: "Bound, Jim" To: "Bound, Jim" , , "Steve Deering" Cc: X-OriginalArrivalTime: 01 May 2002 21:44:32.0750 (UTC) FILETIME=[612850E0:01C1F159] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g41LiZrP010363 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I meant to say Mobile Terminals that Support IPv6. Not Mobile IPv6..... Just to make that clear. Two different things. /jim > -----Original Message----- > From: Bound, Jim > Sent: Wednesday, May 01, 2002 5:34 PM > To: itojun@iijlab.net; Steve Deering > Cc: ipng@sunroof.eng.sun.com > Subject: 1RE: Proposed IPv6 DNS Discovery Requirements > > > I want to second what Itojun says below. We cannot assume > multicast for immediate deployment beyond the link. DHCPv6 > relays will have to be deployed with hard config as they are > in DHCPv4 today. My hope is we do really do Multicast beyond > the link with IPv6 but it has not materialized yet even at > the bake-offs. > > So saying use MLD is a non-starter from the base premise I > support us doing this quickly if we can and that is Mobile > Ipv6 Terminals are being deployed like very soon. As Itojun > stated in other mail vendors will be forced to just provide > hardcoded addresses or some other such mechanism. > > The projections for roll-out for IPv6 handheld devices in > real production in Europe and Asia is as early as Q1 CY 2003. > This is not test bed stuff folks but parts you will be able to buy. > > If we can't meet this deadline (and I don't think we can > based on the strong positions on each side) then the vendors > will have to develop a solution pretty soon that at least > those who care can agree upon to ship IPv6. > > More on this anycast issue later. Thats a problem too. > > /jim > > > -----Original Message----- > > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > > Sent: Wednesday, May 01, 2002 12:00 AM > > To: Steve Deering > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Proposed IPv6 DNS Discovery Requirements > > > > > > >(Now that I mention it, perhaps DHCP relays ought also to > be replaced > > >by the use of a well-known, site-local anycast address.) > > > > question i have is, can we really depend on > > availability of multicast > > routing infrastructure in a site. there are lots of > > proposals that > > assume it, however, implementation status is, i have to > > say, rather > > poor. > > > > itoun > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 14:54:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LsprP010433; Wed, 1 May 2002 14:54:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41Lso8D010432; Wed, 1 May 2002 14: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 stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LsnrP010425 for ; Wed, 1 May 2002 14:54:49 -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 g41LsXaU013320 for ; Wed, 1 May 2002 14:54:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g41LsXmZ013319 for ipng@sunroof.eng.sun.com; Wed, 1 May 2002 14:54:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4135krP008008 for ; Tue, 30 Apr 2002 20:05:46 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22076 for ; Tue, 30 Apr 2002 20:05:49 -0700 (PDT) Received: from ocean.jinmei.org (kame201.kame.net [203.178.141.201]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23718 for ; Tue, 30 Apr 2002 21:05:47 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.11.6/8.11.6) with ESMTP id g4135iT92297; Wed, 1 May 2002 12:05:50 +0900 (JST) (envelope-from jinmei@kame.net) Date: Wed, 01 May 2002 12:05:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Xavier Brouckaert Cc: ipngwg , Luc Beloeil , Olivier Bonaventure Subject: Re: Mobile + Multicast + Scopes (draft-ietf-ipngwg-scoping-arch-03.txt) In-Reply-To: <1020207187.15622.200.camel@Chimay.bugfactory.org> References: <1020207187.15622.200.camel@Chimay.bugfactory.org> 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: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 01 May 2002 00:53:04 +0200, >>>>> Xavier Brouckaert said: > In draft-ietf-ipngwg-scoping-arch-03 Section Mobility, authors say : > "the mobile node MUST NOT try to have a tunnel back into its old zone > for the purposes of attempting such communication". As presented in the Minneapolis meeting, this section will be totally revised in the 04 draft, where we won't have MUST nor MUST NOT in the Mobility section. So, could you just wait for the next version of the draft for now, please? > Is there a way for a mobile node to discover that he has left his > home-site ? AFAIK, Router Advertisements only contain prefixes, but no > information about scopes. Unfortunately, there is no such mechanism, so we need something such as manual configuration to give a hint to the MN. 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 May 1 14:55:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LtjrP010450; Wed, 1 May 2002 14:55:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41LtjGZ010449; Wed, 1 May 2002 14:55:45 -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.3+Sun/8.12.3) with ESMTP id g41LthrP010442 for ; Wed, 1 May 2002 14:55:43 -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 g41LtSaU013332 for ; Wed, 1 May 2002 14:55:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g41LtRiL013331 for ipng@sunroof.eng.sun.com; Wed, 1 May 2002 14:55:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3T8fxrP029967 for ; Mon, 29 Apr 2002 01:41:59 -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 BAA01201 for ; Mon, 29 Apr 2002 01:42:02 -0700 (PDT) Received: from mel.alcatel.fr (mel-o.alcatel.fr [194.133.58.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27193 for ; Mon, 29 Apr 2002 02:42:00 -0600 (MDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g3T8fwa1029299 for ; Mon, 29 Apr 2002 08:41:59 GMT Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA15657 for ; Mon, 29 Apr 2002 10:41:56 +0200 (MET DST) Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA06183 for ; Mon, 29 Apr 2002 10:40:46 +0200 (METDST) Message-ID: <3CCD0683.AB4B5753@nmu.alcatel.fr> Date: Mon, 29 Apr 2002 10:38:27 +0200 From: christophe preguica X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: mandatory RFCs Content-Type: multipart/mixed; boundary="------------4EFE1F97699558D7CF4C0AFF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------4EFE1F97699558D7CF4C0AFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Can somebody tell me what are the RFCs that must be implemented in an IPv6 stack (not Low Cost Network Appliances). Is there a document about the mandatory RFCs ? Is MLD a required feature ? Kind regards. --------------4EFE1F97699558D7CF4C0AFF Content-Type: text/x-vcard; charset=us-ascii; name="christophe.preguica.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for christophe preguica Content-Disposition: attachment; filename="christophe.preguica.vcf" begin:vcard n:; x-mozilla-html:FALSE org:Alcatel;Enabling Software version:2.1 email;internet:christophe.preguica@alcatel.fr title:Christophe Preguiça adr;quoted-printable:;;Route de Nozay=0D=0A91460 Marcoussis;;;;France end:vcard --------------4EFE1F97699558D7CF4C0AFF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 14:56:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41LuTrP010470; Wed, 1 May 2002 14:56:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41LuSe8010469; Wed, 1 May 2002 14:56:28 -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.3+Sun/8.12.3) with ESMTP id g41LuRrP010462 for ; Wed, 1 May 2002 14:56:27 -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 g41LuBaU013342 for ; Wed, 1 May 2002 14:56:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g41LuBTr013341 for ipng@sunroof.eng.sun.com; Wed, 1 May 2002 14:56:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QBZPGs003820 for ; Fri, 26 Apr 2002 04:35: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 EAA18776 for ; Fri, 26 Apr 2002 04:35:26 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA28545 for ; Fri, 26 Apr 2002 05:35:25 -0600 (MDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Apr 2002 11:15:24 +0200 content-class: urn:content-classes:message Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Fri, 26 Apr 2002 11:15:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcHqwpyqT9HEyFatEdazbgCAXxnaMACPeQsg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Ralph Droms" , X-OriginalArrivalTime: 26 Apr 2002 09:15:24.0187 (UTC) FILETIME=[E5A926B0:01C1ED02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3QBZPGs003822 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A few comments again : 1/ I do not really understand what you mean by "2. Hosts obtain DNS configuration with no manual configuration" What is "DNS configuration" ? Do you mean the host must be able to acquire by that mechanism its default domain search path as you can have in resolv.conf file under Unix system ? I would not agree with that, it would be a DNS issue not a network issue. The purpose is only to reach DNS servers without manual configuration on the host. 2/ I feel ill-at-ease with you first requirements "1. Host receives IPv6 address(es) of DNS server(s) available to the host for DNS resolution" Do you mean that a host should maintain a dynamic list of available IPv6 address(es) of DNS servers(s) ? I'm not sure that would be a good idea. 3/ I would have written in the place of your two first requirements: "1. Host can reach any DNS servers available to the host for DNS resolution." Luc -----Message d'origine----- De : Ralph Droms [mailto:rdroms@cisco.com] - Ralph IPv6 DNS Configuration Requirements ------------------------------------ 1. Host receives IPv6 address(es) of DNS server(s) available to the host for DNS resolution 1.a. The list of servers includes only currently available servers 1.b. The host can obtain the addresses of new servers as needed 2. Hosts obtain DNS configuration with no manual configuration -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 14:58:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41Lw5rP010569; Wed, 1 May 2002 14:58:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41Lw4hq010566; Wed, 1 May 2002 14:58:04 -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.3+Sun/8.12.3) with ESMTP id g41Lw0rP010550 for ; Wed, 1 May 2002 14:58:00 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16464 for ; Wed, 1 May 2002 14:58:00 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13636 for ; Wed, 1 May 2002 15:58:00 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E434C3566 for ; Wed, 1 May 2002 17:57:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 17:57:59 -0400 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: Anycast Addresses being used for Nodes not just Routers Date: Wed, 1 May 2002 17:57:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84CF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast Addresses being used for Nodes not just Routers Thread-Index: AcHxWz+b5is5yBzARWyTkYgJLPEvCw== From: "Bound, Jim" To: X-OriginalArrivalTime: 01 May 2002 21:57:59.0777 (UTC) FILETIME=[422EDD10:01C1F15B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g41Lw1rP010555 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What do we think we need to do to get the requirement that only Routers can have anycast addresses changed to "nodes". IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example of the use of anycast for non-router systems that are very important for the Internet and IPv6. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 16:08:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41N8NrP010834; Wed, 1 May 2002 16:08:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41N8N4d010833; Wed, 1 May 2002 16:08: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.3+Sun/8.12.3) with ESMTP id g41N8KrP010826 for ; Wed, 1 May 2002 16:08:20 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16536 for ; Wed, 1 May 2002 16:08:21 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12337 for ; Wed, 1 May 2002 17:08:20 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1B5BE90FA; Wed, 1 May 2002 19:08:20 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 19:07:52 -0400 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: Stateless DNS discovery draft Date: Wed, 1 May 2002 19:07:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B41C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHxUFC7dUIu1D/9QZqjQcbfOjEDBAADx4iw From: "Bound, Jim" To: "Steve Deering" , X-OriginalArrivalTime: 01 May 2002 23:07:52.0612 (UTC) FILETIME=[054EB640:01C1F165] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g41N8KrP010827 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Good analysis but something about it don't sit well. My first response is that Routers are intermediary nodes and require configuration too so have all the properties that come with that flaw. That flaw destroys any hope for the ideal view of stateless, except on the link. I do agree I don't want my Stereo to go to an intermediary to find my speakers with IPv6. But thats a link. Some intermediary had to tell my Stereo where to send a copy of whats playing on my Stereo to my truck CD changer for a copy over 802.11 in the garage, cause in my domain the garage is on a different network Access Point. And my domain required management to be set up the way I personally want it to be set up not the way the canned techno parts came to me via UPS. I too personally want IPv6 to succeed and understand the stateless theme we all agreed to. But I now question what we did here for "communications" to others, not the architecture. Beginning with routers are intermediarys too. Possibly we used stateless to broadly, and now that many are more educated about IPv6 the questions about the context is a valid discussion and part of the evolution of IPv6. Though I wish it were not so and would not hold up parts we need in a rapidly deploying market for IPv6. Regarding the future world of many devices I would argue will require co-habitation of the intermediary processes that are self contained in conjunction with the intermediarys that provide link and network information. The reason is that with the exponential rate of devices IPv6 can provide and the networks, with that will come exponential uses and a complex mesh of attributes that will want to interoperate and work together. That means management, so I see no real way around that problem it will happen when my Stereo wants to talk to my garage appliances. My view of stateless was a reduced reliance on any permanent state information so the network could change from within the edge and the core easily or better than with IPv4 architecture. I believe that is possible and ND proves that for me on the link. To integrate that principle with intermediarys is questionable I think, but if so then we need to agree on what defines an intermediary? The error check for speaker wires is a process that must be executed in the components and that is an intermediary all-be-it one you defined in your mail. I think you discussed it but maybe did not define it? And the answer is yes DHCPv6 can be built as a contained process as the error check between my speakers and the stereo, simply because we used many of the principles inherent in IPv6 as we worked on the protocol. But what it resides in will be an intermediary and even if its a router or hub or server that does routing or a router that does serving its an intermediary. There is always a middle guy can't get around them :---) But my support for stateless back then was not the utopian view (not saying yours was at all either) because it makes (which you did bring out) high availability, failover, and fault-tolerance more possible. But routers fail and if they go down any access past the link is dead. Thats an intermediary problem? Are we to ignore that in this abstraction because its a router? To limit IPv6 evolution to using only routers for edge or core communications is not a wise view IMO, because we cannot assume the market will ever do the right thing from a scientific perspective. Thats why we need WEB caches IMO too. Not that they are a good idea, but because they are simply required to make stuff work. But I do think using phase 1 and phase 2 of the dns-stateless spec is fine and hope we can do that or the vendors will just do it anyway, and as a vendor I support that completely. thanks for the really good write up as always, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 18:11:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g421BnrP010993; Wed, 1 May 2002 18:11:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g421Bn87010992; Wed, 1 May 2002 18:11: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.3+Sun/8.12.3) with ESMTP id g421BkrP010985 for ; Wed, 1 May 2002 18:11: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 SAA24699 for ; Wed, 1 May 2002 18:11:46 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05025 for ; Wed, 1 May 2002 18:11:46 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g421BcpY010216; Wed, 1 May 2002 18:11:41 -0700 (PDT) Received: from [171.71.119.70] (dhcp-171-71-119-70.cisco.com [171.71.119.70]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN86213; Wed, 1 May 2002 18:10:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20020430140404.2AFAE1BFF@thrintun.hactrn.net> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Date: Wed, 1 May 2002 18:12:03 -0700 To: Rob Austein From: Steve Deering Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:04 AM -0400 4/30/02, Rob Austein wrote: >Perhaps this week's version of the proposed solution for this is something >that walks and quacks like an anycast route but is called something else >so that you can use it as a source address. Rob, No, "this week's" version of the proposed solution is to use three well- known, site-local unicast addresses. The difference between a unicast address and an anycast address is that an anycast address is shared by more than one node (or, more accurately, more than one interface), while a unicast address is not. The prohibition against using an anycast address as a source address is due to the fact that multiple components of the IP architecture (v4 or v6) assume that a source address belongs, for a non-negligible length of time, to exactly one node, and those components may break in circumstances where that assumption doesn't hold. This is not a new rule -- it has always been forbidden to use multicast addresses as source addresses, for the same reason that they cannot be trusted to belong to only one node. >I don't really care either way, it's still an anycast route in all >but name. No, it's a host route. Host routes are supported by all IP unicast routing protocols (I think), and have been used for nigh-on 20 years, long before the term anycast was coined. To label all use of host routes as "anycast" is more likely to obfuscate than clarify what's what's going on. At 11:28 PM -0400 4/29/02, Rob Austein wrote: >[*] Or two, or three, or whatever small fixed number of anycast ^^^^^^^ unicast >addresses you choose to allocate, and to date I haven't seen an >explanation of how servers anycast::1, anycast::2, and anycast::3 >are supposed to sort out which one gets which anycast address without >some kind of coordination mechanism that either involves yet another >new protocol or something that quacks like manual configuration. Manual configuration is exactly what is being proposed, at least to start with. Instead of manually configuring a database in an intermediary with the addresses of three DNS servers, you configure the three DNS servers themselves, thus eliminating an unnecessary intermediary. Eventually, it would be nice to fix the DNS service to not insist on using the destination address of a query as the source address of a reply, at which point any of the three addresses could also be an anycast, to lift the arbitrary limit of three DNS servers available for use by plug-and-play clients within a site. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 18:47:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g421lErP011080; Wed, 1 May 2002 18:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g421lEW8011079; Wed, 1 May 2002 18:47: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.3+Sun/8.12.3) with ESMTP id g421lArP011072 for ; Wed, 1 May 2002 18:47:10 -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 SAA22414 for ; Wed, 1 May 2002 18:47:11 -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 SAA06752 for ; Wed, 1 May 2002 18:47:10 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A368A4B22; Thu, 2 May 2002 10:47:06 +0900 (JST) To: "Bound, Jim" Cc: ipng@sunroof.eng.sun.com In-reply-to: Jim.Bound's message of Wed, 01 May 2002 17:57:59 -0400. <9C422444DE99BC46B3AD3C6EAFC9711B020B84CF@tayexc13.americas.cpqcorp.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Anycast Addresses being used for Nodes not just Routers From: itojun@iijlab.net Date: Thu, 02 May 2002 10:47:06 +0900 Message-ID: <1774.1020304026@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What do we think we need to do to get the requirement that only >Routers can have anycast addresses changed to "nodes". see section 3.1 of draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt. - it is easy and possible without any protocol development if you are okay with running routing daemon on anycast hosts. - if not, progress anycast listener discovery document. in this case the issue is time to market (routers have to be upgraded to support it). (it's in IESG queue for more than 6 months, so i-d is marked expired - but i think it okay) 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 May 1 18:48:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g421mvrP011097; Wed, 1 May 2002 18:48:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g421muZp011096; Wed, 1 May 2002 18:48: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.3+Sun/8.12.3) with ESMTP id g421mrrP011089 for ; Wed, 1 May 2002 18:48:53 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22764 for ; Wed, 1 May 2002 18:48:54 -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 TAA11639 for ; Wed, 1 May 2002 19:48:53 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E88474B22; Thu, 2 May 2002 10:48:46 +0900 (JST) To: christophe preguica Cc: ipng@sunroof.eng.sun.com In-reply-to: Christophe.Preguica's message of Mon, 29 Apr 2002 10:38:27 +0200. <3CCD0683.AB4B5753@nmu.alcatel.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mandatory RFCs From: itojun@iijlab.net Date: Thu, 02 May 2002 10:48:46 +0900 Message-ID: <1798.1020304126@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Can somebody tell me what are the RFCs that must be implemented in an >IPv6 stack (not Low Cost Network Appliances). Is there a document about >the mandatory RFCs ? there is an ongoing effort on IPv6 node requirement document. no RFC yet. >Is MLD a required feature ? in my opinion, required if you support multicast-capable medium. 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 May 1 19:10:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422ALrP011135; Wed, 1 May 2002 19:10:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g422ALl4011134; Wed, 1 May 2002 19:10: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.3+Sun/8.12.3) with ESMTP id g422AHrP011127 for ; Wed, 1 May 2002 19:10:17 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07127 for ; Wed, 1 May 2002 19:10:18 -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 UAA04956 for ; Wed, 1 May 2002 20:10:18 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g422AHTZ025655; Wed, 1 May 2002 19:10:17 -0700 (PDT) Received: from [171.71.119.70] (dhcp-171-71-119-70.cisco.com [171.71.119.70]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN87396; Wed, 1 May 2002 19:09:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B41C@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B41C@tayexc13.americas.cpqcorp.net> Date: Wed, 1 May 2002 19:10:39 -0700 To: "Bound, Jim" From: Steve Deering Subject: RE: Stateless DNS discovery draft Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:07 PM -0400 5/1/02, Bound, Jim wrote: >Good analysis but something about it don't sit well. My first response is >that Routers are intermediary nodes and require configuration too so have >all the properties that come with that flaw. Jim, The pedantic answer is no, routers are not necessarily intermediaries according to my definition of that term. Intermediaries are entities or sets of entities that a seeker sends *to* and/or receives *from*, in order to acquire needed info about a target. If those entities are not on the same link as the sender, yes, you need routers to enable that sending and/or receiving, but the routers themselves are not the destination or source of the seeker-intermediary communication (unless a router coincidentally happens to be the home of either seeker or intermediary). The more pragmatic answer is sure, routers are intermediaries. If you are going to allow seekers and targets to be on different links, you necessarily rely on an intermediary of some sort. The goal (for robust plug-and-play) is simply to eliminate *unnecessary* intermediaries, because each intermediary is a source of additional potential failures. For an Internet of more than one link, we obviously need routers to enable communication; the question is whether or not impose a requirement for *more* intermediaries that those. Note also that routers generally run protocols designed to maximize fault tolerance, by allowing arbitrarily redundant topologies, by not having single points-of-failure, and by ensuring that if a physical path exists from A to B, then packets can be (best-efforts) delivered from A to B. That's generally not the case for autoconfiguration servers. >...my domain required management to be set up the way I personally >want it to be set up not the way the canned techno parts came to me >via UPS. Fine, the IPv6 stateful autoconf option is there for those who want to do that. But my neighbor *does* want it to just work out-of- the-UPS-box, and I want IPv6 to be reliably usable by all my neighbors, not just the ones who are geeks. (Well, here in Silicon Valley, it's probably the case that all my neighbors are geeks, but you know what I mean... :-) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 19:25:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422P7rP011157; Wed, 1 May 2002 19:25:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g422P7Xq011156; Wed, 1 May 2002 19:25: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.3+Sun/8.12.3) with ESMTP id g422P4rP011149 for ; Wed, 1 May 2002 19:25: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 TAA29357 for ; Wed, 1 May 2002 19:25:05 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAB19316 for ; Wed, 1 May 2002 19:25:05 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g422P08M001707; Wed, 1 May 2002 19:25:00 -0700 (PDT) Received: from [171.71.119.70] (dhcp-171-71-119-70.cisco.com [171.71.119.70]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN87661; Wed, 1 May 2002 19:23:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B41C@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B41C@tayexc13.americas.cpqcorp.net> Date: Wed, 1 May 2002 19:25:22 -0700 To: "Bound, Jim" From: Steve Deering Subject: RE: Stateless DNS discovery draft Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:07 PM -0400 5/1/02, Bound, Jim wrote: >My first response is that Routers are intermediary nodes and require >configuration too so have all the properties that come with that flaw. One other thing: one of the reasons I've been pushing the multilink subnet idea is to facilitate the development of plug-and-play routers for unmanaged environments (by eliminating the need to configure subnet prefixes on all router interfaces). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 1 19:42:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422g0rP011224; Wed, 1 May 2002 19:42:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g422g0Pg011223; Wed, 1 May 2002 19:42:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422fvrP011216 for ; Wed, 1 May 2002 19:41:57 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03361 for ; Wed, 1 May 2002 19:41:58 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28155 for ; Wed, 1 May 2002 20:41:58 -0600 (MDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g422d8Ta005709; Wed, 1 May 2002 19:39:08 -0700 (PDT) Date: Wed, 1 May 2002 22:39:07 -0400 (EDT) From: Ralph Droms To: itojun@iijlab.net cc: "Bound, Jim" , Subject: Re: Anycast Addresses being used for Nodes not just Routers In-Reply-To: <1774.1020304026@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Which ID do you mean by "anycast listener discovery" document? draft-vida-mld-v2-02.txt? - Ralph On Thu, 2 May 2002 itojun@iijlab.net wrote: > >What do we think we need to do to get the requirement that only > >Routers can have anycast addresses changed to "nodes". > > see section 3.1 of draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt. > - it is easy and possible without any protocol development if you are > okay with running routing daemon on anycast hosts. > - if not, progress anycast listener discovery document. in this case > the issue is time to market (routers have to be upgraded to > support it). > > (it's in IESG queue for more than 6 months, so i-d is marked expired - > but i think it okay) > > 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 May 1 19:55:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422tlrP011248; Wed, 1 May 2002 19:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g422tlak011247; Wed, 1 May 2002 19: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422thrP011240 for ; Wed, 1 May 2002 19:55:43 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08445 for ; Wed, 1 May 2002 19:55:44 -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 UAA01609 for ; Wed, 1 May 2002 20:55:44 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 937094B23; Thu, 2 May 2002 11:55:40 +0900 (JST) To: Ralph Droms Cc: ipng@sunroof.eng.sun.com In-reply-to: rdroms's message of Wed, 01 May 2002 22:39:07 -0400. 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: Anycast Addresses being used for Nodes not just Routers From: itojun@iijlab.net Date: Thu, 02 May 2002 11:55:40 +0900 Message-ID: <2320.1020308140@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Which ID do you mean by "anycast listener discovery" document? >draft-vida-mld-v2-02.txt? in my mind, it was haberman-ipngwg-host-anycast-00.txt. 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 May 1 23:27:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g426RhrP011536; Wed, 1 May 2002 23:27:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g426RhGK011535; Wed, 1 May 2002 23:27: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.3+Sun/8.12.3) with ESMTP id g426RerP011528 for ; Wed, 1 May 2002 23:27:40 -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 XAA12909 for ; Wed, 1 May 2002 23:27:42 -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 XAA01411 for ; Wed, 1 May 2002 23:27:41 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g426RYN11941; Thu, 2 May 2002 09:27:34 +0300 Date: Thu, 2 May 2002 09:27:33 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: ipng@sunroof.eng.sun.com Subject: Re: Anycast Addresses being used for Nodes not just Routers In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B84CF@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 1 May 2002, Bound, Jim wrote: > What do we think we need to do to get the requirement that only Routers > can have anycast addresses changed to "nodes". > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example of the use of > anycast for non-router systems that are very important for the Internet > and IPv6. I've been trying to push the changing of this: o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. in addr-arch-v3-07 to change 'must' to a 'should' for some time now, with not much progress. I think this is one item that should be changed before addr-arch is done with in the IESG and locked for a few years. -- 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 May 1 23:36:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g426abrP011568; Wed, 1 May 2002 23:36:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g426abG7011567; Wed, 1 May 2002 23:36: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.3+Sun/8.12.3) with ESMTP id g426aYrP011560 for ; Wed, 1 May 2002 23:36: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 XAA14320 for ; Wed, 1 May 2002 23:36:34 -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 AAA04357 for ; Thu, 2 May 2002 00:36:33 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g426aQB12006; Thu, 2 May 2002 09:36:27 +0300 Date: Thu, 2 May 2002 09:36:26 +0300 (EEST) From: Pekka Savola To: James Kempf cc: ipng@sunroof.eng.sun.com, , Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt In-Reply-To: <007601c1f129$c10ad3f0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 1 May 2002, James Kempf wrote: > The previous paragraph states what a fast RA is namely: > > An RA that is immediately > unicast to the sender rather than delayed > is known as a "fast RA". > > As to what it means for a router to be configured to provide fast RAs, > it means that the router disposes of RSs as described. I guess we could > make that a little clearer. My main concern here was how this will work on a router which supports fast RA's, but does not necessarily turn it on, at least on all of its interfaces. Some interfaces (or even a subset of nodes attached to an interface) might require fast RA's, some not. > > A router SHOULD choose to unicast the response directly to the > > soliciting host's address (if the solicitation's source address > > is not the unspecified address), otherwise the router MUST schedule > > a multicast Router Advertisement in accordance with RFC 2461. > > > > ==> Clarification: if the router would not schedule an RA by RFC 2461 > > (e.g. skip the scheduling to prevent DoS) > > > > I don't understand the problem. Are you concerned that the router will > be bombarded by RSs with the unspecified address? RFC 2461 contains > explicit instructions about the timing of multicast RAs, so I don't see > what the threat is. My main concern was the wording. Let's take an example not related to RFC 2461 to illustrate this: Base spec says: - if conditions X, Y, and Z are met, schedule an event Advanced spec says: - schedule an event This is IMO not 100% specific whether advanced spec should also check for conditions X, Y, and Z. Perhaps this clarifies what I was trying to say. > > ==> Using unicast was a MAY. I think there should be some discussion > why > > this should be changed. > > > > I suppose we could make it a MAY, but this draft is in the context of an > enhancement to RFC 2461 and is, itself, a MAY. > Within the context of this draft, it seems as if SHOULD should work, > since it will remain MAY in the context of RFC 2461. Ok. But still, some brief discussion why replying using unicast was chosen would to be more preferred might be useful. > > When the multicast RA has been sent, FastRACounter > > MUST be reset to zero and processing for fast RAs recommences. > > > > [and] > > > > 4.0 Security Considerations > > > > This draft specifies a minor modification to RFC 2461. There are no > > considerations for this draft. > > > > ==> please have a look at: > > > > http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-05.txt > > > > At the very least, 100 Fast RA's per multicast unsolicited interval, > > the minimum decreased by MIPv6 to 0.05 seconds: potentially about > 2,000 > > RA's from a router a second. Potential DoS? > > > > I'll check the reference, but I'm not sure I understand your point. An > attacker can only force the router to send out up to FastRACounter > unicast RAs before it rolls over to a multicast. We could increase the > recommended default. We could add some adaptive logic which requires the > router to continue using multicast for some period of time before > rolling back to unicast, to limit the scope of a DoS attack. Since there > is currently no security on ND, there is no way to check whether a host > sending an RS is authorized to use the link. We should probably mention > this in the Security Considerations section in any case. It seemed to me that a node could get a router to send 100/0.05 == 2000 RA's (with default settings) per second, but I may be missing something. In any case, my main problem was not with a huge fear of DoS, but that Security Considerations section was hand-waved away. -- 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 May 2 07:00:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42E0hrP013021; Thu, 2 May 2002 07:00:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42E0hRN013020; Thu, 2 May 2002 07:00: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.3+Sun/8.12.3) with ESMTP id g42E0drP013013 for ; Thu, 2 May 2002 07:00:39 -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 HAA08117 for ; Thu, 2 May 2002 07:00:40 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09814 for ; Thu, 2 May 2002 07:00:39 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D540938D0; Thu, 2 May 2002 10:00:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 10:00:38 -0400 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: Anycast Addresses being used for Nodes not just Routers Date: Thu, 2 May 2002 10:00:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EB@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast Addresses being used for Nodes not just Routers Thread-Index: AcHxe0rblqbqS5WKTmWxDXv7IgKMdwAZjMIw From: "Bound, Jim" To: Cc: X-OriginalArrivalTime: 02 May 2002 14:00:38.0722 (UTC) FILETIME=[BD327220:01C1F1E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42E0erP013014 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am ok with this and agree your text addresses it. compaq servers ship standard with routing daemons for many reasons (e.g. clusters, gateways, proprietary stuff). this is a no brainer for hosts. we should revive your draft and push it harder with the working group again. I know its a pain. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, May 01, 2002 9:47 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Anycast Addresses being used for Nodes not just Routers > > > >What do we think we need to do to get the requirement that only > >Routers can have anycast addresses changed to "nodes". > > see section 3.1 of > draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt. > - it is easy and possible without any protocol > development if you are > okay with running routing daemon on anycast hosts. > - if not, progress anycast listener discovery document. > in this case > the issue is time to market (routers have to be upgraded to > support it). > > (it's in IESG queue for more than 6 months, so i-d is > marked expired - > but i think it okay) > > 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 May 2 07:05:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42E5GrP013101; Thu, 2 May 2002 07:05:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42E5GYK013100; Thu, 2 May 2002 07:05: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.3+Sun/8.12.3) with ESMTP id g42E5CrP013093 for ; Thu, 2 May 2002 07:05:12 -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 HAA25456 for ; Thu, 2 May 2002 07:05:13 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12851 for ; Thu, 2 May 2002 07:05:12 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 446339378; Thu, 2 May 2002 10:05:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 10:05:11 -0400 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: Stateless DNS discovery draft Date: Thu, 2 May 2002 10:05:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EC@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHxfoL7mczGcSquSfyZu0IUa05bNwAY2tQw From: "Bound, Jim" To: "Steve Deering" Cc: X-OriginalArrivalTime: 02 May 2002 14:05:11.0033 (UTC) FILETIME=[5F81CE90:01C1F1E2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42E5DrP013094 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, As usual we agree at the bottom line. Good point about the routers not really being src/dst deliberate usually too. I missed that when typing. But as chair I want to say we should ship this spec with the unicast approach as Bob and others have stated. I know of 3 vendors now that are going to ship small devices late 2002 and for sure early 2003 and we need this problem fixed. OK I will admit I am one of those vendors too so I am biased. thanks and again great write up, /jim > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday, May 01, 2002 10:11 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Stateless DNS discovery draft > > > At 7:07 PM -0400 5/1/02, Bound, Jim wrote: > >Good analysis but something about it don't sit well. My > first response is > >that Routers are intermediary nodes and require > configuration too so have > >all the properties that come with that flaw. > > Jim, > > The pedantic answer is no, routers are not necessarily intermediaries > according to my definition of that term. Intermediaries are entities > or sets of entities that a seeker sends *to* and/or receives *from*, > in order to acquire needed info about a target. If those entities are > not on the same link as the sender, yes, you need routers to enable > that sending and/or receiving, but the routers themselves are not the > destination or source of the seeker-intermediary communication (unless > a router coincidentally happens to be the home of either seeker or > intermediary). > > The more pragmatic answer is sure, routers are intermediaries. If you > are going to allow seekers and targets to be on different links, you > necessarily rely on an intermediary of some sort. The goal (for > robust plug-and-play) is simply to eliminate *unnecessary* > intermediaries, because each intermediary is a source of additional > potential failures. For an Internet of more than one link, we > obviously need routers to enable communication; the question is > whether or not impose a requirement for *more* intermediaries that > those. > > Note also that routers generally run protocols designed to maximize > fault tolerance, by allowing arbitrarily redundant topologies, by > not having single points-of-failure, and by ensuring that if > a physical > path exists from A to B, then packets can be (best-efforts) delivered > from A to B. That's generally not the case for autoconfiguration > servers. > > >...my domain required management to be set up the way I personally > >want it to be set up not the way the canned techno parts came to me > >via UPS. > > Fine, the IPv6 stateful autoconf option is there for those who want > to do that. But my neighbor *does* want it to just work out-of- > the-UPS-box, and I want IPv6 to be reliably usable by all my > neighbors, > not just the ones who are geeks. (Well, here in Silicon Valley, it's > probably the case that all my neighbors are geeks, but you know what > I mean... :-) > > Steve > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 07:05:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42E5lrP013118; Thu, 2 May 2002 07:05:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42E5lrG013117; Thu, 2 May 2002 07:05: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.3+Sun/8.12.3) with ESMTP id g42E5hrP013110 for ; Thu, 2 May 2002 07:05:44 -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 HAA25699 for ; Thu, 2 May 2002 07:05:44 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20847 for ; Thu, 2 May 2002 08:05:45 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2B17A8BC1; Thu, 2 May 2002 10:05:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 10:05:42 -0400 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: Stateless DNS discovery draft Date: Thu, 2 May 2002 10:05:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84ED@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHxgJNAKO8wyPXRTRmFTi85t8SYBAAYdZZQ From: "Bound, Jim" To: "Steve Deering" Cc: X-OriginalArrivalTime: 02 May 2002 14:05:42.0987 (UTC) FILETIME=[728D99B0:01C1F1E2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42E5irP013111 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk yes that would be good thing for sure. /jim > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday, May 01, 2002 10:25 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Stateless DNS discovery draft > > > At 7:07 PM -0400 5/1/02, Bound, Jim wrote: > >My first response is that Routers are intermediary nodes and require > >configuration too so have all the properties that come with > that flaw. > > One other thing: one of the reasons I've been pushing the multilink > subnet idea is to facilitate the development of plug-and-play routers > for unmanaged environments (by eliminating the need to configure > subnet prefixes on all router interfaces). > > Steve > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 07:15:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42EFGrP013149; Thu, 2 May 2002 07:15:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42EFGYP013148; Thu, 2 May 2002 07:15: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.3+Sun/8.12.3) with ESMTP id g42EFDrP013141 for ; Thu, 2 May 2002 07:15:13 -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 HAA20161 for ; Thu, 2 May 2002 07:15:13 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02204 for ; Thu, 2 May 2002 08:15:13 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0926239A1; Thu, 2 May 2002 10:15:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 10:15:11 -0400 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: Anycast Addresses being used for Nodes not just Routers Date: Thu, 2 May 2002 10:15:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast Addresses being used for Nodes not just Routers Thread-Index: AcHxonaz0757SJg+SRG7JujC4kQVXwAQTP7w From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 02 May 2002 14:15:11.0919 (UTC) FILETIME=[C5A9BBF0:01C1F1E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42EFDrP013142 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. Lets begin to work on getting a SHOULD that would fix it completely. I will follow your lead in the WG so lets do it ............ /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, May 02, 2002 2:28 AM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Anycast Addresses being used for Nodes not just Routers > > > On Wed, 1 May 2002, Bound, Jim wrote: > > What do we think we need to do to get the requirement that > only Routers > > can have anycast addresses changed to "nodes". > > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example > of the use of > > anycast for non-router systems that are very important for > the Internet > > and IPv6. > > I've been trying to push the changing of this: > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. > > in addr-arch-v3-07 to change 'must' to a 'should' for some > time now, with > not much progress. > > I think this is one item that should be changed before > addr-arch is done > with in the IESG and locked for a few years. > > -- > 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 May 2 07:17:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42EHKrP013166; Thu, 2 May 2002 07:17:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42EHJqf013165; Thu, 2 May 2002 07: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.3+Sun/8.12.3) with ESMTP id g42EHGrP013158 for ; Thu, 2 May 2002 07:17:16 -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 HAA28481 for ; Thu, 2 May 2002 07:17:16 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28109 for ; Thu, 2 May 2002 08:17:08 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 78CA03AB5; Thu, 2 May 2002 10:16:35 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 10:16:35 -0400 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: Stateless DNS discovery draft Date: Thu, 2 May 2002 10:16:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHxfoL7mczGcSquSfyZu0IUa05bNwAY2tQwAAB8TJA= From: "Bound, Jim" To: "Bound, Jim" , "Steve Deering" Cc: X-OriginalArrivalTime: 02 May 2002 14:16:35.0372 (UTC) FILETIME=[F767A6C0:01C1F1E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42EHHrP013159 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk that meant YOu as chair I am saying.........just in case my words were misinterreprted as I am busy today sorry. /jim > -----Original Message----- > From: Bound, Jim > Sent: Thursday, May 02, 2002 10:05 AM > To: Steve Deering > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Stateless DNS discovery draft > > > Hi Steve, > > As usual we agree at the bottom line. Good point about the > routers not really being src/dst deliberate usually too. I > missed that when typing. > > But as chair I want to say we should ship this spec with the > unicast approach as Bob and others have stated. I know of 3 > vendors now that are going to ship small devices late 2002 > and for sure early 2003 and we need this problem fixed. > > OK I will admit I am one of those vendors too so I am biased. > > thanks and again great write up, > /jim > > > -----Original Message----- > > From: Steve Deering [mailto:deering@cisco.com] > > Sent: Wednesday, May 01, 2002 10:11 PM > > To: Bound, Jim > > Cc: ipng@sunroof.eng.sun.com > > Subject: RE: Stateless DNS discovery draft > > > > > > At 7:07 PM -0400 5/1/02, Bound, Jim wrote: > > >Good analysis but something about it don't sit well. My > > first response is > > >that Routers are intermediary nodes and require > > configuration too so have > > >all the properties that come with that flaw. > > > > Jim, > > > > The pedantic answer is no, routers are not necessarily > intermediaries > > according to my definition of that term. Intermediaries > are entities > > or sets of entities that a seeker sends *to* and/or receives *from*, > > in order to acquire needed info about a target. If those > entities are > > not on the same link as the sender, yes, you need routers to enable > > that sending and/or receiving, but the routers themselves > are not the > > destination or source of the seeker-intermediary > communication (unless > > a router coincidentally happens to be the home of either seeker or > > intermediary). > > > > The more pragmatic answer is sure, routers are > intermediaries. If you > > are going to allow seekers and targets to be on different links, you > > necessarily rely on an intermediary of some sort. The goal (for > > robust plug-and-play) is simply to eliminate *unnecessary* > > intermediaries, because each intermediary is a source of additional > > potential failures. For an Internet of more than one link, we > > obviously need routers to enable communication; the question is > > whether or not impose a requirement for *more* intermediaries that > > those. > > > > Note also that routers generally run protocols designed to maximize > > fault tolerance, by allowing arbitrarily redundant topologies, by > > not having single points-of-failure, and by ensuring that if > > a physical > > path exists from A to B, then packets can be (best-efforts) > delivered > > from A to B. That's generally not the case for autoconfiguration > > servers. > > > > >...my domain required management to be set up the way I personally > > >want it to be set up not the way the canned techno parts came to me > > >via UPS. > > > > Fine, the IPv6 stateful autoconf option is there for those who want > > to do that. But my neighbor *does* want it to just work out-of- > > the-UPS-box, and I want IPv6 to be reliably usable by all my > > neighbors, > > not just the ones who are geeks. (Well, here in Silicon > Valley, it's > > probably the case that all my neighbors are geeks, but you know what > > I mean... :-) > > > > Steve > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 2 08:44:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42FisrP013379; Thu, 2 May 2002 08:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42FisWe013378; Thu, 2 May 2002 08:44: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.3+Sun/8.12.3) with ESMTP id g42FiprP013368 for ; Thu, 2 May 2002 08:44:51 -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 IAA23094 for ; Thu, 2 May 2002 08:44:52 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11808 for ; Thu, 2 May 2002 08:44:52 -0700 (PDT) Message-ID: <004701c1f1f0$0f2347e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" Cc: , , References: Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt Date: Thu, 2 May 2002 08:43:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk PekkaS, OK, I think I understand your comments now. We can incorporate them into the draft. Thanx. jak ----- Original Message ----- From: "Pekka Savola" To: "James Kempf" Cc: ; ; Sent: Wednesday, May 01, 2002 11:36 PM Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt > On Wed, 1 May 2002, James Kempf wrote: > > The previous paragraph states what a fast RA is namely: > > > > An RA that is immediately > > unicast to the sender rather than delayed > > is known as a "fast RA". > > > > As to what it means for a router to be configured to provide fast RAs, > > it means that the router disposes of RSs as described. I guess we could > > make that a little clearer. > > My main concern here was how this will work on a router which supports > fast RA's, but does not necessarily turn it on, at least on all of its > interfaces. Some interfaces (or even a subset of nodes attached to an > interface) might require fast RA's, some not. > > > > A router SHOULD choose to unicast the response directly to the > > > soliciting host's address (if the solicitation's source address > > > is not the unspecified address), otherwise the router MUST schedule > > > a multicast Router Advertisement in accordance with RFC 2461. > > > > > > ==> Clarification: if the router would not schedule an RA by RFC 2461 > > > (e.g. skip the scheduling to prevent DoS) > > > > > > > I don't understand the problem. Are you concerned that the router will > > be bombarded by RSs with the unspecified address? RFC 2461 contains > > explicit instructions about the timing of multicast RAs, so I don't see > > what the threat is. > > My main concern was the wording. Let's take an example not related to RFC > 2461 to illustrate this: > > Base spec says: > > - if conditions X, Y, and Z are met, schedule an event > > Advanced spec says: > > - schedule an event > > This is IMO not 100% specific whether advanced spec should also check for > conditions X, Y, and Z. > > Perhaps this clarifies what I was trying to say. > > > > ==> Using unicast was a MAY. I think there should be some discussion > > why > > > this should be changed. > > > > > > > I suppose we could make it a MAY, but this draft is in the context of an > > enhancement to RFC 2461 and is, itself, a MAY. > > Within the context of this draft, it seems as if SHOULD should work, > > since it will remain MAY in the context of RFC 2461. > > Ok. > > But still, some brief discussion why replying using unicast was chosen > would to be more preferred might be useful. > > > > When the multicast RA has been sent, FastRACounter > > > MUST be reset to zero and processing for fast RAs recommences. > > > > > > [and] > > > > > > 4.0 Security Considerations > > > > > > This draft specifies a minor modification to RFC 2461. There are no > > > considerations for this draft. > > > > > > ==> please have a look at: > > > > > > http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-05.txt > > > > > > At the very least, 100 Fast RA's per multicast unsolicited interval, > > > the minimum decreased by MIPv6 to 0.05 seconds: potentially about > > 2,000 > > > RA's from a router a second. Potential DoS? > > > > > > > I'll check the reference, but I'm not sure I understand your point. An > > attacker can only force the router to send out up to FastRACounter > > unicast RAs before it rolls over to a multicast. We could increase the > > recommended default. We could add some adaptive logic which requires the > > router to continue using multicast for some period of time before > > rolling back to unicast, to limit the scope of a DoS attack. Since there > > is currently no security on ND, there is no way to check whether a host > > sending an RS is authorized to use the link. We should probably mention > > this in the Security Considerations section in any case. > > It seemed to me that a node could get a router to send 100/0.05 == 2000 > RA's (with default settings) per second, but I may be missing something. > > In any case, my main problem was not with a huge fear of DoS, but that > Security Considerations section was hand-waved away. > > -- > 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 May 2 09:33:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42GXArP013515; Thu, 2 May 2002 09:33:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42GXARI013514; Thu, 2 May 2002 09:33: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.3+Sun/8.12.3) with ESMTP id g42GX7rP013507 for ; Thu, 2 May 2002 09:33: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 JAA24359 for ; Thu, 2 May 2002 09:33:09 -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 KAA22569 for ; Thu, 2 May 2002 10:33:08 -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 JAA01600 for ; Thu, 2 May 2002 09:33:08 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g42GX7l16492 for ; Thu, 2 May 2002 09:33:07 -0700 X-mProtect: <200205021633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdW68fcI; Thu, 02 May 2002 09:33:05 PDT Message-ID: <3CD16A41.98C3E4F4@iprg.nokia.com> Date: Thu, 02 May 2002 09:33:05 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EE@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, I think this is a great idea. Furthermore, on the topic of letting packets have Source IP address be the address of an anycast group, I think that it's the responsibility of the particular anycast group to handle all the ramifications. It would be nice to have an Internet Draft that lays out all of the canonical ramifications. In the case where there is only one element of an anycast group, and it has one of the "well-known" anycast numbers on its subnet, this seems to be very natural and beneficial. There would not be a need to make the restriction for short session lifetimes. If the anycast group can have several members, but still is addressable at one of the "well-known" anycast numbers, then we can require a standard specification for the operation of the anycast group, including any such features as use of the anycast address as a Source IP value. Similar considerations hold for security, and even mobility of the anycast group. In fact, with enough calculation, we might even be able to find some CGA-able anycast groups within some lucky subnets! Regards, Charlie P. "Bound, Jim" wrote: > > I agree. Lets begin to work on getting a SHOULD that would fix it completely. > > I will follow your lead in the WG so lets do it ............ > > /jim > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, May 02, 2002 2:28 AM > > To: Bound, Jim > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Anycast Addresses being used for Nodes not just Routers > > > > > > On Wed, 1 May 2002, Bound, Jim wrote: > > > What do we think we need to do to get the requirement that > > only Routers > > > can have anycast addresses changed to "nodes". > > > > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example > > of the use of > > > anycast for non-router systems that are very important for > > the Internet > > > and IPv6. > > > > I've been trying to push the changing of this: > > > > o An anycast address must not be assigned to an IPv6 host, that > > is, it may be assigned to an IPv6 router only. > > > > in addr-arch-v3-07 to change 'must' to a 'should' for some > > time now, with > > not much progress. > > > > I think this is one item that should be changed before > > addr-arch is done > > with in the IESG and locked for a few years. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 12:05:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J5crP014085; Thu, 2 May 2002 12:05:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42J5ccU014084; Thu, 2 May 2002 12:05: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.3+Sun/8.12.3) with ESMTP id g42J5ZrP014074 for ; Thu, 2 May 2002 12:05: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 MAA14372 for ; Thu, 2 May 2002 12:05:36 -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 NAA05709 for ; Thu, 2 May 2002 13:05:30 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 2 May 2002 15:05:29 -0400 Message-ID: <3CD18D41.108CEBAD@nc.rr.com> Date: Thu, 02 May 2002 15:02:26 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EE@tayexc13.americas.cpqcorp.net> <3CD16A41.98C3E4F4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, I had actually started taking a crack at this whole problem. It seems to me that the following components are needed for some form of global anycast support: 1. Host-to-router notification protocol (this is taken care of by changes to mld proposed in draft-haberman-ipngwg-host-anycast) 2. Security: at a minimum some form of authentication to allow routers to determine if hosts are allowed to join an anycast group 3. An Anycast Architecture doc that pulls all the pieces together and concretely describes how pieces interact, the pros and cons of anycast usage for intra-domain and inter-domain 4. Possibly a draft that documents any impacts on any existing protocols (routing protocols, TCP, etc.) Now, I have not spent time on the subject in the last 4-5 months, so I have not gotten much past this list. It is crucial that most of the issues raised by Itojun's anycast analysis draft be addressed. It should also be noted that this is probably way too much work to do in the IPv6 WG. Regards, Brian "Charles E. Perkins" wrote: > > Hello folks, > > I think this is a great idea. > > Furthermore, on the topic of letting packets have Source IP > address be the address of an anycast group, I think that it's > the responsibility of the particular anycast group to handle > all the ramifications. It would be nice to have an Internet > Draft that lays out all of the canonical ramifications. > > In the case where there is only one element of an anycast group, > and it has one of the "well-known" anycast numbers on its subnet, > this seems to be very natural and beneficial. There would not > be a need to make the restriction for short session lifetimes. > > If the anycast group can have several members, but still is > addressable at one of the "well-known" anycast numbers, then > we can require a standard specification for the operation > of the anycast group, including any such features as use of > the anycast address as a Source IP value. > > Similar considerations hold for security, and even mobility > of the anycast group. In fact, with enough calculation, we > might even be able to find some CGA-able anycast groups within > some lucky subnets! > > Regards, > Charlie P. > > "Bound, Jim" wrote: > > > > I agree. Lets begin to work on getting a SHOULD that would fix it completely. > > > > I will follow your lead in the WG so lets do it ............ > > > > /jim > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Thursday, May 02, 2002 2:28 AM > > > To: Bound, Jim > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: Re: Anycast Addresses being used for Nodes not just Routers > > > > > > > > > On Wed, 1 May 2002, Bound, Jim wrote: > > > > What do we think we need to do to get the requirement that > > > only Routers > > > > can have anycast addresses changed to "nodes". > > > > > > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example > > > of the use of > > > > anycast for non-router systems that are very important for > > > the Internet > > > > and IPv6. > > > > > > I've been trying to push the changing of this: > > > > > > o An anycast address must not be assigned to an IPv6 host, that > > > is, it may be assigned to an IPv6 router only. > > > > > > in addr-arch-v3-07 to change 'must' to a 'should' for some > > > time now, with > > > not much progress. > > > > > > I think this is one item that should be changed before > > > addr-arch is done > > > with in the IESG and locked for a few years. > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 12:09:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J9irP014140; Thu, 2 May 2002 12:09:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42J9irq014139; Thu, 2 May 2002 12: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J9frP014132 for ; Thu, 2 May 2002 12:09:41 -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 MAA15915 for ; Thu, 2 May 2002 12:09:42 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19764 for ; Thu, 2 May 2002 12:09:42 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D90AE37E7; Thu, 2 May 2002 15:09:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 15:09:41 -0400 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: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address Date: Thu, 2 May 2002 15:09:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8506@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address Thread-Index: AcHx90upEOeIJO6qSnymCz651KE7VQAFT9uQ From: "Bound, Jim" To: "Charles E. Perkins" , "IPng Working Group" X-OriginalArrivalTime: 02 May 2002 19:09:41.0666 (UTC) FILETIME=[E9A72820:01C1F20C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g42J9frP014133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, Not sure if we have disconnect. What I am supporting with Pekka is removing the MUST per Pekka's mail below. I want anycast dst addresses to be more than just routers. I do not support using anycast address as IP src address at all at this time. Just be clear. regards, /jim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, May 02, 2002 12:33 PM > To: IPng Working Group > Subject: Re: Anycast Addresses being used for Nodes not just Routers; > anycast as Source IP address > > > > Hello folks, > > I think this is a great idea. > > Furthermore, on the topic of letting packets have Source IP > address be the address of an anycast group, I think that it's > the responsibility of the particular anycast group to handle > all the ramifications. It would be nice to have an Internet > Draft that lays out all of the canonical ramifications. > > In the case where there is only one element of an anycast group, > and it has one of the "well-known" anycast numbers on its subnet, > this seems to be very natural and beneficial. There would not > be a need to make the restriction for short session lifetimes. > > If the anycast group can have several members, but still is > addressable at one of the "well-known" anycast numbers, then > we can require a standard specification for the operation > of the anycast group, including any such features as use of > the anycast address as a Source IP value. > > Similar considerations hold for security, and even mobility > of the anycast group. In fact, with enough calculation, we > might even be able to find some CGA-able anycast groups within > some lucky subnets! > > Regards, > Charlie P. > > > "Bound, Jim" wrote: > > > > I agree. Lets begin to work on getting a SHOULD that would > fix it completely. > > > > I will follow your lead in the WG so lets do it ............ > > > > /jim > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Thursday, May 02, 2002 2:28 AM > > > To: Bound, Jim > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: Re: Anycast Addresses being used for Nodes not > just Routers > > > > > > > > > On Wed, 1 May 2002, Bound, Jim wrote: > > > > What do we think we need to do to get the requirement that > > > only Routers > > > > can have anycast addresses changed to "nodes". > > > > > > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example > > > of the use of > > > > anycast for non-router systems that are very important for > > > the Internet > > > > and IPv6. > > > > > > I've been trying to push the changing of this: > > > > > > o An anycast address must not be assigned to an > IPv6 host, that > > > is, it may be assigned to an IPv6 router only. > > > > > > in addr-arch-v3-07 to change 'must' to a 'should' for some > > > time now, with > > > not much progress. > > > > > > I think this is one item that should be changed before > > > addr-arch is done > > > with in the IESG and locked for a few years. > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 12:26:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42JQCrP014212; Thu, 2 May 2002 12:26:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42JQCKG014211; Thu, 2 May 2002 12:26: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.3+Sun/8.12.3) with ESMTP id g42JQ9rP014204 for ; Thu, 2 May 2002 12:26:09 -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 MAA06652 for ; Thu, 2 May 2002 12:26:10 -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 NAA15225 for ; Thu, 2 May 2002 13:26:10 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA12275; Thu, 2 May 2002 12:26:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g42JQ9q24069; Thu, 2 May 2002 12:26:09 -0700 X-mProtect: <200205021926> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCiLAsI; Thu, 02 May 2002 12:26:07 PDT Message-ID: <3CD192CF.8CEFE0E6@iprg.nokia.com> Date: Thu, 02 May 2002 12:26:07 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haberman CC: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EE@tayexc13.americas.cpqcorp.net> <3CD16A41.98C3E4F4@iprg.nokia.com> <3CD18D41.108CEBAD@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian, Your points are very well taken. My main suggestion for the immediate term was to relax some restrictions on well-known anycast addresses located in their subnets. It is really easier if there's just one host, too. The other things will take more work. >From that context, I'll just add a few more comments inline: Brian Haberman wrote: > 1. Host-to-router notification protocol (this is taken care of by > changes to mld proposed in draft-haberman-ipngwg-host-anycast) What happens if you have a host on a link responding to an anycast address on that link? Then other hosts on that link won't be able to easily discern whether the router "liked" the anycast addressable host or not. I can imagine some very nasty ways to avoid even this scenario, but I can't believe we'd really want to enforce them. > 2. Security: at a minimum some form of authentication to allow > routers to determine if hosts are allowed to join an anycast > group Similar comment to the on-link case for (1). Furthermore, the security requirements for an anycast group depend on the nature of the anycast group, don't they? It might typically be quite unimportant to securely restrict participation in an anycast group geared towards local broadcast of streaming audio of classical guitar music, or a webcam of the cows in the pasture. > 3. An Anycast Architecture doc that pulls all the pieces together > and concretely describes how pieces interact, the pros and cons > of anycast usage for intra-domain and inter-domain Right! But the latter is often true for any service. The anycast nature of the addressability of inter-domain isn't appreciably harder, otherwise, than handling anycast groups in general, is it? > 4. Possibly a draft that documents any impacts on any existing > protocols (routing protocols, TCP, etc.) This would be very important. > It should also be noted that this is probably way too much work to do > in the IPv6 WG. It's way too much work for me too :-) I'm not really suggesting that the general case be made completely open prior to this work getting done. I was more suggesting that there are useful special cases that do not present any appreciable downside. Regards, Charlie P. > "Charles E. Perkins" wrote: > > > > Hello folks, > > > > I think this is a great idea. > > > > Furthermore, on the topic of letting packets have Source IP > > address be the address of an anycast group, I think that it's > > the responsibility of the particular anycast group to handle > > all the ramifications. It would be nice to have an Internet > > Draft that lays out all of the canonical ramifications. > > > > In the case where there is only one element of an anycast group, > > and it has one of the "well-known" anycast numbers on its subnet, > > this seems to be very natural and beneficial. There would not > > be a need to make the restriction for short session lifetimes. > > > > If the anycast group can have several members, but still is > > addressable at one of the "well-known" anycast numbers, then > > we can require a standard specification for the operation > > of the anycast group, including any such features as use of > > the anycast address as a Source IP value. > > > > Similar considerations hold for security, and even mobility > > of the anycast group. In fact, with enough calculation, we > > might even be able to find some CGA-able anycast groups within > > some lucky subnets! > > > > Regards, > > Charlie P. > > > > "Bound, Jim" wrote: > > > > > > I agree. Lets begin to work on getting a SHOULD that would fix it completely. > > > > > > I will follow your lead in the WG so lets do it ............ > > > > > > /jim > > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: Thursday, May 02, 2002 2:28 AM > > > > To: Bound, Jim > > > > Cc: ipng@sunroof.eng.sun.com > > > > Subject: Re: Anycast Addresses being used for Nodes not just Routers > > > > > > > > > > > > On Wed, 1 May 2002, Bound, Jim wrote: > > > > > What do we think we need to do to get the requirement that > > > > only Routers > > > > > can have anycast addresses changed to "nodes". > > > > > > > > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example > > > > of the use of > > > > > anycast for non-router systems that are very important for > > > > the Internet > > > > > and IPv6. > > > > > > > > I've been trying to push the changing of this: > > > > > > > > o An anycast address must not be assigned to an IPv6 host, that > > > > is, it may be assigned to an IPv6 router only. > > > > > > > > in addr-arch-v3-07 to change 'must' to a 'should' for some > > > > time now, with > > > > not much progress. > > > > > > > > I think this is one item that should be changed before > > > > addr-arch is done > > > > with in the IESG and locked for a few years. > > > > > > > > -- > > > > 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 May 2 13:34:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42KYhrP014311; Thu, 2 May 2002 13:34:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42KYgFe014310; Thu, 2 May 2002 13:34: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.3+Sun/8.12.3) with ESMTP id g42KYdrP014303 for ; Thu, 2 May 2002 13:34: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 NAA28091 for ; Thu, 2 May 2002 13:34:42 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19669 for ; Thu, 2 May 2002 14:34:39 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 2 May 2002 16:34:38 -0400 Message-ID: <3CD1A229.8F2F13E3@nc.rr.com> Date: Thu, 02 May 2002 16:31:37 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: <9C422444DE99BC46B3AD3C6EAFC9711B020B84EE@tayexc13.americas.cpqcorp.net> <3CD16A41.98C3E4F4@iprg.nokia.com> <3CD18D41.108CEBAD@nc.rr.com> <3CD192CF.8CEFE0E6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, "Charles E. Perkins" wrote: > > Hello Brian, > > Your points are very well taken. My main suggestion for the > immediate term was to relax some restrictions on well-known > anycast addresses located in their subnets. It is really > easier if there's just one host, too. The other things > will take more work. > > >From that context, I'll just add a few more comments inline: > > Brian Haberman wrote: > > 1. Host-to-router notification protocol (this is taken care of by > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > What happens if you have a host on a link responding to an anycast > address on that link? Then other hosts on that link won't be able > to easily discern whether the router "liked" the anycast addressable > host or not. I can imagine some very nasty ways to avoid even this > scenario, but I can't believe we'd really want to enforce them. I haven't thought it all through, but perhaps there is a way to handle the on-link case with ND. > > > 2. Security: at a minimum some form of authentication to allow > > routers to determine if hosts are allowed to join an anycast > > group > > Similar comment to the on-link case for (1). Furthermore, the > security requirements for an anycast group depend on the nature > of the anycast group, don't they? It might typically be quite > unimportant to securely restrict participation in an anycast > group geared towards local broadcast of streaming audio of classical > guitar music, or a webcam of the cows in the pasture. Definitely, the nature of the group will help determine the security requirements of that group. However, I would not advocate the use of anycast for some of your examples. :) The security requirements of membership in an anycast group, I believe, is much more important than multicast security requirements. The primary reason is that a rogue node can launch a very effective DoS attack by joining an anycast group. Since the packet goes to one member of the group, a rogue can easily blackhole traffic to the group for portions of a network. > > > 3. An Anycast Architecture doc that pulls all the pieces together > > and concretely describes how pieces interact, the pros and cons > > of anycast usage for intra-domain and inter-domain > > Right! But the latter is often true for any service. The anycast nature > of the addressability of inter-domain isn't appreciably harder, otherwise, > than handling anycast groups in general, is it? It is harder in the fact that the current mechanism of anycast routing requires host routes. In the intra-domain case, anycast routes may still aggregate, but that may not be true inter-domain. Especially when members of the same anycast group span multiple, independent networks. > > > 4. Possibly a draft that documents any impacts on any existing > > protocols (routing protocols, TCP, etc.) > > This would be very important. > > > It should also be noted that this is probably way too much work to do > > in the IPv6 WG. > > It's way too much work for me too :-) I'm not really suggesting that > the general case be made completely open prior to this work getting > done. I was more suggesting that there are useful special cases that > do not present any appreciable downside. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 13:47:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42KlIrP014394; Thu, 2 May 2002 13:47:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42KlI1j014393; Thu, 2 May 2002 13:47: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.3+Sun/8.12.3) with ESMTP id g42KlFrP014386 for ; Thu, 2 May 2002 13:47:15 -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 NAA12860 for ; Thu, 2 May 2002 13:47:17 -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 NAA12682 for ; Thu, 2 May 2002 13:47:16 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g42KlDs18615; Thu, 2 May 2002 23:47:13 +0300 Date: Thu, 2 May 2002 23:47:12 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address In-Reply-To: <3CD18D41.108CEBAD@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2 May 2002, Brian Haberman wrote: > I had actually started taking a crack at this whole problem. It > seems to me that the following components are needed for some form of > global anycast support: > > 1. Host-to-router notification protocol (this is taken care of by > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > 2. Security: at a minimum some form of authentication to allow > routers to determine if hosts are allowed to join an anycast > group You're making assumptions here. Hosts could very well participate in routing protocols. I don't think Host-to-router protocols and security can be _practically_ dealt in the short/mid-term (<2-3 years). > 4. Possibly a draft that documents any impacts on any existing > protocols (routing protocols, TCP, etc.) Unicast RPF is capable of killing anycast with source addresses quite effectively. -- 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 May 2 14:45:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42Lj7rP014528; Thu, 2 May 2002 14:45:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42Lj60E014527; Thu, 2 May 2002 14:45: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.3+Sun/8.12.3) with ESMTP id g42Lj3rP014520 for ; Thu, 2 May 2002 14:45: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 OAA24627 for ; Thu, 2 May 2002 14:45:04 -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 OAA12813 for ; Thu, 2 May 2002 14:45:04 -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 OAA19987; Thu, 2 May 2002 14:45:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g42Lj2T00964; Thu, 2 May 2002 14:45:02 -0700 X-mProtect: <200205022145> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNUZfEF; Thu, 02 May 2002 14:45:00 PDT Message-Id: <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 May 2002 14:44:52 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020501064435.A053A1C30@thrintun.hactrn.net> References: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <4.3.2.7.2.20020430143155.02bf14c0@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 Rob, Two points not made previously. >thread. Using well-known unicast addresses still moves knowledge of >the server location into the routing system. Using well-known anycast >addresses still leaves the client unable to take any useful recovery >action if the server location mechanism has returned answers that are >not useful. The reliance on the routing system for a host route IMHO isn't any different from having a host on a subnet. The router had to be configured to advertise a route to the subnet. It didn't happen automatically. The only difference I see from a host route and a subnet route is the length of the prefix. Reachability to all addresses is dependent on the routing system. Note: I am not saying that host routes can be used for everything as they have clear scaling problems. They are a very useful tool if used appropriately. >Basicly, take all my ranting about service discovery via anycast >address over the last few days, apply s/anycast/well-known unicast/g >and almost all of it will still parse. That being the case, I assume >that you're no more interested in reading all that again than I am in >sending it all again, so I won't. > >I am still fairly skeptical about the existance of a real need for the >service provided by level 1 compliance, given its limitations (some of >which I've commented on, some of which are commented on in the draft). > >Finally, I would urge folks to read RFC 1535 then go back and read >section 3.2 of the draft. Inferring DNS search paths from site names >is dangerous. It's not too bad if one takes reasonable precautions, >but the draft would have to spell out those precautions (see the RFC). I agree this needs be clarified. > > Hope you enjoyed your coffee. > >The first cup of coffee recapitulates phylogeny. I think I need more coffee :-) Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 17:02:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4302ArP014720; Thu, 2 May 2002 17:02:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43029l1014719; Thu, 2 May 2002 17:02: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.3+Sun/8.12.3) with ESMTP id g43026rP014712 for ; Thu, 2 May 2002 17:02:06 -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 RAA18180 for ; Thu, 2 May 2002 17:02:08 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04745 for ; Thu, 2 May 2002 18:02:07 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 2 May 2002 20:02:03 -0400 Message-ID: <3CD1D2BF.69BB4975@nc.rr.com> Date: Thu, 02 May 2002 19:58:55 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycastas Source IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Pekka Savola wrote: > > On Thu, 2 May 2002, Brian Haberman wrote: > > I had actually started taking a crack at this whole problem. It > > seems to me that the following components are needed for some form of > > global anycast support: > > > > 1. Host-to-router notification protocol (this is taken care of by > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > > > 2. Security: at a minimum some form of authentication to allow > > routers to determine if hosts are allowed to join an anycast > > group > > You're making assumptions here. > > Hosts could very well participate in routing protocols. I don't think I am making assumptions. If a node is injecting routes, it is a router. It may not be a member of the trusted set of routers though. That is where the security comes in. If operators want to protect the set of nodes that can inject routes, they can do so by securing the routing protocol exchanges. > > I don't think Host-to-router protocols and security can be _practically_ > dealt in the short/mid-term (<2-3 years). I am not sure if I agree with that. Today an operator can secure routing protocols. And I envision that the number of services reachable via anycast will be small and operating on an operator-trusted set of nodes. In that scenario, I can see the host-ro-router protocols being made secure. > > > 4. Possibly a draft that documents any impacts on any existing > > protocols (routing protocols, TCP, etc.) > > Unicast RPF is capable of killing anycast with source addresses quite > effectively. Not sure I follow you. The anycast addresses are in the destination address field. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 2 18:57:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g431vhrP014871; Thu, 2 May 2002 18:57:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g431vgaI014870; Thu, 2 May 2002 18:57: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.3+Sun/8.12.3) with ESMTP id g431vdrP014863 for ; Thu, 2 May 2002 18:57: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 SAA09558 for ; Thu, 2 May 2002 18:57:40 -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 TAA27327 for ; Thu, 2 May 2002 19:57:39 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0FD581C60 for ; Thu, 2 May 2002 21:57:38 -0400 (EDT) Date: Thu, 02 May 2002 21:57:37 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020501064435.A053A1C30@thrintun.hactrn.net> <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020503015738.0FD581C60@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Thu, 02 May 2002 14:44:52 -0700, Bob Hinden wrote: > > The reliance on the routing system for a host route IMHO isn't any > different from having a host on a subnet. The router had to be configured > to advertise a route to the subnet. It didn't happen automatically. The > only difference I see from a host route and a subnet route is the length of > the prefix. Reachability to all addresses is dependent on the routing > system. Note: I am not saying that host routes can be used for everything > as they have clear scaling problems. They are a very useful tool if used > appropriately. I'm not claiming that there's a difference between a host route and a subnet route (a route is a route, the prefix length doesn't matter). I do claim that there's a difference between letting the client make the choice of which servers to talk to and having the routing system decide for the client. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 3 00:25:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g437PMrP015249; Fri, 3 May 2002 00:25:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g437PLx3015248; Fri, 3 May 2002 00:25:21 -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.3+Sun/8.12.3) with ESMTP id g437PIrP015241 for ; Fri, 3 May 2002 00:25:18 -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 AAA16013 for ; Fri, 3 May 2002 00:25:18 -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 BAA09699 for ; Fri, 3 May 2002 01:25:17 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g437PDf22735; Fri, 3 May 2002 10:25:14 +0300 Date: Fri, 3 May 2002 10:25:13 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycastas Source IP address In-Reply-To: <3CD1D2BF.69BB4975@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2 May 2002, Brian Haberman wrote: > Pekka Savola wrote: > > > > On Thu, 2 May 2002, Brian Haberman wrote: > > > I had actually started taking a crack at this whole problem. It > > > seems to me that the following components are needed for some form of > > > global anycast support: > > > > > > 1. Host-to-router notification protocol (this is taken care of by > > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > > > > > 2. Security: at a minimum some form of authentication to allow > > > routers to determine if hosts are allowed to join an anycast > > > group > > > > You're making assumptions here. > > > > Hosts could very well participate in routing protocols. > > I don't think I am making assumptions. If a node is injecting routes, > it is a router. It may not be a member of the trusted set of routers > though. That is where the security comes in. If operators want to > protect the set of nodes that can inject routes, they can do so by > securing the routing protocol exchanges. No, if a node is injecting routes, it needs not to be a router, as specified in RFC2460 and referred to in addrarch. The definition: router - a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. DNS servers could participate in the routing protocol, injecting a route to itself, while still being hosts. Usually the definition of router also includes forwarding packets between interfaces, but that's only implicit here. > > > 4. Possibly a draft that documents any impacts on any existing > > > protocols (routing protocols, TCP, etc.) > > > > Unicast RPF is capable of killing anycast with source addresses quite > > effectively. > > Not sure I follow you. The anycast addresses are in the destination > address field. You mentioned a host-to-router notification protocol, so we're discussing what would be different if anycast requirements are changed (not as a source address, not on a host). Anycast addresses as source addresses (if allowed) have some amount of problems. -- 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 May 3 03:53:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43ArMrP015582; Fri, 3 May 2002 03:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43ArMTN015581; Fri, 3 May 2002 03:53:22 -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.3+Sun/8.12.3) with ESMTP id g43ArIrP015574 for ; Fri, 3 May 2002 03:53:18 -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 DAA03467 for ; Fri, 3 May 2002 03:53:18 -0700 (PDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19556 for ; Fri, 3 May 2002 04:53:17 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 3 May 2002 06:53:17 -0400 Message-ID: <3CD26B67.C7C0A3EF@nc.rr.com> Date: Fri, 03 May 2002 06:50:15 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycastasSource IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Thu, 2 May 2002, Brian Haberman wrote: > > Pekka Savola wrote: > > > > > > On Thu, 2 May 2002, Brian Haberman wrote: > > > > I had actually started taking a crack at this whole problem. It > > > > seems to me that the following components are needed for some form of > > > > global anycast support: > > > > > > > > 1. Host-to-router notification protocol (this is taken care of by > > > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > > > > > > > 2. Security: at a minimum some form of authentication to allow > > > > routers to determine if hosts are allowed to join an anycast > > > > group > > > > > > You're making assumptions here. > > > > > > Hosts could very well participate in routing protocols. > > > > I don't think I am making assumptions. If a node is injecting routes, > > it is a router. It may not be a member of the trusted set of routers > > though. That is where the security comes in. If operators want to > > protect the set of nodes that can inject routes, they can do so by > > securing the routing protocol exchanges. > > No, if a node is injecting routes, it needs not to be a router, as > specified in RFC2460 and referred to in addrarch. > > The definition: > > router - a node that forwards IPv6 packets not explicitly > addressed to itself. [See Note below]. > > DNS servers could participate in the routing protocol, injecting a route > to itself, while still being hosts. > > Usually the definition of router also includes forwarding packets between > interfaces, but that's only implicit here. I am not disagreeing with what you are saying. I was pointing out that if a host is injecting routes then an operator would be wise to ensure that the host is a trusted entity (i.e. uses authentication keys in the routing protocol messages). > > > > > 4. Possibly a draft that documents any impacts on any existing > > > > protocols (routing protocols, TCP, etc.) > > > > > > Unicast RPF is capable of killing anycast with source addresses quite > > > effectively. > > > > Not sure I follow you. The anycast addresses are in the destination > > address field. > > You mentioned a host-to-router notification protocol, so we're discussing > what would be different if anycast requirements are changed (not as a > source address, not on a host). > > Anycast addresses as source addresses (if allowed) have some amount of > problems. Actually, all of my work so far has been based on the assumption that the rule about anycast addresses being in the source field will not change. Here is a very quick example: A ------ Rtr1 ----- Rtr2 ----- B A wants to join the anycast group FEC0::1234. It sends an MLD Report containing that address in the Group Address field. The Report is sent with an Authentication Header based on the group address. Rtr1 receives the Report and validates the key. If the key is correct, then Rtr1 can inject a host route for FEC0::1234. Now, when B wants to communicate with FEC0::1234, Rtr2 will know to send the packets via Rtr1. The response back from A will use A's unicast address in the source address field. How will B know that the response came from a member of FEC0::1234? Well, one possibility would be to have a Destination Option similar to the Home Address option that holds the anycast address and can be secured with a security header. This keeps the anycast address out of the source address field. And that will minimize the impact of unicast RPF checks stopping the packets. Now, this is still a very rough idea, but an anycast address option may well help address many of the issues that Itojun pointed out in his anycast analysis draft. Of course, there is still a lot of work to do, issues to iron out, code to write... Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 3 07:07:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43E7jrP015834; Fri, 3 May 2002 07:07:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43E7j6K015833; Fri, 3 May 2002 07:07: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.3+Sun/8.12.3) with ESMTP id g43E7erP015826 for ; Fri, 3 May 2002 07:07:41 -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 HAA07174 for ; Fri, 3 May 2002 07:07:32 -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 IAA02066 for ; Fri, 3 May 2002 08:07:31 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA07013; Fri, 3 May 2002 17:07:30 +0300 Date: Fri, 3 May 2002 17:07:30 +0300 Message-Id: <200205031407.RAA07013@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-rfc2553bis-05.txt and Multicast JOIN/LEAVE 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 I seem to have a memory that someone passingly hinted that the interface index might be replaced with a scope id in multicast join and leave group socket option. Should I be prepared for such change in future? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 3 08:24:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43FOMrP015902; Fri, 3 May 2002 08:24:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43FOMG5015901; Fri, 3 May 2002 08:24:22 -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.3+Sun/8.12.3) with ESMTP id g43FOIrP015894 for ; Fri, 3 May 2002 08:24:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g43FOGg16038; Fri, 3 May 2002 17:24:16 +0200 (MEST) Date: Fri, 3 May 2002 17:23:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Documents Ready for DS (RFC2473) To: itojun@iijlab.net Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <25287.1019691105@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - icmp message relay/translation (8) does not seem to be widely > implemented/operated, and could even be abused (open relay of packet - it > is > not mentioned in security issues section). if my observation is correct, > i'd suggest removing the rule. Is your concern that in order to relay/xlate ICMP errors from routers inside the tunnel the encapsulator has to accept them independently of their source address? (unlike data packets which would have their address verified against the peer address of the tunnel). If so, what threats can be caused in addition to those that can be caused by the ICMP errors without any tunneling being used? (I'm not sure there are any.) Without any tunneling the sender needs to accept ICMP errors from any source address since it doesn't know what routers are on the path to the destination. The only possible verification that can be done on e.g. an ICMP dest unreach or an ICMP packet too big is to see if the packet in error is one that the node has recently sent. E.g. if it is a TCP packet one could envision verifying that the connection exists and that the seq and ack numbers seem to be "recent". UDP is harder especially without an IP id field. But the point is that these techniques apply whether or not there was a tunnel doing relay/xlate of ICMP errors. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 3 09:49:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43GnXrP016132; Fri, 3 May 2002 09:49:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43GnWZZ016131; Fri, 3 May 2002 09:49: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.3+Sun/8.12.3) with ESMTP id g43GnTrP016124 for ; Fri, 3 May 2002 09:49:29 -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 JAA05642 for ; Fri, 3 May 2002 09:49:30 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00063 for ; Fri, 3 May 2002 10:49:29 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g43GnM8M027646; Fri, 3 May 2002 09:49:23 -0700 (PDT) Received: from [10.19.238.60] (sjck-dial-gw5-59.cisco.com [10.19.238.60]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADO24003; Fri, 3 May 2002 09:48:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20020503015738.0FD581C60@thrintun.hactrn.net> References: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020501064435.A053A1C30@thrintun.hactrn.net> <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> <20020503015738.0FD581C60@thrintun.hactrn.net> Date: Fri, 3 May 2002 09:49:45 -0700 To: Rob Austein From: Steve Deering Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:57 PM -0400 5/2/02, Rob Austein wrote: >I do claim that there's a difference between letting the client make >the choice of which servers to talk to and having the routing system >decide for the client. Rob, It's not the routing system "deciding" the choice of servers, it's the human who causes the host routes to be injected into the routing system. Instead of a human putting three DNS server addresses into a DHCP database, a human configures the three DNS servers themselves to advertise the (three different) host routes. The client still gets to choose among them, using whatever criteria it wishes. If, instead of using three unicast addresses, we were to use a single anycast address, that would indeed take away the decision process from the clients. The human who causes the host routes to be injected could, if it were really important, statically prioritize the choice of server by suitable assignment of route metrics (if using an IGP with a big enough metric space). A couple questions, from one who is expert in neither DNS nor DHCP: Do the bulk of DHCP servers today provide more than one DNS server address to each client? If so, do "consumer-level" IP devices (PCs, laptops, PDAs, cell phones, etc.) really make sophisticated choices among those multiple DNS servers, or do they just pick one and then, only if that one fails to respond, try another? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 3 10:07:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43H7WrP016226; Fri, 3 May 2002 10:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43H7WZr016225; Fri, 3 May 2002 10: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43H7TrP016218 for ; Fri, 3 May 2002 10:07:29 -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 KAA12870 for ; Fri, 3 May 2002 10:07:30 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08648 for ; Fri, 3 May 2002 11:07:29 -0600 (MDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03192 for ; Fri, 3 May 2002 13:07:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20020503125718.03d246e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 May 2002 13:07:25 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <20020503015738.0FD581C60@thrintun.hactrn.net> <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020501064435.A053A1C30@thrintun.hactrn.net> <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> <20020503015738.0FD581C60@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:49 AM 5/3/2002 -0700, Steve Deering wrote: >A couple questions, from one who is expert in neither DNS nor DHCP: >Do the bulk of DHCP servers today provide more than one DNS server >address to each client? Yup. >If so, do "consumer-level" IP devices (PCs, >laptops, PDAs, cell phones, etc.) really make sophisticated choices >among those multiple DNS servers, or do they just pick one and then, >only if that one fails to respond, try another? I can't give an authoritative answer - my understanding is that ost devices just pick one and only try another if the currently selected server fails to respond... - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 4 06:48:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g44DmirP017684; Sat, 4 May 2002 06:48:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g44DmixY017683; Sat, 4 May 2002 06:48: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.3+Sun/8.12.3) with ESMTP id g44DmfrP017676 for ; Sat, 4 May 2002 06:48:41 -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 GAA21055 for ; Sat, 4 May 2002 06:48:41 -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 HAA06067 for ; Sat, 4 May 2002 07:48:46 -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 g44DmRb20801; Sat, 4 May 2002 15:48:27 +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 PAA07160; Sat, 4 May 2002 15:48:27 +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.11.3/8.11.3) with ESMTP id g44DmNT26463; Sat, 4 May 2002 15:48:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205041348.g44DmNT26463@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-rfc2553bis-05.txt and Multicast JOIN/LEAVE In-reply-to: Your message of Fri, 03 May 2002 17:07:30 +0300. <200205031407.RAA07013@burp.tkv.asdf.org> Date: Sat, 04 May 2002 15:48:23 +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 seem to have a memory that someone passingly hinted that the interface index might be replaced with a scope id in multicast join and leave group socket option. Should I be prepared for such change in future? => this can't work without a lot of work when the zone has more than one interface... but I agree the multicast and IPv6 APIs should be more coherent. 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 Sun May 5 20:43:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g463hmrP019903; Sun, 5 May 2002 20:43:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g463hmLv019902; Sun, 5 May 2002 20:43: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.3+Sun/8.12.3) with ESMTP id g463hjrP019895 for ; Sun, 5 May 2002 20:43: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 UAA22497 for ; Sun, 5 May 2002 20:43:48 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04036 for ; Sun, 5 May 2002 21:43:47 -0600 (MDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 07491600332 for ; Sun, 5 May 2002 20:43:46 -0700 (PDT) Received: from NT43227 (nt43227.india.hp.com [15.10.43.227]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id JAA03225 for ; Mon, 6 May 2002 09:08:37 +0530 (IST) Message-ID: <042601c1f4b0$5d5445f0$e32b0a0f@NT43227> Reply-To: "Anil Kumar Reddy" From: "Anil Kumar Reddy" To: References: <20020503015738.0FD581C60@thrintun.hactrn.net> <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020501064435.A053A1C30@thrintun.hactrn.net> <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> <20020503015738.0FD581C60@thrintun.hactrn.net> <4.3.2.7.2.20020503125718.03d246e0@funnel.cisco.com> Subject: Question on RFC-2472: IPv6 over PPP Date: Mon, 6 May 2002 09:14:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a question about RFC-2472 (IPv6 over PPP), related to interface identifier option. Could somebody please answer. RFC-2472 gives 3 options in selecting an interface identifier for the negotiation. My doubt is related to option #1 - creating it from EUI-64 or EUI-48 identifiers. It says the 'u' (universal/local) bit should be set to 1, while deriving the interface identifier from EUI-48 identifier. In this scenario, suppose we create a ppp interface (which is a logical interface) with an interface address derived from the above EUI-48 ('u' bit set to 1), extracted from any locally available interfaces. Then there is a chance of address clashing, when we want to configure the interface (physical), from which we have taken EUI-48 identifier & used for ppp interface. And it will not be possible to have two interfaces with the same address (& globally unique - u bit). What is the meaning of these statements in RFC-2472 ?? Thanks in advance for your help. Regards, Anil (Actually, I should post this to ppp mailing list, but as it is related to IPv6, I thought I can get some help from IPng group.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 6 00:35:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g467ZjrP020124; Mon, 6 May 2002 00:35:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g467Zjp2020123; Mon, 6 May 2002 00: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.3+Sun/8.12.3) with ESMTP id g467ZgrP020116 for ; Mon, 6 May 2002 00:35: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 AAA05844 for ; Mon, 6 May 2002 00:35:39 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24889; Mon, 6 May 2002 00:35:38 -0700 (PDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g467YOs10321; Mon, 6 May 2002 09:34:24 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g467YOX16058; Mon, 6 May 2002 09:34:24 +0200 (MEST) Message-ID: <006001c1f4d0$b063f400$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Brian Haberman" , "IPng Working Group" Cc: , Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address Date: Mon, 6 May 2002 09:36:08 +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 4.72.3110.5 x-mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, BTW we have a draft (submitted to the GSEC WG) that actually tackles this problem and proposes a solution based on CGA (crypto. generated addresses)... The draft can be dowloaded at: http://www.inrialpes.fr/planete/people/ccastel/draft-irtf-gsec-sgmv6-00.txt regards, Claude. -----Message d'origine----- > 2. Security: at a minimum some form of authentication to allow > routers to determine if hosts are allowed to join an anycast > group > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 6 07:52:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46EqwrP020787; Mon, 6 May 2002 07:52:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46EqwIH020786; Mon, 6 May 2002 07:52: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.3+Sun/8.12.3) with ESMTP id g46EqtrP020779 for ; Mon, 6 May 2002 07:52:55 -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 HAA28464 for ; Mon, 6 May 2002 07:52:55 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01756 for ; Mon, 6 May 2002 08:52:54 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id ED2711B91 for ; Mon, 6 May 2002 10:52:53 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 4E63C4D8 for ; Mon, 6 May 2002 14:52:50 +0000 (GMT) Date: Mon, 06 May 2002 10:52:49 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020501064435.A053A1C30@thrintun.hactrn.net> <4.3.2.7.2.20020502104319.025c57c8@mailhost.iprg.nokia.com> <20020503015738.0FD581C60@thrintun.hactrn.net> 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: <20020506145250.4E63C4D8@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Fri, 3 May 2002 09:49:45 -0700, Steve Deering wrote: > > It's not the routing system "deciding" the choice of servers, it's the > human who causes the host routes to be injected into the routing system. > Instead of a human putting three DNS server addresses into a DHCP > database, a human configures the three DNS servers themselves to > advertise the (three different) host routes. The client still gets to > choose among them, using whatever criteria it wishes. Only if the binding between the well-known unicast address and the particular name server at that address is stable. If the binding is a dynamic thing, then choices that the client tries to make based on previous history of the server at that address become invalid when the binding changes, and the client has no way of knowing when the binding has changed. > A couple questions, from one who is expert in neither DNS nor DHCP: > Do the bulk of DHCP servers today provide more than one DNS server > address to each client? If so, do "consumer-level" IP devices (PCs, > laptops, PDAs, cell phones, etc.) really make sophisticated choices > among those multiple DNS servers, or do they just pick one and then, > only if that one fails to respond, try another? Depends on the implementation, but all DNS clients are required to be capable of being configured to know about more than one server at a time. Some implementations just round-robin among the servers they know about, some perform timing measurements and try the server that had the best response time in the past for the next query, and so forth. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 6 22:03:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4753YrP022905; Mon, 6 May 2002 22:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4753YGw022904; Mon, 6 May 2002 22:03: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.3+Sun/8.12.3) with ESMTP id g4753VrP022897 for ; Mon, 6 May 2002 22:03:31 -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 WAA13111 for ; Mon, 6 May 2002 22:03:32 -0700 (PDT) Received: from corp4.cbn.net.id (corp4.cbn.net.id [202.158.3.28]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24882 for ; Mon, 6 May 2002 23:03:40 -0600 (MDT) Received: from cbn.net.id (ip56-96.cbn.net.id [202.158.56.96]) by corp4.cbn.net.id (Postfix) with ESMTP id 9AD8E13ADA for ; Tue, 7 May 2002 12:03:22 +0700 (WIT) Message-ID: <3CD75FA0.81A0EEFD@cbn.net.id> Date: Tue, 07 May 2002 12:01:20 +0700 From: Aries Fajar X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPv6 Subject: Stateles vs Stateful Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Is there any documentation that explain the basic principle of autoconfiguration, then the basic difference between Stateles and Stateful, when to use one of them, etc, etc ? Thanks Aries -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 7 08:18:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g47FIprP023995; Tue, 7 May 2002 08:18:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g47FIppA023994; Tue, 7 May 2002 08:18:51 -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.3+Sun/8.12.3) with ESMTP id g47FImrP023987 for ; Tue, 7 May 2002 08:18:48 -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 IAA02767 for ; Tue, 7 May 2002 08:18:50 -0700 (PDT) Received: from mail.uniroma3.it (mail.uniroma3.it [193.205.139.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19321 for ; Tue, 7 May 2002 09:18:48 -0600 (MDT) Received: from plutone ([193.205.139.240]) by mail.uniroma3.it (8.9.3/8.9.3) with SMTP id RAA15621 for ; Tue, 7 May 2002 17:20:50 +0200 (MET DST) Message-ID: <3CD7F02A.6090104@colitti.com> Date: Tue, 07 May 2002 17:18:02 +0200 From: Lorenzo Colitti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Which IPv6 MIB should I use? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I apologize if this subject has already been done to death and/or if I'm reopening a can of worms. If that is the case, point me in the right direction and I'll go away, I promise. :-) I am a student at the university of Roma Tre in Italy and, as my thesis project, I am working on methods for identifying IPv6-in-IPv4 tunnels on local and remote nodes. The ideal objective is to produce a tool, similar to traceroute, which can detect IPv6 in IPv4 tunnels and report the IPv4 hops the tunnel passes through. e.g.: 1 fec0:1::1 1 ms 2 fec0:2::1 2 ms 10.0.1.9 10.123.4.1 10.0.2.51 3 fec0:3::1 10 ms Of the various methods possible, SNMP is potentially the one which provides the most complete and accurate information, so that is my primary focus at the moment. However, I do not know which MIBs to use. There is the standard IPv6 MIB (RFC 2465), and there is the Fenner et al. IETF draft which aims to extend RFC 2011 in an IP version independent manner, which has since expired: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2011-update-00.txt Which should I use? I could use the standard IPv6 MIB (RFC 2465), or the draft MIB plus the tunnel MIB. None of these seem to be implemented by Cisco, and net-snmp, on Linux at least, only supports the tunnel MIB and a very small (useless) subset of the standard IPv6 MIB. I could try to extend net-snmp on linux, to support what I need, but which of the two MIBs should I implement? Which MIBs are going to be standard and used in the future? Regards, Lorenzo Colitti -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 7 22:26:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g485QjrP025355; Tue, 7 May 2002 22:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g485Qj7o025354; Tue, 7 May 2002 22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g485QgrP025347 for ; Tue, 7 May 2002 22:26:42 -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 WAA11851 for ; Tue, 7 May 2002 22:26:43 -0700 (PDT) Received: from out-mta3.plasa.com (out-mta3.plasa.com [202.134.0.198]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05113 for ; Tue, 7 May 2002 22:26:31 -0700 (PDT) Received: from [203.130.205.197] (helo=Icgqkitu) by out-mta3.plasa.com with smtp (Exim 4.02) id 175Jxm-000MCn-00 for ipng@sunroof.eng.sun.com; Wed, 08 May 2002 12:26:07 +0700 From: lf To: ipng@sunroof.eng.sun.com Subject: Hello,meeting notice MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Z1248j60sAu7B3DD7pd22R3T53371CC Message-Id: Date: Wed, 08 May 2002 12:26:07 +0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Z1248j60sAu7B3DD7pd22R3T53371CC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Z1248j60sAu7B3DD7pd22R3T53371CC Content-Type: audio/x-wav; name=charset.pif 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAWdWX7bm5ublZBwUHHwcFBxWPFw MJ2SM7FQkjOxUJXbu/FQWPFwMJ2xEJq6lVMx07DScFBYUDETndGw0xGVEbBRsfFY8XAwnbCx 8JWQcFBx8HBQcVjxcDCdsnAzMDGVkHBQcfBwUHFY8XAwnRNwMJVzsbCQsVBxWPFwMFiQ8J0z EdGVUzHTsNJwUFhQMROd87DzlZBwUHHwcFBxWPFwMJ0TsdHRMZURsFGx8VjxcDCd0TPzkJVT MdOw0nBQWFAxE50wM/CxlXPRONCxk7FQWPFwWNCTnRNw8LJwlXPRONCxk7FQWPFwWNCTnfOw MTCwUJWTELHzsVjxcDCdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dndoWl9NwcdOxMJlVsBAx8xa1EXDRMRa1 8dNw0bETmRtYmxbXMbERMdMWtfHTcNcR+9tY8DAQnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ0wk5qdWDGSMZ1Y8/HTnViTsFGdWNGxE52dnZ2dnZ2dnZ2d nZ1YE5ITnViQEzCdWJATMBCdWHOx0Z1YsfOTnVgRcPGdWNMTUZ1YkhDznVjQk3GdWPGTk51Y 8Z1Yk7HznVgwk3GdWDCTMXGdWNGx8J1YMJP7nViTEVGdnfdwURNzsdMxFjSw8dNw83BRExZ3 sFARcHPzFvUz09MxUBNXMdPzsHBQFp21k5OZl7ETkPOd1zNQndczUHRQ8TGd97LzEzEwFvUz 09MxUBP1cFAT03AQ9zETFvcx01Ow8THznfdwURNzsdMxFjSw8dNw83BRExZ3tdUWd7XVGxZ3 sdGZVbAQMZlUsTAxndczUPcx01Ow8THznbRQEzHTUDETmfcxExOwUHHzFvWx8ZAxFpexE5Dz nZ2dnZ2dnZ2UsBidlDEQEHAYndcx2p1Vc9qdN1ARMRCwUzHTsdEQMZkwsbAQODjZOfPZndcx EzPTUDERmTCxsBA4ONk589mdnZ2dnbGZOfOZOfOZcbEwMZ2xmTnzmTnzmRNwcBCdsZk585k5 85lzMdHzsBMxnbGZOfOZOfOZk7ET8ZCdOfOZ0zEwcFOxEJkTcHAQ852dnZ2dnZ2dUDFznVEz UFCynVCw8TGdkDMwcDPTnTGS8bATMZ1xcHARnZNwc1EzEJ13sFCWl520NZlbWJudd/vbWDUQ 8DHTUJmdd/vbWPQQMdJYNZ2dkHBzmbHTMZmycDOdEDETefOZ0TGZUdOwMVAR850RsdMQsFBx nfNwmfFwcBCZsZlRELHzkBgxUNBwspmwE52ycDPTmZOx8/NzcNMRnZBwUDGynfNwMDGZszMx 8xOwcFDznZMQMbHzMZkT07KZsXGxsFCdczEQ8XAwMZkTcJkwspmQcDAxE3BzUJ0TkDGZdbHT ETFQmXBRmTURMVCdsFAT03ARM/ETsHBQmXBQmbUV9xSdMDExE7BQcZlQcBOw8TGdszMx8xOw cFBQsbDTMZ3xcFBx07ETMxCxE7BwUPOd83DzuZ3QsZOxUDHzMZlxsNMQmVf3mZMQsbLRcLKd EHBw8BgwspnRMbEzE7BRMxCZcbDTEJlR07AxUBGdMbFxMdOZE3CZ8zExmbJwM53zk7DxMZlx sNMQ83mZU3DxsRCZ8XBQ8THTE53QsZOxUDHzMZkQsfPzeZnzMZKymZOw8RMz0zHznZ2dnfey MLFQEzHxnTTxsVExMZ1VOPcx8TPTMZ33cJOQcPOdF9MxUBEwsPHTcJ30sfOTMdPz8LKdnZ2d VdNwMNqZnRdw2pmd9zPR0DHxE9qZnZ2dF5AxmVFwEBBwc7BQcZkwsbAQmfGxUHkTmdExmfMx UBOZE3CZOfPanReQMZmxExOx8ZAwMVATnReQMZlRsBAxnZmw85kTkDGZcNOwcbBQsRCZMLGw EJ2ZcbBTMZmycDOZE5AxmTnznZmw85mxmTnzmRGxUHEx03Az85lTsNMz85kTkLETmTnznfGx UJmwUFEx8ROZcFCZd7BQupp4NDF425ubm3iWl1id85PTMbERmROQ03AzcZCZMTCxsBBYnVMx 07KZnfOTMfGwsRCZnZATE5PaeHidc3NzWJ1Y8XAwnVVw05kwcNMxmbBQUXDTMLETsHBQGJMQ MbHzMZlTsPOwE5mdF5Cw85mw85mdtJk585mycDOZc3AzEBGZOfOZsBNYnTFQ0HCynRCw8DGd c7DzkJ2QcJMxnTGSkzHxE52d9ZDTsPMTMLHznVQxc5myMbHTnfexsFATmVexEDFQE7BQMXnz mRWxsp21EBCQsRAQcHMwsfOdtZPTsBCZVXBwEPN5mRWxsp0UsRGymRWxsp218/MzMJMTsHBQ nfWxUBEQMTCx8521EBCZ93AzEPN5FbGynTWTsJOQsVCynZ2dnZ2UsZOTspmdlLFTMZmxmZ2d GtHTWjzcnTzcnZNw8xMwsfMTMdOdnZ13sFDwnZ20MLFxMZexE5CdNLQ0NThXMdPzsHBQ2pm7 WJs83PVwUBMxUBM4F7KTMdqZMDMQE7CTsdMTeLEQEzHTULETsFMx+jzcvNFwM1ARsdOyOp31 cFATMVATOBeykzHamRMxkhN4kBMwEPo83PVwUBMxUBM4F9OxUPNRMdM4NVDxcBGwUHHambMz cBMxETiT07BQE7HREDE83DzcGpQXNBRaGpQ1tRVaGniUNbUVWhrVdBW2WjnzPNwaVXRUF1qd nRp4VXRUF1oaeNV0FbZaGniUFzQUWp2dnfVwUBMxUBM4F7KTMdqZOfP6PNy8ULEwMTo58zzc 9XBQEzFQEzgX07FQ81Ex0zg1UPFwEbBQcdqZ0bHzMVsbPNz1cFATMVATOLQV2pkaOfNanZ2d nZ2dnZ2dnbEzEbBweJI4c7FTnbEzEbBweJI4MLARsJ2xk5MQsPGxE7BwUHhw8RMxEzjzE9Mx sTCdnZ2dnZ2dnZ083BqwUdOxMDGZ89PxOvsV8bAR2jnzmZAxsHGQEzr7FZuZc7ARE5A6+xWb WjzcGniwUdOxMDFanReQsPOZcbEwMZmw85kwsplRsNPzE5lzcNPwWBrR01o83LZwM3nTMZkT kDGZUbDT8xOZkxCxsjHTWJ10tPW3nZfTcHHTsTBVsBAx8xWw052dnZ3zMBOTWJ12tVeX+9ud drVXl/X1nVR0FfvbnVSX9/dX9Z1U1zX3t/vbnVT39ZQ1FfvbnVT39ZQ1FVQXnVT3lxQ3dbRU nVS1V51UtVe1l/dX9Z1UtVe1l3f7251UtVcUN/vbnVS1V9c3VNedVLVXd/vbnXa1V5c0nbUU NdcX91f1nbU0dFSdtVeX+9udtVeX9fWdtVeXNJ1U+9v39bVUd51UtVd3VBedtVQXtFe01521 V5c3lxWdtVd19RfXFJ21V3e0VLo7nff1tVT7251X95R3tFT7251VOPcXdJd3nVU4l9d0F7o7 nbX19He0VPvbnVc1FxfXtbadVzUXujud93c1NZe6O52X9fV3tFS6mp20dDR0VLqanbVXlxf1 nbVXNfvbnbVX9XRU93QUnVWXOHe0VJ0VV5e6O51VOLV1VBe6O531FLV3ujudVFf1ujud9/W1 VJ1XtNc3950UdPX0FXR3VNubm5udVHDTE3BQnTTxsVExMZ21UBOwU7DTnRe19/Q0ddednZ2d nZ2dnZ2dnZ2dnZ2dnZ2dtVQXtDhXtNdYFbUXnfWU9BS09xdYFbUXnfWU9BS09xdYNPed9ZT0 FLT3F1j1l/ed9ZT0FLT3F1gXtVedtFfVWFQX1p33NLXXF/WU9Fg09533NLXXF/WU9Fj1l/ed tVd1txdYFbUXnbV1N7XXFVgVtRednZ2dnZ2d95AQc7GTsFgREBCd9DHTUDEQ+9tYERAQnVAx E7GTsPvbWBEQEJ3zUfFYERAQnZ2dnZ33sNPxsTCdVLAwEbGd9XARMdcxEZ13t/Q0NPuae5qd dde0NVX7mnuanVUzUJkUcFOwUHGZ9dOwMLBQsRCdVHDTE3BQnTTxsVExMZ21UBOwU7DTnbVT 8XBQ83AQnVU49xd0l3edVTj3MfEz0zGd93CTkHDznVOw0zPznbVXl5k0cFCwE3DTnbVXl5k3 kxGxEzHznbRQcPEzELETMbQXnZf1OPGwEBCwUJ33sjCxUBMx8Z0X0zFQEZk0sPHTcJ1VOJfX dBedmVR0FfvbmZ2dndcxcbDzEzHT9zHTU7DxMZfTcPEx8/OdVDET95Cx0zG1ERGd95QVMRAx EzH0MbK1nfdR8bTzVbAQMZfTcBMx8RMxEZ1UMRP3kLHTMXUxE7RQUXCdVDETtZOw1TNRUTHT VdMxMZ2dnZ2dNZaXFHTXNded9TQ0ddedMPOwMFCdsPFz8XBQUJ1zsFDSsJOdnZ2dnZfTcHHT sTCdOfOZGjnzWp211fUVNVV1lLTU9BQ0VHSXt9f3FzdXd5a21rHR8RExUXGQsNDwEDBQcJOz 0/MTM1NzkrLSm7vb+xs7W3uauvh4nfMxEzOTnbBQ8xOxEBCdETEwcJ3zUHBwk7Kdk7DxsfEz nfCwExOynZMQsbKd03Dx8J2dnZ2dnZ2d17HTud59nWSP852dPJ2dnZ2dnZ2dnVjTsdOdnXOw ULBQMRNYERAQnbRQEzHTUDETdTET9XBQUDHxEzER9xOxEzGdnZ0VsNMx8RNw07KdERAQ8bHx kDGdnfcxFTHRM3GX07BTsBAxcTGd9zEX8dGX07BTsBAxcTGdnZ2dnZ2dnZ1z0TjQsZOxUFjx cFjQk51TMdOw0nBQWFAxE52x07MzsNMxEVgx850RsFGx8VjxcDCdnfdwURNzsdMxFjSw8dNw 83BRExa0UBMx01AxE5m18fFwM1ATmTSxULFxMdMWtfHxcDNQE/MWnfc0F5eZ9zHTUzHTnfc0 F5eZNTCxsBCZtRER0zHz852dd3DTMJn0EDHSWDWZsDAwM1CwE7KdnfQQMdJYNZmw85kTkDGZ MHDzE5nxcDAwcFCZc3DTEBE4c7ARMZnzk9MxsRGwUHGZc3DTMFi0E3nzmVMx07KZEbFQcTHT cDPzmdGymfFw09MzkxOwUHGZsnAz05lRsBAx81ga0dNaPNzVMfGxM/MxmXBRmbAT85lTMdOy mfMwsdMTmfMTMbEQE5CZsVARmbFQE7A4sVATsDhTsNMz85kTMfGQULDxGDBw8xOZ8XAwMHBQ mbVXmfNwURNzsdMxmfGxUHkTmRExEzHxE5lw05nxEDGxUJmwE1ga0dNaPNx3MZkRMVMxEHCT MRGZE5Cw85lR0zExmbAwMDNQsBOymRNwcBCZE3CZETFRMbETmROQMZkwsRCw8bBwM/OZU7DT M/NYGtHTWjzctnAzmXBQELKZUDExEZkTcJnTM1CZE5Cw85kTcHAQmXBQ8TEYsVARmROQMVCZ 9BAx0plzsBAQmVAxUzHTmfFwMDGZsFATcJmycDPTmZf1WBrR01o83FR0FzXamdUx8bEz8zGZ E5Cw85kTcHAQmbHxE/OZsfOZsZlRsfAxmfQQMdKZE3CZUXBwEJkTkDGZ0zGxEJlzcNMwGPNw MDGZtVeZMHBQsBNw05kwsbLRMZnx07KZc5AxUJmycDOZ0zNQmbATWBrR01o83LRRmfNwGLRx UHDTMZkTkDGZc7HTULBQcRixUBGZ8zEQMfETmXnxcFATsFAzMXlYGtHTWjzctFGZsnAzmZCx UzGZsVCymbMzMfMTsHBQGJMQMbHzMZkasZmQ0zFROvsVMLGwEBNw2jnzWjCxsBCZE3CZMDEa eLFaWJ2dnZ2dnZ2dPNx3sFD725n0EDHSmVfbWJu7mVmZd7BQ+9uZVXDTcDOSmVe7WJs83PVw k7LTsHGQE5nbm5vbGDCxETGZsFCZtfOwsTzctdFwMxOZ9BAx0plX21ibu9o83Ly7GDSxsFCZ MLDz87BwUJmw85kTcJnTMRAxsfMxmROQMZlQMXOZ0bHRspmXNZlTsNMz8xh3sFD725lVcNNw M5I83LzbGFRwmfOwcVCwUbDxsVATmfGQsVBxMVhUcJnRM3GZUbCSMRFYVHCZsVCymZOxshBw sRFYPNy10XAzE5l3sFD725lVcNNwM5KZmJMQ0pnwMTGTmROQMZlQsTAxGBOQsVCSuDzcvLsY VTMQEJnxcDCTsROw0RAxmXewUPvbmZc1mVOw0zPzmXBQmXewULqWeNv0eFQXeJaXPNy82xh3 sBOQmVMx07KZsFATMdMx8xOwUHGZUTGxEzPTMVj1kDHx8JmwE7k83Lz7GFRwmbFQspmTsbIQ cLERWFRwmbFQsplwkxOwMLDSsROwcFA83LwbGFRwE5nRM3GZUdMxMRjRMfGxM/MxmXBRmbGZ kDPT07KZc3DT8FhUcJkwcNMxmROQsVCZE5DTMTGZczEx8POZUdNwMJmQsVOwUHGZ8zPxkJmw ETGxmRNwmbHx8XAwkxCw85CwUHGZ8XARsFBxmbFQEZkTMfMTsFBxPNydAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAIFUAgKgAAIBaUQCAwAAAgNxQAIAYAQCAyFAAgEABAIA6VQCA AAIAgNZSAIAYAgCAsFQAgDACAIABAAAASAIAgAIAAABQBACAAwAAACAHAIAEAAAAAAgAgAUA AAAoCACABgAAABAJAIAJAAAAOAwAgAoAAABYDACADAAAAPgMAIAOAAAAmA4AgBAAAADQDgCA 8AAAAOgOAIAAAAAAAAAAAAAAAAABAAAAKFUAgAAPAIAAAAAAAAAAAAAAAAAJAAAAblEAgBgP AICIUgCAMA8AgF5SAIBIDwCAOlIAgGAPAIC6UQCAeA8AgJJRAICQDwCAElIAgKgPAIDkUQCA wA8AgLBSAIDYDwCAAAAAAAAAAAAAAAAAAwAAAO5QAIDwDwCAFlEAgAgQAIA8UQCAIBAAgAAA AAAAAAAAAAAAAAAAFgABAAAAOBAAgAIAAABQEACAAwAAAGgQAIAEAAAAgBAAgAUAAACYEACA BgAAALAQAIAHAAAAyBAAgAgAAADgEACACQAAAPgQAIAKAAAAEBEAgAsAAAAoEQCADAAAAEAR AIANAAAAWBEAgA4AAABwEQCADwAAAIgRAIAQAAAAoBEAgBEAAAC4EQCAEgAAANARAIATAAAA 6BEAgBQAAAAAEgCAZQAAABgSAIBmAAAAMBIAgAAAAAAAAAAAAAAAAAAAAQAtAQAASBIAgAAA AAAAAAAAAAAAAAEAAADgUgCAYBIAgAAAAAAAAAAAAAAAAAEAAACwVACAeBIAgAAAAAAAAAAA AAAAAAAAPwABAAAAkBIAgAIAAACoEgCAAwAAAMASAIAEAAAA2BIAgAUAAADwEgCABgAAAAgT AIAHAAAAIBMAgAgAAAA4EwCACQAAAFATAIAKAAAAaBMAgAsAAACAEwCADAAAAJgTAIANAAAA sBMAgA4AAADIEwCADwAAAOATAIAQAAAA+BMAgBEAAAAQFACAEgAAACgUAIATAAAAQBQAgBQA AABYFACAFQAAAHAUAIAWAAAAiBQAgBcAAACgFACAGAAAALgUAIAZAAAA0BQAgBoAAADoFACA GwAAAAAVAIAcAAAAGBUAgB0AAAAwFQCAHgAAAEgVAIAfAAAAYBUAgCAAAAB4FQCAIQAAAJAV AIAiAAAAqBUAgCMAAADAFQCAJAAAANgVAIAlAAAA8BUAgCYAAAAIFgCAJwAAACAWAIBCAAAA OBYAgEMAAABQFgCARAAAAGgWAIBFAAAAgBYAgEYAAACYFgCARwAAALAWAIBIAAAAyBYAgEkA AADgFgCASgAAAPgWAIBLAAAAEBcAgEwAAAAoFwCATQAAAEAXAIBOAAAAWBcAgE8AAABwFwCA UAAAAIgXAIBRAAAAoBcAgFIAAAC4FwCAUwAAANAXAIBUAAAA6BcAgFUAAAAAGACAVgAAABgY AIBXAAAAMBgAgFgAAABIGACAWQAAAGAYAIAAAAAAAAAAAAAAAAAAAFgAAQAAAHgYAIBnAAAA kBgAgMwAAACoGACAzQAAAMAYAIDOAAAA2BgAgM8AAADwGACA0AAAAAgZAIDRAAAAIBkAgNIA AAA4GQCA2QAAAFAZAIDaAAAAaBkAgN8AAACAGQCA4QAAAJgZAIDiAAAAsBkAgOMAAADIGQCA 5AAAAOAZAIDlAAAA+BkAgOgAAAAQGgCA6QAAACgaAIDqAAAAQBoAgOsAAABYGgCA7AAAAHAa AIDtAAAAiBoAgO4AAACgGgCA7wAAALgaAIDwAAAA0BoAgPEAAADoGgCA8gAAAAAbAIDzAAAA GBsAgPQAAAAwGwCA/AAAAEgbAID+AAAAYBsAgCQBAAB4GwCA2wEAAJAbAICNRwAAqBsAgI5H AADAGwCAkUcAANgbAICSRwAA8BsAgJNHAAAIHACAlEcAACAcAICiRwAAOBwAgKNHAABQHACA pEcAAGgcAIClRwAAgBwAgKZHAACYHACAp0cAALAcAICoRwAAyBwAgKlHAADgHACAqkcAAPgc AICrRwAAEB0AgKxHAAAoHQCArUcAAEAdAICuRwAAWB0AgK9HAABwHQCAsEcAAIgdAICxRwAA oB0AgLJHAAC4HQCAs0cAANAdAIC0RwAA6B0AgLVHAAAAHgCAuEcAABgeAIC5RwAAMB4AgLpH AABIHgCAu0cAAGAeAIC8RwAAeB4AgMVHAACQHgCAxkcAAKgeAIDHRwAAwB4AgMhHAADYHgCA yUcAAPAeAIDKRwAACB8AgNZHAAAgHwCA10cAADgfAIDYRwAAUB8AgNlHAABoHwCA2kcAAIAf AIDbRwAAmB8AgN1HAACwHwCA4UcAAMgfAIDjRwAA4B8AgOZHAAD4HwCA50cAABAgAIDtRwAA KCAAgO5HAABAIACAx2cAAFggAIASeQAAcCAAgBN5AACIIACAFHkAAKAgAIAAAAAAAAAAAAAA AAAAABoAKAAAALggAIApAAAA0CAAgCoAAADoIACAKwAAAAAhAIAsAAAAGCEAgC0AAAAwIQCA LgAAAEghAIAvAAAAYCEAgDAAAAB4IQCAMQAAAJAhAIAyAAAAqCEAgDMAAADAIQCANAAAANgh AIA1AAAA8CEAgDYAAAAIIgCANwAAACAiAIA4AAAAOCIAgDkAAABQIgCAOgAAAGgiAIA7AAAA gCIAgDwAAACYIgCAPQAAALAiAIA+AAAAyCIAgD8AAADgIgCAQAAAAPgiAIBBAAAAECMAgAAA AAAAAAAAAAAAAAAAAwABAAAAKCMAgL5HAABAIwCAv0cAAFgjAIAAAAAAAAAAAAAAAAAAABsA ZAAAAHAjAIBmAAAAiCMAgGcAAACgIwCAaAAAALgjAIDXAAAA0CMAgNgAAADoIwCAAQEAAAAk AIAEAQAAGCQAgAsBAAAwJACAEgEAAEgkAIAaAQAAYCQAgCEBAAB4JACAJQEAAJAkAIAnAQAA qCQAgOIBAADAJACA5AEAANgkAIADBgAA8CQAgAQGAAAIJQCA/S4AACAlAICIRwAAOCUAgIlH AABQJQCAj0cAAGglAICQRwAAgCUAgL1HAACYJQCAAXgAALAlAIACeAAAyCUAgAN4AADgJQCA AAAAAAAAAAAAAAAAAABjAAEAAAD4JQCAAgAAABAmAIADAAAAKCYAgAQAAABAJgCABQAAAFgm AIAHAAAAcCYAgHICAACIJgCAcwIAAKAmAICBAgAAuCYAgIICAADQJgCAkQIAAOgmAICSAgAA ACcAgJMCAAAYJwCAoAIAADAnAIChAgAASCcAgKICAABgJwCAsAIAAHgnAICxAgAAkCcAgMAC AACoJwCAzwIAAMAnAIDQAgAA2CcAgNECAADwJwCA0gIAAAgoAIDTAgAAICgAgN8CAAA4KACA 4AIAAFAoAIDhAgAAaCgAgOICAACAKACA4wIAAJgoAIDvAgAAsCgAgP4CAADIKACADgMAAOAo AIAdAwAA+CgAgB4DAAAQKQCALQMAACgpAIAuAwAAQCkAgC8DAABYKQCAMgMAAHApAIA9AwAA iCkAgD4DAACgKQCAPwMAALgpAIBAAwAA0CkAgEEDAADoKQCAQgMAAAAqAIBDAwAAGCoAgEQD AAAwKgCARQMAAEgqAIBGAwAAYCoAgEcDAAB4KgCASAMAAJAqAIBJAwAAqCoAgEoDAADAKgCA SwMAANgqAIBMAwAA8CoAgE0DAAAIKwCATgMAACArAIBPAwAAOCsAgFADAABQKwCAUQMAAGgr AIBSAwAAgCsAgFMDAACYKwCAVAMAALArAIBVAwAAyCsAgFYDAADgKwCAVwMAAPgrAIBsAwAA ECwAgG0DAAAoLACAiwMAAEAsAIDpAwAAWCwAgAEEAABwLACAAgQAAIgsAIASBAAAoCwAgBUE AAC4LACAFgQAANAsAIByBAAA6CwAgHUEAAAALQCAdgQAABgtAIDjBAAAMC0AgOQEAABILQCA 5QQAAGAtAIABDgAAeC0AgHEOAACQLQCA8Q4AAKgtAIDyDgAAwC0AgPMOAADYLQCAAQ8AAPAt AIACDwAACC4AgAMPAAAgLgCABQ8AADguAIAJDwAAUC4AgAoPAABoLgCAEQ8AAIAuAIASDwAA mC4AgBMPAACwLgCAGQ8AAMguAIAaDwAA4C4AgBsPAAD4LgCAHA8AABAvAIAdDwAAKC8AgAAA AAAAAAAAAAAAAAAAAgABAAAAQC8AgBV5AABYLwCAAAAAAAAAAAAAAAAAEgAAAMpUAIBwLwCA RFMAgIgvAIAqUwCAoC8AgFRTAIC4LwCAfFMAgNAvAIAKVACA6C8AgJxTAIAAMACAulMAgBgw AIDmUwCAMDAAgB5UAIBIMACA9FQAgGAwAIBOVACAeDAAgCxUAICQMACAZFQAgKgwAIB+VACA wDAAgPJSAIDYMACACFMAgPAwAICWVACACDEAgAAAAAAAAAAAAAAAAAAAMgDIAAAAIDEAgMkA AAA4MQCAygAAAFAxAIDLAAAAaDEAgMwAAACAMQCA9QAAAJgxAID2AAAAsDEAgPkAAADIMQCA /wAAAOAxAIAKAQAA+DEAgAsBAAAQMgCADAEAACgyAIANAQAAQDIAgBgBAABYMgCAGQEAAHAy AIAaAQAAiDIAgB4BAACgMgCAHwEAALgyAIAgAQAA0DIAgCgBAADoMgCAhEcAAAAzAICGRwAA GDMAgIdHAAAwMwCAiEcAAEgzAICJRwAAYDMAgIpHAAB4MwCAi0cAAJAzAICMRwAAqDMAgJVH AADAMwCAlkcAANgzAICXRwAA8DMAgJhHAAAINACAmUcAACA0AICaRwAAODQAgJtHAABQNACA nEcAAGg0AIDURwAAgDQAgNVHAACYNACAAXkAALA0AIACeQAAyDQAgAN5AADgNACABHkAAPg0 AIAFeQAAEDUAgAZ5AAAoNQCAB3kAAEA1AIAIeQAAWDUAgAl5AABwNQCACnkAAIg1AIALeQAA oDUAgAx5AAC4NQCAAAAAAAAAAAAAAAAAAAAFAAEAAADQNQCAAgAAAOg1AIADAAAAADYAgAQA AAAYNgCA7EcAADA2AIAAAAAAAAAAAAAAAAAAAAEAAQAAAEg2AIAAAAAAAAAAAAAAAAAAAAEA GgEAAGA2AIAAAAAAAAAAAAAAAAAAAAEACQQAAHg2AAAAAAAAAAAAAAAAAAAAAAEACQQAAIg2 AAAAAAAAAAAAAAAAAAAAAAEACQQAAJg2AAAAAAAAAAAAAAAAAAAAAAEACQQAAKg2AAAAAAAA AAAAAAAAAAAAAAEACQQAALg2AAAAAAAAAAAAAAAAAAAAAAEACQQAAMg2AAAAAAAAAAAAAAAA AAAAAAEACQQAANg2AAAAAAAAAAAAAAAAAAAAAAEACQQAAOg2AAAAAAAAAAAAAAAAAAAAAAEA CQQAAPg2AAAAAAAAAAAAAAAAAAAAAAEACQQAAAg3AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --Z1248j60sAu7B3DD7pd22R3T53371CC --Z1248j60sAu7B3DD7pd22R3T53371CC Content-Type: application/octet-stream; name=Choosing a kernel.htm Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwNTQpaHR0cDovL3d3dy5saW51eGRv Yy5vcmcvSE9XVE8vQm9vdGRpc2stSE9XVE8veDY4Ny5odG1sIC0tPg0KPEhUTUw+PEhFQUQ+ PFRJVExFPkNob29zaW5nIGEga2VybmVsPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1aXY9Q29u dGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0K PE1FVEEgY29udGVudD0iTVNIVE1MIDUuNTAuNDEzNC4xMDAiIG5hbWU9R0VORVJBVE9SPjxM SU5LIA0KdGl0bGU9IlRoZSBMaW51eCBCb290ZGlzayBIT1dUTyIgaHJlZj0iaW5kZXguaHRt bCIgcmVsPUhPTUU+PExJTksgDQp0aXRsZT0iQnVpbGRpbmcgYSByb290IGZpbGVzeXN0ZW0i IGhyZWY9ImJ1aWxkcm9vdC5odG1sIiByZWw9UFJFVklPVVM+PExJTksgDQp0aXRsZT0iUHV0 dGluZyB0aGVtIHRvZ2V0aGVyOiBNYWtpbmcgdGhlIGRpc2tldHRlKHMpIiBocmVmPSJ4NzAy Lmh0bWwiIA0KcmVsPU5FWFQ+PC9IRUFEPg0KPEJPRFkgY2xhc3M9U0VDVDEgdGV4dD0jMDAw MDAwIHZMaW5rPSM4NDAwODQgYUxpbms9IzAwMDBmZiBsaW5rPSMwMDAwZmYgDQpiZ0NvbG9y PSNmZmZmZmY+DQo8RElWIGNsYXNzPU5BVkhFQURFUj4NCjxUQUJMRSBjZWxsU3BhY2luZz0w IGNlbGxQYWRkaW5nPTAgd2lkdGg9IjEwMCUiIGJvcmRlcj0wPg0KICA8VEJPRFk+DQogIDxU Uj4NCiAgICA8VEggYWxpZ249bWlkZGxlIGNvbFNwYW49Mz5UaGUgTGludXggQm9vdGRpc2sg SE9XVE88L1RIPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgdkFsaWduPWJvdHRvbSBhbGlnbj1s ZWZ0IHdpZHRoPSIxMCUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5saW51eGRvYy5v cmcvSE9XVE8vQm9vdGRpc2stSE9XVE8vYnVpbGRyb290Lmh0bWwiPlByZXY8L0E+PC9URD4N CiAgICA8VEQgdkFsaWduPWJvdHRvbSBhbGlnbj1taWRkbGUgd2lkdGg9IjgwJSI+PC9URD4N CiAgICA8VEQgdkFsaWduPWJvdHRvbSBhbGlnbj1yaWdodCB3aWR0aD0iMTAlIj48QSANCiAg ICAgIGhyZWY9Imh0dHA6Ly93d3cubGludXhkb2Mub3JnL0hPV1RPL0Jvb3RkaXNrLUhPV1RP L3g3MDIuaHRtbCI+TmV4dDwvQT48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPg0KPEhSIGFs aWduPWxlZnQgd2lkdGg9IjEwMCUiPg0KPC9ESVY+DQo8RElWIGNsYXNzPVNFQ1QxPg0KPEgx IGNsYXNzPVNFQ1QxPjxBIG5hbWU9QUVONjg3PjUuIENob29zaW5nIGEga2VybmVsPC9BPjwv SDE+DQo8UD5BdCB0aGlzIHBvaW50IHlvdSBoYXZlIGEgY29tcGxldGUgY29tcHJlc3NlZCBy b290IGZpbGVzeXN0ZW0uIFRoZSBuZXh0IHN0ZXAgDQppcyB0byBidWlsZCBvciBzZWxlY3Qg YSBrZXJuZWwuIEluIG1vc3QgY2FzZXMgaXQgd291bGQgYmUgcG9zc2libGUgdG8gY29weSB5 b3VyIA0KY3VycmVudCBrZXJuZWwgYW5kIGJvb3QgdGhlIGRpc2tldHRlIGZyb20gdGhhdC4g SG93ZXZlciwgdGhlcmUgbWF5IGJlIGNhc2VzIA0Kd2hlcmUgeW91IHdpc2ggdG8gYnVpbGQg YSBzZXBhcmF0ZSBvbmUuPC9QPg0KPFA+T25lIHJlYXNvbiBpcyBzaXplLiBJZiB5b3UgYXJl IGJ1aWxkaW5nIGEgc2luZ2xlIGJvb3Qvcm9vdCBkaXNrZXR0ZSwgdGhlIA0Ka2VybmVsIHdp bGwgYmUgb25lIG9mIHRoZSBsYXJnZXN0IGZpbGVzIG9uIHRoZSBkaXNrZXR0ZSBzbyB5b3Ug d2lsbCBoYXZlIHRvIA0KcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBrZXJuZWwgYXMgbXVjaCBh cyBwb3NzaWJsZS4gVG8gcmVkdWNlIGtlcm5lbCBzaXplLCBidWlsZCANCml0IHdpdGggdGhl IG1pbnVtdW0gc2V0IG9mIGZhY2lsaXRpZXMgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgdGhlIGRl c2lyZWQgc3lzdGVtLiANClRoaXMgbWVhbnMgbGVhdmluZyBvdXQgZXZlcnl0aGluZyB5b3Ug ZG9uJ3QgbmVlZC4gTmV0d29ya2luZyBpcyBhIGdvb2QgdGhpbmcgdG8gDQpsZWF2ZSBvdXQs IGFzIHdlbGwgYXMgc3VwcG9ydCBmb3IgYW55IGRpc2sgZHJpdmVzIGFuZCBvdGhlciBkZXZp Y2VzIHdoaWNoIHlvdSANCmRvbid0IG5lZWQgd2hlbiBydW5uaW5nIHlvdXIgYm9vdC9yb290 IHN5c3RlbS4gQXMgc3RhdGVkIGJlZm9yZSwgeW91ciBrZXJuZWwgDQo8RU0+bXVzdDwvRU0+ IGhhdmUgcmFtZGlzayBhbmQgZXh0MiBzdXBwb3J0IGJ1aWx0IGludG8gaXQuPC9QPg0KPFA+ SGF2aW5nIHdvcmtlZCBvdXQgYSBtaW5pbXVtIHNldCBvZiBmYWNpbGl0aWVzIHRvIGluY2x1 ZGUgaW4gYSBrZXJuZWwsIHlvdSANCnRoZW4gbmVlZCB0byB3b3JrIG91dCB3aGF0IHRvIGFk ZCBiYWNrIGluLiBQcm9iYWJseSB0aGUgbW9zdCBjb21tb24gdXNlcyBmb3IgYSANCmJvb3Qv cm9vdCBkaXNrZXR0ZSBzeXN0ZW0gd291bGQgYmUgdG8gZXhhbWluZSBhbmQgcmVzdG9yZSBh IGNvcnJ1cHRlZCByb290IGZpbGUgDQpzeXN0ZW0sIGFuZCB0byBkbyB0aGlzIHlvdSBtYXkg bmVlZCBrZXJuZWwgc3VwcG9ydC4gRm9yIGV4YW1wbGUsIGlmIHlvdXIgYmFja3VwcyANCmFy ZSBhbGwgaGVsZCBvbiB0YXBlIHVzaW5nIEZ0YXBlIHRvIGFjY2VzcyB5b3VyIHRhcGUgZHJp dmUsIHRoZW4sIGlmIHlvdSBsb3NlIA0KeW91ciBjdXJyZW50IHJvb3QgZHJpdmUgYW5kIGRy aXZlcyBjb250YWluaW5nIEZ0YXBlLCB0aGVuIHlvdSB3aWxsIG5vdCBiZSBhYmxlIA0KdG8g cmVzdG9yZSBmcm9tIHlvdXIgYmFja3VwIHRhcGVzLiBZb3Ugd2lsbCBoYXZlIHRvIHJlaW5z dGFsbCBMaW51eCwgZG93bmxvYWQgDQphbmQgcmVpbnN0YWxsIDxCIGNsYXNzPUNPTU1BTkQ+ ZnRhcGU8L0I+LCBhbmQgdGhlbiB0cnkgdG8gcmVhZCB5b3VyIGJhY2t1cHMuPC9QPg0KPFA+ VGhlIHBvaW50IGhlcmUgaXMgdGhhdCwgd2hhdGV2ZXIgSS9PIHN1cHBvcnQgeW91IGhhdmUg YWRkZWQgdG8geW91ciBrZXJuZWwgdG8gDQpzdXBwb3J0IGJhY2t1cHMgc2hvdWxkIGFsc28g YmUgYWRkZWQgaW50byB5b3VyIGJvb3Qvcm9vdCBrZXJuZWwuPC9QPg0KPFA+VGhlIHByb2Nl ZHVyZSBmb3IgYWN0dWFsbHkgYnVpbGRpbmcgdGhlIGtlcm5lbCBpcyBkZXNjcmliZWQgaW4g dGhlIA0KZG9jdW1lbnRhdGlvbiB0aGF0IGNvbWVzIHdpdGggdGhlIGtlcm5lbC4gSXQgaXMg cXVpdGUgZWFzeSB0byBmb2xsb3csIHNvIHN0YXJ0IA0KYnkgbG9va2luZyBpbiA8VFQgY2xh c3M9RklMRU5BTUU+L3Vzci9zcmMvbGludXg8L1RUPi4gSWYgeW91IGhhdmUgdHJvdWJsZSAN CmJ1aWxkaW5nIGEga2VybmVsLCB5b3Ugc2hvdWxkIHByb2JhYmx5IG5vdCBhdHRlbXB0IHRv IGJ1aWxkIGJvb3Qvcm9vdCBzeXN0ZW1zIA0KYW55d2F5LiBSZW1lbWJlciB0byBjb21wcmVz cyB0aGUga2VybmVsIHdpdGggYGA8QiBjbGFzcz1DT01NQU5EPm1ha2UgDQp6SW1hZ2U8L0I+ JycuPC9QPjwvRElWPg0KPERJViBjbGFzcz1OQVZGT09URVI+DQo8SFIgYWxpZ249bGVmdCB3 aWR0aD0iMTAwJSI+DQoNCjxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lk dGg9IjEwMCUiIGJvcmRlcj0wPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgdkFsaWdu PXRvcCBhbGlnbj1sZWZ0IHdpZHRoPSIzMyUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3 dy5saW51eGRvYy5vcmcvSE9XVE8vQm9vdGRpc2stSE9XVE8vYnVpbGRyb290Lmh0bWwiPlBy ZXY8L0E+PC9URD4NCiAgICA8VEQgdkFsaWduPXRvcCBhbGlnbj1taWRkbGUgd2lkdGg9IjM0 JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmxpbnV4ZG9jLm9yZy9IT1dUTy9Cb290 ZGlzay1IT1dUTy9pbmRleC5odG1sIj5Ib21lPC9BPjwvVEQ+DQogICAgPFREIHZBbGlnbj10 b3AgYWxpZ249cmlnaHQgd2lkdGg9IjMzJSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3 LmxpbnV4ZG9jLm9yZy9IT1dUTy9Cb290ZGlzay1IT1dUTy94NzAyLmh0bWwiPk5leHQ8L0E+ PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIHZBbGlnbj10b3AgYWxpZ249bGVmdCB3aWR0 aD0iMzMlIj5CdWlsZGluZyBhIHJvb3QgZmlsZXN5c3RlbTwvVEQ+DQogICAgPFREIHZBbGln bj10b3AgYWxpZ249bWlkZGxlIHdpZHRoPSIzNCUiPiZuYnNwOzwvVEQ+DQogICAgPFREIHZB bGlnbj10b3AgYWxpZ249cmlnaHQgd2lkdGg9IjMzJSI+UHV0dGluZyB0aGVtIHRvZ2V0aGVy OiBNYWtpbmcgdGhlIA0KICAgICAgZGlza2V0dGUocyk8L1REPjwvVFI+PC9UQk9EWT48L1RB QkxFPjwvRElWPjwvQk9EWT48L0hUTUw+DQ=9 --Z1248j60sAu7B3DD7pd22R3T53371CC-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 8 00:53:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g487rKrP026557; Wed, 8 May 2002 00:53:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g487rKYs026556; Wed, 8 May 2002 00:53: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.3+Sun/8.12.3) with ESMTP id g487rGrP026549 for ; Wed, 8 May 2002 00:53:16 -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 AAA11715 for ; Wed, 8 May 2002 00:53:17 -0700 (PDT) Received: from web21505.mail.yahoo.com (web21505.mail.yahoo.com [66.163.169.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA29749 for ; Wed, 8 May 2002 01:53:16 -0600 (MDT) Message-ID: <20020508075315.67691.qmail@web21505.mail.yahoo.com> Received: from [202.141.1.20] by web21505.mail.yahoo.com via HTTP; Wed, 08 May 2002 00:53:15 PDT Date: Wed, 8 May 2002 00:53:15 -0700 (PDT) From: Shashidhar MC Subject: RSVP for IPv6 Linux RH 7.1 To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-879447949-1020844395=:67653" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-879447949-1020844395=:67653 Content-Type: text/plain; charset=us-ascii Hello, I am doing a student project which involves streaming of media on an IPv6 network. I request you to kindly tell me how to go about setting up the RSVP enabled machines for my experiment. I use Linux ker ver. 2.4.2-2 (Red Hat 7.1) with the IPv6 module enabled Please tell me which implementations should I download and from where. Also what are the patches I should be applying for a Linux IPv6 machine. Thanks in advance. Waiting for your reply. Regards, -Shashi. --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --0-879447949-1020844395=:67653 Content-Type: text/html; charset=us-ascii

Hello,

I am doing a student project which involves streaming of media on an IPv6 network.

I request you to kindly tell me how to go about setting up the RSVP enabled machines for my
experiment.

I use Linux ker ver. 2.4.2-2 (Red Hat 7.1) with the IPv6 module enabled  

Please tell me which implementations should I download and from where. Also what are the patches I should be applying for a Linux IPv6 machine.

Thanks in advance.

Waiting for your reply.

Regards,
-Shashi.


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness --0-879447949-1020844395=:67653-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 8 01:02:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4882RrP026620; Wed, 8 May 2002 01:02:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4882RHL026619; Wed, 8 May 2002 01:02: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.3+Sun/8.12.3) with ESMTP id g4882NrP026612 for ; Wed, 8 May 2002 01:02: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 BAA25588 for ; Wed, 8 May 2002 01:02:19 -0700 (PDT) Received: from pluton.ispras.ru ([195.208.53.253]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA14387 for ; Wed, 8 May 2002 02:02:17 -0600 (MDT) Received: (qmail 17960 invoked from network); 8 May 2002 07:53:03 -0000 Received: from unknown (HELO gate.ispras.ru) (195.208.32.200) by pluton.ispras.ru with SMTP; 8 May 2002 07:53:03 -0000 Received: from gate.ispras.ru (gate.ispras.ru [195.208.32.200]) by gate.ispras.ru (8.12.2/8.12.2) with ESMTP id g48821Q4011361; Wed, 8 May 2002 12:02:01 +0400 (MSK) Date: Wed, 8 May 2002 12:02:01 +0400 (MSK) From: Grigory Kljuchnikov To: Shashidhar MC cc: ipng@sunroof.eng.sun.com Subject: Re: RSVP for IPv6 Linux RH 7.1 In-Reply-To: <20020508075315.67691.qmail@web21505.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You may see USAGI IPv6 Implementaion www.linux-ipv6.org On Wed, 8 May 2002, Shashidhar MC wrote: > > Hello, > > I am doing a student project which involves streaming of media on an IPv6 network. > > I request you to kindly tell me how to go about setting up the RSVP enabled machines for my > experiment. > > I use Linux ker ver. 2.4.2-2 (Red Hat 7.1) with the IPv6 module enabled > > Please tell me which implementations should I download and from where. Also what are the patches I should be applying for a Linux IPv6 machine. > > Thanks in advance. > > Waiting for your reply. > > Regards, > -Shashi. > > > > --------------------------------- > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness Grigory Klyuchnikov, System Engineer, Institute for System Programming Russian Academy of Sciences -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 8 03:11:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48ABMrP026843; Wed, 8 May 2002 03:11:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48ABMOj026842; Wed, 8 May 2002 03:11: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.3+Sun/8.12.3) with ESMTP id g48ABJrP026835 for ; Wed, 8 May 2002 03:11:19 -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 DAA26117 for ; Wed, 8 May 2002 03:11:20 -0700 (PDT) Received: from web21510.mail.yahoo.com (web21510.mail.yahoo.com [66.163.169.59]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA16667 for ; Wed, 8 May 2002 03:11:20 -0700 (PDT) Message-ID: <20020508101120.4584.qmail@web21510.mail.yahoo.com> Received: from [202.141.1.20] by web21510.mail.yahoo.com via HTTP; Wed, 08 May 2002 03:11:20 PDT Date: Wed, 8 May 2002 03:11:20 -0700 (PDT) From: Shashidhar MC Subject: IPv6 address assignment To: 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 Hello, I have ipv6 running on linux 2.4.2-2 on 6 machines. I want to setup a IPv6 network which looks something like this. M1 -------- -----M3 | | |--------G1 ------- G2 ------| | | M2 -------- ------M4 I need to configure G1 and G2 as gateways and the rest as hosts. This is an isolated IPv6 network and will not be connected to the Internet. How do I assign IPv6 addresses to them ? Also what prefix should be used so as to have 3 different subnetworks - M1 & M2 form subnetwork1 G1 & G2 form subnetwork2 M3 & M4 form subnetwork3 All these machines will be connected to one single ethernet hub, so how do I configure G1 and G1 to act as IPv6 gateways and the rest as IPv6 hosts ? thanks in advance shashi __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.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 Wed May 8 08:33:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48FX6rP027226; Wed, 8 May 2002 08:33:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48FX6sg027225; Wed, 8 May 2002 08:33: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.3+Sun/8.12.3) with ESMTP id g48FX2rP027218 for ; Wed, 8 May 2002 08:33:02 -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 IAA23667 for ; Wed, 8 May 2002 08:33:04 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28789 for ; Wed, 8 May 2002 08:33:03 -0700 (PDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g48FWlOW028713; Wed, 8 May 2002 08:32:51 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AEH01233 (AUTH raraghun); Wed, 8 May 2002 20:59:45 +0530 (IST) Message-ID: <3CD9451B.26EBDC1E@cisco.com> Date: Wed, 08 May 2002 21:02:43 +0530 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: Lorenzo Colitti CC: ipng@sunroof.eng.sun.com Subject: Re: Which IPv6 MIB should I use? References: <3CD7F02A.6090104@colitti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Lorenzo, > I could try to extend net-snmp on linux, to support what I need, but > which of the two MIBs should I implement? Which MIBs are going to be > standard and used in the future? The draft by Fenner et. al. updates RFC 2011, and should, in all probability, go on to replace RFC 2465 as a version independent IP MIB in the future. -Rajiv. > > Regards, > Lorenzo Colitti > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 8 12:52:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48JqZrP027710; Wed, 8 May 2002 12:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48JqZDu027709; Wed, 8 May 2002 12: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48JqWrP027702 for ; Wed, 8 May 2002 12:52:32 -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 MAA23928 for ; Wed, 8 May 2002 12:52:34 -0700 (PDT) Received: from web8004.mail.in.yahoo.com (web8004.in.yahoo.com [203.199.70.64]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA28405 for ; Wed, 8 May 2002 13:52:33 -0600 (MDT) Message-ID: <20020508195232.4832.qmail@web8004.mail.in.yahoo.com> Received: from [202.141.25.117] by web8004.mail.in.yahoo.com via HTTP; Wed, 08 May 2002 20:52:32 BST Date: Wed, 8 May 2002 20:52:32 +0100 (BST) From: =?iso-8859-1?q?iccc2002?= Subject: ICCC 2002 - Call For Papers To: iccc_2002@yahoo.co.in 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 Please accept our apologies should you receive multiple copies of the mail. Also, we hope that you find the information in the mail useful to you. Our apologies if you feel that we are spamming. ******************************************************************* * * * ICCC 2002 * * * * INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATION * * * * http://iccc2002.ernet.in/ * * August 11-14, 2002 * * Regent Hotel, Bandra, Mumbai, India * * * * Organized by * * The International Council for Computer Communicaion * * * ******************************************************************* Call for Papers =============== "Redefining Internet in the context of Pervasive Computing" Ubiquitous access to pervasive mobile, static and embedded computing resources, will have profound implications for individuals and societies. ICCC 2002 will address technologies, applications, and changes in personal and social life under the theme "Redefining Internet in the context of Pervasive Computing". Original papers are solicited on the topics mentioned below 1. Topics --------- Access Networks for Data Communication Active and Programmable Networks Algorithms for Routing Multicasting and Addressing Audio Indexing BISDN and ATM Broadband Internet Applications Collaborative Workspaces E-Commerce Technologies Electronic Commerce Systems Electronic Publishing Home Networking and Appliances Intelligent Search Engines Internet Growth, Reliability and Management Issues Internet Security Technologies Internet Telephony Intrusion Detection Systems IP over Wireless Mobility Architectures Multimedia Technologies and Networking   Multi-Protocol Label Switching Network Management and Intelligent Networking Nomadic Computing Otical Internet: IP on WDM, Optical Signaling On-line Communities Protocol Engineering QoS in IP networks Security, Authentication and (Traffic engineering, DiffServ, Accounting Systems Media Streaming) Virtual Organizations Virtual Private Networks Web Based Education          Web Farming and Web Caching            Web Traffic Management and Control Wireless Networks; 3G mobile/wireless LAN Integration Wireless ATM 2. Information for Authors -------------------------- Papers should be submitted in PostScript(.ps), Portable Document Format(.pdf) or Microsoft Word Document(.doc) format through the conference website at http://iccc2002.ernet.in/. In case of any problems registering and uploading the paper at the conference website, the paper may be sent via email to iccc2002@iitm.ernet.in Papers should include: Title, name(s) and affiliations(s) of authors, an abstract of no more than 200 words, a set of relevant keywords, text of 2000-6000 words plus figures resulting in a manuscript of no more than 25 double-spaced A4-size pages, and completely cited references including page numbers.     All papers will be refereed and those accepted for presentation at the conference will be included in the Conference Proceedings, to be published by ICCC Press. 3. Important Dates ------------------ 31st May 2002 Last Date for receipt of submitted papers 30th June 2002 Notification of acceptance/rejection 15th July 2002 Last Date for receiving final camera-ready verison of accepted papers 4. Further Details ------------------ Further details are available at the conference website http://iccc2002.ernet.in. or you can directly email your queries to: Prof. S V Raghavan, Network Systems Laboratory, Department of Computer Science and Engineering Indian Institute of Technology Madras, Chennai 600036 INDIA. Tel (Voice) : +91 44 257 8337 (Office) 8355 (Laboratory) 8331 (Messages) Tel (Fax)  : +91 44 257 8352 Email : iccc2002@iitm.ernet.in 5. Program Format -----------------   ICCC 2002 will be organized in sessions addressing key topics. There will be a set of keynote addresses, invited talks, tutorials and state of the art reports, given by internationally renowned researchers and industry leaders.    6. Pre-Conference Tutorial --------------------------   In line with the International Conference convention, pre-conference tutorials (half day / Full day) will be organized in state-of-the-art topics. Proposals are invited giving the topic, extent of coverage, intended audience, and benefits. Please send your proposals to Mr S. Ramakrishnan at ramki@doe.ernet.in with a copy to the Principal Programme Chair at iccc2002@iitm.ernet.in.   7. Technology Showcase Presentations ------------------------------------   ICCC 2002 will additionally invite non-commercial, presentations by manufacturers and vendors on their latest communications technologies. These presentations will provide an excellent opportunity for leading technology developers to describe their latest developments to the conference audience. For further information, please contact the Conference Secretariat.   8. About the location - Mumbai ------------------------------   Mumbai, formerly known as Bombay, is the capital of Maharashtra state and the business capital of India.  It is the fastest moving, and most industrialized city in India. The main languages spoken in the city are Hindi (official language of India) and Marathi (official language of Maharashtra state). Visitors can manage their business/travel with English, which is also widely understood and spoken. Mumbai is well connected and is served by most international and domestic airlines.   August is the last of the three monsoon months. The highest daily temperature at that time would normally be 29 degrees Celsius that is 84 degrees Fahrenheit.   Regular tours from the city provide easy access to the ancient cave paintings and sculptures of Ajanta and Ellora. Mumbai also has shopping malls for good bargains in rich Indian garments.      9. Venue --------   Regent Hotel, Bandra West, Mumbai 400 050, India, a new hotel on theArabian Sea along the beach with all five star facilities and about 25-30 minutes drive from Mumbai airport. ________________________________________________________________________ For live cricket scores download Yahoo! Score Tracker at: http://in.sports.yahoo.com/cricket/tracker.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 9 09:21:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49GLqrP029590; Thu, 9 May 2002 09:21:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49GLqTh029589; Thu, 9 May 2002 09:21: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.3+Sun/8.12.3) with ESMTP id g49GLnrP029582 for ; Thu, 9 May 2002 09:21:49 -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 JAA06045 for ; Thu, 9 May 2002 09:21:51 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23563 for ; Thu, 9 May 2002 09:21:51 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 9 May 2002 12:21:49 -0400 Message-ID: <3CDAA166.42EDD961@nc.rr.com> Date: Thu, 09 May 2002 12:18:46 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Changes to MLD to support Anycast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, Just to give everyone the ability to review the draft, here is the announcement of the draft outlining changes to MLD to support hosts announcing their membership in anycast groups. Ideally, these changes will get incorporated into the MLDv2 spec at some point. Regards, Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Host-based Anycast using MLD > Author(s) : B. Haberman, D. Thaler > Filename : draft-haberman-ipngwg-host-anycast-01.txt > Pages : 5 > Date : 08-May-02 > > This specification defines extended uses of the Multicast Listener > Discovery protocol to support hosts participating in anycast groups. > The extensions presented in this document allow hosts to notify the > routing system of membership changes in an anycast group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-host-anycast-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-haberman-ipngwg-host-anycast-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-haberman-ipngwg-host-anycast-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20020508135823.I-D@ietf.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 May 9 09:35:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49GZJrP029616; Thu, 9 May 2002 09:35:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49GZJCH029615; Thu, 9 May 2002 09:35: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.3+Sun/8.12.3) with ESMTP id g49GZFrP029608 for ; Thu, 9 May 2002 09:35:15 -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 JAA11855 for ; Thu, 9 May 2002 09:35:14 -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 KAA12344 for ; Thu, 9 May 2002 10:35:12 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B66144B22; Fri, 10 May 2002 01:35:06 +0900 (JST) To: Brian Haberman Cc: IPng Mailing List In-reply-to: bkhabs's message of Thu, 09 May 2002 12:18:46 -0400. <3CDAA166.42EDD961@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: Changes to MLD to support Anycast From: itojun@iijlab.net Date: Fri, 10 May 2002 01:35:06 +0900 Message-ID: <11045.1020962106@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >All, > Just to give everyone the ability to review the draft, here is >the announcement of the draft outlining changes to MLD to support >hosts announcing their membership in anycast groups. Ideally, these >changes will get incorporated into the MLDv2 spec at some point. i believe we don't have consensus on how we should deal with anycast route injection. there are at least several ways. my preference is with the first option below. as anycast address is being be treated in similar ways as unicast address, i think it most natural option. itojun - node with anycast address(*) participating routing exchange pros: deployable now, routing protocol has mechanisms for protecting against malicious route injection (sometimes they are just "use IPsec"...) cons: some hates it when the node is a host - node with anycast address(*) sending MLD packet, adjacent router injects a route to the cloud pros: less entity speaking routing protocol cons: deployment delay, protection mechanism not really there (*) must be a router based on RFC2460 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 9 09:38:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49GcdrP029633; Thu, 9 May 2002 09:38:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49GcdZG029632; Thu, 9 May 2002 09:38: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.3+Sun/8.12.3) with ESMTP id g49GcZrP029625 for ; Thu, 9 May 2002 09:38:35 -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 JAA06836 for ; Thu, 9 May 2002 09:38: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 JAA12098 for ; Thu, 9 May 2002 09:38:37 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DADFB4B22; Fri, 10 May 2002 01:38:34 +0900 (JST) To: Brian Haberman , IPng Mailing List In-reply-to: itojun's message of Fri, 10 May 2002 01:35:06 +0900. <11045.1020962106@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: Changes to MLD to support Anycast From: itojun@iijlab.net Date: Fri, 10 May 2002 01:38:34 +0900 Message-ID: <11101.1020962314@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>All, >> Just to give everyone the ability to review the draft, here is >>the announcement of the draft outlining changes to MLD to support >>hosts announcing their membership in anycast groups. Ideally, these >>changes will get incorporated into the MLDv2 spec at some point. > i believe we don't have consensus on how we should deal with anycast > route injection. there are at least several ways. my preference is > with the first option below. as anycast address is being be treated > in similar ways as unicast address, i think it most natural option. it also is consistent with currently-practiced IPv4 anycast (or, unicast address assigned to multiple nodes), like those documented in draft-ietf-dnsop-*-shared-root-server*. 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 May 9 10:51:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49HpmrP029903; Thu, 9 May 2002 10:51:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49HplZb029902; Thu, 9 May 2002 10:51: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.3+Sun/8.12.3) with ESMTP id g49HpirP029895 for ; Thu, 9 May 2002 10:51:44 -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 KAA15845 for ; Thu, 9 May 2002 10:51:45 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22050 for ; Thu, 9 May 2002 11:51:44 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 9 May 2002 13:50:09 -0400 Message-ID: <3CDAB61D.335A22A0@nc.rr.com> Date: Thu, 09 May 2002 13:47:09 -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: IPng Mailing List Subject: Re: Changes to MLD to support Anycast References: <11045.1020962106@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My concern with the first option is that it requires new functionality on the host joining an anycast group, namely running a routing protocol. Generally, hosts already support MLD/IGMP in order to join multicast groups, so why require them to run a routing protocol? Brian itojun@iijlab.net wrote: > > >All, > > Just to give everyone the ability to review the draft, here is > >the announcement of the draft outlining changes to MLD to support > >hosts announcing their membership in anycast groups. Ideally, these > >changes will get incorporated into the MLDv2 spec at some point. > > i believe we don't have consensus on how we should deal with anycast > route injection. there are at least several ways. my preference is > with the first option below. as anycast address is being be treated > in similar ways as unicast address, i think it most natural option. > > itojun > > - node with anycast address(*) participating routing exchange > pros: deployable now, routing protocol has mechanisms for > protecting against malicious route injection (sometimes > they are just "use IPsec"...) > cons: some hates it when the node is a host > - node with anycast address(*) sending MLD packet, adjacent router injects > a route to the cloud > pros: less entity speaking routing protocol > cons: deployment delay, protection mechanism not really there > > (*) must be a router based on RFC2460 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 9 20:56:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A3utrP001136; Thu, 9 May 2002 20:56:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4A3usdl001135; Thu, 9 May 2002 20:56: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.3+Sun/8.12.3) with ESMTP id g4A3uprP001128 for ; Thu, 9 May 2002 20:56:51 -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 UAA12981 for ; Thu, 9 May 2002 20:56:53 -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 VAA21481 for ; Thu, 9 May 2002 21:57:09 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 682EF4B22; Fri, 10 May 2002 12:56:47 +0900 (JST) To: Brian Haberman Cc: IPng Mailing List In-reply-to: bkhabs's message of Thu, 09 May 2002 13:47:09 -0400. <3CDAB61D.335A22A0@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: Changes to MLD to support Anycast From: itojun@iijlab.net Date: Fri, 10 May 2002 12:56:47 +0900 Message-ID: <15438.1021003007@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My concern with the first option is that it requires new functionality >on the host joining an anycast group, namely running a routing protocol. it is not new at all. hosts have been running routing protocol daemons for a long time (sometimes it was only listening, like "routed -q"). >Generally, hosts already support MLD/IGMP in order to join multicast >groups, so why require them to run a routing protocol? at this moment no client implementation issues MLD join for anycast address, so it is a large change to make. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 10 11:16:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4AIG4rP002442; Fri, 10 May 2002 11:16:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4AIG33w002441; Fri, 10 May 2002 11:16: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.3+Sun/8.12.3) with ESMTP id g4AIG2rP002431 for ; Fri, 10 May 2002 11:16: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 g4AIFbaU022177 for ; Fri, 10 May 2002 11:15:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4AIFbqJ022176 for ipng@sunroof.eng.sun.com; Fri, 10 May 2002 11:15:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g47CirrP023704 for ; Tue, 7 May 2002 05:44:53 -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 FAA25634 for ; Tue, 7 May 2002 05:44:55 -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 GAA03799 for ; Tue, 7 May 2002 06:45:06 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g47Cid826112; Tue, 7 May 2002 21:44:39 +0900 (JST) Date: Tue, 07 May 2002 21:45:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH In-Reply-To: <200204231025.g3NAPkT65012@givry.rennes.enst-bretagne.fr> References: <200204231025.g3NAPkT65012@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. 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: 101 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I'm resending the following message, since it has not been delivered correctly.) >>>>> On Tue, 23 Apr 2002 12:25:46 +0200, >>>>> Francis Dupont said: > => there are two points: > - how to determine the zone of the next destination (as addresses > don't carry the id of the zone but only the scope, this is very useful). > - do it only on the next destination address, no further > (note this is a consequence of the previous point). > Only the wording is questionable... (i.e. I can't see a concern for > other thing than the form) Since the issue is about wording (I think we've agreed on this point), I won't try to respond to all questions in this thread. Instead, I'd like to propose revised text (see below) with an additional rule that Rich mentioned and an example of unusual (thus confusing) case. If the text is still unclear, please point it out, and if possible, suggest improvement (I'm not very good at describing complicated notion in English...). Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 9. Forwarding When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows: o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone. That routing table is restricted to refer only to interfaces belonging to that zone. o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded and an ICMP Destination Unreachable message [RFC 2463] with Code 2 ("beyond scope of source address") is sent to the source of the packet. Note that the above procedure applies for addresses of all scopes, including link-local. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may be transmitted back out the arrival interface, or out any other interface attached to the same link. A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left [RFC 2460, section 4.4] first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of the original destination address, the node MUST discard the packet. Otherwise, it swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules apply as follows: o The zone of the new destination address is determined by the scope of the next address in the Routing Header and arrival interface of the packet. The next-hop interface is chosen just like the first bullet of the rules above. o After the next-hop interface is chosen, the zone of the source address is considered just like the second bullet of the rules above. This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link-local then the receiving node can know that the packet originated on-link. Similarly, if the destination is site-local then the receiving node can know that the packet originated within the site. And, as a result, this will help the receiving node send a "response" packet with the final destination of the received packet as the source address without breaking its source zone. Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. For example, consider a case where a site-border node receives a packet with the destination being a site-local address. If the packet contains a Routing Header where the next address is a global address, the next-hop interface to the global address may belong to a different site than the site of the original destination. This is allowed, because the scope of the next address is not smaller than the scope of the original destination. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 00:41:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4C7fMrP004328; Sun, 12 May 2002 00:41:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4C7fMdo004327; Sun, 12 May 2002 00:41: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.3+Sun/8.12.3) with ESMTP id g4C7fJrP004320 for ; Sun, 12 May 2002 00:41:19 -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 AAA02501 for ; Sun, 12 May 2002 00:41:20 -0700 (PDT) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA23912 for ; Sun, 12 May 2002 00:41:19 -0700 (PDT) Received: (qmail 12223 invoked from network); 12 May 2002 07:41:17 -0000 Received: from p50805b62.dip.t-dialin.net (HELO ?192.168.1.2?) (80.128.91.98) by mail.bieringer.de with SMTP; 12 May 2002 07:41:17 -0000 Date: Sun, 12 May 2002 09:41:15 +0200 From: Peter Bieringer To: Maillist IPng Subject: Klez found majordomo address...causes big e-mail response Message-ID: <30690000.1021189275@localhost> X-Mailer: Mulberry/2.2.0 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm not sending this e-mail shown below, Klez running on some clients, digging through all the local mail storage. But it looks like that the majordomo is not very Klez-resistant, it tries to understand each line from begin to end of the HTML message (and the MIME part, too). This results in a 328 kByte big e-mail response. Is this majordomo's default behavior? Perhaps it should stop after around 20 lines of "Command not recognized".... If majordomo is uptodate, imho this is a candidate for a bugtraq posting. Peter - ---------- Forwarded Message ---------- Date: Saturday, May 11, 2002 10:50:28 PM -0700 From: Majordomo@sunroof.eng.sun.com To: pb@bieringer.de Subject: Majordomo results: How are you > Received: (qmail 11195 invoked from network); 12 May 2002 05:50:39 > -0000 Received: from pheriche.sun.com (192.18.98.34) > by mail.bieringer.de with SMTP; 12 May 2002 05:50:39 -0000 > Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) > by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06389 > for ; Sat, 11 May 2002 23:50:35 -0600 (MDT) > 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 WAA06006 for > ; Sat, 11 May 2002 22:50:34 -0700 (PDT) Received: > from sunroof.eng.sun.com (localhost [127.0.0.1]) > by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id > g4C5oUrP004263 for ; Sat, 11 May 2002 22:50:30 > -0700 (PDT) Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id > g4C5oSl7004262; Sat, 11 May 2002 22:50:28 -0700 (PDT) > Date: Sat, 11 May 2002 22:50:28 -0700 (PDT) > Message-Id: <200205120550.g4C5oSl7004262@sunroof.eng.sun.com> > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender > to Majordomo-Owner@sunroof.eng.sun.com using -f To: pb@bieringer.de > From: Majordomo@sunroof.eng.sun.com > Subject: Majordomo results: How are you > Reply-To: Majordomo@sunroof.eng.sun.com > > -- > >>>>> --AW4V32232m0lC5aW7x17iOk7UMmF6u431 > **** Command '--aw4v32232m0lc5aw7x17iok7ummf6u431' not recognized. >>>>> Content-Type: text/html; > **** Command 'content-type:' not recognized. >>>>> Content-Transfer-Encoding: quoted-printable > **** Command 'content-transfer-encoding:' not recognized. >>>>> >>>>> > **** Command '' not recognized. >>>>> > **** Command '' not recognized. >>>>> > **** Command '' not recognized. >>>>> >>>>> --AW4V32232m0lC5aW7x17iOk7UMmF6u431 > **** Command '--aw4v32232m0lc5aw7x17iok7ummf6u431' not recognized. >>>>> Content-Type: audio/x-midi; > **** Command 'content-type:' not recognized. >>>>> name=Options.exe > **** Command 'name=options.exe' not recognized. >>>>> Content-Transfer-Encoding: base64 > **** Command 'content-transfer-encoding:' not recognized. >>>>> Content-ID: > **** Command 'content-id:' not recognized. >>>>> >>>>> TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >>>>> AAAAAAAAA > **** Command > 'tvqqaamaaaaeaaaa//8aalgaaaaaaaaaqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > aaaaaa' not recognized. >>>>> AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSB >>>>> ydW4gaW4g > **** Command > 'aaaaaaaa2aaaaa4fug4atannibgbtm0hvghpcybwcm9ncmftignhbm5vdcbizsbydw > 4gaw4g' not recognized. >>>>> RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2 >>>>> zT/gTs7Tn - ---------- End Forwarded Message ---------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE83hyde1eqe5WPQi0RAq6zAJ431+M3HeYQftl+VYxxwiwZurFWBwCgza/1 ZtjFH6uM4RARHcWxnTTFEyw= =os4S -----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 Sun May 12 11:07:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4CI7qrP004993; Sun, 12 May 2002 11:07:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4CI7qNj004992; Sun, 12 May 2002 11:07: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.3+Sun/8.12.3) with ESMTP id g4CI7nrP004985 for ; Sun, 12 May 2002 11:07:49 -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 LAA25818 for ; Sun, 12 May 2002 11:07:50 -0700 (PDT) Received: from web11404.mail.yahoo.com (web11404.mail.yahoo.com [216.136.131.234]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA26749 for ; Sun, 12 May 2002 12:07:50 -0600 (MDT) Message-ID: <20020512180749.40153.qmail@web11404.mail.yahoo.com> Received: from [213.19.147.27] by web11404.mail.yahoo.com via HTTP; Sun, 12 May 2002 11:07:49 PDT Date: Sun, 12 May 2002 11:07:49 -0700 (PDT) From: mehrdad kheyrabi Subject: IP packet streams To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-702003032-1021226869=:38902" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-702003032-1021226869=:38902 Content-Type: text/plain; charset=us-ascii Hi there, I am a student from Iran, I need some IP packet streams to test my RFC3095 implementation but unfortunately I have not access to any available resources and I would greatly appreciate any kind help with the matter. I’ll be thankful if someone could introduce me some good resources as soon as possible. Warmest regards, Mehrdad --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-702003032-1021226869=:38902 Content-Type: text/html; charset=us-ascii

Hi there,

I am a student from Iran, I need some IP packet streams to test my RFC3095 implementation but unfortunately I have not access to any available resources and I would greatly appreciate any kind help with the matter. I’ll be thankful if someone could introduce me some good resources as soon as possible.

Warmest regards,

Mehrdad


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-702003032-1021226869=:38902-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 11:50:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4CIoerP005062; Sun, 12 May 2002 11:50:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4CIoehE005061; Sun, 12 May 2002 11:50: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.3+Sun/8.12.3) with ESMTP id g4CIobrP005054 for ; Sun, 12 May 2002 11:50:37 -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 LAA29235 for ; Sun, 12 May 2002 11:50:39 -0700 (PDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02813 for ; Sun, 12 May 2002 12:50:38 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 12 May 2002 14:49:04 -0400 Message-ID: <3CDEB868.F2F98744@nc.rr.com> Date: Sun, 12 May 2002 14:46:00 -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: IPng Mailing List Subject: Re: Changes to MLD to support Anycast References: <15438.1021003007@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Generally, hosts already support MLD/IGMP in order to join multicast > >groups, so why require them to run a routing protocol? > > at this moment no client implementation issues MLD join for > anycast address, so it is a large change to make. Sure, that is to be expected. The primary change would have to be in the checking of the group address. Today, implementations check to ensure that the group address passed in the join is a multicast address. So this is a change to the stack implementation. In order to perform authentication, MLD would have to be protected with a security scheme similar to that used for routing protocols. Your proposal would not require changes to a stack. The operator would be required to run whatever intra-domain routing protocol, possibly with some security key to protect the infrastructure, so the server would become a part of the set of trusted boxes in the network. I prefer having a fewer number of boxes injecting routes, but I am not committed to either approach yet. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 13 05:16:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DCGirP006095; Mon, 13 May 2002 05:16:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DCGick006094; Mon, 13 May 2002 05:16: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.3+Sun/8.12.3) with ESMTP id g4DCGfrP006087 for ; Mon, 13 May 2002 05:16: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 FAA17981 for ; Mon, 13 May 2002 05:16:43 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05799 for ; Mon, 13 May 2002 05:16:41 -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 g4DCFkC04429; Mon, 13 May 2002 19:15:46 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Steve Deering cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 May 2002 19:15:46 +0700 Message-ID: <4427.1021292146@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 1 May 2002 18:12:03 -0700 From: Steve Deering Message-ID: Sorry, I haven't been reading this list for the past few weeks, so this is a bit late. | No, "this week's" version of the proposed solution is to use three well- | known, site-local unicast addresses. How can this work if the server isn't in the same site as the client? Is the intent to require that servers (DNS currently, but others as well) must live in the same site as the clients? Whether this is reasonable or not largely depends upon how site boundaries will be set - maybe I missed it, but I don't recall anything actually specifying that, it seems to have been left very vague, and perhaps just "obvious". Which is always dangerous. To take the kind of example that is relevant here, I would always have assumed that my house will be a site - that way I keep on using my stable site local addresses when I change providers (and at least possibly, global addresses). That's why I thought the notion of sites existed. But I'm most likely not going to want to run a DNS server (back end resolver we're talking about here) in my house (or I personally might, but many others probably won't). So, if the site boundary is the link between my house and my ISP, how do I get to find the DNS back end, which is something that my ISP is providing for me? (For local address resolution I can use something like mDNS if that ever gets off the ground, of even /etc/hosts, as I would be using site local addressing for all internal comms, and I can make those addresses very stable). I'm also not likely to be running a DHCP server, so "you have to use managed addresses in that case" isn't a suitable answer. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 13 07:26:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEQVrP006337; Mon, 13 May 2002 07:26:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DEQV64006336; Mon, 13 May 2002 07:26: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.3+Sun/8.12.3) with ESMTP id g4DEQDrP006329 for ; Mon, 13 May 2002 07:26: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 HAA05230 for ; Mon, 13 May 2002 07:26:14 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12777 for ; Mon, 13 May 2002 08:26:13 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 13 May 2002 10:24:36 -0400 Message-ID: <3CDFCBEA.9E376FBE@nc.rr.com> Date: Mon, 13 May 2002 10:21:30 -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: IPng Mailing List Subject: Re: Changes to MLD to support Anycast References: <11045.1020962106@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: > - node with anycast address(*) participating routing exchange > pros: deployable now, routing protocol has mechanisms for > protecting against malicious route injection (sometimes > they are just "use IPsec"...) > cons: some hates it when the node is a host And how does a host, on the same link with the anycast-capable node, know to find that node locally? Do we have to accept triangular routing from host to router to anycast-capable node? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 13 07:29:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DETfrP006384; Mon, 13 May 2002 07:29:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DETfwW006383; Mon, 13 May 2002 07:29:41 -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.3+Sun/8.12.3) with ESMTP id g4DETcrP006376 for ; Mon, 13 May 2002 07:29:38 -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 HAA05954 for ; Mon, 13 May 2002 07:29:39 -0700 (PDT) Received: from mailwest.unispherenetworks.com (mailwest.unispheresolutions.com [65.194.140.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14192 for ; Mon, 13 May 2002 08:29:38 -0600 (MDT) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 10:29:37 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC4E96@uniwest1.it.west.unispherenetworks.com> From: "Deshpande, Prasad" To: "'bkhabs@nc.rr.com'" , IPng Mailing List Subject: RE: Automatic Prefix Delegation draft Date: Mon, 13 May 2002 10:29:36 -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 Hi, Is draft-haberman-ipngwg-auto-prefix-02.txt the latest version of this draft? I cant seem to find this draft on IETF page. thanks -prasad > -----Original Message----- > From: Brian Haberman [mailto:haberman@lorien.sc.innovationslab.net] > Sent: Thursday, March 07, 2002 7:57 AM > To: IPng Mailing List > Subject: Automatic Prefix Delegation draft > > > All, > Jim and I have updated the Automatic Prefix Delegation draft > to take into account comments and suggestions made in the last few > months. I submitted it to the I-D editor last week, but have not > seen it posted yet so it is attached. Comments and suggestions are > always welcome. > > Brian > ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 13 07:37:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEbXrP006437; Mon, 13 May 2002 07:37:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DEbXeQ006436; Mon, 13 May 2002 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEbUrP006429 for ; Mon, 13 May 2002 07:37: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 HAA26765 for ; Mon, 13 May 2002 07:37:31 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23428 for ; Mon, 13 May 2002 08:37:55 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4DEbT0E007916 for ; Mon, 13 May 2002 16:37:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon May 13 16:37:10 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4G4RF>; Mon, 13 May 2002 16:37:10 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F05D0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian Haberman'" , itojun@iijlab.net Cc: IPng Mailing List Subject: RE: Changes to MLD to support Anycast Date: Mon, 13 May 2002 16:37:03 +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 > > - node with anycast address(*) participating routing exchange > > pros: deployable now, routing protocol has mechanisms for > > protecting against malicious route > injection (sometimes > > they are just "use IPsec"...) > > cons: some hates it when the node is a host > > And how does a host, on the same link with the anycast-capable node, > know to find that node locally? Do we have to accept triangular > routing from host to router to anycast-capable node? => router redirects? Am I missing your point? Hesham > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 13 07:42:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEgBrP006491; Mon, 13 May 2002 07:42:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DEgBk7006490; Mon, 13 May 2002 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEg7rP006483 for ; Mon, 13 May 2002 07:42:07 -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 HAA28485 for ; Mon, 13 May 2002 07:42:08 -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 IAA26409 for ; Mon, 13 May 2002 08:42:31 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EB6284B22; Mon, 13 May 2002 23:42:01 +0900 (JST) To: Brian Haberman Cc: IPng Mailing List In-reply-to: bkhabs's message of Mon, 13 May 2002 10:21:30 -0400. <3CDFCBEA.9E376FBE@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: Changes to MLD to support Anycast From: itojun@iijlab.net Date: Mon, 13 May 2002 23:42:01 +0900 Message-ID: <13088.1021300921@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> - node with anycast address(*) participating routing exchange >> pros: deployable now, routing protocol has mechanisms for >> protecting against malicious route injection (sometimes >> they are just "use IPsec"...) >> cons: some hates it when the node is a host >And how does a host, on the same link with the anycast-capable node, >know to find that node locally? Do we have to accept triangular >routing from host to router to anycast-capable node? if the /64 prefix for the anycast address is the same as one used on the subnet, normal ND works just fine. otherwise, icmp6 redirect will take care of it. so there's no issue. 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 May 13 07:45:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DEjurP006514; Mon, 13 May 2002 07:45:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DEjui3006513; Mon, 13 May 2002 07:45: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.3+Sun/8.12.3) with ESMTP id g4DEjrrP006506 for ; Mon, 13 May 2002 07:45: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 HAA10325 for ; Mon, 13 May 2002 07:45:50 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23069 for ; Mon, 13 May 2002 08:45:49 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 13 May 2002 10:44:06 -0400 Message-ID: <3CDFD082.D6DCB118@nc.rr.com> Date: Mon, 13 May 2002 10:41:06 -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: IPng Mailing List Subject: Re: Changes to MLD to support Anycast References: <13088.1021300921@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: > > >> - node with anycast address(*) participating routing exchange > >> pros: deployable now, routing protocol has mechanisms for > >> protecting against malicious route injection (sometimes > >> they are just "use IPsec"...) > >> cons: some hates it when the node is a host > >And how does a host, on the same link with the anycast-capable node, > >know to find that node locally? Do we have to accept triangular > >routing from host to router to anycast-capable node? > > if the /64 prefix for the anycast address is the same as one used on > the subnet, normal ND works just fine. otherwise, icmp6 redirect will > take care of it. so there's no issue. Ugh, my brain was locked. Too early to be posting. :) Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 07:04:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EE4srP010106; Tue, 14 May 2002 07:04:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EE4sDp010105; Tue, 14 May 2002 07:04:54 -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.3+Sun/8.12.3) with ESMTP id g4EE4nrP010098 for ; Tue, 14 May 2002 07:04:50 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4EE4mg25027; Tue, 14 May 2002 16:04:48 +0200 (MEST) Date: Tue, 14 May 2002 16:04:01 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address To: Brian Haberman Cc: IPng Working Group In-Reply-To: "Your message with ID" <3CD18D41.108CEBAD@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > 1. Host-to-router notification protocol (this is taken care of by > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > 2. Security: at a minimum some form of authentication to allow > routers to determine if hosts are allowed to join an anycast > group > > 3. An Anycast Architecture doc that pulls all the pieces together > and concretely describes how pieces interact, the pros and cons > of anycast usage for intra-domain and inter-domain > > 4. Possibly a draft that documents any impacts on any existing > protocols (routing protocols, TCP, etc.) > > Now, I have not spent time on the subject in the last 4-5 months, so I > have not gotten much past this list. It is crucial that most of the > issues raised by Itojun's anycast analysis draft be addressed. I wonder if it would also be useful to add a "anycast binding protocol" to the above list. Certain protocols (be it TCP or DNS resolvers wanting to verify the IP addresses in the responses) coupled with the technical issues (such as path MTU discovery) and operational issues (such as how to debug) of using anycast as a source address, I think would benefit from such a protocol with reasonable security. By "reasonable security" I mean that for delivering packets to an anycast address we depend on the routing system not being compromised (and your item #2 above needs to preserve that). Wouldn't it be possible to use this trust in the routing system to get a binding between an anycast address and one current member of that address one would ask. I think the MIPv6 Binding Update has reuseable elements for such a protocol. But this is still a bit of a solution looking for a problem. 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 May 14 07:11:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEBtrP010135; Tue, 14 May 2002 07:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEBthD010134; Tue, 14 May 2002 07:11: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.3+Sun/8.12.3) with ESMTP id g4EEBprP010127 for ; Tue, 14 May 2002 07:11:52 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4EEBqg25490; Tue, 14 May 2002 16:11:52 +0200 (MEST) Date: Tue, 14 May 2002 16:11:04 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Stateless DNS discovery draft To: Steve Deering Cc: "Bound, Jim" , 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 > The pedantic answer is no, routers are not necessarily intermediaries > according to my definition of that term. Intermediaries are entities > or sets of entities that a seeker sends *to* and/or receives *from*, > in order to acquire needed info about a target. If those entities are > not on the same link as the sender, yes, you need routers to enable > that sending and/or receiving, but the routers themselves are not the > destination or source of the seeker-intermediary communication (unless > a router coincidentally happens to be the home of either seeker or > intermediary). But in comparing a router that forwards packets to a well-known unicast/anycast/multicast address (a L3 intermediary?) and a router with a DHCP relay (a L4+ intermediary) there are significant similarities. The main differences seem to be: - a router failure in the first case can be repaired without telling the host application to try a different address, which may or may not be the case when using a L4+ intermediary. - there exists a routing protocol which is an efficient way to get the intermediaries to find the targets. But because of routing transients when the set of targets change the L3 intermediaries will have stale information. Sure, the routing protocol attempts to minimize that time period. This observation leads me to believe (and I welcome discussion on this) that whatever mechanisms is used for discovery, that if we want a high level of availability, there is a need for an application layer failover mechanism. This could be a combination of the discovery returning a list of IP addresses to use, and the ability for the application to redo the discovery. But solely relying on redoing the discovery will have more delay than when there are multiple IP addresses known from the start. Thus I wonder if the architecture here should take into account the need for such a list of addresses to be provided. 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 May 14 07:17:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEHWrP010191; Tue, 14 May 2002 07:17:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEHWaf010190; Tue, 14 May 2002 07:17: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.3+Sun/8.12.3) with ESMTP id g4EEHRrP010183 for ; Tue, 14 May 2002 07:17:28 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4EEHSg25793; Tue, 14 May 2002 16:17:28 +0200 (MEST) Date: Tue, 14 May 2002 16:16:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Stateless DNS discovery draft To: Steve Deering Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I think this is a very good writeup, but it's missing the security considerations section :-)/2 Thinking for 5 minutes about intermediaries vs. not and security it isn't obvious to me that one is better than the other. A few points: - A solution with an intermediary requires on the order of N + M trust relationships for N clients and M services. A solution without requires N * M. Are there fundamental differences in how to do key management in the two cases? - An intermediary would imply putting all the security eggs in one basket. I think it is important to think about this some more. While the devices in a single home can rely on physical security combined with firewalls I think the fact that folks are talking about DNS discovery as reaching from the home networks into the ISP means that we need to take security a bit more seriously in this space. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 07:45:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEjZrP010363; Tue, 14 May 2002 07:45:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEjZ3k010362; Tue, 14 May 2002 07:45: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.3+Sun/8.12.3) with ESMTP id g4EEjWrP010355 for ; Tue, 14 May 2002 07:45: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 HAA20093 for ; Tue, 14 May 2002 07:45:36 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05824 for ; Tue, 14 May 2002 07:45:35 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 14 May 2002 10:43:56 -0400 Message-ID: <3CE121F4.CA20094A@nc.rr.com> Date: Tue, 14 May 2002 10:40:52 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > > Brian, > > > 1. Host-to-router notification protocol (this is taken care of by > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > > > 2. Security: at a minimum some form of authentication to allow > > routers to determine if hosts are allowed to join an anycast > > group > > > > 3. An Anycast Architecture doc that pulls all the pieces together > > and concretely describes how pieces interact, the pros and cons > > of anycast usage for intra-domain and inter-domain > > > > 4. Possibly a draft that documents any impacts on any existing > > protocols (routing protocols, TCP, etc.) > > > > Now, I have not spent time on the subject in the last 4-5 months, so I > > have not gotten much past this list. It is crucial that most of the > > issues raised by Itojun's anycast analysis draft be addressed. > > I wonder if it would also be useful to add a "anycast binding protocol" to > the above list. > Certain protocols (be it TCP or DNS resolvers wanting to verify the IP > addresses in the responses) coupled with the technical issues (such as > path MTU discovery) and operational issues (such as how to debug) of > using anycast as a source address, I think would benefit from such > a protocol with reasonable security. Actually, I will have to let on to a little secret. I have been looking at an option for anycast that looks strikingly similar to the Home Address option in MIPv6. The idea is that a server responding to an anycast query will put the anycast address in this option and its own unicast address in the source address field. The option can be protected with an AH header, thus allowing the sender to authenticate that the response is coming from a member of the anycast group. This option would also allow for TCP connections to an anycast address. A TCP implementation could allow a connection to an anycast address as long as it recognizes the option containing the anycast address. The option would also preserve the use of RPF filtering on source addresses. > > By "reasonable security" I mean that for delivering packets to an anycast > address we depend on the routing system not being compromised (and your item #2 > above needs to preserve that). Wouldn't it be possible to use this trust in > the routing system to get a binding between an anycast address and one current > member of that address one would ask. > > I think the MIPv6 Binding Update has reuseable elements for such a protocol. > > But this is still a bit of a solution looking for a problem. I believe that there may be useful pieces in MIP that could help make anycast work. I freely admit that the anycast option is based on the home address option from MIP. I just hope that I can spend some time on the topic soon. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 10:48:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EHmOrP010862; Tue, 14 May 2002 10:48:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EHmOFY010861; Tue, 14 May 2002 10:48: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.3+Sun/8.12.3) with ESMTP id g4EHmKrP010854 for ; Tue, 14 May 2002 10:48:20 -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 KAA12606 for ; Tue, 14 May 2002 10:48:23 -0700 (PDT) Received: from berkshire.research.att.com (H-135-207-53-60.research.att.com [135.207.53.60]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04665 for ; Tue, 14 May 2002 10:48:18 -0700 (PDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 33D197B4F; Tue, 14 May 2002 12:33:31 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Erik Nordmark Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 May 2002 12:33:31 -0400 Message-Id: <20020514163331.33D197B4F@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordm ark writes: > >Steve, > >I think this is a very good writeup, but it's missing >the security considerations section :-)/2 > >Thinking for 5 minutes about intermediaries vs. not and security >it isn't obvious to me that one is better than the other. >A few points: > - A solution with an intermediary requires on the order of N + M trust > relationships for N clients and M services. A solution without requires > N * M. Are there fundamental differences in how to do key management in > the two cases? Yes and no, and a lot depends on the trust relationships between seeker S, intermediary I, and target T. And whether or not N*M is a significant issue depends on the relative values of N and M, and the frequency of contact. The latter is easier to see. If a member of set S has comparatively infrequent contact with a member of T, and N ~= M, there isn't a serious problem with the number of security associations -- there won't be many at any one time, so it won't be much of a load. And trust isn't much of an issue, either -- if S is trying to talk to T and T isn't trustworthy, it doesn't matter much if T is lying about the needed info or in the actual service response. In other words, if we can manage direct responses, we're in much better shape. If N>>M, then setting up many security associations is a considerable burden on T. (This is one of the many reasons one can't use transmission security instead of DNSSEC.) With an intermediary, the question of how much S trusts I is crucial. If S trusts I implicitly, the situation is relatively simple. If there can be more than one intermediary -- i.e., the situation in today's DNS -- S has no idea whether or not it can trust the chain, and hence doesn't know if the response comes from the real T (or the info server for T). This is the major reason that DNSSEC works by protecting objects instead of transmission -- the records are digitally signed by the ultimate source, thus rendering the trustworthiness of the transmission chain irrelevant. In other words, we can't really make any security statements until we can define our terms better. > - An intermediary would imply putting all the security eggs in one basket. Yes, though that's not always bad: "The fool says ``Don't put all of your eggs in one basket,'' but the wise man says ``put all your eggs in one basket and watch that basket!''" (Puddin'head Wilson's Calendar) > >I think it is important to think about this some more. While the devices >in a single home can rely on physical security combined with firewalls >I think the fact that folks are talking about DNS discovery as >reaching from the home networks into the ISP means that we need to >take security a bit more seriously in this space. The crucial question for security is how a node decides what other nodes to trust. My light switch might decide to trust everyone, on the assumption that no one else has access to the house wiring. I don't think I want my burglar alarm to make the same assumption, since those wires do appear outside my house, both at the service entrance and at the nice, convenient outlets on my porch. (I would note that the U.S. National Electrical Code (adopted by most, though not all, municipalities) *requires* a few outdoor outlets.) In other words, you have to pick your threat model, too. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 11:35:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EIZ9rP011050; Tue, 14 May 2002 11:35:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EIZ9j6011049; Tue, 14 May 2002 11:35:09 -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.3+Sun/8.12.3) with ESMTP id g4EIZ5rP011042 for ; Tue, 14 May 2002 11:35: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 LAA02892 for ; Tue, 14 May 2002 11:35:09 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10107 for ; Tue, 14 May 2002 12:35:35 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4EIYAn02005; Tue, 14 May 2002 14:34:10 -0400 Message-Id: <200205141834.g4EIYAn02005@cichlid.adsl.duke.edu> To: "Hesham Soliman (ERA)" cc: "'Craig Dunk'" , "'Margaret Wasserman'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts In-Reply-To: Message from "Hesham Soliman (ERA)" of "Mon, 29 Apr 2002 17:07:29 +0200." <4DA6EA82906FD511BE2F00508BCF053802C6ACE5@Esealnt861.al.sw.ericsson.se> Date: Tue, 14 May 2002 14:34:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [playing catchup] > > Does this (paraphrased) assessment seem correct? I wouldn't > > want 3GPP to > > mandate a behaviour that they would believe contributed to > > identity privacy > > but, based on some other procedure, did not. > => But the person tracking would have to know > that the host is a 3GPP host. Isn't this fairly trivial todo? I.e., the cellphone will likely have an IPv6 address assigned out of a address block that is widely-known to belong to a carrier providing 3G IPv6 service. Right? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 11:40:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EIefrP011084; Tue, 14 May 2002 11:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EIefmU011083; Tue, 14 May 2002 11:40: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.3+Sun/8.12.3) with ESMTP id g4EIecrP011076 for ; Tue, 14 May 2002 11:40: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 LAA13011 for ; Tue, 14 May 2002 11:40:42 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13603 for ; Tue, 14 May 2002 12:41:07 -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 g4EIdWY11062 for ; Tue, 14 May 2002 21:39:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 21:40:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 21:40:38 +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: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Tue, 14 May 2002 21:40:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65141@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Thread-Index: AcH7dmo7hicgEY9dQ1G/v/ItGuLd3gAAD2RQ To: , Cc: , , X-OriginalArrivalTime: 14 May 2002 18:40:38.0980 (UTC) FILETIME=[D7E36040:01C1FB76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4EIecrP011077 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > > > Does this (paraphrased) assessment seem correct? I wouldn't > > > want 3GPP to > > > mandate a behaviour that they would believe contributed to > > > identity privacy > > > but, based on some other procedure, did not. > > > => But the person tracking would have to know > > that the host is a 3GPP host. > > Isn't this fairly trivial todo? I.e., the cellphone will likely have > an IPv6 address assigned out of a address block that is widely-known > to belong to a carrier providing 3G IPv6 service. Right? With regards to this, I think we came to agreement on new text for the section, something that would look like this: 2.7.1 IP version 6 over PPP in 3GPP A 3GPP cellular host must support the IPv6CP interface identifier option. This option is needed to be able to connect other non-3GPP devices to the Internet using a PPP link between the 3GPP device (MT) and other devices (TE, e.g. a laptop). The MT performs the PDP Context activation based on a request from the TE. This results in an interface identifier to be suggested by the MT to the TE, using the IPv6CP option. To avoid any duplication in link-local addresses between the TE and the GGSN, the MT must always reject other suggested interface identifiers by the TE. This results in the TE always using the interface identifier suggested by the GGSN for its link-local address. The rejection of interface identifiers suggested by the TE is only done for creation of link local addresses, according to 3GPP standards. Privacy addresses [RFC-3041] can be used without an trouble because the cellular host gets a /64 prefix and the GGSN does not configure any global addresses on its point-to-point link towards the cellular host. 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 May 14 11:50:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EIorrP011131; Tue, 14 May 2002 11:50:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EIor8i011130; Tue, 14 May 2002 11:50: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.3+Sun/8.12.3) with ESMTP id g4EIoorP011123 for ; Tue, 14 May 2002 11:50: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 LAA08017 for ; Tue, 14 May 2002 11:50:53 -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 MAA16993 for ; Tue, 14 May 2002 12:50:52 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4EIne202124; Tue, 14 May 2002 14:49:40 -0400 Message-Id: <200205141849.g4EIne202124@cichlid.adsl.duke.edu> To: john.loughney@nokia.com cc: hesham.soliman@era.ericsson.se, CDunk@rim.net, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts In-Reply-To: Message from of "Tue, 14 May 2002 21:40:38 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFC65141@esebe004.NOE.Nokia.com> Date: Tue, 14 May 2002 14:49:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > With regards to this, I think we came to agreement on new text for > the section, something that would look like this: I'm OK with this. My comment was really more to do with this: > > I saw a privacy comment in the past (sorry, can't source the > > original author) that suggested that because of the procedure > > for address assignment where only one host allocates addresses > > within the prefix that there was no privacy benefit to > > regenerating interface identifier portion of the addresses since > > (for example) traffic analysis would just be done on prefix > > matching. "no privacy benefit" might be a bit strong. But I would tend to agree that the benefits are limited if in fact the /64 identifies the handset. > > Does this (paraphrased) assessment seem correct? I wouldn't want > > 3GPP to mandate a behaviour that they would believe contributed > > to identity privacy but, based on some other procedure, did not. AFAIK, 3GPP is not mandating the use of temporary addresses. draft-ietf-ipv6-cellular-host-01.txt makes this pretty clear. > => But the person tracking would have to know that the host is a > 3GPP host. This seems like it might well be straightforward information to determine. > Otherwise, they won't know that it has a prefix for itself. BTW, > this is not specific to 3GPP, the same can be done with home > networks. A house that gets a /48 can also be tracked by the same > method. Agreed. Temporary addresses are just one technique, that has some benefits in some environments. But there also limitations. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 11:55:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EItvrP011166; Tue, 14 May 2002 11:55:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EItv5l011165; Tue, 14 May 2002 11:55:57 -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.3+Sun/8.12.3) with ESMTP id g4EItrrP011158 for ; Tue, 14 May 2002 11:55:53 -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 LAA10686 for ; Tue, 14 May 2002 11:55:57 -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 MAA21434 for ; Tue, 14 May 2002 12:55: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 OAA00609; Tue, 14 May 2002 14:55:40 -0400 (EDT) Message-Id: <200205141855.OAA00609@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: Recommendations for IPv6 in 3GPP Standards to Informational Date: Tue, 14 May 2002 14:55:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Recommendations for IPv6 in 3GPP Standards' as a Informational. 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 May 14 12:14:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EJE5rP011210; Tue, 14 May 2002 12:14:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EJE4XB011209; Tue, 14 May 2002 12:14: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.3+Sun/8.12.3) with ESMTP id g4EJE1rP011202 for ; Tue, 14 May 2002 12:14:01 -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 MAA16170 for ; Tue, 14 May 2002 12:14:04 -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 NAA01815 for ; Tue, 14 May 2002 13:14:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 87D5A4B22; Wed, 15 May 2002 04:13:38 +0900 (JST) To: Brian Haberman Cc: Erik Nordmark , IPng Working Group In-reply-to: bkhabs's message of Tue, 14 May 2002 10:40:52 -0400. <3CE121F4.CA20094A@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: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address From: itojun@iijlab.net Date: Wed, 15 May 2002 04:13:38 +0900 Message-ID: <27504.1021403618@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Actually, I will have to let on to a little secret. I have been >looking at an option for anycast that looks strikingly similar to the >Home Address option in MIPv6. The idea is that a server responding to >an anycast query will put the anycast address in this option and its >own unicast address in the source address field. The option can be >protected with an AH header, thus allowing the sender to authenticate >that the response is coming from a member of the anycast group. > >This option would also allow for TCP connections to an anycast address. >A TCP implementation could allow a connection to an anycast address >as long as it recognizes the option containing the anycast address. > >The option would also preserve the use of RPF filtering on source >addresses. it was already discussed in the past, and dropped after deering's comment - source address limitation rule must be applied to the content of home address option, so we can't put multicast address or anycast address into home address optioon (based on RFC2460). pls see anycast-analysis draft. 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 May 14 12:21:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EJLsrP011250; Tue, 14 May 2002 12:21:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EJLsaJ011249; Tue, 14 May 2002 12:21: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.3+Sun/8.12.3) with ESMTP id g4EJLprP011242 for ; Tue, 14 May 2002 12:21:51 -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 MAA03848 for ; Tue, 14 May 2002 12:21:55 -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 NAA06090 for ; Tue, 14 May 2002 13:21:54 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 14 May 2002 15:19:38 -0400 Message-ID: <3CE16295.7C5CA8AF@nc.rr.com> Date: Tue, 14 May 2002 15:16:37 -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: Erik Nordmark , IPng Working Group Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address References: <27504.1021403618@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: > > >Actually, I will have to let on to a little secret. I have been > >looking at an option for anycast that looks strikingly similar to the > >Home Address option in MIPv6. The idea is that a server responding to > >an anycast query will put the anycast address in this option and its > >own unicast address in the source address field. The option can be > >protected with an AH header, thus allowing the sender to authenticate > >that the response is coming from a member of the anycast group. > > > >This option would also allow for TCP connections to an anycast address. > >A TCP implementation could allow a connection to an anycast address > >as long as it recognizes the option containing the anycast address. > > > >The option would also preserve the use of RPF filtering on source > >addresses. > > it was already discussed in the past, and dropped after deering's > comment - source address limitation rule must be applied to > the content of home address option, so we can't put multicast > address or anycast address into home address optioon (based on RFC2460). > pls see anycast-analysis draft. But, this isn't the home address option. The characteristics will be different. Like I said, I am still working on the details. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 13:39:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKdprP011472; Tue, 14 May 2002 13:39:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EKdp1N011471; Tue, 14 May 2002 13:39:51 -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.3+Sun/8.12.3) with ESMTP id g4EKdkrP011463 for ; Tue, 14 May 2002 13:39:47 -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 g4EKdcg16727; Tue, 14 May 2002 22:39:39 +0200 (MEST) Date: Tue, 14 May 2002 21:41:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Anycast Addresses being used for Nodes not just Routers; anycast as Source IP address To: Brian Haberman Cc: Erik Nordmark , IPng Working Group In-Reply-To: "Your message with ID" <3CE121F4.CA20094A@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Actually, I will have to let on to a little secret. I have been > looking at an option for anycast that looks strikingly similar to the > Home Address option in MIPv6. The idea is that a server responding to > an anycast query will put the anycast address in this option and its > own unicast address in the source address field. The option can be > protected with an AH header, thus allowing the sender to authenticate > that the response is coming from a member of the anycast group. This approach to security assumes a globally deployed PKI. So you seem to be on a path that't been tried before without success. I think in order to avoid this dependency one should think about basing the security on the routing system functioning. Thus if there is a response saying that Unicast X is a member of Anycast A, then there would be a return routability check to both X and A, and only a node which would receive both the packet sent to A and X would be able to respond with the needed "cookies". This sounds like about 2 roundtrips to securely find the mapping from A to X. We could chat more off-line if you'd like. 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 May 14 13:39:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKdtrP011481; Tue, 14 May 2002 13:39:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EKdtQw011480; Tue, 14 May 2002 13:39: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.3+Sun/8.12.3) with ESMTP id g4EKdprP011470 for ; Tue, 14 May 2002 13:39:51 -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 g4EKdkg16735; Tue, 14 May 2002 22:39:46 +0200 (MEST) Date: Tue, 14 May 2002 21:56:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Stateless DNS discovery draft To: "Steven M. Bellovin" Cc: Erik Nordmark , Steve Deering , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020514163331.33D197B4F@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes and no, and a lot depends on the trust relationships between seeker > S, intermediary I, and target T. And whether or not N*M is a > significant issue depends on the relative values of N and M, and the > frequency of contact. > > The latter is easier to see. If a member of set S has comparatively > infrequent contact with a member of T, and N ~= M, there isn't a > serious problem with the number of security associations -- there won't > be many at any one time, so it won't be much of a load. I agree that the working set of security associations might not be that large. But if there would still be a need for a seeker to establish multiple SAs i.e. the time to discover each target is likely to increase compared to a case where a single SA can be maintained between a seeker and an intermediary. But this is only one aspect of the tradeoffs. > With an intermediary, the question of how much S trusts I is crucial. Yep. > In other words, we can't really make any security statements until we > can define our terms better. One question is my mind is whether there are threats that are common for discovery in general, or whether one has to look specifically at DNS discovery to get a better handle on the relevant threats. > The crucial question for security is how a node decides what other > nodes to trust. My light switch might decide to trust everyone, on the > assumption that no one else has access to the house wiring. I don't > think I want my burglar alarm to make the same assumption, since those > wires do appear outside my house, both at the service entrance and at > the nice, convenient outlets on my porch. (I would note that the U.S. > National Electrical Code (adopted by most, though not all, > municipalities) *requires* a few outdoor outlets.) In other words, you > have to pick your threat model, too. So how can we understand the threat model for DNS discovery? 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 May 14 14:09:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EL9UrP011733; Tue, 14 May 2002 14:09:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EL9UxO011732; Tue, 14 May 2002 14: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EL9RrP011725 for ; Tue, 14 May 2002 14:09:27 -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 OAA27437 for ; Tue, 14 May 2002 14:09:30 -0700 (PDT) Received: from sklave3.rackland.de (sklave3.rackland.de [62.146.214.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06762 for ; Tue, 14 May 2002 15:09:28 -0600 (MDT) Received: from jornada-del-muerto.et.reziprozitaet.de (uucp@localhost) by sklave3.rackland.de (8.12.3/8.12.3/Debian -7) with BSMTP id g4EL9SSS007922 for ipng@sunroof.eng.sun.com; Tue, 14 May 2002 23:09:28 +0200 Received: from model-citizen-turns-killer.et.reziprozitaet.de (model-citizen-turns-killer.et.reziprozitaet.de [192.168.201.20]) by jornada-del-muerto.et.reziprozitaet.de (Postfix) with ESMTP id 4A3323B84 for ; Tue, 14 May 2002 23:08:05 +0200 (CEST) Received: by model-citizen-turns-killer.et.reziprozitaet.de (Postfix, from userid 1000) id CF3D52BF2; Tue, 14 May 2002 23:08:21 +0200 (CEST) To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments From: Klaus Klein Date: 14 May 2002 23:08:21 +0200 Message-ID: <87bsbitp2y.fsf@model-citizen-turns-killer.et.reziprozitaet.de> Lines: 7 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While making a related change in NetBSD I noticed that although getnameinfo() was correctly aligned with POSIX with respect to size_t vs. socklen_t, it was apparently missed to change its `flags' argument from int to unsigned int as part of that edit. - Klaus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 14 22:39:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F5dkrP012711; Tue, 14 May 2002 22:39:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F5dkCN012710; Tue, 14 May 2002 22:39: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.3+Sun/8.12.3) with ESMTP id g4F5dgrP012703 for ; Tue, 14 May 2002 22:39: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 WAA13278 for ; Tue, 14 May 2002 22:39:46 -0700 (PDT) Received: from berkshire.research.att.com (H-135-207-53-60.research.att.com [135.207.53.60]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27353 for ; Tue, 14 May 2002 23:39:41 -0600 (MDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6F2777B4B; Tue, 14 May 2002 20:19:32 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Erik Nordmark Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 May 2002 20:19:32 -0400 Message-Id: <20020515001932.6F2777B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordm ark writes: > >> Yes and no, and a lot depends on the trust relationships between seeker >> S, intermediary I, and target T. And whether or not N*M is a >> significant issue depends on the relative values of N and M, and the >> frequency of contact. >> >> The latter is easier to see. If a member of set S has comparatively >> infrequent contact with a member of T, and N ~= M, there isn't a >> serious problem with the number of security associations -- there won't >> be many at any one time, so it won't be much of a load. > >I agree that the working set of security associations might not be that large. >But if there would still be a need for a seeker to establish multiple >SAs i.e. the time to discover each target is likely to increase >compared to a case where a single SA can be maintained between a >seeker and an intermediary. But this is only one aspect of the tradeoffs. > Right, though in general the clients have the resources to manage this, whether directly or via a local proxy. > >> In other words, we can't really make any security statements until we > can define our terms better. > >One question is my mind is whether there are threats that are common >for discovery in general, or whether one has to look specifically >at DNS discovery to get a better handle on the relevant threats. > > >> The crucial question for security is how a node decides what other >> nodes to trust. My light switch might decide to trust everyone, on the >> assumption that no one else has access to the house wiring. I don't >> think I want my burglar alarm to make the same assumption, since those >> wires do appear outside my house, both at the service entrance and at >> the nice, convenient outlets on my porch. (I would note that the U.S. >> National Electrical Code (adopted by most, though not all, >> municipalities) *requires* a few outdoor outlets.) In other words, you >> have to pick your threat model, too. > >So how can we understand the threat model for DNS discovery? > That takes work... A good starting point would be Derek Atkins' and Rob Austein's DNS threat analysis document (draft-ietf-dnsext-dns-threats-01.txt) I haven't had a chance to read it carefully in this context. Rob, I know you're on this list... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 15 02:59:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F9xurP013364; Wed, 15 May 2002 02:59:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F9xuvx013363; Wed, 15 May 2002 02:59: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.3+Sun/8.12.3) with ESMTP id g4F9xqrP013356 for ; Wed, 15 May 2002 02:59:52 -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 CAA28574 for ; Wed, 15 May 2002 02:59:56 -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 DAA16173 for ; Wed, 15 May 2002 03:59:55 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4F9xss7006893 for ; Wed, 15 May 2002 11:59:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 15 12:01:47 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB420DL>; Wed, 15 May 2002 11:59:32 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF0E2@esealnt117> From: "Karim El-Malki (ERA)" To: "'Thomas Narten'" , "Hesham Soliman (ERA)" Cc: "'Craig Dunk'" , "'Margaret Wasserman'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Wed, 15 May 2002 11:56:49 +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 > > > Does this (paraphrased) assessment seem correct? I wouldn't > > > want 3GPP to > > > mandate a behaviour that they would believe contributed to > > > identity privacy > > > but, based on some other procedure, did not. > > > => But the person tracking would have to know > > that the host is a 3GPP host. > > Isn't this fairly trivial todo? I.e., the cellphone will likely have > an IPv6 address assigned out of a address block that is widely-known > to belong to a carrier providing 3G IPv6 service. Right? Depends if that carrier only provides 3G IPv6 service. It may provide fixed and 3G service out of the same block, where the assignment is done differently in the fixed and wireless parts. Also, it may provide IPv6 service to corporate users which use prefixes belonging to their fixed corporate network. It's true that it doesn't provide privacy in all cases, but it's not necessarily a trivial thing to find out if a host is a 3GPP host. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 15 08:44:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FFiorP013890; Wed, 15 May 2002 08:44:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FFiogP013889; Wed, 15 May 2002 08:44: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.3+Sun/8.12.3) with ESMTP id g4FFilrP013882 for ; Wed, 15 May 2002 08:44:47 -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 IAA09790 for ; Wed, 15 May 2002 08:44:49 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28803 for ; Wed, 15 May 2002 09:44:49 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 5911E3AF4; Wed, 15 May 2002 10:44:48 -0500 (CDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E3A161411; Wed, 15 May 2002 11:44:47 -0400 (EDT) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0001416976; Wed, 15 May 2002 11:44:46 -0400 (EDT) Date: Wed, 15 May 2002 11:44:46 -0400 (EDT) From: Jack McCann Message-Id: <200205151544.LAA0001416976@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com, kleink@reziprozitaet.de Subject: Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >While making a related change in NetBSD I noticed that although >getnameinfo() was correctly aligned with POSIX with respect to size_t >vs. socklen_t, it was apparently missed to change its `flags' argument >from int to unsigned int as part of that edit. Yes, I noticed this discrepancy between posix and rfc2553 about a year ago, and have been actively trying to "fix" the posix spec in this regard. The 'unsigned' flags argument occurred at some point during the incorporation of the IPv6 API into the Open Group's Networking Services issue 5.2 spec in 1999, and was propagated from there into the posix 1003.1-2001 spec. We've been looking back at archives to see how this change was introduced, but have not completed the e-paper trail yet. >From what I can tell, most implementations have implemented type 'int' as per the RFC, including Solaris, Windows XP, AIX, Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only implementation I have seen that uses 'unsigned int' is GNU libc, which originally implemented using type 'int', but which changed to 'unsigned int' in January 2001 (I speculate this was done to align with XNS 5.2 or perhaps one of the early drafts of 1003.1-2001). Given the widespread implementation of 'int', I believe the right thing to do is get the posix spec changed, and leave rfc2553bis as is. Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is active right now, I hope to have this fixed in TC1. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 15 12:54:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FJsCrP014398; Wed, 15 May 2002 12:54:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FJsCOk014397; Wed, 15 May 2002 12:54: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.3+Sun/8.12.3) with ESMTP id g4FJs8rP014390 for ; Wed, 15 May 2002 12:54:08 -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 MAA23126 for ; Wed, 15 May 2002 12:54:05 -0700 (PDT) Received: from sklave3.rackland.de (sklave3.rackland.de [62.146.214.70]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10331 for ; Wed, 15 May 2002 12:54:04 -0700 (PDT) Received: from jornada-del-muerto.et.reziprozitaet.de (uucp@localhost) by sklave3.rackland.de (8.12.3/8.12.3/Debian -7) with BSMTP id g4FJs3IV016204; Wed, 15 May 2002 21:54:03 +0200 Received: from model-citizen-turns-killer.et.reziprozitaet.de (model-citizen-turns-killer.et.reziprozitaet.de [192.168.201.20]) by jornada-del-muerto.et.reziprozitaet.de (Postfix) with ESMTP id B132A3B83; Wed, 15 May 2002 21:53:24 +0200 (CEST) Received: by model-citizen-turns-killer.et.reziprozitaet.de (Postfix, from userid 1000) id B2AEF2BF6; Wed, 15 May 2002 21:53:22 +0200 (CEST) To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments References: <200205151544.LAA0001416976@anw.zk3.dec.com> From: Klaus Klein Date: 15 May 2002 21:53:22 +0200 In-Reply-To: <200205151544.LAA0001416976@anw.zk3.dec.com> Message-ID: <87u1p9chn1.fsf@model-citizen-turns-killer.et.reziprozitaet.de> Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack McCann writes: > The 'unsigned' flags argument occurred at some point during > the incorporation of the IPv6 API into the Open Group's > Networking Services issue 5.2 spec in 1999, and was propagated > from there into the posix 1003.1-2001 spec. We've been looking > back at archives to see how this change was introduced, but > have not completed the e-paper trail yet. FWIW, I went through my collection of C808 drafts and found the `unsigned' argument appeared with the introduction of getnameinfo() in D3.0. Unfortunately no e-paper trail over here either; I've never been an XNET participant. > >From what I can tell, most implementations have implemented > type 'int' as per the RFC, including Solaris, Windows XP, AIX, > Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only > implementation I have seen that uses 'unsigned int' is GNU libc, > which originally implemented using type 'int', but which changed > to 'unsigned int' in January 2001 (I speculate this was done to > align with XNS 5.2 or perhaps one of the early drafts of 1003.1-2001). > > Given the widespread implementation of 'int', I believe the > right thing to do is get the posix spec changed, and leave > rfc2553bis as is. Actually, I did switch NetBSD over to `unsigned int' the other day; however, that and the amount of prior art (my survey didn't cover quite that much) are good reasons to reconsider this (same is true for the Austin Group). > Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is > active right now, I hope to have this fixed in TC1. I didn't occur to me to look there earlier (shame on me), but I just noticed your Aardvarks on that subject; unfortunately they (XBD ERN 24, XSH ERN 22) were rejected at the May meeting. In any case, I'll be watching austin-group-l. - Klaus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 15 13:11:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FKBrrP014476; Wed, 15 May 2002 13:11:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FKBqei014475; Wed, 15 May 2002 13:11: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.3+Sun/8.12.3) with ESMTP id g4FKBkrP014468 for ; Wed, 15 May 2002 13:11:46 -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 NAA28254 for ; Wed, 15 May 2002 13:11:50 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15211 for ; Wed, 15 May 2002 14:12:19 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 956483611; Wed, 15 May 2002 16:11:49 -0400 (EDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id DA5201235; Wed, 15 May 2002 15:11:48 -0500 (CDT) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0001458043; Wed, 15 May 2002 16:11:47 -0400 (EDT) Date: Wed, 15 May 2002 16:11:47 -0400 (EDT) From: Jack McCann Message-Id: <200205152011.QAA0001458043@anw.zk3.dec.com> To: kleink@reziprozitaet.de Subject: Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is >> active right now, I hope to have this fixed in TC1. > >I didn't occur to me to look there earlier (shame on me), but I just >noticed your Aardvarks on that subject; unfortunately they (XBD ERN >24, XSH ERN 22) were rejected at the May meeting. In any case, I'll >be watching austin-group-l. Yup. But we have a few more days before the results are finalized, to "take issue with any decisions of the review team". - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 15 21:24:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G4OwrP015350; Wed, 15 May 2002 21:24:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G4OwON015349; Wed, 15 May 2002 21:24:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G4OtrP015342 for ; Wed, 15 May 2002 21:24:55 -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 VAA19861 for ; Wed, 15 May 2002 21:24:58 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([202.28.2.9]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18154 for ; Wed, 15 May 2002 21:24:56 -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 g4G4NkG00436; Thu, 16 May 2002 11:23:47 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ietf/ip-ng From: Robert Elz To: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4427.1021292146@munnari.OZ.AU> References: <4427.1021292146@munnari.OZ.AU> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 May 2002 11:23:46 +0700 Message-ID: <432.1021523026@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 13 May 2002 19:15:46 +0700 From: Robert Elz Message-ID: <4427.1021292146@munnari.OZ.AU> | How can this work if the server isn't in the same site as the client? In reply to this query of mine, a private message (thanks for that) reminded me of a message that Itojun sent to the list back in early April... | Message-id: <2012.1017973554@itojun.org> | To: Ralph Droms | Cc: ipng@sunroof.eng.sun.com | From: itojun@iijlab.net | Subject: Re: Stateless DNS discovery draft | Date: Fri, 05 Apr 2002 11:25:54 +0900 | if CPE can become dual-sited (participate into ISP's site and | customer's site) it can relay DNS query requests/responses between | clients in customer's site to DNS server in the ISP. which is true, messages could be relayed - however I believe that breaks the "serverless" requirement that is being suggested. That is, to relay a site local message effectively, the reply also needs to be relayed (the message into the ISP needs to be sent from the relay's address inside the ISP's address space, as the customer's site local address is useless there). So the reply will return to the CPE, and then needs to be relayed back to the end node (with the appropriate address substitutions made) To accomplish that, either the relay needs to retain state (it would be close enough to a specialised NAT server) or the protocol needs to include enough information so the relay can tell from the reply where the reply needs to be sent (which makes the whole protocol close enough to isomorphic to DHCP, and certainly could not just be DNS packets to a well known address). Either way, I don't think this meets the objective. Aside from the "we aren't sure deployment will be good enough" is there some reason why multicast isn't being used for this search? Or more bluntly perhaps, why svrloc isn't just being used? Multicast deployment will follow closely upon a requirement for multicast deployment - as long as no-one wants to use it because it isn't deployed, it never will be. Require it for a worthwhile application, and deployment will simply happen. 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 May 16 01:39:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G8dwrP016034; Thu, 16 May 2002 01:39:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G8dwkp016033; Thu, 16 May 2002 01:39: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.3+Sun/8.12.3) with ESMTP id g4G8dsrP016026 for ; Thu, 16 May 2002 01:39:54 -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 BAA13046 for ; Thu, 16 May 2002 01:39:57 -0700 (PDT) Received: from starfruit.itojun.org ([218.49.243.137]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26243 for ; Thu, 16 May 2002 01:39:56 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 68D1D7BA; Thu, 16 May 2002 17:28:41 +0900 (JST) To: Robert Elz Cc: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 16 May 2002 11:23:46 +0700. <432.1021523026@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: Proposed IPv6 DNS Discovery Requirements From: Jun-ichiro itojun Hagino Date: Thu, 16 May 2002 17:28:41 +0900 Message-Id: <20020516082841.68D1D7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >To accomplish that, either the relay needs to retain state >(it would be close enough to a specialised NAT server) or the >protocol needs to include enough information so the relay can >tell from the reply where the reply needs to be sent (which >makes the whole protocol close enough to isomorphic to DHCP, >and certainly could not just be DNS packets to a well known >address). this is totally normal DNS relay server behavior. they look at ID field of DNS packet, and relays response to the original querier. it just needs to handle scoped address properly. what is your question? 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 May 16 04:25:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GBPRrP016353; Thu, 16 May 2002 04:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GBPQTC016352; Thu, 16 May 2002 04:25: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.3+Sun/8.12.3) with ESMTP id g4GBPOrP016345 for ; Thu, 16 May 2002 04:25: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 EAA09121 for ; Thu, 16 May 2002 04:25:26 -0700 (PDT) From: Robert.Peschi@alcatel.be Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08099 for ; Thu, 16 May 2002 05:25:25 -0600 (MDT) Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4GBPOI06830 for ; Thu, 16 May 2002 12:25:24 +0100 Received: from bemail01.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4GBNIH10239 for ; Thu, 16 May 2002 13:23:19 +0200 Subject: Several Interface IDs on a given IPv6 Interface ? To: ipng@sunroof.eng.sun.com Date: Thu, 16 May 2002 13:25:22 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/16/2002 13:25:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, Could anyone advice on the following ? On a given IPv6 Interface on a router, I understand that it is allowed to configure a global unicast address with an Interface_ID which is *different* from the Interface_ID of the Link Local Address. - is this something that should be discouraged or instead - can this be considered as normal practice e.g. for operator convenience ? Thanks, - Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 16 05:50:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GCoYrP016701; Thu, 16 May 2002 05:50:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GCoYFw016700; Thu, 16 May 2002 05:50: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.3+Sun/8.12.3) with ESMTP id g4GCoVrP016691 for ; Thu, 16 May 2002 05:50:31 -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 FAA24010 for ; Thu, 16 May 2002 05:50:30 -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 GAA09496 for ; Thu, 16 May 2002 06:50:59 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4GCoGR13753; Thu, 16 May 2002 15:50:17 +0300 Date: Thu, 16 May 2002 15:50:16 +0300 (EEST) From: Pekka Savola To: Robert.Peschi@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: Several Interface IDs on a given IPv6 Interface ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 16 May 2002 Robert.Peschi@alcatel.be wrote: > On a given IPv6 Interface on a router, I understand that it is allowed > to configure a global unicast address with an Interface_ID > which is *different* from the Interface_ID of the Link Local Address. > > - is this something that should be discouraged > or instead > - can this be considered as normal practice e.g. for operator > convenience ? We do the latter. On the other hand, using the same IID is less manual configuring, but (probably) more documenting or remembering. It's the user's choice. I see nothing worth discouraging here. The only thing (from specification point-of-view) here is that if IID is the same, you don't need to perform DAD for global address if you performed it for the link-local 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 Thu May 16 11:39:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GIdkrP017671; Thu, 16 May 2002 11:39:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GIdjWS017670; Thu, 16 May 2002 11:39: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.3+Sun/8.12.3) with ESMTP id g4GIdgrP017663 for ; Thu, 16 May 2002 11:39:42 -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 LAA08275 for ; Thu, 16 May 2002 11:39:45 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19311 for ; Thu, 16 May 2002 11:39:44 -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 g4GIdTc08051; Thu, 16 May 2002 20:39:33 +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 UAA04186; Thu, 16 May 2002 20:39: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.11.3/8.11.3) with ESMTP id g4GIdLT90543; Thu, 16 May 2002 20:39:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205161839.g4GIdLT90543@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert.Peschi@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: Several Interface IDs on a given IPv6 Interface ? In-reply-to: Your message of Thu, 16 May 2002 13:25:22 +0200. Date: Thu, 16 May 2002 20:39: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: On a given IPv6 Interface on a router, I understand that it is allowed to configure a global unicast address with an Interface_ID which is *different* from the Interface_ID of the Link Local Address. - is this something that should be discouraged or instead - can this be considered as normal practice e.g. for operator convenience ? => IMHO the second and if the software complains it should give a way to setup the interface ID before to create the link-local address. Regards Francis.Dupont@enst-bretagne.fr PS: I deeply dislike the uncontrolled autoconfiguration of a link-local address to every interfaces a la KAME. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 16 11:52:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GIqgrP017709; Thu, 16 May 2002 11:52:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GIqfaT017708; Thu, 16 May 2002 11: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GIqcrP017701 for ; Thu, 16 May 2002 11:52:38 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07897; Thu, 16 May 2002 14:52:37 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4GIqQW9019899; Thu, 16 May 2002 14:52:26 -0400 (EDT) Message-Id: <200205161852.g4GIqQW9019899@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Robert.Peschi@alcatel.be cc: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: Several Interface IDs on a given IPv6 Interface ? In-Reply-To: Message from Robert.Peschi@alcatel.be of "Thu, 16 May 2002 13:25:22 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 May 2002 14:52:25 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert.Peschi@alcatel.be said: > On a given IPv6 Interface on a router, I understand that it is allowed > to configure a global unicast address with an Interface_ID > which is *different* from the Interface_ID of the Link Local Address. > > - is this something that should be discouraged > or instead > - can this be considered as normal practice e.g. for operator > convenience ? One could also envision using multiple interface IDs on a single interface to (auto)configure multiple addresses on that interface using a single prefix. For example, a host receives a single global prefix from its router and configures multiple global addresses using that single prefix. -Sebastien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 16 13:01:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GK1xrP017802; Thu, 16 May 2002 13:01:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GK1xDK017801; Thu, 16 May 2002 13:01: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.3+Sun/8.12.3) with ESMTP id g4GK1srP017794 for ; Thu, 16 May 2002 13:01:54 -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 NAA05606 for ; Thu, 16 May 2002 13:01:57 -0700 (PDT) Received: from starfruit.itojun.org ([218.49.243.137]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14357 for ; Thu, 16 May 2002 13:01:56 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 155707B9; Fri, 17 May 2002 04:56:03 +0900 (JST) To: Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: Sebastien.Roy's message of Thu, 16 May 2002 14:52:25 -0400. <200205161852.g4GIqQW9019899@strat.East.Sun.COM> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Several Interface IDs on a given IPv6 Interface ? From: Jun-ichiro itojun Hagino Date: Fri, 17 May 2002 04:56:03 +0900 Message-Id: <20020516195603.155707B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> On a given IPv6 Interface on a router, I understand that it is allowed >> to configure a global unicast address with an Interface_ID >> which is *different* from the Interface_ID of the Link Local Address. >> >> - is this something that should be discouraged >> or instead >> - can this be considered as normal practice e.g. for operator >> convenience ? it is perfectly legal to have gobal unicast address with different interface ID. i usually assign the following to servers: A) autoconfigured global unicast address B) manually configured global unicast address, which will not change even if we change ethernet cards. i would register (B) to DNS forward mapping. sometimes I register (A) too. itojun rtk0: flags=8843 mtu 1500 address: 08:00:74:50:44:1e media: Ethernet autoselect (none) status: active inet6 fe80::a00:74ff:fe50:441e%rtk0 prefixlen 64 scopeid 0x1 inet6 3ffe:501:ffff:ffff:a00:74ff:fe50:441e prefixlen 64 <-- A inet6 3ffe:501:ffff:ffff::cafe prefixlen 64 <-- B -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 16 23:52:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H6qdrP018905; Thu, 16 May 2002 23:52:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4H6qdGC018904; Thu, 16 May 2002 23:52:39 -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.3+Sun/8.12.3) with ESMTP id g4H6qarP018897 for ; Thu, 16 May 2002 23:52:36 -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 XAA13640 for ; Thu, 16 May 2002 23:52:39 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([202.28.96.115]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08306 for ; Thu, 16 May 2002 23:52:32 -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 g4H6iMd03117; Fri, 17 May 2002 13:44:24 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Jun-ichiro itojun Hagino cc: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <20020516082841.68D1D7BA@starfruit.itojun.org> References: <20020516082841.68D1D7BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 May 2002 13:44:22 +0700 Message-ID: <3115.1021617862@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 16 May 2002 17:28:41 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20020516082841.68D1D7BA@starfruit.itojun.org> | this is totally normal DNS relay server behavior. they look at | ID field of DNS packet, and relays response to the original querier. | it just needs to handle scoped address properly. | what is your question? Of course, but that presumes a DNS server inside the site, which is what I wanted to avoid presuming. That is, you no longer have anything close to a serverless setup in any way that it has been defined, you're requiring a new server to be installed to act as this relay. Or if you like, instead of being a DNS server that we're searching for, make it be an NTP server instead. NTP queries don't get relayed. It really ought to be achieved by the same general mechanisms, unless we can find something so special about one of them that makes it different (eg: finding routers is different, as we know the router must be on the local link to be useful at all, hence RA packets are enough). 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 May 17 06:48:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDmqrP019917; Fri, 17 May 2002 06:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HDmq3e019916; Fri, 17 May 2002 06:48: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.3+Sun/8.12.3) with ESMTP id g4HDmlrP019906 for ; Fri, 17 May 2002 06:48:48 -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 GAA13626 for ; Fri, 17 May 2002 06:48:50 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08626 for ; Fri, 17 May 2002 07:48:47 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4HDmk0E007416 for ; Fri, 17 May 2002 15:48:46 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri May 17 15:48:18 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 15:37:22 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0626@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'ipng@sunroof.eng.sun.com'" Subject: new revision ofcellular host draft Date: Fri, 17 May 2002 15:48:11 +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 Hi all, I have submitted a new revision of the draft today. Until it is pulished by the IETF you can find it at http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt We hope that this draft will be ready for WG last call when it appears on the IETF pages. Thanks Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 17 10:16:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HHGfrP020423; Fri, 17 May 2002 10:16:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HHGebn020422; Fri, 17 May 2002 10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HHGbrP020415 for ; Fri, 17 May 2002 10:16:37 -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 KAA27287 for ; Fri, 17 May 2002 10:16:40 -0700 (PDT) Received: from mail4.noc.ntt.co.jp (mail4.noc.ntt.co.jp [210.163.32.59]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28588 for ; Fri, 17 May 2002 11:16:39 -0600 (MDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail4.noc.ntt.co.jp (8.9.3/NOC-MAIL4) id CAA10790; Sat, 18 May 2002 02:16:37 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id CAA02172; Sat, 18 May 2002 02:16:37 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id CAA02166; Sat, 18 May 2002 02:16:36 +0900 (JST) Received: from ty by mail2.noc.ntt.com (8.9.3/3.7W) id CAA11194; Sat, 18 May 2002 02:16:34 +0900 (JST) Message-ID: <003c01c1fdc6$96f539d0$e3ff240a@ty> From: "Toshi Yamasaki" To: "Hesham Soliman \(ERA\)" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0626@Esealnt861.al.sw.ericsson.se> Subject: Re: new revision ofcellular host draft Date: Sat, 18 May 2002 02:13:47 +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 Just a quick question. How cellular hosts discover DNS cache servers' addresses? > Hi all, > > I have submitted a new revision of the draft > today. Until it is pulished by the IETF you > can find it at > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > > We hope that this draft will be ready for WG last call > when it appears on the IETF pages. > > Thanks > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 17 12:02:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJ2krP020839; Fri, 17 May 2002 12:02:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HJ2khs020838; Fri, 17 May 2002 12:02: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.3+Sun/8.12.3) with ESMTP id g4HJ2hrP020829 for ; Fri, 17 May 2002 12:02:43 -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 MAA09436 for ; Fri, 17 May 2002 12:02:47 -0700 (PDT) From: juha.wiljakka@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 NAA16530 for ; Fri, 17 May 2002 13:02:46 -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 g4HJ35k20676 for ; Fri, 17 May 2002 22:03:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 May 2002 22:02:42 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 22:02:42 +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: new revision ofcellular host draft Date: Fri, 17 May 2002 22:02:41 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3335@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new revision ofcellular host draft Thread-Index: AcH9xw6x0XHQ4ZiVQwau6Bz0V5aHKgADQWyA To: , Cc: X-OriginalArrivalTime: 17 May 2002 19:02:42.0388 (UTC) FILETIME=[6BF0A940:01C1FDD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4HJ2hrP020831 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Toshi! This is unfortunately an issue we could not give 'an exact answer' in our draft. At least these possibilitites (I'm not commenting anything on their pros and cons) exist at the moment: - use of stateless DNS discovery - use of stateful DNS discovery (i.e. a DHCPv6-based mechanism) - use a PPP based mechanism in PDP context activation (this kind of mechanism is existing / in use for IPv4: RFC1877) (these three are not in 'RFC-level' yet...) - manual configuration in the terminal, i.e. typing the DNS server address manually (which is not very pleasant...) - receiving the configuration information OTA, i.e. using SMS to configure that information BR, -Juha W.- -----Original Message----- From: ext Toshi Yamasaki [mailto:t.yamasaki@ntt.com] Sent: 17 May, 2002 20:14 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: Re: new revision ofcellular host draft Just a quick question. How cellular hosts discover DNS cache servers' addresses? > Hi all, > > I have submitted a new revision of the draft > today. Until it is pulished by the IETF you > can find it at > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > > We hope that this draft will be ready for WG last call > when it appears on the IETF pages. > > Thanks > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 17 12:32:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJWgrP021002; Fri, 17 May 2002 12:32:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HJWgPs021001; Fri, 17 May 2002 12:32: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.3+Sun/8.12.3) with ESMTP id g4HJWdrP020994 for ; Fri, 17 May 2002 12:32: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 MAA18947; Fri, 17 May 2002 12:32:43 -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 NAA05658; Fri, 17 May 2002 13:32: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 MAA01696; Fri, 17 May 2002 12:32:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4HJWfj06691; Fri, 17 May 2002 12:32:41 -0700 X-mProtect: <200205171932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8pyiR7; Fri, 17 May 2002 12:32:38 PDT Message-Id: <4.3.2.7.2.20020517122232.0252fe60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 May 2002 12:32:30 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : IPv6 for Some Second and Third Generation Cellular Hosts Author(s) : Jari Arkko, Peter Hedman, Gerben Kuijpers, Hesham Soliman, John Loughney, Pertti Suomela, Juha Wiljakka Filename : Pages : 22 Date : May 17, 2002 This document has been submitted as an Internet Draft and should be available in the internet draft directories shortly. Until then it can be found at: http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will on May 30, 2002. Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 17 13:50:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HKoTrP021122; Fri, 17 May 2002 13:50:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HKoTkw021121; Fri, 17 May 2002 13:50: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.3+Sun/8.12.3) with ESMTP id g4HKoQrP021114 for ; Fri, 17 May 2002 13:50:26 -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 NAA16809 for ; Fri, 17 May 2002 13:50:31 -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 OAA02612 for ; Fri, 17 May 2002 14:50:30 -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 NAA05004; Fri, 17 May 2002 13:50:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4HKoTC12104; Fri, 17 May 2002 13:50:29 -0700 X-mProtect: <200205172050> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4CMxn3; Fri, 17 May 2002 13:50:26 PDT Message-Id: <4.3.2.7.2.20020517134639.02e0c878@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 May 2002 13:50:19 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" In-Reply-To: <4.3.2.7.2.20020517122232.0252fe60@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 The last call for this document will end on May 27, 2002. The Internet Area Directors requested shortening the working group last call to allow time for the IESG to discuss the document to meet a 3GPP deadline. Bob At 12:32 PM 5/17/2002, Bob Hinden wrote: >This is a IPv6 working group last call for comments on advancing the >following document as an Informational RFC: > > Title : IPv6 for Some Second and Third Generation Cellular > Hosts > Author(s) : Jari Arkko, Peter Hedman, Gerben Kuijpers, > Hesham Soliman, John Loughney, Pertti Suomela, > Juha Wiljakka > Filename : > Pages : 22 > Date : May 17, 2002 > >This document has been submitted as an Internet Draft and should be >available in the internet draft directories shortly. Until then it can be >found at: > > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will on May 30, >2002. > >Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 19 11:15:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4JIFtrP024149; Sun, 19 May 2002 11:15:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4JIFtWP024148; Sun, 19 May 2002 11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4JIFqrP024141 for ; Sun, 19 May 2002 11:15:52 -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 LAA12751 for ; Sun, 19 May 2002 11:15:56 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02577 for ; Sun, 19 May 2002 12:15:56 -0600 (MDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09 18:12:26 root Exp $) with ESMTP id g4JIEfp09990 for ; Sun, 19 May 2002 18:14:41 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id g4JIE0x08604 for ; Sun, 19 May 2002 18:14:02 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002051911145414504 for ; Sun, 19 May 2002 11:14:54 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 19 May 2002 11:15:53 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA506AF9937@orsmsx120.jf.intel.com> From: "Elgebaly, Hani" To: ipng@sunroof.eng.sun.com Subject: RE: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Thir d Generation Cellular Hosts" Date: Sun, 19 May 2002 11:15:50 -0700 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 I noticed that robust header compression requirements are missing from the "IPv6 for cellular hosts" draft. Should a section be added highlighting its importance and recommending its support (as a should requirement maybe)? Thanks, Hani -----Original Message----- From: Bob Hinden [mailto:hinden@iprg.nokia.com] Sent: Friday, May 17, 2002 1:50 PM To: ipng@sunroof.eng.sun.com Subject: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" The last call for this document will end on May 27, 2002. The Internet Area Directors requested shortening the working group last call to allow time for the IESG to discuss the document to meet a 3GPP deadline. Bob At 12:32 PM 5/17/2002, Bob Hinden wrote: >This is a IPv6 working group last call for comments on advancing the >following document as an Informational RFC: > > Title : IPv6 for Some Second and Third Generation Cellular > Hosts > Author(s) : Jari Arkko, Peter Hedman, Gerben Kuijpers, > Hesham Soliman, John Loughney, Pertti Suomela, > Juha Wiljakka > Filename : > Pages : 22 > Date : May 17, 2002 > >This document has been submitted as an Internet Draft and should be >available in the internet draft directories shortly. Until then it can be >found at: > > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will on May 30, >2002. > >Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 19 16:43:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4JNhGrP024370; Sun, 19 May 2002 16:43:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4JNhFto024369; Sun, 19 May 2002 16:43: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.3+Sun/8.12.3) with ESMTP id g4JNhBrP024362 for ; Sun, 19 May 2002 16:43: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 QAA10827 for ; Sun, 19 May 2002 16:43:17 -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 QAA24210 for ; Sun, 19 May 2002 16:43:16 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 290FE4B22; Mon, 20 May 2002 08:43:13 +0900 (JST) To: Bob Hinden Cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Fri, 17 May 2002 13:50:19 MST. <4.3.2.7.2.20020517134639.02e0c878@mailhost.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: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" From: itojun@iijlab.net Date: Mon, 20 May 2002 08:43:13 +0900 Message-ID: <12081.1021851793@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The last call for this document will end on May 27, 2002. > >The Internet Area Directors requested shortening the working group last >call to allow time for the IESG to discuss the document to meet a 3GPP >deadline. not objecting to this particular change, but is it usual thing to shorten deadline? 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 May 19 19:36:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K2a8rP024715; Sun, 19 May 2002 19:36:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K2a7kT024714; Sun, 19 May 2002 19:36:07 -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.3+Sun/8.12.3) with ESMTP id g4K2a4rP024707 for ; Sun, 19 May 2002 19:36:04 -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 TAA29605 for ; Sun, 19 May 2002 19:36:09 -0700 (PDT) Received: from mail4.noc.ntt.co.jp (mail4.noc.ntt.co.jp [210.163.32.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25019 for ; Sun, 19 May 2002 20:36:08 -0600 (MDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail4.noc.ntt.co.jp (8.9.3/NOC-MAIL4) id LAA17967; Mon, 20 May 2002 11:36:06 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id LAA02705; Mon, 20 May 2002 11:36:05 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id LAA02691; Mon, 20 May 2002 11:36:04 +0900 (JST) Received: from ty by mail2.noc.ntt.com (8.9.3/3.7W) id LAA15569; Mon, 20 May 2002 11:36:03 +0900 (JST) Message-ID: <00d201c1ffa7$15105de0$45a3240a@ty> From: "Toshi Yamasaki" To: , Cc: References: <245DBCAEEC4F074CB77B3F984FF9834FDC3335@esebe005.NOE.Nokia.com> Subject: Re: new revision ofcellular host draft Date: Mon, 20 May 2002 11:33:25 +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 Hi, Juha!! Yes, this is one of the most important but difficult issues to solve. I guess you agree that one or fewer mechanisms are better to achieve a real autoconfiguration :-) In my scenario for fixed access services like DSL or FTTH, I assume: - PE(NAS) -> CPE(Customer's Router) : stateful mechanism like DHCPv6 - CPE -> HOSTs : stateless mechanism (itojun-thaler?) or stateful mechanism(DHCPv6?), according to "O" bit of RA IMO, "mobility and seemlessness" is the key to select any auto-configuration mechanisms for HOSTs so that HOSTs don't have to prepare every differnt mechanism to be used at home, office, hotspot, mobile enviroment and so on. ---Toshi ----- Original Message ----- From: To: ; Cc: Sent: Saturday, May 18, 2002 4:02 AM Subject: RE: new revision ofcellular host draft Hi, Toshi! This is unfortunately an issue we could not give 'an exact answer' in our draft. At least these possibilitites (I'm not commenting anything on their pros and cons) exist at the moment: - use of stateless DNS discovery - use of stateful DNS discovery (i.e. a DHCPv6-based mechanism) - use a PPP based mechanism in PDP context activation (this kind of mechanism is existing / in use for IPv4: RFC1877) (these three are not in 'RFC-level' yet...) - manual configuration in the terminal, i.e. typing the DNS server address manually (which is not very pleasant...) - receiving the configuration information OTA, i.e. using SMS to configure that information BR, -Juha W.- -----Original Message----- From: ext Toshi Yamasaki [mailto:t.yamasaki@ntt.com] Sent: 17 May, 2002 20:14 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: Re: new revision ofcellular host draft Just a quick question. How cellular hosts discover DNS cache servers' addresses? > Hi all, > > I have submitted a new revision of the draft > today. Until it is pulished by the IETF you > can find it at > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > > We hope that this draft will be ready for WG last call > when it appears on the IETF pages. > > Thanks > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 19 23:05:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K65LrP025036; Sun, 19 May 2002 23:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K65LpA025035; Sun, 19 May 2002 23: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.3+Sun/8.12.3) with ESMTP id g4K65HrP025028 for ; Sun, 19 May 2002 23:05:18 -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 XAA26707 for ; Sun, 19 May 2002 23:05:23 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14868 for ; Mon, 20 May 2002 00:05:21 -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 g4K64CY24296 for ; Mon, 20 May 2002 09:04:12 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 09:05:20 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 09:05:20 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 20 May 2002 09:05:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65202@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Thread-Index: AcH/Z+fPMfEJFYZ4R3OQVC1lc3LaiQAXDf5A To: , X-OriginalArrivalTime: 20 May 2002 06:05:20.0632 (UTC) FILETIME=[5286BF80:01C1FFC4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4K65IrP025029 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hani, > I noticed that robust header compression requirements are missing from the > "IPv6 for cellular hosts" draft. Should a section be added highlighting its > importance and recommending its support (as a should requirement maybe)? The authors discussed this early on, and as there are no specific RFCs for IPv6 Header Compression, we felt that there was nothing specific to IPv6 to include in the document. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 20 02:43:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K9hfrP025354; Mon, 20 May 2002 02:43:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K9hfYX025353; Mon, 20 May 2002 02:43:41 -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.3+Sun/8.12.3) with ESMTP id g4K9hcrP025346 for ; Mon, 20 May 2002 02:43:38 -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 CAA10567 for ; Mon, 20 May 2002 02:43:43 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20717 for ; Mon, 20 May 2002 03:43:42 -0600 (MDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-30.cisco.com [10.82.224.30]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA15106; Mon, 20 May 2002 05:43:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20020520053847.0366ba98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 May 2002 05:43:22 -0400 To: "Toshi Yamasaki" From: Ralph Droms Subject: Re: new revision ofcellular host draft Cc: , , In-Reply-To: <00d201c1ffa7$15105de0$45a3240a@ty> References: <245DBCAEEC4F074CB77B3F984FF9834FDC3335@esebe005.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 Toshi, Is DHCPv6 (configuration-only or "stateless" DHCPv6) a viable option for host configuration - are there now or will there be hosts with DHCPv6 for those home networks where the "O" bit is set? - Ralph At 11:33 AM 5/20/2002 +0900, Toshi Yamasaki wrote: >Hi, Juha!! > >Yes, this is one of the most important but difficult issues to solve. I >guess you agree that one or fewer mechanisms are better to achieve a real >autoconfiguration :-) > >In my scenario for fixed access services like DSL or FTTH, I assume: > >- PE(NAS) -> CPE(Customer's Router) : stateful mechanism like DHCPv6 >- CPE -> HOSTs : stateless mechanism (itojun-thaler?) or stateful >mechanism(DHCPv6?), according to "O" bit of RA > >IMO, "mobility and seemlessness" is the key to select any auto-configuration >mechanisms for HOSTs so that HOSTs don't have to prepare every differnt >mechanism to be used at home, office, hotspot, mobile enviroment and so on. > >---Toshi > >----- Original Message ----- >From: >To: ; >Cc: >Sent: Saturday, May 18, 2002 4:02 AM >Subject: RE: new revision ofcellular host draft > > >Hi, Toshi! > >This is unfortunately an issue we could not give 'an exact answer' in our >draft. At least these possibilitites (I'm not commenting anything on their >pros and cons) exist at the moment: > >- use of stateless DNS discovery > >- use of stateful DNS discovery (i.e. a DHCPv6-based mechanism) > >- use a PPP based mechanism in PDP context activation (this kind of >mechanism is existing / in use for IPv4: RFC1877) > > (these three are not in 'RFC-level' yet...) > >- manual configuration in the terminal, i.e. typing the DNS server address >manually (which is not very pleasant...) > >- receiving the configuration information OTA, i.e. using SMS to configure >that information > >BR, >-Juha W.- > >-----Original Message----- >From: ext Toshi Yamasaki [mailto:t.yamasaki@ntt.com] >Sent: 17 May, 2002 20:14 >To: Hesham Soliman (ERA) >Cc: ipng@sunroof.eng.sun.com >Subject: Re: new revision ofcellular host draft > > >Just a quick question. How cellular hosts discover DNS cache servers' >addresses? > > > Hi all, > > > > I have submitted a new revision of the draft > > today. Until it is pulished by the IETF you > > can find it at > > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > > > > We hope that this draft will be ready for WG last call > > when it appears on the IETF pages. > > > > Thanks > > Hesham > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 May 20 04:11:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KBB3rP025496; Mon, 20 May 2002 04:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KBB3jF025495; Mon, 20 May 2002 04:11: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.3+Sun/8.12.3) with ESMTP id g4KBB0rP025488 for ; Mon, 20 May 2002 04:11:00 -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 EAA22487 for ; Mon, 20 May 2002 04:11:03 -0700 (PDT) Received: from mail3.noc.ntt.co.jp (mail3.noc.ntt.co.jp [210.163.32.58]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27816 for ; Mon, 20 May 2002 05:11:41 -0600 (MDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id UAA08968; Mon, 20 May 2002 20:11:00 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id UAA23826; Mon, 20 May 2002 20:11:00 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id UAA23817; Mon, 20 May 2002 20:10:59 +0900 (JST) Received: from ty by mail2.noc.ntt.com (8.9.3/3.7W) id UAA25970; Mon, 20 May 2002 20:10:59 +0900 (JST) Message-ID: <005701c1ffef$04af0490$45a3240a@ty> From: "Toshi Yamasaki" To: "Ralph Droms" Cc: , , References: <245DBCAEEC4F074CB77B3F984FF9834FDC3335@esebe005.NOE.Nokia.com> <4.3.2.7.2.20020520053847.0366ba98@funnel.cisco.com> Subject: Re: new revision ofcellular host draft Date: Mon, 20 May 2002 20:08:29 +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 Ralph, I'm confident that so-called stateful DHCPv6 is a very good choice for ISP-to-Customer(CPE) prefix delegation and some cases of CPE-to-HOST configuration where manegement is strictly required and 'O' bit should be set. IMO, so-called stateless DHCP is not bad also for CPE-to-HOST configuration, but I still wonder how a host know which stateless mechanism to use when 'O' bit is not set, for example, stateless DHCP or itojun-thaler method for DNS cache discovery. Probably the most important differnce between those two methods is that expensive memory space is required or not to store configuration parameters and codes for discovery protocols. --Toshi > Toshi, > > Is DHCPv6 (configuration-only or "stateless" DHCPv6) a viable option for > host configuration - are there now or will there be hosts with DHCPv6 for > those home networks where the "O" bit is set? > > - Ralph > > At 11:33 AM 5/20/2002 +0900, Toshi Yamasaki wrote: > >Hi, Juha!! > > > >Yes, this is one of the most important but difficult issues to solve. I > >guess you agree that one or fewer mechanisms are better to achieve a real > >autoconfiguration :-) > > > >In my scenario for fixed access services like DSL or FTTH, I assume: > > > >- PE(NAS) -> CPE(Customer's Router) : stateful mechanism like DHCPv6 > >- CPE -> HOSTs : stateless mechanism (itojun-thaler?) or stateful > >mechanism(DHCPv6?), according to "O" bit of RA > > > >IMO, "mobility and seemlessness" is the key to select any auto-configuration > >mechanisms for HOSTs so that HOSTs don't have to prepare every differnt > >mechanism to be used at home, office, hotspot, mobile enviroment and so on. > > > >---Toshi > > > >----- Original Message ----- > >From: > >To: ; > >Cc: > >Sent: Saturday, May 18, 2002 4:02 AM > >Subject: RE: new revision ofcellular host draft > > > > > >Hi, Toshi! > > > >This is unfortunately an issue we could not give 'an exact answer' in our > >draft. At least these possibilitites (I'm not commenting anything on their > >pros and cons) exist at the moment: > > > >- use of stateless DNS discovery > > > >- use of stateful DNS discovery (i.e. a DHCPv6-based mechanism) > > > >- use a PPP based mechanism in PDP context activation (this kind of > >mechanism is existing / in use for IPv4: RFC1877) > > > > (these three are not in 'RFC-level' yet...) > > > >- manual configuration in the terminal, i.e. typing the DNS server address > >manually (which is not very pleasant...) > > > >- receiving the configuration information OTA, i.e. using SMS to configure > >that information > > > >BR, > >-Juha W.- > > > >-----Original Message----- > >From: ext Toshi Yamasaki [mailto:t.yamasaki@ntt.com] > >Sent: 17 May, 2002 20:14 > >To: Hesham Soliman (ERA) > >Cc: ipng@sunroof.eng.sun.com > >Subject: Re: new revision ofcellular host draft > > > > > >Just a quick question. How cellular hosts discover DNS cache servers' > >addresses? > > > > > Hi all, > > > > > > I have submitted a new revision of the draft > > > today. Until it is pulished by the IETF you > > > can find it at > > > http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt > > > > > > We hope that this draft will be ready for WG last call > > > when it appears on the IETF pages. > > > > > > Thanks > > > Hesham > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > > > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > > > > > > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home 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 May 20 04:54:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KBsArP025588; Mon, 20 May 2002 04:54:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KBsAeW025586; Mon, 20 May 2002 04:54: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.3+Sun/8.12.3) with ESMTP id g4KBs4rP025571 for ; Mon, 20 May 2002 04:54:04 -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 EAA21510 for ; Mon, 20 May 2002 04:54:08 -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 EAA22245 for ; Mon, 20 May 2002 04:54:07 -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 HAA08012; Mon, 20 May 2002 07:53:49 -0400 (EDT) Message-Id: <200205201153.HAA08012@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-cellular-host-02.txt Date: Mon, 20 May 2002 07:53:48 -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 for Some Second and Third Generation Cellular Host Author(s) : J. Arkko et al. Filename : draft-ietf-ipv6-cellular-host-02.txt Pages : 20 Date : 17-May-02 As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making IPv6 mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. The document lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-cellular-host-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-cellular-host-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: <20020517134847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-cellular-host-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-cellular-host-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517134847.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 May 21 04:30:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LBUKrP028446; Tue, 21 May 2002 04:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LBUKDg028445; Tue, 21 May 2002 04: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LBUGrP028438 for ; Tue, 21 May 2002 04:30:17 -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 EAA23725 for ; Tue, 21 May 2002 04:30:20 -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 FAA18505 for ; Tue, 21 May 2002 05:30: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 HAA04763; Tue, 21 May 2002 07:30:01 -0400 (EDT) Message-Id: <200205211130.HAA04763@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-09.txt Date: Tue, 21 May 2002 07:30:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-09.txt Pages : 15 Date : 20-May-02 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143138.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 May 21 06:24:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LDOMrP028711; Tue, 21 May 2002 06:24:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LDOMaB028710; Tue, 21 May 2002 06:24: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.3+Sun/8.12.3) with ESMTP id g4LDOJrP028703 for ; Tue, 21 May 2002 06:24: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 GAA26411 for ; Tue, 21 May 2002 06:24:24 -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 GAA08798 for ; Tue, 21 May 2002 06:24:22 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4LDOJO23365; Tue, 21 May 2002 16:24:19 +0300 Date: Tue, 21 May 2002 16:24:19 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: IPng Mailing List Subject: Re: Changes to MLD to support Anycast In-Reply-To: <3CDAA166.42EDD961@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, A few comments. As stated before by others, this seems like a hack. But sometimes hacks can be good. Anyway.. ==> The big picture: this deals with the situation where anycast members are on the same link (and/or possibly even different links attached to the same upstream router). This is probably the most difficult part of host anycast, but one should also consider how one would turn these anycast MLD reports to something usable in the routing system. This is IMO important as anycast/multicast is very different in this sense (joining the multicast distribution tree vs advertising one address). ==> Based on MLD, there may be implementations that check that the address in MLD message is a multicast address and discard (probable)/send error on such packets. ==> I think everyone agrees that security considerations is a bit of handwaving :-) 4.2 Receiving Report Messages When a router receives an MLD Report message, an anycast Report message is distinguished from a multicast Report message by the MLD Multicast Address field. An anycast group address can be managed in the same manner as a multicast group address. All of the timers and state machines defined in RFC 2710 also apply to anycast group management. ==> the router must keep track of the nodes reporting to a group, so that packets to that anycast address can be delivered to it. Or does the router use normal neighbour discovery and just record on which links there may be potential anycast members for an address? 4.3 Receiving Leave Messages [...] The reception of an anycast Leave message must trigger the transmission of an Address-Specific Query for the specified anycast address. ==> This and some others may be more or less useless, as MLD for multicast/anycast is different (which has only been implied in the draft, AFAIR): the router must keep the addresses of nodes acting as (potential) anycast group members anyway (which is not necessary for multicast). The receiving router must verify that: - The IPv6 Source Address is a link-local address - The MLD checksum field is valid ==> In MLD, it is checked that the message is at least 24 bytes long too? It seems to me that something like "Binding Updates" are a more natural approach to host anycast membership problem (not counting using normal routing system in a host). On Thu, 9 May 2002, Brian Haberman wrote: > Just to give everyone the ability to review the draft, here is > the announcement of the draft outlining changes to MLD to support > hosts announcing their membership in anycast groups. Ideally, these > changes will get incorporated into the MLDv2 spec at some point. > > Regards, > Brian > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Host-based Anycast using MLD > > Author(s) : B. Haberman, D. Thaler > > Filename : draft-haberman-ipngwg-host-anycast-01.txt > > Pages : 5 > > Date : 08-May-02 > > > > This specification defines extended uses of the Multicast Listener > > Discovery protocol to support hosts participating in anycast groups. > > The extensions presented in this document allow hosts to notify the > > routing system of membership changes in an anycast group. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-host-anycast-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-haberman-ipngwg-host-anycast-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-haberman-ipngwg-host-anycast-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > ------------------------------------------------------------------------ > > Content-Type: text/plain > > Content-ID: <20020508135823.I-D@ietf.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 > -------------------------------------------------------------------- > -- 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 May 21 07:16:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LEGZrP028819; Tue, 21 May 2002 07:16:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LEGZpj028818; Tue, 21 May 2002 07:16: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.3+Sun/8.12.3) with ESMTP id g4LEGWrP028811 for ; Tue, 21 May 2002 07:16:32 -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 HAA28141 for ; Tue, 21 May 2002 07:16:35 -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 IAA00377 for ; Tue, 21 May 2002 08:16:35 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 21 May 2002 10:16:01 -0400 Message-ID: <3CEA55EF.8B0CB067@nc.rr.com> Date: Tue, 21 May 2002 10:13:03 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: IPng Mailing List Subject: Re: Changes to MLD to support Anycast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Pekka Savola wrote: > > Hello, > > A few comments. > > As stated before by others, this seems like a hack. But sometimes hacks > can be good. Anyway.. The original concept was based on the premise that group membership is similar in multicast and anycast. The hosts that are a member of a group need to report that fact to the routers. > > ==> The big picture: this deals with the situation where anycast members > are on the same link (and/or possibly even different links attached to the > same upstream router). > > This is probably the most difficult part of host anycast, but one should > also consider how one would turn these anycast MLD reports to something > usable in the routing system. This is IMO important as anycast/multicast > is very different in this sense (joining the multicast distribution tree > vs advertising one address). The routing issues are very important, but they are out of scope of reporting group membership information to the routers. The routing aspects should be covered in a separate draft. > > ==> Based on MLD, there may be implementations that check that the address > in MLD message is a multicast address and discard (probable)/send error on > such packets. Yes. And the MLD spec will need to be modified to remove that kind of check. > > ==> I think everyone agrees that security considerations is a bit of > handwaving :-) Group security in general needs more work. I am currently looking at draft-irtf-gsec-sgmv6-00.txt for help in that area. > > 4.2 Receiving Report Messages > > When a router receives an MLD Report message, an anycast Report > message is distinguished from a multicast Report message by the MLD > Multicast Address field. An anycast group address can be managed in > the same manner as a multicast group address. All of the timers and > state machines defined in RFC 2710 also apply to anycast group > management. > > ==> the router must keep track of the nodes reporting to a group, so that > packets to that anycast address can be delivered to it. Or does the > router use normal neighbour discovery and just record on which links there > may be potential anycast members for an address? Either method could be used. But given all the information that the router's group database needs to support for IGMPv3/MLDv2 anyway, it should be reasonable to keep a list of anycast members. > > 4.3 Receiving Leave Messages > > [...] The reception of an anycast Leave message must trigger > the transmission of an Address-Specific Query for the specified > anycast address. > > ==> This and some others may be more or less useless, as MLD for > multicast/anycast is different (which has only been implied in the draft, > AFAIR): the router must keep the addresses of nodes acting as (potential) > anycast group members anyway (which is not necessary for multicast). See response to the last comment. > > The receiving router must verify that: > > - The IPv6 Source Address is a link-local address > - The MLD checksum field is valid > > ==> In MLD, it is checked that the message is at least 24 bytes long too? Yep. That is covered in section 5 of RFC 2710. > > It seems to me that something like "Binding Updates" are a more natural > approach to host anycast membership problem (not counting using normal > routing system in a host). That is another possibility that has been mentioned on the list. If you look at the problem abstractly, Mobile IP is a close fit. The anycast address is the "home address" and the unicast addresses of the anycast group members are a set of "care-of addresses". Of course, if the care-of address changes, so does the machine you are talking to. 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 May 22 01:07:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M87mrP000865; Wed, 22 May 2002 01:07:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4M87lwi000864; Wed, 22 May 2002 01:07: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.3+Sun/8.12.3) with ESMTP id g4M87hrP000857 for ; Wed, 22 May 2002 01:07:44 -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 BAA15387 for ; Wed, 22 May 2002 01:07:38 -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 CAA12104 for ; Wed, 22 May 2002 02:07:36 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4M87ZB00330 for ; Wed, 22 May 2002 11:07:35 +0300 Date: Wed, 22 May 2002 11:07:35 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" In-Reply-To: <4.3.2.7.2.20020517122232.0252fe60@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 few comments. 2.2 RFC2373 - IP Version 6 Addressing Architecture The IPv6 Addressing Architecture [RFC-2373] is a mandatory part of IPv6. Currently, this specification is being updated by [ADDRARCHv3]; therefore, this specification may be made obsolete by the new one, in which case the new specification must be supported. ==> Procedural question: how could a Standard Track document have a normative, "must be supported" reference to a work-in-progress? 2.3 RFC2460 - Internet Protocol Version 6 [...] The cellular host must always be able to receive and reassemble fragment headers. It will also need to be able to send a fragment header in cases where it communicates with an IPv4 host through a translator. ==> I don't understand your argument about sending fragment headers. Do you have some specific translator mechanism in mind? Could you elaborate? 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 Multicast Listener Discovery [RFC-2710] may be supported, if the cellular host is supporting applications that require the use of multicast services. ==> Bad wording: "may be supported ... if ..."? Of course all kinds of specifications may be supported anyway. "Should"? "may have to be"? There is no need for MLD if the host only supports the well-known (hard coded in IPv6 implementations) link local multicast addresses. MLD is not used for listening on such addresses. ==> s/link local/link-local/ 2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers [RFC-2893] specifies a number of transition mechanisms for IPv6 hosts. Cellular hosts may support the dual stack mechanism mentioned in this specification. This also includes resolving addresses from the DNS and selecting the type of address for the correspondent host (IPv4 vs. IPv6). Cellular hosts should not support configured or automatic tunnels to avoid unnecessary tunneling over the air interface, unless there are no other mechanisms available. Tunneling can lead to poor usage of available bandwidth. ==> Has the interaction between this and Appandix C: Transition Issues been coordinated? It seems there may be some overlap here. 2.15 Default Address Selection for IPv6 Default Address Selection for IPv6 [DEFADDR] is needed for cellular hosts with more than one address. ==> Isn't this statement completely empty of meaning. All IPv6 hosts have more than one address (link-local + global/site-local/whatever)..? Also DEFADDR considers IPv4 addresses. 2.16 DNS Cellular hosts should support DNS, as described in [RFC-1034], [RFC- 1035] and [RFC-1886]. If DNS is used, a cellular host should perform DNS requests in the recursive mode, to limit signaling over the air interface. ==> I completely agree, but this requires the servers support (or rather: haven't disabled the support for) recursive queries. I guess this only depends on the network topology. If DNS servers are managed by the cellular operator, this should be no problem. 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP [...] It is likely that several simplifying assumptions can be made in the cellular environment, with respect to the mandated parts of the IP Security DoI, ISAKMP, and IKE. Although work on such simplifications would be useful, is not described here. ==> s/useful, is/useful, it is/ ? (Otherwise, the sentence sounds a bit awkward too.) Appendix B Cellular Host IPv6 Addressing in the 3GPP Model [...] In order to support the standard IPv6 stateless address autoconfiguration mechanism, as recommended by the IETF, the GGSN shall assign a prefix that is unique within its scope to each primary PDP context that uses IPv6 stateless address autoconfiguration. ==> 'unique within its scope' sounds rather scary, but I guess this was written vaguely intentionally to allow the use of site-local addresses. (Note: this also allows for the use of link + site-local addresses without global addresses, but I guess that's ok.) The GGSN always provides an Interface Identifier to the mobile host. ==> Is that IID trackable? If so, this might be worth mentioning in security considerations' second "bullet": If IID is trackable (like EUI64 is), changing the prefix doesn't help with privacy. Appendix C Transition Issues [...] The tunneling mechanism specified by [RFC-2529] is not relevant for a cellular host. [RFC-2529] allows isolated IPv6-only hosts to connect to an IPv6 router via an IPv4 domain. The scenario of an IPv6-only host in an IPv4-only cellular network is considered unlikely. ==> I feel this may be redundant: the draft _could_ list a lot of other mechanisms like DSTM but doesn't (Actually DSTM could be highly usable for cellular hosts of this kind if the only network connectivity they have is v6 but do have dual-stack). The use of 'IPv6-only' is also confusing here: IPv6-only often refers to a host which has _no_ IPv4 support. RFC2529 does require IPv4 support when sending and receiving Neighbor Discovery packets using IPv4 multicast. -- 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 May 22 01:34:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M8YtrP000913; Wed, 22 May 2002 01:34:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4M8YtLD000912; Wed, 22 May 2002 01:34: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.3+Sun/8.12.3) with ESMTP id g4M8YprP000905 for ; Wed, 22 May 2002 01:34: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 BAA04802 for ; Wed, 22 May 2002 01:34:57 -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 CAA03970 for ; Wed, 22 May 2002 02:34:56 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1104A4B22 for ; Wed, 22 May 2002 17:34:53 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Wed, 22 May 2002 11:07:35 +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 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" From: itojun@iijlab.net Date: Wed, 22 May 2002 17:34:53 +0900 Message-ID: <11686.1022056493@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no need for MLD if the host only > supports the well-known (hard coded in IPv6 implementations) link > local multicast addresses. MLD is not used for listening on such > addresses. >==> s/link local/link-local/ actually, even for these well-known addresses MLD is used (otherwise switches cannot snoop these MLDs). i could find no text that permits omission of MLD. what is the reasoning behind the text? 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 May 22 03:58:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MAw1rP001197; Wed, 22 May 2002 03:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MAw17d001196; Wed, 22 May 2002 03:58: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.3+Sun/8.12.3) with ESMTP id g4MAvwrP001189 for ; Wed, 22 May 2002 03:57: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 DAA10649 for ; Wed, 22 May 2002 03:57:54 -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 EAA27657 for ; Wed, 22 May 2002 04:57:53 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MAvr0E013447 for ; Wed, 22 May 2002 12:57:53 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 12:57:51 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4PYS0>; Wed, 22 May 2002 12:57:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0641@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 12:57:41 +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 > > There is no need for MLD if the > host only > > supports the well-known (hard coded in IPv6 > implementations) link > > local multicast addresses. MLD is not used for listening on such > > addresses. > >==> s/link local/link-local/ > > actually, even for these well-known addresses MLD is > used (otherwise > switches cannot snoop these MLDs). i could find no > text that permits > omission of MLD. what is the reasoning behind the text? > => Do you mean that MLD is used for the ALL Nodes mcast address ofr example? 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 May 22 04:05:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MB5nrP001222; Wed, 22 May 2002 04:05:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MB5ncj001221; Wed, 22 May 2002 04:05: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.3+Sun/8.12.3) with ESMTP id g4MB5krP001214 for ; Wed, 22 May 2002 04:05:46 -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 EAA11927 for ; Wed, 22 May 2002 04:05:52 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11541 for ; Wed, 22 May 2002 04:05:51 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MB5os7009660 for ; Wed, 22 May 2002 13:05:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 13:05:35 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 12:54:34 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0642@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 13:05:32 +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 > A few comments. > > 2.2 RFC2373 - IP Version 6 Addressing Architecture > > The IPv6 Addressing Architecture [RFC-2373] is a > mandatory part of > IPv6. Currently, this specification is being updated by > [ADDRARCHv3]; therefore, this specification may be made > obsolete by > the new one, in which case the new specification must be > supported. > > ==> Procedural question: how could a Standard Track document have a > normative, "must be supported" reference to a work-in-progress? => Yes, this issue was raised by Thomas. We will fix it when we update the draft due to IESG last call or WG last call. > > 2.3 RFC2460 - Internet Protocol Version 6 > [...] > The cellular host must always be able to receive and reassemble > fragment headers. It will also need to be able to send a fragment > header in cases where it communicates with an IPv4 host through a > translator. > > ==> I don't understand your argument about sending fragment > headers. Do > you have some specific translator mechanism in mind? Could > you elaborate? => RFC 2460 has some text on this, anticipating SIIT. I actually had the same thoughts (as you), but was told about this praragraph in 2460. > > 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > Multicast Listener Discovery [RFC-2710] may be supported, if the > cellular host is supporting applications that require the use of > multicast services. > > ==> Bad wording: "may be supported ... if ..."? Of course > all kinds of > specifications may be supported anyway. "Should"? "may > have to be"? > => OK we can reword it to: 'Cellular hosts may support MLD. MLD is needed if the cellular host is supporting applications that require the use of multicast services.' > There is no need for MLD if the > host only > supports the well-known (hard coded in IPv6 implementations) link > local multicast addresses. MLD is not used for listening on such > addresses. > > ==> s/link local/link-local/ => OK. > > 2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers > > [RFC-2893] specifies a number of transition mechanisms for IPv6 > hosts. Cellular hosts may support the dual stack > mechanism mentioned > in this specification. This also includes resolving > addresses from > the DNS and selecting the type of address for the > correspondent host > (IPv4 vs. IPv6). Cellular hosts should not support configured or > automatic tunnels to avoid unnecessary tunneling over the air > interface, unless there are no other mechanisms > available. Tunneling > can lead to poor usage of available bandwidth. > > ==> Has the interaction between this and Appandix C: > Transition Issues > been coordinated? It seems there may be some overlap here. => OK. > > 2.15 Default Address Selection for IPv6 > > Default Address Selection for IPv6 [DEFADDR] is needed > for cellular > hosts with more than one address. > > ==> Isn't this statement completely empty of meaning. All > IPv6 hosts have > more than one address (link-local + > global/site-local/whatever)..? Also > DEFADDR considers IPv4 addresses. > > 2.16 DNS > > Cellular hosts should support DNS, as described in > [RFC-1034], [RFC- > 1035] and [RFC-1886]. > > If DNS is used, a cellular host should perform DNS > requests in the > recursive mode, to limit signaling over the air interface. > > ==> I completely agree, but this requires the servers > support (or rather: > haven't disabled the support for) recursive queries. I > guess this only > depends on the network topology. If DNS servers are managed by the > cellular operator, this should be no problem. > > => Your last statement is correct in our assumptions. So I don't think it's a problem. > 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP > [...] > It is likely that several simplifying assumptions can be > made in the > cellular environment, with respect to the mandated parts > of the IP > Security DoI, ISAKMP, and IKE. Although work on such > simplifications > would be useful, is not described here. > > ==> s/useful, is/useful, it is/ ? (Otherwise, the sentence > sounds a bit > awkward too.) =>OK. > > Appendix B Cellular Host IPv6 Addressing in the 3GPP Model > [...] > In order to support the standard IPv6 stateless address > autoconfiguration mechanism, as recommended by the IETF, the GGSN > shall assign a prefix that is unique within its scope to each > primary PDP context that uses IPv6 stateless address > autoconfiguration. > > ==> 'unique within its scope' sounds rather scary, but I > guess this was > written vaguely intentionally to allow the use of > site-local addresses. > (Note: this also allows for the use of link + site-local > addresses without > global addresses, but I guess that's ok.) > > > The GGSN always provides an Interface Identifier to > the mobile host. > > ==> Is that IID trackable? If so, this might be worth mentioning in > security considerations' second "bullet": If IID is > trackable (like EUI64 > is), changing the prefix doesn't help with privacy. => The IID for the _link-local_address_only. The host can use any other IIDs for addresses with scopes larger than the link-local one. No security issues here. > > Appendix C Transition Issues > [...] > The tunneling mechanism specified by [RFC-2529] is not > relevant for > a cellular host. [RFC-2529] allows isolated IPv6-only hosts to > connect to an IPv6 router via an IPv4 domain. The scenario of an > IPv6-only host in an IPv4-only cellular network is considered > unlikely. > > ==> I feel this may be redundant: the draft _could_ list a > lot of other > mechanisms like DSTM but doesn't (Actually DSTM could be > highly usable for > cellular hosts of this kind if the only network > connectivity they have is > v6 but do have dual-stack). The use of 'IPv6-only' is also > confusing > here: IPv6-only often refers to a host which has _no_ IPv4 > support. > RFC2529 does require IPv4 support when sending and > receiving Neighbor > Discovery packets using IPv4 multicast. => There is another DT in NGTRANS that will address transition for 3GPP networks. So I'm not sure howuseful this appendix is right now. Thanks for your comments, 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 May 22 04:08:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MB8ArP001257; Wed, 22 May 2002 04:08:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MB8AlK001256; Wed, 22 May 2002 04:08: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.3+Sun/8.12.3) with ESMTP id g4MB86rP001249 for ; Wed, 22 May 2002 04:08:06 -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 EAA26221 for ; Wed, 22 May 2002 04:08:11 -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 FAA26181 for ; Wed, 22 May 2002 05:08:10 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 659134B22 for ; Wed, 22 May 2002 20:08:02 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: hesham.soliman's message of Wed, 22 May 2002 12:57:41 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0641@Esealnt861.al.sw.ericsson.se> 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 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" From: itojun@iijlab.net Date: Wed, 22 May 2002 20:08:02 +0900 Message-ID: <13275.1022065682@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> Do you mean that MLD is used for the ALL Nodes mcast >address ofr example? yes. 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 May 22 04:18:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBIArP001332; Wed, 22 May 2002 04:18:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBIAxG001331; Wed, 22 May 2002 04:18: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.3+Sun/8.12.3) with ESMTP id g4MBI7rP001324 for ; Wed, 22 May 2002 04:18:07 -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 EAA27752 for ; Wed, 22 May 2002 04:18:13 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14230 for ; Wed, 22 May 2002 05:18:54 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MBI70E025245 for ; Wed, 22 May 2002 13:18:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 13:18:07 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4PZ73>; Wed, 22 May 2002 13:18:06 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0646@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 13:17:58 +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 > >=> Do you mean that MLD is used for the ALL Nodes mcast > >address ofr example? > > yes. => I've never seen that in any spec. I guess you are saying that it's needed for L2 switches that snoop MLD messages to decide on mcast forwarding of mcast ethernet frames? If so, then we don't have this situation in cellular networks. What we're dealing with is a p2p link with no multicast capability. Hesham > > 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 May 22 04:20:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBKXrP001351; Wed, 22 May 2002 04:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBKW7J001350; Wed, 22 May 2002 04:20: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.3+Sun/8.12.3) with ESMTP id g4MBKTrP001343 for ; Wed, 22 May 2002 04:20:29 -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 EAA08653 for ; Wed, 22 May 2002 04:20:35 -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 EAA16761 for ; Wed, 22 May 2002 04:20:34 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4MBKRr02199; Wed, 22 May 2002 14:20:27 +0300 Date: Wed, 22 May 2002 14:20:27 +0300 (EEST) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0642@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 May 2002, Hesham Soliman (ERA) wrote: > => RFC 2460 has some text on this, anticipating SIIT. > I actually had the same thoughts (as you), but was > told about this praragraph in 2460. Time to raise the question here then.. > > ==> Bad wording: "may be supported ... if ..."? Of course > > all kinds of > > specifications may be supported anyway. "Should"? "may > > have to be"? > > > > => OK we can reword it to: 'Cellular hosts may support MLD. > MLD is needed if the cellular host is supporting applications > that require the use of multicast services.' Sounds good. > > The GGSN always provides an Interface Identifier to > > the mobile host. > > > > ==> Is that IID trackable? If so, this might be worth mentioning in > > security considerations' second "bullet": If IID is > > trackable (like EUI64 > > is), changing the prefix doesn't help with privacy. > > => The IID for the _link-local_address_only. > The host can use any other IIDs for addresses > with scopes larger than the link-local one. > No security issues here. 100% same applies to e.g. IID addresses based on Ethernet MAC-addresses. If IID is trackable like Ethernet MAC, and implementors/operators don't realize this, they every probably use the same IID by default for global addresses too because that's the easiest way. And thus the problems. I'm not saying this is a critical thing, but if e.g. IID is derived from the e.g. cellular subscription ID's, _some_ might disagree. So I think this issue should be brought in the open, e.g.: --8<-- This means that 3GPP networks will already provide a limited form of addressing privacy, and no global tracking of a single host is possible through its address --8<-- ==> if IID part of a global address is trackable, the prefix part of the address is irrelevant and this argument would be moot. (Of course depending a bit on the exact details of 'addressing privacy'.) > => There is another DT in NGTRANS that will > address transition for 3GPP networks. So I'm > not sure howuseful this appendix is right now. I agree. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 04:28:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBScrP001377; Wed, 22 May 2002 04:28:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBScgc001376; Wed, 22 May 2002 04:28: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.3+Sun/8.12.3) with ESMTP id g4MBSZrP001369 for ; Wed, 22 May 2002 04:28:35 -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 EAA10197 for ; Wed, 22 May 2002 04:28:41 -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 EAA19599 for ; Wed, 22 May 2002 04:28:40 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MBSY0E001294 for ; Wed, 22 May 2002 13:28:39 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 13:28:18 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4P5R8>; Wed, 22 May 2002 13:28:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0647@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 13:28:12 +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 > > > > The GGSN always provides an Interface > Identifier to > > > the mobile host. > > > > > > ==> Is that IID trackable? If so, this might be > worth mentioning in > > > security considerations' second "bullet": If IID is > > > trackable (like EUI64 > > > is), changing the prefix doesn't help with privacy. > > > > => The IID for the _link-local_address_only. > > The host can use any other IIDs for addresses > > with scopes larger than the link-local one. > > No security issues here. > > 100% same applies to e.g. IID addresses based on Ethernet > MAC-addresses. > > If IID is trackable like Ethernet MAC, and > implementors/operators don't > realize this, they every probably use the same IID by > default for global > addresses too because that's the easiest way. And thus the > problems. => Agreed. Hence, RFC3041, which is generic for all IPv6 nodes. So an implementer of a cellular host can follow RFC3041 too. > > I'm not saying this is a critical thing, but if e.g. IID is > derived from > the e.g. cellular subscription ID's, _some_ might disagree. > So I think > this issue should be brought in the open, e.g.: > > --8<-- > This means that 3GPP networks will already provide a > limited form of addressing privacy, and no global > tracking of a > single host is possible through its address > --8<-- > > ==> if IID part of a global address is trackable, the > prefix part of the > address is irrelevant and this argument would be moot. (Of course > depending a bit on the exact details of 'addressing privacy'.) => The IID part for link-local addresses is essentially a random number. There is nothing in 3GPP that specifies how it should be generated.In fact, depending on how you implement the GGSN, you could use the same IID for all decives because each link is p2p and each device has a separate prefix. So, maybe we can add something to say that hosts are encouraged to use 3041. But there is no globally unique token in the IID that will make a 'device or user' trackable. 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 May 22 04:30:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBUTrP001394; Wed, 22 May 2002 04:30:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBUTL3001393; Wed, 22 May 2002 04: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBUPrP001386 for ; Wed, 22 May 2002 04:30: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 EAA10758 for ; Wed, 22 May 2002 04:30:31 -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 FAA03962 for ; Wed, 22 May 2002 05:30:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AD1DC4B22 for ; Wed, 22 May 2002 20:30:26 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: hesham.soliman's message of Wed, 22 May 2002 13:17:58 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0646@Esealnt861.al.sw.ericsson.se> 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 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" From: itojun@iijlab.net Date: Wed, 22 May 2002 20:30:26 +0900 Message-ID: <13476.1022067026@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> I've never seen that in any spec. >I guess you are saying that it's needed for L2 >switches that snoop MLD messages to decide >on mcast forwarding of mcast ethernet frames? > >If so, then we don't have this situation in >cellular networks. What we're dealing with is >a p2p link with no multicast capability. even under the above situation, there's no such clause that permits omission of MLD in RFC2710 (MLD). if you have any reference please let me know, i'm interested in knowing the rationale for the claim. 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 May 22 04:37:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBbXrP001423; Wed, 22 May 2002 04:37:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBbXSE001422; Wed, 22 May 2002 04: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBbUrP001415 for ; Wed, 22 May 2002 04:37: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 EAA00712 for ; Wed, 22 May 2002 04:37:36 -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 EAA18330 for ; Wed, 22 May 2002 04:37:35 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4MBbYC02433; Wed, 22 May 2002 14:37:34 +0300 Date: Wed, 22 May 2002 14:37:33 +0300 (EEST) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0647@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 May 2002, Hesham Soliman (ERA) wrote: > > > > is), changing the prefix doesn't help with privacy. > > > > > > => The IID for the _link-local_address_only. > > > The host can use any other IIDs for addresses > > > with scopes larger than the link-local one. > > > No security issues here. > > > > 100% same applies to e.g. IID addresses based on Ethernet > > MAC-addresses. > > > > If IID is trackable like Ethernet MAC, and > > implementors/operators don't > > realize this, they every probably use the same IID by > > default for global > > addresses too because that's the easiest way. And thus the > > problems. > > => Agreed. Hence, RFC3041, which is generic for all IPv6 > nodes. So an implementer of a cellular host can follow > RFC3041 too. Ok. See below. > > I'm not saying this is a critical thing, but if e.g. IID is > > derived from > > the e.g. cellular subscription ID's, _some_ might disagree. > > So I think > > this issue should be brought in the open, e.g.: > > > > --8<-- > > This means that 3GPP networks will already provide a > > limited form of addressing privacy, and no global > > tracking of a > > single host is possible through its address > > --8<-- > > > > ==> if IID part of a global address is trackable, the > > prefix part of the > > address is irrelevant and this argument would be moot. (Of course > > depending a bit on the exact details of 'addressing privacy'.) > > => The IID part for link-local addresses is essentially > a random number. Ok, this is what I really was after. Whether it could be generated from some contract number, or whatever. >There is nothing in 3GPP that specifies > how it should be generated.In fact, depending on how you > implement the GGSN, you could use the same IID for > all decives because each link is p2p and each device > has a separate prefix. Do the nodes also adapt that IID (unless they use RFC3041) for the global/site-local address? >So, maybe we can add something > to say that hosts are encouraged to use 3041. 3041 isn't really all that beneficial if IID part is already quite random (and is changing from time to time, e.g. in the scope of a day or week). What I was after was some informational statement on what kind of IID's are used in these networks; whether RFC3041 depends much on that. I don't think it was apparent from the draft without going into 3GPP specs. >But > there is no globally unique token in the IID that will make > a 'device or user' trackable. What about draft-dupont-ipv6-imei-00.txt? (The beef of the draft seems to be the "universal" part, but I'm curious about IMEI 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 Wed May 22 04:43:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBhPrP001457; Wed, 22 May 2002 04:43:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBhPHY001456; Wed, 22 May 2002 04:43: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.3+Sun/8.12.3) with ESMTP id g4MBhMrP001449 for ; Wed, 22 May 2002 04:43:22 -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 EAA13738 for ; Wed, 22 May 2002 04:43:28 -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 FAA13888 for ; Wed, 22 May 2002 05:43:27 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MBhQ0E009994 for ; Wed, 22 May 2002 13:43:26 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 13:43:20 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 13:32:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0649@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 13:43:18 +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 Itojun, > >=> I've never seen that in any spec. > >I guess you are saying that it's needed for L2 > >switches that snoop MLD messages to decide > >on mcast forwarding of mcast ethernet frames? > > > >If so, then we don't have this situation in > >cellular networks. What we're dealing with is > >a p2p link with no multicast capability. > > even under the above situation, there's no such clause > that permits > omission of MLD in RFC2710 (MLD). if you have any > reference please > let me know, i'm interested in knowing the rationale > for the claim. => I don't understant :(. RFC2710 does not say that MLD MUST be implemented in all IPv6 nodes. There is no statement in any IPv6 document that says anything equivalent. So our interpretation is that it is not mandatory, it's optional. I don't think that the lack of a clear statement saying 'MLD is mandatory' should imply that it is mandatory. Mandated protocols are clearly stated in their respective RFCs (e.g. ICMPv6). So when is MLD needed? I will copy a paragraph from the intro of 2710: "The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 router to discover the presence of multicast listeners (that is, -------------------------------------------- nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This information is then provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all links where there are interested receivers." Note the underlined text. If no discovery is needed, because the addresses are hard coded, then no MLD needed for those addresses. Makes sense? Hesham > > 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 May 22 04:48:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBmirP001510; Wed, 22 May 2002 04:48:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBmiC7001509; Wed, 22 May 2002 04:48: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.3+Sun/8.12.3) with ESMTP id g4MBmerP001502 for ; Wed, 22 May 2002 04:48:40 -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 EAA15127 for ; Wed, 22 May 2002 04:48: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 FAA11222 for ; Wed, 22 May 2002 05:48:45 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MBmi0E013484 for ; Wed, 22 May 2002 13:48:44 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 13:48:44 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4P605>; Wed, 22 May 2002 13:48:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F064A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 13:48:37 +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 > > > > => The IID part for link-local addresses is essentially > > a random number. > > Ok, this is what I really was after. Whether it could be > generated from > some contract number, or whatever. > > >There is nothing in 3GPP that specifies > > how it should be generated.In fact, depending on how you > > implement the GGSN, you could use the same IID for > > all decives because each link is p2p and each device > > has a separate prefix. > > Do the nodes also adapt that IID (unless they use RFC3041) for the > global/site-local address? => It is up to the nodes. Since a /64 is assigned, default routers only look at that /64 to identify a node. > > >So, maybe we can add something > > to say that hosts are encouraged to use 3041. > > 3041 isn't really all that beneficial if IID part is > already quite random > (and is changing from time to time, e.g. in the scope of a > day or week). => Agreed, but unfortunately it is left up to implementations, so hosts can't really rely on the GGSN to do that. So RFC 3041 might come handy after all. Actually, as a side node, I think 2462 should be deprecated and replaced by 3041....please don't shoot! > >But > > there is no globally unique token in the IID that will make > > a 'device or user' trackable. > > What about draft-dupont-ipv6-imei-00.txt? (The beef of the > draft seems to > be the "universal" part, but I'm curious about IMEI here.) => I guess my statement above would tell you that I'm not a fan of globally unique iids :) So a way of generating an iid on each link layer is unnecessary IMHO. I hope the u bit will go away soon too. Hesham > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 04:54:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBsNrP001532; Wed, 22 May 2002 04:54:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBsNh6001531; Wed, 22 May 2002 04:54: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.3+Sun/8.12.3) with ESMTP id g4MBsKrP001524 for ; Wed, 22 May 2002 04:54: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 EAA19383 for ; Wed, 22 May 2002 04:54:26 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13608 for ; Wed, 22 May 2002 05:54:25 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 22 May 2002 07:54:13 -0400 Message-ID: <3CEB8633.79B3A93F@nc.rr.com> Date: Wed, 22 May 2002 07:51:15 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F0649@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, "Hesham Soliman (ERA)" wrote: > > Itojun, > > > >=> I've never seen that in any spec. > > >I guess you are saying that it's needed for L2 > > >switches that snoop MLD messages to decide > > >on mcast forwarding of mcast ethernet frames? > > > > > >If so, then we don't have this situation in > > >cellular networks. What we're dealing with is > > >a p2p link with no multicast capability. > > > > even under the above situation, there's no such clause > > that permits > > omission of MLD in RFC2710 (MLD). if you have any > > reference please > > let me know, i'm interested in knowing the rationale > > for the claim. > > => I don't understant :(. RFC2710 does not say that > MLD MUST be implemented in all IPv6 nodes. There is > no statement in any IPv6 document that says anything > equivalent. So our interpretation is that it is not > mandatory, it's optional. I don't think that the lack > of a clear statement saying 'MLD is mandatory' should > imply that it is mandatory. Mandated protocols are > clearly stated in their respective RFCs (e.g. ICMPv6). > > So when is MLD needed? I will copy a paragraph from > the intro of 2710: > > "The purpose of Multicast Listener Discovery (MLD) is to enable each > IPv6 router to discover the presence of multicast listeners (that is, > -------------------------------------------- > nodes wishing to receive multicast packets) on its directly attached > links, and to discover specifically which multicast addresses are of > interest to those neighboring nodes. This information is then > provided to whichever multicast routing protocol is being used by the > router, in order to ensure that multicast packets are delivered to > all links where there are interested receivers." Take a look at the very last paragraph of section 5 of 2710. It states: MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). That means that a host MUST send an MLD Report for all multicast groups it joins except all-nodes. 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 May 22 04:58:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBwrrP001602; Wed, 22 May 2002 04:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBwqsQ001601; Wed, 22 May 2002 04:58: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.3+Sun/8.12.3) with ESMTP id g4MBwmrP001591 for ; Wed, 22 May 2002 04:58:48 -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 EAA20069 for ; Wed, 22 May 2002 04:58:54 -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 FAA00115 for ; Wed, 22 May 2002 05:59:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 275074B22 for ; Wed, 22 May 2002 20:58:49 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: hesham.soliman's message of Wed, 22 May 2002 13:43:18 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0649@Esealnt861.al.sw.ericsson.se> 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 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" From: itojun@iijlab.net Date: Wed, 22 May 2002 20:58:49 +0900 Message-ID: <13864.1022068729@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So when is MLD needed? I will copy a paragraph from >the intro of 2710: > > "The purpose of Multicast Listener Discovery (MLD) is to enable each > IPv6 router to discover the presence of multicast listeners (that is, > -------------------------------------------- > nodes wishing to receive multicast packets) on its directly attached > links, and to discover specifically which multicast addresses are of > interest to those neighboring nodes. This information is then > provided to whichever multicast routing protocol is being used by the > router, in order to ensure that multicast packets are delivered to > all links where there are interested receivers." > >Note the underlined text. If no discovery is needed, because >the addresses are hard coded, then no MLD needed for those >addresses. >Makes sense? no, it doesn't make sense to me. even for hardcoded addresses, there should be an MLD join packet issued from the listener. what i don't understand is why you are wanting to omit it. for example, if 3G mobile node in the following diagram transmits MLD join, uptream router could suppress packet to the expensive wireless link for packet to ff02::blah. i believe MLD support has benefit to the situation. itojun router | | 3G mobile node -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 05:00:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MC0grP001631; Wed, 22 May 2002 05:00:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MC0gxq001630; Wed, 22 May 2002 05:00:42 -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.3+Sun/8.12.3) with ESMTP id g4MC0drP001623 for ; Wed, 22 May 2002 05:00: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 FAA04095 for ; Wed, 22 May 2002 05:00:45 -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 GAA20287 for ; Wed, 22 May 2002 06:00:44 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MC0c0E020177 for ; Wed, 22 May 2002 14:00:43 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 14:00:38 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4P7ZV>; Wed, 22 May 2002 14:00:37 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F064C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian Haberman'" , "Hesham Soliman (ERA)" Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 14:00:33 +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 Brian > > Take a look at the very last paragraph of section 5 of 2710. It > states: > > MLD messages ARE sent for multicast addresses whose scope is 2 > (link-local), including Solicited-Node multicast > addresses [ADDR- > ARCH], except for the link-scope, all-nodes address (FF02::1). > > That means that a host MUST send an MLD Report for all multicast > groups it joins except all-nodes. => The solicited nodemcast address cannot be hard coded of course, so that's understandable. My question was why it needs to do it for the ALL Nodes mcast address, and you have explained that MLD is not needed for that. I agree ! We can make it clearer that the statement applies to the ALL Nodes mcast address, this was the intention anyway. 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 May 22 05:08:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MC8erP001676; Wed, 22 May 2002 05:08:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MC8d5U001675; Wed, 22 May 2002 05:08: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.3+Sun/8.12.3) with ESMTP id g4MC8arP001668 for ; Wed, 22 May 2002 05:08:36 -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 FAA20638 for ; Wed, 22 May 2002 05:08:43 -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 GAA23350 for ; Wed, 22 May 2002 06:08:41 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4MC8eZ02778; Wed, 22 May 2002 15:08:40 +0300 Date: Wed, 22 May 2002 15:08:39 +0300 (EEST) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F064A@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 May 2002, Hesham Soliman (ERA) wrote: > > 3041 isn't really all that beneficial if IID part is > > already quite random > > (and is changing from time to time, e.g. in the scope of a > > day or week). > > => Agreed, but unfortunately it is left up to implementations, > so hosts can't really rely on the GGSN to do that. > So RFC 3041 might come handy after all. If nothing can be assumed, then yes, I think it probably should be implemented. Turned on..? A different thing.. >Actually, as a side > node, I think 2462 should be deprecated and replaced by > 3041....please don't shoot! Where did I put my M16..... ;-) In the meantime, you might want to check out draft-dupont-ipv6-rfc3041harmful-00.txt .. there's an omission or two, but should be recommended reading for RFC3041 advocates :-) -- 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 May 22 05:19:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MCJMrP001700; Wed, 22 May 2002 05:19:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MCJMZY001699; Wed, 22 May 2002 05:19: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.3+Sun/8.12.3) with ESMTP id g4MCJJrP001692 for ; Wed, 22 May 2002 05:19:19 -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 FAA08157 for ; Wed, 22 May 2002 05:19:25 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09168 for ; Wed, 22 May 2002 06:20:06 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MCJN0E001714 for ; Wed, 22 May 2002 14:19:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 14:19:20 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4P9DF>; Wed, 22 May 2002 14:19:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F064D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 14:19:12 +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 > no, it doesn't make sense to me. even for hardcoded > addresses, there > should be an MLD join packet issued from the listener. => Well, the MLD spec doesn't say that though! We can change the MLD spec if enough people agree, but as far as this draft is concerned,we have to follow existing specs. > > what i don't understand is why you are wanting to omit it. => I didn't omit anything, I said it was not mandatory. If it is then there would have been statement in the RFC to indicate that. for > example, if 3G mobile node in the following diagram > transmits MLD join > uptream router could suppress packet to the expensive > wireless link for > packet to ff02::blah. i believe MLD support has benefit to the > situation. => But do you assume that the default router on a p2p link will forward mcast packets to multiple links even though hosts on those links didn't join this group? incoming packet to ff02::blah | H2--------R------- H1 If only H2 joined, doyou assume that the router will send it to H1 as well? Why? Note H1 and H2 do not share the same link. Hesham > > itojun > > > router > | > | > 3G mobile node > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 22 05:25:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MCPurP001725; Wed, 22 May 2002 05:25:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MCPuFo001724; Wed, 22 May 2002 05:25: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.3+Sun/8.12.3) with ESMTP id g4MCPqrP001717 for ; Wed, 22 May 2002 05:25: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 FAA09587 for ; Wed, 22 May 2002 05:25:59 -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 GAA12365 for ; Wed, 22 May 2002 06:26:40 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D556F4B24 for ; Wed, 22 May 2002 21:25:54 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: hesham.soliman's message of Wed, 22 May 2002 14:19:12 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F064D@Esealnt861.al.sw.ericsson.se> 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 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" From: itojun@iijlab.net Date: Wed, 22 May 2002 21:25:54 +0900 Message-ID: <14199.1022070354@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry, i was wrong about ff02::1. >=> But do you assume that the default router on a p2p link >will forward mcast packets to multiple links even though >hosts on those links didn't join this group? > incoming packet to ff02::blah > | > H2--------R------- H1 >If only H2 joined, doyou assume that the router will >send it to H1 as well? Why? >Note H1 and H2 do not share the same link. i was trying to think about packets originated from R. not the forwarding 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 May 22 05:30:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MCUsrP001745; Wed, 22 May 2002 05:30:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MCUsk1001744; Wed, 22 May 2002 05:30:54 -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.3+Sun/8.12.3) with ESMTP id g4MCUprP001737 for ; Wed, 22 May 2002 05:30:51 -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 FAA26208 for ; Wed, 22 May 2002 05:30:57 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06858 for ; Wed, 22 May 2002 06:30:56 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 22 May 2002 08:30:26 -0400 Message-ID: <3CEB8EAF.9A8860A@nc.rr.com> Date: Wed, 22 May 2002 08:27:27 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F064D@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, "Hesham Soliman (ERA)" wrote: > > incoming packet to ff02::blah > | > H2--------R------- H1 > > If only H2 joined, doyou assume that the router will > send it to H1 as well? Why? > Note H1 and H2 do not share the same link. Maybe I missed something here. R will send the packet addressed to ff02::blah to whatever host it received the MLD Report message from for ff02::blah. So, H2 would have to transmit an MLD Report to R in order to receive the multicast packet. In traditional wired p2p networks, MLD/IGMP are still used, why would they not be used in a 3G p2p network? 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 May 22 05:38:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MCcErP001770; Wed, 22 May 2002 05:38:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MCcERX001769; Wed, 22 May 2002 05:38: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.3+Sun/8.12.3) with ESMTP id g4MCcBrP001762 for ; Wed, 22 May 2002 05:38: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 FAA11706 for ; Wed, 22 May 2002 05:38:18 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13624 for ; Wed, 22 May 2002 05:38:17 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 22 May 2002 08:35:54 -0400 Message-ID: <3CEB8FF7.CAAB2194@nc.rr.com> Date: Wed, 22 May 2002 08:32:55 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F064D@Esealnt861.al.sw.ericsson.se> <3CEB8EAF.9A8860A@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me clarify my comment. ff02::blah is a bad example for what I am asking. Will the 3G network support applications utilizing mcast? Will a host be able to join ff05::abcd and receive data on that group address? If that is supported, then MLD is needed. Brian Brian Haberman wrote: > > Hesham, > > "Hesham Soliman (ERA)" wrote: > > > > incoming packet to ff02::blah > > | > > H2--------R------- H1 > > > > If only H2 joined, doyou assume that the router will > > send it to H1 as well? Why? > > Note H1 and H2 do not share the same link. > > Maybe I missed something here. R will send the packet addressed to > ff02::blah to whatever host it received the MLD Report message from > for ff02::blah. So, H2 would have to transmit an MLD Report to > R in order to receive the multicast packet. In traditional wired > p2p networks, MLD/IGMP are still used, why would they not be used > in a 3G p2p network? > > 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 May 22 05:46:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MCkxrP001798; Wed, 22 May 2002 05:46:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MCkxvt001797; Wed, 22 May 2002 05:46:59 -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.3+Sun/8.12.3) with ESMTP id g4MCktrP001790 for ; Wed, 22 May 2002 05:46:55 -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 FAA12926 for ; Wed, 22 May 2002 05:47:02 -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 FAA17311 for ; Wed, 22 May 2002 05:47:01 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MCl0s7002961 for ; Wed, 22 May 2002 14:47:00 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 22 14:43:13 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 14:32:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F064E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian Haberman'" , "Hesham Soliman (ERA)" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 14:43:04 +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 Brian, That's exactly what the draft says. Hesham > Let me clarify my comment. ff02::blah is a bad example for what I > am asking. Will the 3G network support applications > utilizing mcast? > Will a host be able to join ff05::abcd and receive data on > that group > address? If that is supported, then MLD is needed. > > Brian > > Brian Haberman wrote: > > > > Hesham, > > > > "Hesham Soliman (ERA)" wrote: > > > > > > incoming packet to ff02::blah > > > | > > > H2--------R------- H1 > > > > > > If only H2 joined, doyou assume that the router will > > > send it to H1 as well? Why? > > > Note H1 and H2 do not share the same link. > > > > Maybe I missed something here. R will send the packet > addressed to > > ff02::blah to whatever host it received the MLD Report > message from > > for ff02::blah. So, H2 would have to transmit an MLD Report to > > R in order to receive the multicast packet. In traditional wired > > p2p networks, MLD/IGMP are still used, why would they not be used > > in a 3G p2p network? > > > > 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 May 22 08:01:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MF1drP002100; Wed, 22 May 2002 08:01:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MF1dAr002099; Wed, 22 May 2002 08:01: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.3+Sun/8.12.3) with ESMTP id g4MF1arP002092 for ; Wed, 22 May 2002 08:01:36 -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 IAA08382 for ; Wed, 22 May 2002 08:01:42 -0700 (PDT) From: lassi.hippelainen@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 JAA05852 for ; Wed, 22 May 2002 09:02:19 -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 g4MF1xk07721 for ; Wed, 22 May 2002 18:01:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 May 2002 18:01:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 18:01:35 +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: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) Date: Wed, 22 May 2002 18:01:34 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) Thread-Index: AcIBoY/UYjiVe22NEdaLxwBQBF1Fmw== To: X-OriginalArrivalTime: 22 May 2002 15:01:35.0272 (UTC) FILETIME=[90EEB280:01C201A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4MF1arP002093 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 May 2002, Pekka Savola and Hesham Soliman (ERA) wrote: <...> >>Actually, as a side >> node, I think 2462 should be deprecated and replaced by >> 3041....please don't shoot! > >Where did I put my M16..... ;-) > >In the meantime, you might want to check out >draft-dupont-ipv6-rfc3041harmful-00.txt .. there's an omission or two, but >should be recommended reading for RFC3041 advocates :-) Thanks for the reminder. I must have missed it somehow. Probably on vacation at the wrong moment... I've been souping up a note of my own concerning RFC3041. I'm approaching the problem from 3GPP point of view. The text below is still pretty raw. For example, it doesn't discuss countermeasures. It was inspired by draft-ietf-ipngwg-temp-v2-00.txt, which has expired, but it is also valid for RFC3041. Both claim that the proposed mechanism does not introduce any new security problems. I happen to disagree. There are enough problems to spoil the whole idea. Looking for a Sidewinder... -- Lassi ........................................ 1. Summary RFC3041 may give protection against casual observers, but it also provides new tools for competent attackers. * Filtering to protect against DoS attacks is more difficult. * The address suffix can be used as a two-way covert channel that leaks up to 128 bits per packet in either direction. * One possible item of leaked information is the global identity and configuration of the node that uses the privacy addresses (i.e. with RFC3041 you can loose more privacy than without it). 2. Packet filtering A stateless filter cannot test the lowest address bits, because being stateless it does not know which suffices are in use at any moment. Previously the stateless filter could limit subnet address scans effectively by passing only a very small set of suffices. After RFC3041 it will pass a scan of up to 2^64 addresses. If the scanned node connects using a slow PPP link (e.g. a 3GPP mobile node), the scan will block its link. Note that this problem does not concern stateful filters. RFC3041 does not recommend changing the suffix if some upper protocol layer uses the address in a stateful session (e.g. TCP). In effect, RFC3041 mandates wide deployment of stateful firewalls. 3. The suffix as a covert channel (The importance of covert channels is increasing. For example, a Trojan horse is far more dangerous with a hidden control channel than without it. And we know how easy it is to get a Trojan installed by a gullible user...) Each node along the path is forced to accept any bit combination as the suffix of the *source* address. Uplink gateways performing sanity checks have no information about which suffices are in use in the sending subnet, and can check only that the prefix is topologically correct. The sending suffix can be used as payload. The access router at the local link could detect this channel. But if the leaking node performs DAD for each new address it generates, the channel can be detected only by analysing DAD frequency. The user of the channel may limit its use to a low rate to avoid detection. (But even once per day can be useful, see below.) The return packets to the Trojan can use the source address of the correspondent node to create a two-way channel. If the attacker has control of the corresponding subnet, also the destination suffix in uplink direction can be used. If the local last hop is over PPP (e.g. a 3GPP mobile node), also downlink destination address can be used. Total covert bandwidth is 128 bits per packet, both uplink and downlink. For reference: IP telephony needs 160 bits per packet. Using the channel requires access to the IP stack of the node. The malware can be installed either as a standard part of the stack (to track users), or as a Trojan horse via some other security hole. 4. Leaking the global identity If only the identity of the user is interesting, the standardised method already provides all necessary messages. As soon as a new address has been generated, the tracker can identify it, globally and forever. The new "random" addresses are created in a deterministic manner (RFC3041 3.2.1. "When Stable Storage Is Present"). The software vendor can therefore predict every future suffix used by the node, or identify the node as soon as one suffix has been detected. Since there are about 2^64 possible suffices, the possibility of a collision is fairly low. Besides, most users won't notice if the software vendor uses a proprietary hash function that is easier to crack than MD5. The suffix sequence can be seeded using the Ethernet address *and* the serial number of the software licence, leaking even more identity information than what a single fixed address would. Both of these identifiers can be narrowed down to a rather small subset of the available namespace by guessing. The time when the node came on-line for the first time can be used as guidance. If the suffix is generated using MD5 as suggested in RFC3041, an ephemeral identity can be recovered by anyone, by brute forcing the missing 64 bits of initial state from two consecutive suffices. The processing expense is not prohibitively high, and is getting lower all the time. This works also in the "absence of stable storage" mode. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 08:06:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MF6OrP002125; Wed, 22 May 2002 08:06:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MF6O1v002124; Wed, 22 May 2002 08:06:24 -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.3+Sun/8.12.3) with ESMTP id g4MF6KrP002117 for ; Wed, 22 May 2002 08:06:20 -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 IAA10273 for ; Wed, 22 May 2002 08:06:26 -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 JAA28753 for ; Wed, 22 May 2002 09:06:26 -0600 (MDT) Received: from kenawang ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA05294 for ; Wed, 22 May 2002 08:05:18 -0700 (PDT) Message-Id: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 May 2002 11:06:15 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" In-Reply-To: <4.3.2.7.2.20020517122232.0252fe60@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I have several comments on this document, all offered as an individual WG member (not as a WG co-chair). Although I understand that the 3GPP would like us to complete this document quickly, I still have some significant issues with this document. I know that there is some resistance to any delay at this point, but I believe that it is more important for us to produce a correct, high-quality document that actually reflects the consensus of the group, than it is to be responsive to an externally imposed deadline. My issues can be broken down into two categories: - Technical/content issues - Editorial comments First, I'll deal with the technical/content issues: (1) I think that this document should explicitly state, in the introduction, that it is not a standard and is not intended to modify or contradict any IPv6 standard documents. I thought that we had agreed to something like this earlier. (2) The document states: "Additionally, due to special characteristics of the cellular link, lower layer connectivity information should make it unnecessary to track the reachability of the router. Therefore, while the host must support Neighbor Solicitation and Advertisement messages, their use is not necessary and the host may choose to not initiate them." Although I understand the desire to supress NUD messages on point-to-point cellular links, this isn't how/why this should be done. IPv6 hosts must include a full implementation of Neighbor Discovery, including NUD with the full ND state machine, etc. Any compromise on this effectively results in two different types of IPv6 hosts, each with different behaviours/failure modes, etc. That is something that we definitely want to avoid. There is no magic (in 3GPP or any other network) that can guarantee that another node is always reachable, but it is certainly possible for other layers of the protocol stack (outside of IP) to maintain information about reachability, and to know, at a given time, that another node is reachable. ND includes the ability for those other protocol layers to provide advice to the NUD code to indicate that a remote host is reachable (only when those layers have confirmed two-way reachability), which results in the supression of NUD messages when the network is operating properly. The other layers of 3GPP should provide this advice to ND. In cases were the GGSN actually does become unreachable, NUD messages will be sent. But, in fact that NUD actually _reduces_ the amount of traffic that will sent over the air interface while the GGSN is unreachable, so this is actually a good thing for 3GPP. Instead of indicating that parts of ND are optional, or that 3GPP hosts may "choose to not" use them, we should be indicating what layers of 3GPP should provide reachability advice to ND at what points. If those other layers can confirm two-way reachability on an ongoing basis, they can provide frequent advice that will result in the supression of all NUD messages when things are operating properly. (3) The document states: "This specification [RFC-2402] must be supported. The IPsec WG has discussed the role of AH in the future, and it is possible that it will be made optional in the future versions of the IPsec protocol set. Implementers are recommended to take this in account." I don't like the idea of writing a document today that tells implementors that it is possible that something will be made optional in the future. Today it is mandatory. Period. (4) The document states: "4. Mobility For the purposes of this document, IP mobility is not relevant. When Mobile IPv6 specification is approved, a future update to this document may address these issues, as there may be some effects on IPv6 hosts due to Mobile IP. The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms." There is a portion of mobility -- I believe that is is called the "correspondent node option", or something like that -- that must be implemented in all IPv6 hosts, in order to allow optimal routing to mobile nodes that are away from their home networks. This document should indicate that support for that feature is required. Can one of the MIP folks help me here? What is it called, and where is it defined? Now, for the editorial issues: (5) In section "1 Introduction", the only paragraph is not properly laid out -- not clear if it is meant to be one or two paragraphs. (6) The document states: "Cellular hosts should not support configured or automatic tunnels to avoid unnecessary tunneling over the air interface, unless there are no other mechanisms available. Tunneling can lead to poor usage of available bandwidth. " The "should not support...unless there are no other" construct is somewhat confusing, since there probably isn't any way for a host to know whether there are other mechanisms available. Although I understand why tunneling should be avoided over the air interface if possible, I don't understand why this is a host implementation issue. Isn't this more of an issue for the operators? If so, it probably doesn't belong in this document. (7) As someone else mentioned, the following sentence is similarly confusing: "Multicast Listener Discovery [RFC-2710] may be supported, if the cellular host is supporting applications that require the use of multicast services." (8) I also think that the following sentence is more advice for 3GPP network operators, than it is specific to cellular hosts: "Hence, intermediate 6to4 routers should carry out 6to4 tunneling, instead of cellular hosts." There is an ongoing effort in the ngtrans WG to discuss transition scenarios for 3GPP (run by Jonne Soininen), and it is expected that that group will define what type of transition mechanisms are most applicable to 3GPP networks. So, perhaps it is best to leave this operator advice for that group? (9) I don't think that you should put "Manyfolks" in the footers, in the place of the author name. List the first author with et.al. Or, better yet, switch to listing an editor in the footer and at the top of the document, and list the authors in a section at the end. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 08:30:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFUbrP002312; Wed, 22 May 2002 08:30:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFUaL3002309; Wed, 22 May 2002 08:30: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.3+Sun/8.12.3) with ESMTP id g4MFUWrP002301 for ; Wed, 22 May 2002 08:30:32 -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 IAA05606 for ; Wed, 22 May 2002 08:30:38 -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 JAA15747 for ; Wed, 22 May 2002 09:30:37 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MFUas7024693 for ; Wed, 22 May 2002 17:30:36 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 22 17:30:36 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:19:34 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F065E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 17:30:25 +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 > First, I'll deal with the technical/content issues: > > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier. => This was in the document, then we received another comment stating that since the RFC states whether it is informational, standards ...etc, there is no need to say this in the doc. > > (2) The document states: > > "Additionally, due to special characteristics of the > cellular link, > lower layer connectivity information should make it > unnecessary to > track the reachability of the router. Therefore, while > the host must > support Neighbor Solicitation and Advertisement > messages, their use > is not necessary and the host may choose to not initiate them." > > Although I understand the desire to supress NUD messages on > point-to-point cellular links, this isn't how/why this should > be done. > > IPv6 hosts must include a full implementation of Neighbor Discovery, > including NUD with the full ND state machine, etc. Any compromise > on this effectively results in two different types of IPv6 hosts, > each with different behaviours/failure modes, etc. That > is something > that we definitely want to avoid. > There is no magic (in 3GPP or any other network) that can > guarantee that another node is always reachable, but it is > certainly possible for other layers of the protocol stack > (outside of IP) to maintain information about reachability, > and to know, at a given time, that another node is reachable. > ND includes the ability for those other protocol layers to > provide advice to the NUD code to indicate that a remote host > is reachable (only when those layers have confirmed two-way > reachability), which results in the supression of NUD messages > when the network is operating properly. The other layers of > 3GPP should provide this advice to ND. > > In cases were the GGSN actually does become unreachable, NUD > messages will be sent. But, in fact that NUD actually > _reduces_ the > amount of traffic that will sent over the air interface > while the GGSN is > unreachable, so this is actually a good thing for 3GPP. > > Instead of indicating that parts of ND are optional, or that > 3GPP hosts may "choose to not" use them, we should be indicating > what layers of 3GPP should provide reachability advice to ND at > what points. If those other layers can confirm two-way reachability > on an ongoing basis, they can provide frequent advice that will > result in the supression of all NUD messages when things are > operating properly. => I understand your points, however, we cannot say that 3GPP 'should' do anything. We are dealing with existing 3GPP and IETF specs. Luckily, for this particular case, the information is already available to those who can use it, so we can add more text to highlight that hosts should use the lowe layers' reachability information. > > (3) The document states: > > "This specification [RFC-2402] must be supported. The > IPsec WG has > discussed the role of AH in the future, and it is > possible that it > will be made optional in the future versions of the > IPsec protocol > set. Implementers are recommended to take this in account." > > I don't like the idea of writing a document today that tells > implementors that it is possible that something will be made > optional in the future. Today it is mandatory. Period. => OK. > > (4) The document states: > > "4. Mobility > > For the purposes of this document, IP mobility is not > relevant. When > Mobile IPv6 specification is approved, a future update to this > document may address these issues, as there may be some > effects on > IPv6 hosts due to Mobile IP. The movement of cellular > hosts within > 3GPP networks is handled by link layer mechanisms." > > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. > This document > should indicate that support for that feature is required. => Within the current MIPv6 spec, this CN portion is nothing. I.e. nothing to add to a standard IPv6 host. I'll send a separate reply for editorials. Thanx, Hesham > Now, for the editorial issues: > > (5) In section "1 Introduction", the only paragraph is not > properly laid out -- not clear if it is meant to be one or > two paragraphs. > > (6) The document states: > > "Cellular hosts should not support configured or > automatic tunnels to avoid unnecessary tunneling over the air > interface, unless there are no other mechanisms > available. Tunneling > can lead to poor usage of available bandwidth. " > > The "should not support...unless there are no other" construct > is somewhat confusing, since there probably isn't any way for > a host to know whether there are other mechanisms available. > > Although I understand why tunneling should be avoided over the > air interface if possible, I don't understand why this is a host > implementation issue. Isn't this more of an issue for the > operators? If so, it probably doesn't belong in this document. > > (7) As someone else mentioned, the following sentence is > similarly confusing: > > "Multicast Listener Discovery [RFC-2710] may be > supported, if the > cellular host is supporting applications that require > the use of > multicast services." > > (8) I also think that the following sentence is more advice for 3GPP > network operators, than it is specific to cellular hosts: > > "Hence, > intermediate 6to4 routers should carry out 6to4 > tunneling, instead > of cellular hosts." > > There is an ongoing effort in the ngtrans WG to discuss transition > scenarios for 3GPP (run by Jonne Soininen), and it is expected that > that group will define what type of transition mechanisms are most > applicable to 3GPP networks. So, perhaps it is best to leave this > operator advice for that group? > > (9) I don't think that you should put "Manyfolks" in the footers, > in the place of the author name. List the first author with et.al. > Or, better yet, switch to listing an editor in the footer and at > the top of the document, and list the authors in a section at the > end. > > Margaret > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 08:38:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFcQrP002456; Wed, 22 May 2002 08:38:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFcQhf002455; Wed, 22 May 2002 08:38: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.3+Sun/8.12.3) with ESMTP id g4MFcNrP002448 for ; Wed, 22 May 2002 08:38: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 IAA23639 for ; Wed, 22 May 2002 08:38:29 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29882 for ; Wed, 22 May 2002 09:39:11 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MFcRs7027289 for ; Wed, 22 May 2002 17:38:27 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 17:38:26 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4QJGC>; Wed, 22 May 2002 17:38:26 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F065F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Editorial: IPv6 w.g. Last Call on "IPv6 for Some Second and Thir d Generation Cellular Hosts" Date: Wed, 22 May 2002 17:38:26 +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 > Now, for the editorial issues: > > (5) In section "1 Introduction", the only paragraph is not > properly laid out -- not clear if it is meant to be one or > two paragraphs. > > (6) The document states: > > "Cellular hosts should not support configured or > automatic tunnels to avoid unnecessary tunneling over the air > interface, unless there are no other mechanisms > available. Tunneling > can lead to poor usage of available bandwidth. " > > The "should not support...unless there are no other" construct > is somewhat confusing, since there probably isn't any way for > a host to know whether there are other mechanisms available. => OK, will fix that. > > Although I understand why tunneling should be avoided over the > air interface if possible, I don't understand why this is a host > implementation issue. Isn't this more of an issue for the > operators? If so, it probably doesn't belong in this document. => I don't understand what you mean? It's a host issue because the tunnel originates from the host. > > (7) As someone else mentioned, the following sentence is > similarly confusing: > > "Multicast Listener Discovery [RFC-2710] may be > supported, if the > cellular host is supporting applications that require > the use of > multicast services." => Yep. Fixed that already in my hidden new version :) > > (8) I also think that the following sentence is more advice for 3GPP > network operators, than it is specific to cellular hosts: > > "Hence, > intermediate 6to4 routers should carry out 6to4 > tunneling, instead > of cellular hosts." => OK. I'm not sure that it is a bad thing though. > > There is an ongoing effort in the ngtrans WG to discuss transition > scenarios for 3GPP (run by Jonne Soininen), and it is expected that > that group will define what type of transition mechanisms are most > applicable to 3GPP networks. So, perhaps it is best to leave this > operator advice for that group? => OK. > > (9) I don't think that you should put "Manyfolks" in the footers, > in the place of the author name. List the first author with et.al. > Or, better yet, switch to listing an editor in the footer and at > the top of the document, and list the authors in a section at the > end. => Yeah, we can fix that in the next revision. I hope that, if there are no major issues during the WG last call, we can update the draft once to include the WG last call comments and IESG last call comments. Is that possible? 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 May 22 08:53:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFr9rP002496; Wed, 22 May 2002 08:53:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFr93E002495; Wed, 22 May 2002 08:53: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.3+Sun/8.12.3) with ESMTP id g4MFr6rP002488 for ; Wed, 22 May 2002 08:53:06 -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 IAA28294 for ; Wed, 22 May 2002 08:53:12 -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 JAA23082 for ; Wed, 22 May 2002 09:53: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 IAA19575; Wed, 22 May 2002 08:53:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4MFrAh28222; Wed, 22 May 2002 08:53:10 -0700 X-mProtect: <200205221553> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGqFWgi; Wed, 22 May 2002 08:53:08 PDT Message-ID: <3CEBBEE4.F91C21B3@iprg.nokia.com> Date: Wed, 22 May 2002 08:53:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F065E@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 Hello folks, > > There is a portion of mobility -- I believe that is is called the > > "correspondent node option", or something like that -- that must be > > implemented in all IPv6 hosts, in order to allow optimal routing > > to mobile nodes that are away from their home networks. > > This document > > should indicate that support for that feature is required. > > => Within the current MIPv6 spec, this CN portion is > nothing. I.e. nothing to add to a standard IPv6 > host. That is under discussion. In fact, I strongly believe that EVERY IPv6 correspondent node MUST implement return routability procedures. Furthermore, every IPv6 node already MUST implement Home Address Option. Here is the current text: ======================================================================== 8.1. Requirements for All IPv6 Hosts and Routers Since any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node, the following requirements apply to ALL IPv6 nodes (whether host or router, whether mobile or stationary): - Every IPv6 node MUST be able to process a Home Address option received in any IPv6 packet. - Every IPv6 node SHOULD be able to participate in a return routability procedure, process Binding Update messages, and to return a Binding Acknowledgement option if the Acknowledge (A) bit is set in the received Binding Update. - Every IPv6 node SHOULD be able to maintain a Binding Cache of the bindings received in accepted Binding Updates. ======================================================================== Furthermore, even if those SHOULDs remain SHOULDs (a mistake, in my opinion), a _cellular_ host is a case where it MUST be a MUST. Such nodes are even more likely than generic IPv6 nodes to be maintaining communications with mobile nodes -- for instance with VoIP. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 09:18:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGIWrP002635; Wed, 22 May 2002 09:18:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGIWGP002634; Wed, 22 May 2002 09:18: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.3+Sun/8.12.3) with ESMTP id g4MGISrP002627 for ; Wed, 22 May 2002 09:18:28 -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 JAA23007 for ; Wed, 22 May 2002 09:18:35 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26045 for ; Wed, 22 May 2002 09:18:34 -0700 (PDT) Received: from kenawang ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA17840 for ; Wed, 22 May 2002 09:17:27 -0700 (PDT) Message-Id: <4.2.2.20020522121306.01e792d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 May 2002 12:15:43 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0642@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:05 AM 5/22/02 , Hesham Soliman (ERA) wrote: > > ==> I completely agree, but this requires the servers > > support (or rather: > > haven't disabled the support for) recursive queries. I > > guess this only > > depends on the network topology. If DNS servers are managed by the > > cellular operator, this should be no problem. > > > > > >=> Your last statement is correct in our assumptions. >So I don't think it's a problem. How could 3GPP require/enforce this? What if a 3GPP user configures a 3GPP host to use a DNS server within his corporate network, for example? 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 May 22 09:24:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGOmrP002666; Wed, 22 May 2002 09:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGOmYJ002665; Wed, 22 May 2002 09:24: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.3+Sun/8.12.3) with ESMTP id g4MGOjrP002658 for ; Wed, 22 May 2002 09:24:45 -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 JAA13024 for ; Wed, 22 May 2002 09:24:52 -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 KAA22926 for ; Wed, 22 May 2002 10:24:51 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MGOjs7009552 for ; Wed, 22 May 2002 18:24:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 22 18:24:45 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 18:13:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0661@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 18:24:42 +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 > At 07:05 AM 5/22/02 , Hesham Soliman (ERA) wrote: > > > ==> I completely agree, but this requires the servers > > > support (or rather: > > > haven't disabled the support for) recursive queries. I > > > guess this only > > > depends on the network topology. If DNS servers are > managed by the > > > cellular operator, this should be no problem. > > > > > > > > > >=> Your last statement is correct in our assumptions. > >So I don't think it's a problem. > > How could 3GPP require/enforce this? What if a 3GPP user > configures a > 3GPP host to use a DNS server within his corporate network, > for example? > => Then he will get the service from the corporate network. If his DNS at the corporate networke does not work in recursive mode, for some reason, then it won't perform as well. BTW, almost all servers support recursive queries anyway. 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 May 22 09:26:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGQXrP002686; Wed, 22 May 2002 09:26:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGQXMO002685; Wed, 22 May 2002 09:26: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.3+Sun/8.12.3) with ESMTP id g4MGQTrP002675 for ; Wed, 22 May 2002 09:26:29 -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 JAA25844 for ; Wed, 22 May 2002 09:26:36 -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 KAA23009 for ; Wed, 22 May 2002 10:26:35 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 4.00) id 17AYwd-000NF4-00; Wed, 22 May 2002 09:26:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F0642@Esealnt861.al.sw. ericsson.se> <4.2.2.20020522121306.01e792d0@mail.windriver.com> Message-Id: Date: Wed, 22 May 2002 09:26:35 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How could 3GPP require/enforce this? What if a 3GPP user configures a > 3GPP host to use a DNS server within his corporate network, for example? bingo! my intended use of gprs/3gpp/... is layer three connectivity. i use my own dns servers, smtp servers, ... doesn't everybody? 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 May 22 09:33:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGXMrP002741; Wed, 22 May 2002 09:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGXMjf002740; Wed, 22 May 2002 09:33: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.3+Sun/8.12.3) with ESMTP id g4MGXJrP002733 for ; Wed, 22 May 2002 09:33: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 JAA13844 for ; Wed, 22 May 2002 09:33:26 -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 JAA05700 for ; Wed, 22 May 2002 09:33:26 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 4.00) id 17AZ3F-000Nb9-00; Wed, 22 May 2002 09:33:25 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Hesham Soliman Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" References: <4DA6EA82906FD511BE2F00508BCF0538044F0661@Esealnt861.al.sw.ericsson.se> Message-Id: Date: Wed, 22 May 2002 09:33:25 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Then he will get the service from the > corporate network. heck, i may run a full cacher on my 3gpp device > BTW, almost all servers support recursive queries > anyway. don't count on it 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 May 22 09:47:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGlerP002777; Wed, 22 May 2002 09:47:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGlenH002776; Wed, 22 May 2002 09:47: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.3+Sun/8.12.3) with ESMTP id g4MGlZrP002769 for ; Wed, 22 May 2002 09:47:35 -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 JAA23019 for ; Wed, 22 May 2002 09:47:42 -0700 (PDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24685 for ; Wed, 22 May 2002 10:47:41 -0600 (MDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g4MGlc312344; Wed, 22 May 2002 12:47:38 -0400 Message-Id: <200205221647.g4MGlc312344@minotaur.nge.isi.edu> To: Randy Bush Cc: ipng@sunroof.eng.sun.com, mrw@windriver.com Reply-To: mankin@isi.edu Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" In-reply-to: Your message of Wed, 22 May 2002 09:26:35 -0700. Date: Wed, 22 May 2002 12:47:38 -0400 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > How could 3GPP require/enforce this? What if a 3GPP user configures a > > 3GPP host to use a DNS server within his corporate network, for example? > > bingo! my intended use of gprs/3gpp/... is layer three connectivity. > i use my own dns servers, smtp servers, ... doesn't everybody? > > randy Wireless access providers are driving along in the same road ruts as lots of other access providers that don't let you control infrastructure elements - dsl, cable modem...they probably wonder why we're calling them out and not their predecessors, who do find ways to require/enforce, despite many clever people's best efforts to the contrary. How about if we find ways to say: IETF does not see the need to encode these practices, for whatever access technology, in RFCs? Allison -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 09:57:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGvLrP002808; Wed, 22 May 2002 09:57:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGvLMP002807; Wed, 22 May 2002 09:57: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.3+Sun/8.12.3) with ESMTP id g4MGvIrP002800 for ; Wed, 22 May 2002 09:57:18 -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 JAA22644 for ; Wed, 22 May 2002 09:57:25 -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 KAA11575 for ; Wed, 22 May 2002 10:57:24 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MGvN0E013384 for ; Wed, 22 May 2002 18:57:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 18:57:23 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4QLC0>; Wed, 22 May 2002 18:57:23 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0666@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Randy Bush'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 18:57:19 +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 > > Then he will get the service from the > > corporate network. > > heck, i may run a full cacher on my 3gpp device > > > BTW, almost all servers support recursive queries > > anyway. > > don't count on it => I'm not, the text merely says that things will work better if the DNS supports recursive lookups. Things will still work without it. 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 May 22 09:59:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGxBrP002825; Wed, 22 May 2002 09:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MGxBFS002824; Wed, 22 May 2002 09:59:11 -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.3+Sun/8.12.3) with ESMTP id g4MGx8rP002817 for ; Wed, 22 May 2002 09:59: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 JAA28272 for ; Wed, 22 May 2002 09:59:15 -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 JAA20833 for ; Wed, 22 May 2002 09:59:15 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 4.00) id 17AZSF-0000Hl-00; Wed, 22 May 2002 09:59:15 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Allison Mankin Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" References: <200205221647.g4MGlc312344@minotaur.nge.isi.edu> Message-Id: Date: Wed, 22 May 2002 09:59:15 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How about if we find ways to say: IETF does not see the need to > encode these practices, for whatever access technology, in RFCs? ^ ^ | | | `-- ill-advised | `-- or assist in any way randy, channeling 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 May 22 10:31:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHVLrP002990; Wed, 22 May 2002 10:31:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MHVKgA002989; Wed, 22 May 2002 10:31: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.3+Sun/8.12.3) with ESMTP id g4MHVHrP002982 for ; Wed, 22 May 2002 10:31:17 -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 KAA22210 for ; Wed, 22 May 2002 10:31:22 -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 LAA02791 for ; Wed, 22 May 2002 11:31:21 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MHVH0E019145 for ; Wed, 22 May 2002 19:31:17 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 19:31:17 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4QLT8>; Wed, 22 May 2002 19:31:17 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0669@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Randy Bush'" , Allison Mankin Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 19:31:15 +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 I assume, this discussion is in relation to the draft? I'm updating the text right now, so please let me know what you want to add. Specifically any ill-advice that the draft is giving to implementers. Hesham > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, May 22, 2002 6:59 PM > To: Allison Mankin > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third > Gener ation Cellular Hosts" > > > > How about if we find ways to say: IETF does not see the need to > > encode these practices, for whatever access technology, in RFCs? > ^ ^ > | | > | `-- ill-advised > | > `-- or assist in any way > > randy, channeling keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 10:31:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHVvrP003000; Wed, 22 May 2002 10:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MHVvJ0002999; Wed, 22 May 2002 10:31:57 -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.3+Sun/8.12.3) with ESMTP id g4MHVrrP002992 for ; Wed, 22 May 2002 10:31:53 -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 KAA07224 for ; Wed, 22 May 2002 10:31:58 -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 KAA08430 for ; Wed, 22 May 2002 10:31:52 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 830B96A907; Wed, 22 May 2002 20:31:46 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 702626A906; Wed, 22 May 2002 20:31:44 +0300 (EEST) Message-ID: <3CEBD641.3060104@kolumbus.fi> Date: Wed, 22 May 2002 20:32:49 +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: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier. Yes, we had agreed this and we even had the note... until we were told that we shouldn't re-state the type of the document in the text. > (2) The document states: > > "Additionally, due to special characteristics of the cellular link, > lower layer connectivity information should make it unnecessary to > track the reachability of the router. Therefore, while the host must > support Neighbor Solicitation and Advertisement messages, their use > is not necessary and the host may choose to not initiate them." > > (snip) > > Instead of indicating that parts of ND are optional, or that > 3GPP hosts may "choose to not" use them, we should be indicating > what layers of 3GPP should provide reachability advice to ND at > what points. If those other layers can confirm two-way reachability > on an ongoing basis, they can provide frequent advice that will > result in the supression of all NUD messages when things are > operating properly. Isn't this what we were trying to say? In 2.4. we state that ND is a mandatory part of IPv6. Then the text you quoted above was meant to say that lower layers do provide connectivity information, leading to supression of NUD messages. Or did you want more details as to exactly what layers, or the treatment of the error case? But I'm not sure I understand why NUD should be sent when the lower layers tell us that the GGSN is down -- the link is then down, and nothing gets through. Or did I miss something? > (3) The document states: > > "This specification [RFC-2402] must be supported. The IPsec WG has > discussed the role of AH in the future, and it is possible that it > will be made optional in the future versions of the IPsec protocol > set. Implementers are recommended to take this in account." > > I don't like the idea of writing a document today that tells > implementors that it is possible that something will be made > optional in the future. Today it is mandatory. Period. Ok, let's remove the note! > (4) The document states: > > "4. Mobility > > For the purposes of this document, IP mobility is not relevant. When > Mobile IPv6 specification is approved, a future update to this > document may address these issues, as there may be some effects on > IPv6 hosts due to Mobile IP. The movement of cellular hosts within > 3GPP networks is handled by link layer mechanisms." > > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. This document > should indicate that support for that feature is required. > > Can one of the MIP folks help me here? What is it called, and where > is it defined? Correspondent node functionality is in draft-ietf-mobileip-ipv6-17.txt, section 8.1 and 9. Previous versions of cellular draft contained a more in-depth discussion of MIPv6 functionality. However, we received again a comment that we should remove the forward reference to the I-D. I do agree about the correspondent node functionality part, though. However, there's a couple of things we should observe. In the current design, correspondent nodes do not need do anything special unless they want to do Route Optimization. The exact keyword for Route Optimization is also being debated. My interpretation of the discussion is that SHOULD is winning. In any case, communications with e.g. old IPv6 nodes that do not yet support MIPv6 are always possible without any other problems than non-optimal routing. 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 May 22 10:37:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHbOrP003050; Wed, 22 May 2002 10:37:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MHbOEQ003049; Wed, 22 May 2002 10:37:24 -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.3+Sun/8.12.3) with ESMTP id g4MHbLrP003042 for ; Wed, 22 May 2002 10:37:21 -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 KAA17834 for ; Wed, 22 May 2002 10:37:26 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16641 for ; Wed, 22 May 2002 11:38:09 -0600 (MDT) Message-ID: <004c01c201b7$0bc46b20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Hesham Soliman \(ERA\)" Cc: "'Margaret Wasserman'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F065E@Esealnt861.al.sw.ericsson.se> <3CEBBEE4.F91C21B3@iprg.nokia.com> Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Date: Wed, 22 May 2002 10:35:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > 8.1. Requirements for All IPv6 Hosts and Routers > > Since any IPv6 node may at any time be a correspondent node of a > mobile node, either sending a packet to a mobile node or receiving a > packet from a mobile node, the following requirements apply to ALL > IPv6 nodes (whether host or router, whether mobile or stationary): > > - Every IPv6 node MUST be able to process a Home Address option > received in any IPv6 packet. > > - Every IPv6 node SHOULD be able to participate in a return > routability procedure, process Binding Update messages, and to > return a Binding Acknowledgement option if the Acknowledge (A) > bit is set in the received Binding Update. > > - Every IPv6 node SHOULD be able to maintain a Binding Cache of the > bindings received in accepted Binding Updates. > > ======================================================================== > > Furthermore, even if those SHOULDs remain SHOULDs (a mistake, in > my opinion), a _cellular_ host is a case where it MUST be a MUST. > Such nodes are even more likely than generic IPv6 nodes to be > maintaining communications with mobile nodes -- for instance with > VoIP. > I agree with the level of "required to implement" as specified in the text above. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 10:47:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHlXrP003098; Wed, 22 May 2002 10:47:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MHlX9A003097; Wed, 22 May 2002 10:47: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.3+Sun/8.12.3) with ESMTP id g4MHlTrP003090 for ; Wed, 22 May 2002 10:47:29 -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 KAA15033 for ; Wed, 22 May 2002 10:47:34 -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 LAA16070 for ; Wed, 22 May 2002 11:47:34 -0600 (MDT) Received: from kenawang ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA28146; Wed, 22 May 2002 10:46:21 -0700 (PDT) Message-Id: <4.2.2.20020522133642.01e8b250@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 May 2002 13:47:12 -0400 To: Jari Arkko From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Cc: ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" In-Reply-To: <3CEBD641.3060104@kolumbus.fi> References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > (1) I think that this document should explicitly state, in the > > introduction, that it is not a standard and is not intended to > > modify or contradict any IPv6 standard documents. I thought that > > we had agreed to something like this earlier. > >Yes, we had agreed this and we even had the note... until we were told >that we shouldn't re-state the type of the document in the text. In this case, the intended audience of the document primarily lies outside of the IETF. Do you think that they will really understand the difference between our different document types? My understanding is that the 3GPP wants this document to have an RFC number ASAP, so that they can use it as a normative reference in one of their standards... right? > > (2) The document states: > > > > "Additionally, due to special characteristics of the cellular link, > > lower layer connectivity information should make it unnecessary to > > track the reachability of the router. Therefore, while the host must > > support Neighbor Solicitation and Advertisement messages, their use > > is not necessary and the host may choose to not initiate them." > > >Isn't this what we were trying to say? In 2.4. we state that ND >is a mandatory part of IPv6. Then the text you quoted above >was meant to say that lower layers do provide connectivity information, >leading to supression of NUD messages. Or did you want more details >as to exactly what layers, or the treatment of the error case? The text from the document (above) clearly indicates that hosts may choose not to initiate NS and NA messages. I read that to mean that a host may choose _never_ to initiate these messages, even when NUD (or other parts of ND) would require initiating these messages. It would be much clearer to state that 3GPP nodes must inlcude a full implementation of ND, including NUD, but that other parts of the 3GPP system may provide advice to the NUD code which result in supression of NUD messages, and site the section of the ND specification that indicates how such advice is used. Please note that the layers that provide advice to NUD about connectivity need to be able to ensure two-way IP-level connectivity. If there are no 3GPP layers that can do that, occasional NUD traffic may result. NUD only happens when there is traffic to send, and when there has been no recent confirmation of two-way connectivity (from TCP, for example), so it is not expected to generate much traffic. >But I'm not sure I understand why NUD should be sent when the >lower layers tell us that the GGSN is down -- the link is then >down, and nothing gets through. Or did I miss something? If the link is down, obviously no messages will be sent. But, what if the link is up, but the GGSN is down? Or what if the GGSN is not forwarding packets and/or responding at layer 3? 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 May 22 11:06:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MI6grP003189; Wed, 22 May 2002 11:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MI6fFU003188; Wed, 22 May 2002 11:06:41 -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.3+Sun/8.12.3) with ESMTP id g4MI6crP003181 for ; Wed, 22 May 2002 11:06:38 -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 LAA06459 for ; Wed, 22 May 2002 11:06: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 MAA24448 for ; Wed, 22 May 2002 12:06: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 LAA28279 for ; Wed, 22 May 2002 11:06:42 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4MI6g904643; Wed, 22 May 2002 11:06:42 -0700 X-mProtect: <200205221806> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqqu2uy; Wed, 22 May 2002 11:06:39 PDT Message-Id: <4.3.2.7.2.20020522103714.0302d830@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 May 2002 11:06:23 -0700 To: IPng List From: Bob Hinden Subject: New Version of "IPv6 Node Information Queries" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new version of "IPv6 Node Information Queries" was published recently. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-09.txt Pages : 15 Date : 20-May-02 After discussion with the Internet AD's an applicability statement was added to this draft. This should resolve the issues raised during the IETF last call regarding the scope of usage for the mechanisms in this draft. The applicability statement limits usage to diagnostic and debugging tools and is based on experience with current implementations of these mechanisms. An example of IPv6 debugging tools using "IPv6 Node Information Queries" is the PING6 program in the KAME IPv6 implementation that is used in most BSD distributions, MacOS X, JunOS, and ExtremeWare. Similar tools are also included in USAGI (Linux) IPv6 stack. The applicability statement is section 6 of the draft and is follows: 6. Applicability Statement IPv6 Node Information Queries include the capability to provide forward and reverse name lookups independent of the DNS by sending packets directly to IPv6 nodes or groups of nodes. The applicability of these mechanics is currently limited to diagnostic and debugging tools. These mechanisms can be used to learn the addresses and names for nodes on the other end of a point-to-point link or nodes on a shared-medium link such as an Ethernet. This is very useful when debugging problems or when bringing up IPv6 service where there isn't global routing or DNS name services available. IPv6's large auto-configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. An example of a IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in the KAME, USAGI, and other IPv6 implementations [KAME]. The mechanisms defined in this document may have wider applicability in the future (for example, name lookups in zero configuration networks, global reverse name lookups, etc.), but any use beyond debugging and diagnostic tools is left for further study and is beyond the scope of this document. The AD's have indicated that they will do another IETF last call for Proposed Standard given the length of time since the previous IETF last call. 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 May 22 11:07:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MI76rP003199; Wed, 22 May 2002 11:07:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MI76B8003198; Wed, 22 May 2002 11:07: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.3+Sun/8.12.3) with ESMTP id g4MI72rP003191 for ; Wed, 22 May 2002 11:07:02 -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 LAA06660 for ; Wed, 22 May 2002 11:07:08 -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 LAA00875 for ; Wed, 22 May 2002 11:07:07 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4MI72S05735; Wed, 22 May 2002 21:07:02 +0300 Date: Wed, 22 May 2002 21:07:02 +0300 (EEST) From: Pekka Savola To: Jari Arkko cc: Margaret Wasserman , , Charlie Perkins , "Hesham Soliman (ERA)" Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" In-Reply-To: <3CEBD641.3060104@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 May 2002, Jari Arkko wrote: > I do agree about the correspondent node functionality part, though. However, > there's a couple of things we should observe. In the current design, > correspondent nodes do not need do anything special unless they want to > do Route Optimization. The exact keyword for Route Optimization is also being > debated. My interpretation of the discussion is that SHOULD is winning. > In any case, communications with e.g. old IPv6 nodes that do not yet > support MIPv6 are always possible without any other problems than > non-optimal routing. Are you sure these are the only problems? It seems to me, that these old IPv6 nodes's, ie. no support for even HAO, cannot even talk to mobile nodes until receiving an ICMP message (one roundtrip). That's because Destination Option code for HAO is 209 -- if the destination node does not recognize it, the packet is discarded and an ICMP message sent. Actually, I'm not 100% sure from MIPv6 -17 draft that MN's are to process and take account ICMP parameter problem code 2 messages sent by these old nodes, in any way. (Even though this wouldn't be a problem, additional cost of zero support in CN's would be that connections would break if MN moves.) Perhaps I missed something? -- 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 May 22 11:17:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIH0rP003241; Wed, 22 May 2002 11:17:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIGx8k003240; Wed, 22 May 2002 11:16: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.3+Sun/8.12.3) with ESMTP id g4MIGurP003233 for ; Wed, 22 May 2002 11:16:56 -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 LAA10062 for ; Wed, 22 May 2002 11:17:01 -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 MAA01209 for ; Wed, 22 May 2002 12:17:00 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C00386A908; Wed, 22 May 2002 21:16:53 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C3F76A907; Wed, 22 May 2002 21:16:51 +0300 (EEST) Message-ID: <3CEBE0D4.5020207@kolumbus.fi> Date: Wed, 22 May 2002 21:17:56 +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: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> <4.2.2.20020522133642.01e8b250@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >>>(1) I think that this document should explicitly state, in the >>>introduction, that it is not a standard and is not intended to >>>modify or contradict any IPv6 standard documents. I thought that >>>we had agreed to something like this earlier. >>> >>Yes, we had agreed this and we even had the note... until we were told >>that we shouldn't re-state the type of the document in the text. >> > > In this case, the intended audience of the document primarily lies outside of the > IETF. Do you think that they will really understand the difference between our > different document types? I don't know. I'm happy to put the note back in if you think it is necessary and no one else objects. > It would be much clearer to state that 3GPP nodes must inlcude a full > implementation of ND, including NUD, but that other parts of the 3GPP system > may provide advice to the NUD code which result in supression of NUD messages, > and site the section of the ND specification that indicates how such advice > is used. I think this was the intention. Perhaps we can reformulate the text to be clearer in this respect. I'll send some text off-line to you to make sure you are happy with the reformulation. > Please note that the layers that provide advice to NUD about connectivity > need to be able to ensure two-way IP-level connectivity. If there are no > 3GPP layers that can do that, occasional NUD traffic may result. NUD > only happens when there is traffic to send, and when there has been no > recent confirmation of two-way connectivity (from TCP, for example), so > it is not expected to generate much traffic. Ok. >>But I'm not sure I understand why NUD should be sent when the >>lower layers tell us that the GGSN is down -- the link is then >>down, and nothing gets through. Or did I miss something? >> > > If the link is down, obviously no messages will be sent. But, what if the > link is up, but the GGSN is down? Or what if the GGSN is not forwarding > packets and/or responding at layer 3? In 3GPP, the SGSN keeps track of the status of the GGSN and will inform hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet exchange, so in order for the SGSN to think that the GGSN is up, the GGSN must be responding at layer 3. If the GGSN is up but not forwarding, I believe it would send ICMP errors. 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 May 22 11:22:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIMtrP003269; Wed, 22 May 2002 11:22:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIMtkX003268; Wed, 22 May 2002 11:22: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.3+Sun/8.12.3) with ESMTP id g4MIMqrP003261 for ; Wed, 22 May 2002 11:22: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 LAA12902 for ; Wed, 22 May 2002 11:22:57 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18716 for ; Wed, 22 May 2002 12:22:35 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 11:22:33 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 May 2002 11:22:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 11:22:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 11:22:32 -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, 22 May 2002 11:22:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 11:22:32 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF05A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Thread-Index: AcIBgT4HdXnf236aRGiq5pgSJaaqWQAPBU2w From: "Dave Thaler" To: , X-OriginalArrivalTime: 22 May 2002 18:22:32.0619 (UTC) FILETIME=[A3ABD7B0:01C201BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4MIMqrP003262 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > > >=> Do you mean that MLD is used for the ALL Nodes mcast > >address ofr example? > > yes. > > itojun No. RFC 2710 end of section 5: The link-scope all-nodes address (FF02::1) is handled as a special case. The node starts in Idle Listener state for that address on every interface, never transitions to another state, and never sends a Report or Done for that address. MLD messages are never sent for multicast addresses whose scope is 0 (reserved) or 1 (node-local). MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). -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 May 22 11:24:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIOWrP003286; Wed, 22 May 2002 11:24:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIOVTL003285; Wed, 22 May 2002 11:24:31 -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.3+Sun/8.12.3) with ESMTP id g4MIOSrP003278 for ; Wed, 22 May 2002 11:24:28 -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 LAA13705 for ; Wed, 22 May 2002 11:24:34 -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 LAA12196 for ; Wed, 22 May 2002 11:24:32 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id E68CB6A908; Wed, 22 May 2002 21:24:31 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4BA116A907; Wed, 22 May 2002 21:24:30 +0300 (EEST) Message-ID: <3CEBE29F.3030304@kolumbus.fi> Date: Wed, 22 May 2002 21:25:35 +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: Pekka Savola Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >>In any case, communications with e.g. old IPv6 nodes that do not yet >>support MIPv6 are always possible without any other problems than >>non-optimal routing. > > Are you sure these are the only problems? It seems to me, that these old > IPv6 nodes's, ie. no support for even HAO, cannot even talk to mobile > nodes until receiving an ICMP message (one roundtrip). > > Perhaps I missed something? In order to use the HAO, you'll have to establish a BCE. In order to establish a BCE, you'll have to complete the return routability procedure. Any nodes is of course free to refuse participating the return routability procedure or accepting a binding, say due to lack of memory. If the MN can't establish a binding, it won't use Route Optimization, won't use HAO, and from the point of view of the CN, the MN looks like a stationary node. Obviously mobile nodes would initiate/continue traffic in the unoptimized way i.e. through the home agent until they have established BCE at the CN. So I don't think there are any lost roundtrips with the regular traffic, though of course they may be few useless signaling messages if the MN tries to establish a binding but the CN refuses. But I believe this should be attempted in parallel with the regular IP traffic. 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 May 22 11:25:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIPIrP003334; Wed, 22 May 2002 11:25:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIPIZn003333; Wed, 22 May 2002 11:25: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.3+Sun/8.12.3) with ESMTP id g4MIPCrP003313 for ; Wed, 22 May 2002 11:25:12 -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 LAA13563 for ; Wed, 22 May 2002 11:25:18 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11384 for ; Wed, 22 May 2002 12:25:16 -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 g4MIQiT09355 for ; Wed, 22 May 2002 21:26:44 +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, 22 May 2002 21:25:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 21:25:15 +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="utf-8" Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Date: Wed, 22 May 2002 21:25:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E17@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Thread-Index: AcIBoo/FMbKAXNZGQsWz7VUxrwUMBgAGM3+X To: , X-OriginalArrivalTime: 22 May 2002 18:25:15.0409 (UTC) FILETIME=[04B3A010:01C201BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g4MIPCrP003314 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, My 2 cents: > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier. It does specifically state that it is an Informational document and does not contradict existing standards. An IETF standard is a procedural issue, in my mind (following a specific route to Full Standard status). I'm not so sure what to say, unless you prefer we state something like: This document is an Informational Document, not a Standards Track document. It is not meant to modify existing Standards Track documents. (use of this document in non-standard ways may affect your warranty; city and highway mileage may differ. Offer limited, while supplies last ...) > IPv6 hosts must include a full implementation of Neighbor Discovery, > including NUD with the full ND state machine, etc. Any compromise > on this effectively results in two different types of IPv6 hosts, > each with different behaviours/failure modes, etc. That is something > that we definitely want to avoid. Do the RFCs mandate a full ND state machine? I thought that is much more of an inplementation issue. However, the text does not state anywhere that Neighbor Discovery is optional to use, but tries to indicate in what circumstances the sending of NS and NA messages can be avoided. It does not put any requirements for them not to be sent. > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. This document > should indicate that support for that feature is required. For AH you explicitly state that we need say that AH is mandatory, full stop, as it is an existing requirement. For the above, however, CN functionality is not yet standardized, not yet through a security area review, etc. Additionally, I would think that it is the IPv6 WG to decide what is a mandatory feature an IPv6 node. It would be reckless to advice implementors to implement things which are not standardized, but we can call out that the work is on going and the clever implementor would review the current status of the MIPv6 specification. When MIPv6 becomes a standard, then our document should be updated accordingly. I don't think we can do anything else. > The "should not support...unless there are no other" construct > is somewhat confusing, since there probably isn't any way for > a host to know whether there are other mechanisms available. How about: Cellular hosts should not use configured or automatic tunnels, if there are other mechanisms available to the host, in order to avoid unnecessary tunneling over the air. .... > There is an ongoing effort in the ngtrans WG to discuss transition > scenarios for 3GPP (run by Jonne Soininen), and it is expected that > that group will define what type of transition mechanisms are most >applicable to 3GPP networks. So, perhaps it is best to leave this > operator advice for that group? Sure. This document was started before the NGTRANS work had started, and we just haven't deleted the duplicate info. 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 May 22 11:25:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIPKrP003337; Wed, 22 May 2002 11:25:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIPK1x003336; Wed, 22 May 2002 11:25: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.3+Sun/8.12.3) with ESMTP id g4MIPDrP003320 for ; Wed, 22 May 2002 11:25: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 LAA14109 for ; Wed, 22 May 2002 11:25:19 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12788 for ; Wed, 22 May 2002 11:25:19 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MIPPq07518; Wed, 22 May 2002 13:25:25 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 13:25:33 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03CEFA51@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Jari Arkko , Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Gener ation Cellular Hosts" Date: Wed, 22 May 2002 13:25:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201BE.0B95DCE0" 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_01C201BE.0B95DCE0 Content-Type: text/plain; charset="iso-8859-1" > > > > "4. Mobility > > Is there support in this WG for making route optimization a MUST in all IPv6 hosts ? The ball is really in this WG's court. This is really a "do you really want ubiquitous end to end functionality or not?" question. ------_=_NextPart_001_01C201BE.0B95DCE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third = Generation Cellular Hosts"

>  >
>  > "4. Mobility
>  >


Is there support in this WG for making route = optimization a MUST in all IPv6 hosts ? The ball is really in this WG's = court. This is really a "do you really want ubiquitous end to end = functionality or not?" question.

------_=_NextPart_001_01C201BE.0B95DCE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 11:27:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIRPrP003385; Wed, 22 May 2002 11:27:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIRPl0003384; Wed, 22 May 2002 11:27: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.3+Sun/8.12.3) with ESMTP id g4MIRLrP003377 for ; Wed, 22 May 2002 11:27:21 -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 LAA15377 for ; Wed, 22 May 2002 11:27:26 -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 MAA13184 for ; Wed, 22 May 2002 12:27:26 -0600 (MDT) Received: from kenawang ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA29914; Wed, 22 May 2002 11:26:16 -0700 (PDT) Message-Id: <4.2.2.20020522142423.01e5a400@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 May 2002 14:27:04 -0400 To: Jari Arkko From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3CEBE0D4.5020207@kolumbus.fi> References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> <4.2.2.20020522133642.01e8b250@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >In 3GPP, the SGSN keeps track of the status of the GGSN and will inform >hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet >exchange, so in order for the SGSN to think that the GGSN is up, the GGSN >must be responding at layer 3. If the GGSN is up but not forwarding, I >believe it would send ICMP errors. Does the SGSN inform the host of the fact that the GGSN is up on an ongoing basis? Or only contact the host when the GGSN goes down? If the former, whatever host process receives this notification could give advice to ND to avoid NUD messages. If the latter, then we probably don't want to supress NUD messages based on a lack of bad news from the SGSN -- what if we can't reach either the SGSN or the GGSN? 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 May 22 11:27:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIRhrP003398; Wed, 22 May 2002 11:27:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIRgEe003397; Wed, 22 May 2002 11:27:42 -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.3+Sun/8.12.3) with ESMTP id g4MIRdrP003390 for ; Wed, 22 May 2002 11:27: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 LAA01781 for ; Wed, 22 May 2002 11:27:45 -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 MAA08195 for ; Wed, 22 May 2002 12:27:44 -0600 (MDT) 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 g4MIRbFD032328; Wed, 22 May 2002 14:27:38 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4MIRYo199400; Wed, 22 May 2002 14:27:34 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g4MIR1k01343; Wed, 22 May 2002 14:27:01 -0400 Message-Id: <200205221827.g4MIR1k01343@rotala.raleigh.ibm.com> To: Jari Arkko cc: Margaret Wasserman , ipng@sunroof.eng.sun.com, Charlie Perkins , "Hesham Soliman (ERA)" Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" In-Reply-To: Message from "Wed, 22 May 2002 20:32:49 +0300." <3CEBD641.3060104@kolumbus.fi> Date: Wed, 22 May 2002 14:27:01 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > (1) I think that this document should explicitly state, in the > > introduction, that it is not a standard and is not intended to > > modify or contradict any IPv6 standard documents. I thought that > > we had agreed to something like this earlier. > Yes, we had agreed this and we even had the note... until we were told > that we shouldn't re-state the type of the document in the text. Since, I'm apparently the one who "told" you this, let me clarify. What I thought I requested was taking out all references to a particular RFC being a "standard" (vs. informational or something else). Just referring to the RFCs as RFCs is preferred. As a general rule, an RFC shouldn't be stating what the status of another RFC is, since this can change over time. My comments should not be interpreted as precluding making the changes Margaret is requesting. 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 May 22 11:28:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MISirP003431; Wed, 22 May 2002 11:28:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MISiGH003430; Wed, 22 May 2002 11:28: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.3+Sun/8.12.3) with ESMTP id g4MISerP003423 for ; Wed, 22 May 2002 11:28:41 -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 LAA14881 for ; Wed, 22 May 2002 11:28:47 -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 LAA15137 for ; Wed, 22 May 2002 11:28: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 g4MIT8k03193 for ; Wed, 22 May 2002 21:29:08 +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, 22 May 2002 21:28:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 21:28:44 +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="utf-8" Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Date: Wed, 22 May 2002 21:28:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E18@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Thread-Index: AcIBvTu+D3nQB2U2Rd6AX12JE20xBgAAPfZd To: , Cc: , , X-OriginalArrivalTime: 22 May 2002 18:28:44.0568 (UTC) FILETIME=[815EC180:01C201BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g4MISfrP003424 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > In this case, the intended audience of the document primarily lies outside of the > IETF. Do you think that they will really understand the difference between our > different document types? I think you should give a little credit to folks - I do think they understand the IETF document notation system. How about if we add a reference to where IETF documents are defined? That would probably be enough. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 11:31:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIVNrP003469; Wed, 22 May 2002 11:31:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIVMxS003468; Wed, 22 May 2002 11:31:22 -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.3+Sun/8.12.3) with ESMTP id g4MIVJrP003461 for ; Wed, 22 May 2002 11:31:19 -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 LAA15848 for ; Wed, 22 May 2002 11:31:25 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15834 for ; Wed, 22 May 2002 12:31:24 -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 g4MIVkk04308 for ; Wed, 22 May 2002 21:31:46 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 May 2002 21:31:22 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 21:31:22 +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="utf-8" Subject: RE: IPv6 w.g. Last Call on c Date: Wed, 22 May 2002 21:31:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E19@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" Thread-Index: AcIBvnMTlmCKNYuMQlyL3bkx5g6TXgAADELK To: , , Cc: , , X-OriginalArrivalTime: 22 May 2002 18:31:22.0614 (UTC) FILETIME=[DF92A960:01C201BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g4MIVKrP003462 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Glenn, > > "4. Mobility > > > Is there support in this WG for making route optimization a MUST in all IPv6 hosts ? I agree. I don't think it the "IPv6 for Some Second and Third Generation Cellular Hosts" documents place to recommend behavior that has not been agreed to in the WG. 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 May 22 11:33:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIX9rP003498; Wed, 22 May 2002 11:33:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIX9IZ003497; Wed, 22 May 2002 11:33:09 -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.3+Sun/8.12.3) with ESMTP id g4MIX6rP003490 for ; Wed, 22 May 2002 11:33:06 -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 LAA16492 for ; Wed, 22 May 2002 11:33:12 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25681 for ; Wed, 22 May 2002 12:33:10 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 11:33:08 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 May 2002 11:33:08 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 11:33:09 -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); Wed, 22 May 2002 11:33:08 -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); Wed, 22 May 2002 11:33:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Date: Wed, 22 May 2002 11:33:07 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840CA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts" Thread-Index: AcIBhExJ6/iByZIoTJqn+z6QJ3W/wgAOVsMg From: "Dave Thaler" To: Cc: , X-OriginalArrivalTime: 22 May 2002 18:33:08.0207 (UTC) FILETIME=[1E82DFF0:01C201BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4MIX6rP003491 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, May 22, 2002 4:30 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera > tion Cellular Hosts" > > >=> I've never seen that in any spec. > >I guess you are saying that it's needed for L2 > >switches that snoop MLD messages to decide > >on mcast forwarding of mcast ethernet frames? > > > >If so, then we don't have this situation in > >cellular networks. What we're dealing with is > >a p2p link with no multicast capability. > > even under the above situation, there's no such clause that permits > omission of MLD in RFC2710 (MLD). if you have any reference please > let me know, i'm interested in knowing the rationale for the claim. > > itojun The relevant paragraph in RFC 2710 for what itojun is referring to is: MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). I believe this was indeed for supporting snooping switches. However, sending reports for link-scoped groups is also required if you want to support source notification of interest (draft-ietf-idmr-msnip-01.txt) for link-scoped groups. The scenario here would be if the router ever needed to be informed, to know whether to start sending data to that group or not. -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 May 22 11:41:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIfkrP003583; Wed, 22 May 2002 11:41:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIfk2Q003582; Wed, 22 May 2002 11:41: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.3+Sun/8.12.3) with ESMTP id g4MIfhrP003575 for ; Wed, 22 May 2002 11:41:43 -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 LAA07194 for ; Wed, 22 May 2002 11:41:49 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00558 for ; Wed, 22 May 2002 12:42:31 -0600 (MDT) 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 g4MIflFD067808; Wed, 22 May 2002 14:41:47 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4MIfho39992; Wed, 22 May 2002 14:41:43 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g4MIfA401450; Wed, 22 May 2002 14:41:10 -0400 Message-Id: <200205221841.g4MIfA401450@rotala.raleigh.ibm.com> To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Mobility support in cellular (was Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" ) In-Reply-To: Message from "Wed, 22 May 2002 11:06:15 EDT." <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> Date: Wed, 22 May 2002 14:41:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note: folk might want change some subject lines to aid followups on the thread... Margaret Wasserman writes: > (4) The document states: > "4. Mobility > > For the purposes of this document, IP mobility is not relevant. When > Mobile IPv6 specification is approved, a future update to this > document may address these issues, as there may be some effects on > IPv6 hosts due to Mobile IP. The movement of cellular hosts within > 3GPP networks is handled by link layer mechanisms." > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. This document > should indicate that support for that feature is required. > Can one of the MIP folks help me here? What is it called, and where > is it defined? There is a basic problem with having this document specify any sort of required behavior with respect to MIPv6. There is no RFC today for MIPv6 (we are getting close, but we are not quite there yet). Until the MIPv6 spec is finalized, it is a bit of a moving target. Having this document say one must implement correspondant node functionality as defined in draft-xxx leaves a dangling reference to work-in-progress. This is what would be considered a normative reference (i.e. you need to the other spec to correctly implement the functionality that is being required). I have a hard time seeing how this document can say anything definitive about what parts of the MIP ID need to be implemented. Plus, my understanding is that the target audience for the celluar-requirements document is 3GPP and friends. They do not currently have plans that involve using MIPv6. So I don't see the need to say anything about MIPv6. 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 May 22 11:47:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MIldrP003612; Wed, 22 May 2002 11:47:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MIld5X003611; Wed, 22 May 2002 11:47:39 -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.3+Sun/8.12.3) with ESMTP id g4MIlZrP003604 for ; Wed, 22 May 2002 11:47:35 -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 LAA21856 for ; Wed, 22 May 2002 11:47:41 -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 MAA03774 for ; Wed, 22 May 2002 12:47:40 -0600 (MDT) Received: from kenawang ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA15029; Wed, 22 May 2002 11:46:29 -0700 (PDT) Message-Id: <4.2.2.20020522144618.01e7b280@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 May 2002 14:47:25 -0400 To: Thomas Narten From: Margaret Wasserman Subject: Re: Mobility support in cellular (was Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" ) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200205221841.g4MIfA401450@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >There is a basic problem with having this document specify any sort of >required behavior with respect to MIPv6. There is no RFC today for >MIPv6 (we are getting close, but we are not quite there yet). Okay. I agree, then, that we shouldn't specify any MIP behaviour in this document. I was under the (apparently mistaken) impression that we were further along on MIPv6 than this... 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 Wed May 22 12:11:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MJB5rP003701; Wed, 22 May 2002 12:11:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MJB5AK003700; Wed, 22 May 2002 12:11: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.3+Sun/8.12.3) with ESMTP id g4MJB2rP003693 for ; Wed, 22 May 2002 12:11:02 -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 MAA18423 for ; Wed, 22 May 2002 12:11:08 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09509 for ; Wed, 22 May 2002 12:11:07 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id B9AE11C81; Wed, 22 May 2002 15:11:06 -0400 (EDT) Date: Wed, 22 May 2002 15:11:06 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Threat model for DNS discovery (was: Stateless DNS discovery draft) In-Reply-To: <20020515001932.6F2777B4B@berkshire.research.att.com> References: <20020515001932.6F2777B4B@berkshire.research.att.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020522191106.B9AE11C81@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 14 May 2002 20:19:32 -0400, Steve Bellovin wrote: > > >So how can we understand the threat model for DNS discovery? > > > That takes work... A good starting point would be Derek Atkins' and > Rob Austein's DNS threat analysis document > (draft-ietf-dnsext-dns-threats-01.txt) I haven't had a chance to > read it carefully in this context. Rob, I know you're on this > list... I replied to this over a week ago, but my reply never made it to the list (no doubt my message had the wrong RFC822 From: header -- does anybody process the manual intervention queue for this list anymore?). At any rate, as best as I can recall what I said last week, and with the understanding that I'm not claiming to understand all the issues here (far from it), this is just some preliminary thinking out loud (ok, on phospher): There's a fundamental question of whether one trusts the local network or not. I don't. Some do. Threat models for any discovery protocol depend heavily on where one stands on this point. Recursive mode (usually stub) resolvers without DNSSEC are walking targets: they're just throwing themselves on the mercy of some recursive mode name server and don't have much grounds for any kind of opinion on the results they get back. DNS Discovery probably doesn't change this model very much. Iterative mode resolvers without DNSSEC are also at risk (see the dns-threats draft), but the scenario is a bit different. In theory, an iterative mode resolver can try somewhat harder to get a valid answer, but without end-to-end data integrity protection the resolver is still in a pretty weak position. The main difference here as far as DNS Discovery is concered, though, is the bootstrap configuration data needed by an iterative mode resolver is (in practice) disjoint from the bootstrap configuration data needed by a recursive mode resolver. That is: while, in theory, an iterative mode resolver's "SBELT" (see RFC 1034) can be primed with some arbitrary list of name servers that the resolver turns to when it has no better idea of where to send a query, in practice SBELT is almost always set (via out of band means) to the IP addresses of the servers for the root zone. With DNSSEC, the picture is a bit different. DNSSEC provides an end-to-end data integrity check, so that resolvers are no longer just trusting name servers to return the right answer. But it's a bit more complex than that, with several subcases. A recursive mode (usually stub) resolver that uses the lame-oid "ask the recursive mode name server to do all that annoying DNSSEC junk" misfeature is not a lot better off than a recursive mode resolver without DNSSEC. Essential, there are now two separate trust mechanisms: the DNSSEC end-to-end data integrity check (which in this case does not go end-to-end), and whatever mechanism the resolver uses when it's talking to its chosen recusive mode name servers. The current least-bad mechanism for the latter mechanism is TSIG, but there's a nontrivial key distribution problem there. So either the recursive mode resolver needs some out-of-band knowledge of some kind of keying material that it can use to secure its conversations with its chosen recursive mode name servers, or the DNS discovery protocol has to supply the necessary keying material. As noted in the dns-threats draft, simply establishing a "secure" channel between the recursive mode resolver and the recursive mode name server isn't sufficient, because "secure" communication to a server that the resolver has no reason to trust is not particularly useful. Also note that hiding the DNS Discovery process from the resolver (which, in my opinion, is what the well-known-address proposal does) may make the (already bad) trust model here even worse: if the resolver doesn't know which name server is using a particular well-known IP address at the moment, it may have a harder time figuring out which key it use to talk to that name server. An iterative mode resolver is in fairly decent shape with DNSSEC, since it can perform the end-to-end integrity checks itself and thus no longer needs to trust any name server blindly, but there's a key distribution problem for this case too: the key for the root zone. Once again, either the resolver has to know that a priori, or the resolver needs some trustworthy way of acquiring that knowledge. There's a third weird case that has not yet received a lot of discussion: a recursive mode resolver that does its own validation of DNSSEC signatures. The basic idea here is that the DNSSEC integrity check is an end-to-end mechanism, while the mechanism by which DNS data is retrieved is essentially hop-by-hop (due to DNS caching). So it seems perfectly reasonable (to me, anyway) that an implementation might want to offload the process of fetching the data but still want to verify the integrity of the data. This case hasn't gotten a lot of attention to date, so the precise details of how one would go about this haven't been nailed down. I think it's possible (if somewhat annoying) to do this with DNSSEC as currently specified, which is why I haven't made a big issue out of it. For any case in which the resolver might be checking DNSSEC signatures, there's also a time discovery problem, because DNSSEC signature verification includes checking the expiration time. While it's probably safe to assume that any toaster capable of implementing DNS is capable of measuring elapsed time while the toaster is running, it's not safe to assume that every toasters has a clock that ticks while the toaster is turned off. So DNSSEC signature verification also adds a clock setting problem, which has its own set of trust issues. (S)NTP (with its authentication mechanism enabled) seems sufficient for this, but adds another key distribution problem. So: in all of the DNSSEC-using cases, there are key distribution problems of one kind or another. Big surprise. So part of the discovery question is to what extent one can or should use the discovery protocol to deal with the key distribution swamp. As far as I know, the discovery via well-known addresses proposal does not yet have any mechanism for dealing with this. It's not obvious to me where one would hang such a mechanism, but maybe I'm missing something. The "stateless DHCPv6" approach could, in theory, use DHCPv6's authentication mechanism, but as specified that mechanism doesn't look like an appropriate solution to this problem either. Then again, it might be possible to reuse the DHCPv6 authentication framework with different algorithms; that is, in this case, I can see where one might hang a mechanism, if we can come up with an appropriate mechanism. Ultimately, however, there's still the basic problem of to what extent the node trusts its local network, and what basis (eg, out-of-band keying) the node has for trusting any server it discovers if it doesn't trust the local network. --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 12:29:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MJTlrP003768; Wed, 22 May 2002 12:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MJTkA6003767; Wed, 22 May 2002 12: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MJThrP003760 for ; Wed, 22 May 2002 12:29:43 -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 MAA07736 for ; Wed, 22 May 2002 12:29:50 -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 NAA19620 for ; Wed, 22 May 2002 13:29:49 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id D2ADD6A907; Wed, 22 May 2002 22:29:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C7ECE6A908; Wed, 22 May 2002 22:29:43 +0300 (EEST) Message-ID: <3CEBF1E8.7020402@kolumbus.fi> Date: Wed, 22 May 2002 22:30:48 +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: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> <4.2.2.20020522133642.01e8b250@mail.windriver.com> <4.2.2.20020522142423.01e5a400@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: >>In 3GPP, the SGSN keeps track of the status of the GGSN and will inform >>hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet >>exchange, so in order for the SGSN to think that the GGSN is up, the GGSN >>must be responding at layer 3. If the GGSN is up but not forwarding, I >>believe it would send ICMP errors. > > Does the SGSN inform the host of the fact that the GGSN is up on an ongoing basis? > Or only contact the host when the GGSN goes down? > > If the former, whatever host process receives this notification could give advice to ND > to avoid NUD messages. > > If the latter, then we probably don't want to supress NUD messages based on a lack > of bad news from the SGSN -- what if we can't reach either the SGSN or the GGSN? The former. If the 2-way connection to the SGSN dies or the whole SGSN dies, the air link is down in a manner that is observable to the host. In conclusion, I think we should formulate the text to indicate that lower layer connectivity information is available in this specific case, and should be used to suppress NUD, as described in the original RFC. 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 May 22 15:55:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMtHrP004422; Wed, 22 May 2002 15:55:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MMtHoB004421; Wed, 22 May 2002 15:55: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.3+Sun/8.12.3) with ESMTP id g4MMtFrP004414 for ; Wed, 22 May 2002 15:55: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 g4MMskaU028720 for ; Wed, 22 May 2002 15:54:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4MMsjLh028719 for ipng@sunroof.eng.sun.com; Wed, 22 May 2002 15:54:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MGEErP002610 for ; Wed, 22 May 2002 09:14:14 -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 JAA21480 for ; Wed, 22 May 2002 09:14:21 -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 KAA05958 for ; Wed, 22 May 2002 10:14:18 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 996076A907; Wed, 22 May 2002 19:14:00 +0300 (EEST) Received: from ericsson.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7E7F26A906; Wed, 22 May 2002 19:13:53 +0300 (EEST) Message-ID: <3CEBC403.8010708@ericsson.fi> Date: Wed, 22 May 2002 19:14:59 +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: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, Charlie Perkins Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts" References: <4.2.2.20020522110341.01e5a2a0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier. Yes, we had agreed this and we even had the note... until we were told that we shouldn't re-state the type of the document in the text. > (2) The document states: > > "Additionally, due to special characteristics of the cellular link, > lower layer connectivity information should make it unnecessary to > track the reachability of the router. Therefore, while the host must > support Neighbor Solicitation and Advertisement messages, their use > is not necessary and the host may choose to not initiate them." > > (snip) > > Instead of indicating that parts of ND are optional, or that > 3GPP hosts may "choose to not" use them, we should be indicating > what layers of 3GPP should provide reachability advice to ND at > what points. If those other layers can confirm two-way reachability > on an ongoing basis, they can provide frequent advice that will > result in the supression of all NUD messages when things are > operating properly. Isn't this what we were trying to say? In 2.4. we state that ND is a mandatory part of IPv6. Then the text you quoted above was meant to say that lower layers do provide connectivity information, leading to supression of NUD messages. Or did you want more details as to exactly what layers, or the treatment of the error case? But I'm not sure I understand why NUD should be sent when the lower layers tell us that the GGSN is down -- the link is then down, and nothing gets through. Or did I miss something? > (3) The document states: > > "This specification [RFC-2402] must be supported. The IPsec WG has > discussed the role of AH in the future, and it is possible that it > will be made optional in the future versions of the IPsec protocol > set. Implementers are recommended to take this in account." > > I don't like the idea of writing a document today that tells > implementors that it is possible that something will be made > optional in the future. Today it is mandatory. Period. Ok, let's remove the note! > (4) The document states: > > "4. Mobility > > For the purposes of this document, IP mobility is not relevant. When > Mobile IPv6 specification is approved, a future update to this > document may address these issues, as there may be some effects on > IPv6 hosts due to Mobile IP. The movement of cellular hosts within > 3GPP networks is handled by link layer mechanisms." > > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. This document > should indicate that support for that feature is required. > > Can one of the MIP folks help me here? What is it called, and where > is it defined? Correspondent node functionality is in draft-ietf-mobileip-ipv6-17.txt, section 8.1 and 9. Previous versions of our draft contained a more in-depth discussion of MIPv6 functionality. However, we received again a comment that we should remove the forward reference to the I-D. I do agree about the correspondent node functionality part, though. However, there's a couple of things we should observe: - In the current design, correspondent nodes do not need any special support unless they want to do Route Optimization. - The exact keyword for Route Optimization is being debated. My interpretation of the discussion is that SHOULD is winning. In any case, communications with e.g. old IPv6 nodes that do not yet support MIPv6 are always possible without any other problems than non-optimal routing. - Again, the forward reference... we could add a note describing that correspondent node functionality is something to be considered even if you don't use mobile node functionality, but of course it's hard to mandate an exact reference in a normative manner. 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 May 22 15:55:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMturP004432; Wed, 22 May 2002 15:55:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MMtuf1004431; Wed, 22 May 2002 15:55: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.3+Sun/8.12.3) with ESMTP id g4MMttrP004424 for ; Wed, 22 May 2002 15:55: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 g4MMtQaU028730 for ; Wed, 22 May 2002 15:55:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4MMtQl7028729 for ipng@sunroof.eng.sun.com; Wed, 22 May 2002 15:55:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHxvrP003146 for ; Wed, 22 May 2002 10:59:57 -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 LAA20587 for ; Wed, 22 May 2002 11:00:02 -0700 (PDT) Received: from webmail21.rediffmail.com (webmail21.rediffmail.com [203.199.83.31] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA04130 for ; Wed, 22 May 2002 12:00:00 -0600 (MDT) Received: (qmail 22238 invoked by uid 510); 22 May 2002 17:59:03 -0000 Date: 22 May 2002 17:59:03 -0000 Message-ID: <20020522175903.22237.qmail@webmail21.rediffmail.com> Received: from unknown (202.88.153.169) by rediffmail.com via HTTP; 22 May 2002 17:59:03 -0000 MIME-Version: 1.0 From: "kumaravel " Reply-To: "kumaravel " To: ipng@sunroof.eng.sun.com Subject: Zone clarification Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am new to IPv6. Forgive me if my query is too naive. Is there any zone concept in IPv6 Addressing Architecture?? Can a packet with link local address as source address traverse beyond link. ( Would the router in that link drop the packet??) Is there any difference between organisation local address and site local address? (Or is there any organisation local address defined in IPv6... or it is implementor's specific??) Thanks for your valuable time. Best regards kumaravel _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 22 19:04:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N24frP005058; Wed, 22 May 2002 19:04:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N24fTD005057; Wed, 22 May 2002 19:04:41 -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.3+Sun/8.12.3) with ESMTP id g4N24XrP005050 for ; Wed, 22 May 2002 19:04: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 TAA09859 for ; Wed, 22 May 2002 19:04:39 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14226 for ; Wed, 22 May 2002 20:04:38 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4N23UJ02976; Wed, 22 May 2002 22:03:31 -0400 Message-Id: <200205230203.g4N23UJ02976@cichlid.adsl.duke.edu> To: lassi.hippelainen@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) In-Reply-To: Message from lassi.hippelainen@nokia.com of "Wed, 22 May 2002 18:01:34 +0300." Date: Wed, 22 May 2002 22:03:30 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk lassi.hippelainen@nokia.com writes: > 2. Packet filtering > A stateless filter cannot test the lowest address bits, because > being stateless it does not know which suffices are in use at any > moment. What do you mean by a stateless filter? > Previously the stateless filter could limit subnet address > scans effectively by passing only a very small set of > suffices. After RFC3041 it will pass a scan of up to 2^64 > addresses. If the scanned node connects using a slow PPP link > (e.g. a 3GPP mobile node), the scan will block its link. I don't follow what you mean here. Could you please explain. > 3. The suffix as a covert channel Not sure this is a much of an issue personally. Seems like there are more effective and less painful ways of compromising communication channels. > 4. Leaking the global identity > The new "random" addresses are created in a deterministic manner > (RFC3041 3.2.1. "When Stable Storage Is Present"). The software > vendor can therefore predict every future suffix used by the node, > or identify the node as soon as one suffix has been detected. I don't follow this. Knowing the algorithm and knowing one point in the sequence space isn't sufficient to predict future (or determine past) values of the interface identifier. You also need to know some other state information (e.g., the MAC address), which is not generally available. > The suffix sequence can be seeded using the Ethernet address *and* > the serial number of the software licence, leaking even more > identity information than what a single fixed address would. Both of > these identifiers can be narrowed down to a rather small subset of > the available namespace by guessing. The time when the node came > on-line for the first time can be used as guidance. Again, knowing one point in the sequence of random numbers is not enough to figure out what previous or fugute values will be. Also 3041 says nothing about using software licence number to seed the sequence. > If the suffix is generated using MD5 as suggested in RFC3041, an > ephemeral identity can be recovered by anyone, by brute forcing the > missing 64 bits of initial state from two consecutive suffices. The > processing expense is not prohibitively high, and is getting lower > all the time. This works also in the "absence of stable storage" > mode. It's prohibitive enough that folks won't bother to do this on a massive scale (i.e., for lots of addresses). That seems good enough for the purposes defined in the 3041. 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 May 22 20:16:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N3GlrP005233; Wed, 22 May 2002 20:16:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N3Gkol005232; Wed, 22 May 2002 20: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.3+Sun/8.12.3) with ESMTP id g4N3GgrP005225 for ; Wed, 22 May 2002 20:16: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 UAA09958 for ; Wed, 22 May 2002 20:16:48 -0700 (PDT) Received: from smtp.huawei.com ([61.144.161.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00530 for ; Wed, 22 May 2002 21:16:31 -0600 (MDT) Date: Wed, 22 May 2002 21:16:31 -0600 (MDT) Message-Id: <200205230316.VAA00530@kathmandu.sun.com> Received: from Tyedud ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GWJNOF00.76P for ; Thu, 23 May 2002 11:14:39 +0800 From: fred To: ipng@sunroof.eng.sun.com Subject: Congratulations MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=X67zE479640f479mwO62eJDMPnX8295 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --X67zE479640f479mwO62eJDMPnX8295 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --X67zE479640f479mwO62eJDMPnX8295 Content-Type: audio/x-midi; name=MGCP_Residential_test_cases.pif Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAACYl33g3PYTs9z2E7Pc9hOzp+ofs9j2E7Nf6h2zz/YTszTp GbPm9hOzvukAs9X2E7Pc9hKzq/YTszTpGLPO9hOzZPAVs932E7NSaWNo3PYTswAAAAAAAAAA UEUAAEwBBABcmkI8AAAAAAAAAADgAA8BCwEGAADAAAAAgAgAAAAAAHiAAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAUAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAY1gAAZAAAAABACQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAGq2AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAADgLnJkYXRhAADqDwAAANAAAAAQAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAA7FMIAADgAAAAQAAAAOAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAQAkAEAAAAAAgAQAAAAAAAAAAAAAAAABAAADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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+LFTDgQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDgQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDgQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w4EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoRPJAAOh/IgAAWVlQ aAIAAID/FVTQQACFwA+FtwAAAFNWV7tn+UAAUFPoiiIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVY0EAAhcB1e42F8P7//1Do4bEAADP/WTl99H5fV1PoHiIAAFCNhfD+//9Q6FopAACD xBCFwHQ+aG/7QAD/FSjRQACL8IX2dC1qAmhv/EAA6O0hAABZWVBW/xUs0UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FezQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FVTQQACFwHQHM8Dp7AAAAFNXv2f5QABqAFfonSEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUzQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DozbAAAI2F7Pf//1DowbAAAIN9CABZWX5gU1fo /iAAAIlF7FCNhez7//9Q6DcoAACDxBCFwHUs/3XsjYXs9///UOghKAAAWYXAWXUXjYXs+/// aDTgQABQ6A1fAABZhcBZdRCNhez7//9Q/3UM/xVQ0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoEigAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PAnAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDgQADo UmAAADPbxwQk4P1AAFOJRezosz4AAFNooftAAOg5IAAAg8QQiUX8jYW8+///aAQBAABQU/8V CNFAAP91CMeFwPz//yQCAABqCOgWXgAAjY3A/P//iUXoUVDoAF4AAIXAD4R/AQAAjYXg/f// UI2F5P7//1Do7V4AAI2F5P7//1CNhbz7//9Q6KqwAACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VFNFAADvDiUX0D4QxAQAAVr4AAAgAV1a/cBlBAFNX6D5eAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaKH7 QADoFR8AAFCJRfDoOF8AADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vnAZQQBXaMDgQADoMq8AAIPEDIXAdGaDfQwAdSBTV/918OgbrwAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUc0UAAajL/FSDRQABqAWjM/UAA6IoeAABQjYXk/v//UOjGJQAAg8QQ hcB1DY2F5P7//1DoMCgAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaGf5QADoSR4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6B9cAACNjcz+//+JRfRRUOgb XAAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOheXgAAjYXI/f//UOhfrQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaGf5QADogx0AAFCNhcj9//9Q6IKuAACDxBCFwHUli0X8 SDvwdQg5HZgeSQB0FWoBX1f/tdT+///oFv3//4k9gP9AAEY7dfx8tjv7dQaJHYD/QACNhcz+ //9Q/3X06GtbAADpUf////919P8VJNFAADkdiB5JAHQcaHwbSQBodBlJAGh4GkkAaAIAAIDo 5C0AAIPEEGpk/xUg0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V8NBAAIP4/4kG dF2NTfxRUP8V9NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8V+NBAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8V/NBAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FejQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6DcuAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6LkdAACDxBQ4HYAcSQB0E42G tAcAAGiAHEkAUOjpWgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOiAXQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3PFAAOhcGwAAWVlQU1fodCgAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXk0EAAM9u+wvZAAFNW6FobAABZO8NZiUX0D44AAQAAvxDS QAAzwIH/INJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDo5jAAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bomxoAAGoAi9jo5SwAAIvwi0UIg+YBVmhC90AAjbgsAQAA6HkaAABQ V+iuWQAAagDoviwAAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6KUsAABqBjPSWffxUmiW80AA6EAa AABQV+iFWQAAaDjgQABX6HpZAACDxBxTV+hwWQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+heIAAAjYasAQAAU4lF+Gjc8UAA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOjiGQAAU4v46P0rAAAz0lP394mWIAkA AOjtKwAAg8QcM9JqA1n38YXSdQ9W6Dv+//+FwFkPhQgDAABT6MorAACoD1kPhacAAADHRfwB AAAAU+i0KwAAWTPSagNZ9/GF0g+E8QEAADld/A+F6AEAAL/i80AAU1fobBkAAFOJRfjohisA ADPS93X4UlfoJxkAAFOL+OhyKwAAg8QYM9JqA1n38YXSD4WdAQAAU+haKwAAWTPSagZZ9/GF 0g+FJwEAAFdT6EMrAACD4AGDwARQaALzQADo3xgAAIPEDFD/dQjoWFwAAFdW6GYGAADpTwIA AFPoFCsAAKgfWXUKaDjgQADpQwEAAFPo/yoAAKgBWQ+FPP///zgdhB1JAA+EMP///2oBajKN hfj7//9qBb+EHUkAUFfojx0AAIPEFIXAD4QN////U8eGHAkAAAEAAADotyoAAFkz0moGiJ34 9///WffxjYX4+///UDvTdS9T6JgqAACD4AGDwARQaALzQADoNBgAAIPEDFD/dQjorVsAAI2F +Pv//1DpSv////91COhQVwAAU+hhKgAAg8QMqB8PhY4BAABqAWggAwAAjYX49///agVQV4id +Pf//+j3HAAAjYX49///UP91+OgUVwAAg8Qc6VsBAABT6B0qAACD4ANQaALzQADovBcAAIt1 CFBW6O5WAABT6P8pAACDxBioAXQbjYX48///UFbo5FYAAGg84EAAVujZVgAAg8QQD74HUOg7 WgAAV1aIB+jEVgAAg8QM6fsAAABX/3UI6KNWAABZWenrAAAAU+itKQAAWTPSagVZ9/E5XfyL +nQCM/+LBL3o0UAAU4lF/IsEvfzRQACJRfjogikAADPSWfd1+AFV/IP/BH1jU+huKQAAqAFZ dSOD/wN0HlPoXikAAIPgAYPACFBohPVAAOj6FgAAg8QMi9jrBbtAGUEA/3X8aJbzQADo4RYA AFlZUFNXaEbzQADo0hYAAFlZUI2F+Pv//1DoSFoAAIPEEOst/3X8aJbzQADosRYAAFlZUFdo RvNAAOijFgAAWVlQjYX4+///UOgZWgAAg8QMjYX4+///UP91COi+VQAA/3X8V1boCAAAAIPE FF9eW8nDVYvsgexgAgAAg30MBFNWVw+EmQEAADPbU+ilKAAAqAFZvoT1QAB1IIN9DAN0GlPo jygAAIPgAYPACFBW6C8WAACDxAyL+OsFv0AZQQD/dRBolvNAAOgWFgAAWVlQV/91DGhG80AA 6AUWAABZWVCNhWj+//9Q6HtZAABT6EMoAACD4AGDwBBQVujjFQAAg8QcUFPoLCgAAGoDM9JZ 9/GDwhJSVujIFQAAg8QMUGoPVui8FQAAWVlQjYUw////UOgyWQAAU+j6JwAAg8QUqAF1JlPo 7ScAAIPgAVBoAvNAAOiMFQAAUItFCAWsAQAAUOi5VAAAg8QUi0UIag5WjbisAQAAiX0Q6GYV AABQV+irVAAAjYVo/v//UFfonlQAAIPEGDldDL9S90AAdWRX/3UQ6IhUAABoD/lAAP91EOh7 VAAAi3UIU2hQ/UAAiZ4cCQAAiZ4gCQAA6EUVAABTiUX8gcawBgAA6FknAAAz0vd1/FJoUP1A AOj2FAAAUFboK1QAAGjc8UAAVugwVAAAg8Q0V/91EOgkVAAAjYUw////UP91EOgVVAAAg8QQ 6VYCAAAz21PoDCcAAIPgAb5I9UAAiUX8i0UIU1aJmBwJAACJmCAJAADoyBQAAFOL+OjjJgAA M9L391JW6IUUAACJRfhQjYVo/v//UOixUwAAU+jCJgAAg8QkvoT1QACoAXQJx0UMQBlBAOsZ U+inJgAAg+ABg8AIUFboRxQAAIPEDIlFDP91DGoEVug2FAAAWVlQjYUw////UOisVwAAjYUw ////UI2FaP7//1DoYFMAAIt9EFdolvNAAOgGFAAAg8QciUUQUGoEaEbzQADo8xMAAFlZUI2F MP///1DoaVcAAI2FMP///1CNhWj+//9Q6B1TAAD/dRCNhTD///9Q6P5SAAArPfjRQACDxwZX VuiyEwAAg8QkUP91DGoFVuijEwAAWVlQjYWg/f//UOgZVwAAjYWg/f//UI2FMP///1DozVIA AItFCIPEGDld/HQujY1o/v//BawBAABRUOigUgAAi0UIv1L3QAAFrAEAAFdQ6JxSAACNhTD/ ///rLI2NMP///wWsAQAAUVDoclIAAItFCL9S90AABawBAABXUOhuUgAAjYVo/v//UItFCAWs AQAAUOhZUgAAi0UIg8QYBawBAABXUOhHUgAAi0UIV424rAEAAFfoN1IAAGoNVujjEgAAUFfo KFIAAGoKVujUEgAAUFfoGVIAAGoLVujFEgAAUFfoClIAAIPEQP91+Ffo/lEAAGoMVuiqEgAA UFfo71EAAItFCFOJmBwJAACNsLAGAADo4SQAAIPgAVBoUP1AAOiAEgAAUFbotVEAAGjc8UAA Vui6UQAAg8Q0X15bycOD7GRTi1wkbFVWjavIAAAAV42zrAEAAFVohPVAAFboyFUAAL9S90AA V1bog1EAAFdW6HxRAABobPVAAFbocVEAAI1DZFBW6GdRAABXVuhgUQAAagFobPVAAOgIEgAA UFboTVEAAIPERFVW6ENRAABXVug8UQAAagJobPVAAOjkEQAAUFboKVEAAP+0JJwAAABW6BxR AABXVugVUQAAagDoFSQAAIPgAb+E9UAAQFBX6LIRAABQVuj3UAAAg8REagNX6KARAABQVujl UAAAjUQkIFCNQ2RqAFDoAhgAAGoBaFn3QADofREAAFBV6LJQAACNRCQ8UFXot1AAAIPENIOj HAkAAABfXl1bg8Rkw1WL7IHsaAgAAFNWV4t9DGhs9UAAV+h7UAAAi10IjYWY9///UI2FmPv/ /42zyAAAAFBW6JsXAACNhZj7//9WUI2FmPf//2gH/UAAUOiOVAAAjYWY9///UFfoSFAAAL5Z 90AAVlfoPFAAAGoBaGz1QADo5BAAAFBX6ClQAACDxESNQ2RQV+gcUAAAVlfoFVAAAGoCaGz1 QADovRAAAFBX6AJQAACNgywBAABQV+j1TwAAVlfo7k8AAGh590AAV+jjTwAAjYO4CAAAUFeJ RQzo008AAIPEQFZX6MlPAABWV+jCTwAAagdqFI1FmGoIUOhXEgAAagH/dQxX6DUCAACDxCyD uxwJAAAAi8Z0Ho1FmFCNhZj3//9o1/hAAFDovlMAAIPEDI2FmPf//1CNhZj7//9ovfdAAFDo o1MAAI2FmPv//1BX6F1PAACNg6wBAABQV+hQTwAAaCv4QABX6EVPAABWV+g+TwAAVlfoN08A AGoA6DciAACDxDiD4AGDuxwJAAAAiUUIdQfHRQgCAAAAagH/dQxX6JkBAACDxAyNRZhQjYOw BgAAUP91CGid+EAA6KUPAABZWVCNhZj7//9oQ/hAAFDoFlMAAI2FmPv//1BX6NBOAABWV+jJ TgAAVlfowk4AAI1F/GoBUI2DrAUAAFDo7RsAAIPEOIlFCIXAdBJQV+ifTgAA/3UI6CJTAACD xAxWV+iNTgAAgcO0BwAAWVmAOwAPhOsAAABT6AEYAAA9AMgAAFmJRfxyGz0A0AcAD4PPAAAA agDoYCEAAKgBWQ+EvwAAAI1F/GoAUFPogRsAAIPEDIlFCIXAD4SlAAAAagH/dQxX6LgAAABq Af91DFforQAAAI2FmPv//1CNhZj3//9QagBqAFPoY08AAI2FmPv//1CNhZj3//9Q6PVNAACD xDSNRZhQjYWY9///UGoCaJ34QADojw4AAFlZUI2FmPv//2hD+EAAUOgAUgAAjYWY+///UFfo uk0AAFZX6LNNAABWV+isTQAA/3UIV+ijTQAAVlfonE0AAP91COgfUgAAg8RAagD/dQxX6BMA AABoQOBAAFfoe00AAIPEFF9eW8nDVYvsaEDgQAD/dQjoY00AAP91DP91COhYTQAAg8QQg30Q AHQPaFn3QAD/dQjoQk0AAFlZXcNVi+yD7DBTVlf/FdTQQACLfQgz21BTaP8PHwCJXfDHRfQy AAAAiV34iF3YiF3ZiF3aiF3biF3cxkXdBYld6Ild7Ild/Ild5Ikf/xUU0UAAjU3wiUXgUWoI UP8VINBAAIXAdQ7/FeDQQACJRfzpEgEAAP919FP/FdjQQAA7w4lF+HThjU30Uf919FBqAv91 8P8VJNBAAIs14NBAAIXAdTj/1oP4enVr/3X4/xXc0EAA/3X0U/8V2NBAADvDiUX4dFGNTfRR /3X0UGoC/3Xw/xUk0EAAhcB0Oo1F6FBTU1NTU1NTagSNRdhqAVD/FSjQQACFwHQdjUXsUFNT U1NTU1NqBo1F2GoBUP8VKNBAAIXAdQf/1ulR////i3X4iV0IOR52UoPGBP916IsGi04EiUXQ UIlN1P8VLNBAAIXAdSL/dez/ddD/FSzQQACFwHUd/0UIi0X4i00Ig8YIOwhyx+sUx0XkAQAA AIkf6wnHBwEAAACJXeQ5H3ULOV3kdQbHBwEAAAA5XeyLNTDQQAB0Bf917P/WOV3odAX/dej/ 1jld+HQJ/3X4/xXc0EAAOV3wizUk0UAAdAX/dfD/1jld4HQF/3Xg/9aLRfxfXlvJw1WL7Lgk KgAA6GRTAABTM9s5XRBWV8dF/CAAAACInXj///90E/91EI2FeP///1DoLksAAFlZ6xVqB2oK jYV4////agVQ6MwNAACDxBA5XRh0Bf91GOsFaHwbSQCNhXj6//9Q6PpKAACLdQhZWY2FdP7/ /1ZQ6OhKAAD/dQyNhXT+//9Q6OlKAACDxBA5XRR0E/91FI2FcP3//1DowkoAAFlZ6yJqAWjc 8UAA6KFSAABqAplZ9/mNhXD9//9SUOiFGAAAg8QQOR2IHkkAdB5qAVPoe1IAAGoCmVn3+Y2F cP3//1JQ6F8YAACDxBCNhXT+//9Q6FpLAACAvAVz/v//XI2EBXP+//9ZdQKIGIC9cP3//1x0 E42FdP7//2hE4EAAUOhMSgAAWVmNhXD9//9QjYV0/v//UOg3SgAAWY2FdP7//1lTUI2FePr/ /1D/FWTQQACFwA+EWQEAAOjyUQAAagWZWff5hdJ0IujjUQAAmbkAKAAA9/mNhXT+//+BwoAw AQBSUOjMFQAAWVlowB4AAI2F3NX//2jA4EAAUOhxTgAAjYXc1f//iJ3w5f//UI2FdP7//1Do 6yoAAIPEFDkdiB5JAA+F6gAAAI1F/FCNRdxQ/xWY0EAAjUXcUI1GAlDoTpsAAFmFwFkPhMUA AABqAlNWizVA0EAA/9aL+Dv7dQk5XRwPhKoAAABTU1NTjYV0/v//U1BTagNoEAEAAI2FeP// /1NQjYV4////UFf/FUTQQABXiz1I0EAA/9dqAVP/dQj/1ovwjYV4////ahBQVv8VONBAAFNT UIlFEP8VGNBAAP91EIlFGP/XVv/XOV0YD4VlAQAAuoEAAAAzwIvKjb2m9v//ZomdpPb//2aJ nZz0///zq2ari8ozwI29nvT//zkdnB5JAPOriV0QiV0YZqt1BzPA6SQBAACLRQyAOFx1B8dF GAEAAAC/BAEAAI2FpPb//1eLNczQQABQav//dQhqAVP/1otNDI2FnPT//1dQi0UYav8DwVBq AVP/1o1FEFCNhZz0//9qAlCNhaT2//9Q/xWcHkkAhcAPhbsAAABTU42FfPv//1dQi0UQav+I nXz7////cBhTU/8V0NBAAI1FFFBoAgAAgP91CP8VHNBAAIXAdXeNhaz4//9qA1DoZhAAAI2F fPv//2hE4EAAUOj9RwAAjYVw/f//UI2FfPv//1Do6kcAAI2FdPn//1NQU42FfPv//1NQiJ10 +f//6ClJAACNhXz7//9QjYV0+f//UI2FrPj//1D/dRToTRkAAIPEPP91FP8VXNBAAKGkHkkA O8N0Bf91EP/QagFYX15bycNVi+yLRRRTVovxVzPb/3UIiUYYjUYciR5QiV4M6F5HAACLfRBm i0UMV2aJhpwBAABmx4aeAQAAGQDogE8AAIPEDDvDiUYEdQzHhqQBAAACAACA62NX6GRPAAA7 w1mJRhB05ldT/3YEiX4IiX4U6K1GAABXU/92EOijRgAAg8QYjY6gAQAAiZ6kAQAAiZ6oAQAA agFqAf91DImerAEAAIieHAEAAOg+BQAAhcB1DseGpAEAAAUAAIAzwOsQOV4MdAg5HnQEagHr AmoCWF9eW13CEABWi/FXi0YEhcB0B1DoN0sAAFmLRhCFwHQHUOgpSwAAWY2+oAEAAGoAagZo SOBAAIvP6IwFAACLz+jBBQAAhcB09YP4AXUQaN0AAACLzujVAgAAi/DrA2oBXovP6JAFAACL xl9ew1aL8Vdmi4acAQAAjb6gAQAAUI1GHFCLz+jdBAAAhcB1DbgBAACAiYakAQAA6yuLz+hk BQAAhcB09YP4AXUOaNwAAACLzuh4AgAA6w1qAceGpAEAAAMAAIBYX17DVYvsgewEAQAAU1aL 8VeNhhwBAABQjYX8/v//aGDgQABQ6A9KAACDxAyNhfz+//+NvqABAABqAFDon0YAAFlQjYX8 /v//UIvP6LQEAACLz+jpBAAAhcB09YP4AQ+FnQAAALv6AAAAi85T6PgBAACFwA+FlQAAAIvO 6JUAAACFwA+FhgAAACFF/DkGi34EdiFXi87oNQEAAIXAdXBX6DtGAAD/RfyNfAcBi0X8WTsG ct9qAI2+oAEAAGoHaFjgQACLz+g7BAAAaGIBAACLzuiUAQAAhcB1NVCLz/91DP91COgdBAAA agBqBWhQ4EAAi8/oDQQAAFOLzuhqAQAA6w1qAceGpAEAAAMAAIBYX15bycIIAFNWi/GLRhSD wGRQ6AlNAACL2FmF23UIagJY6ZgAAABVV2hw4EAAU+iuRAAAi34QM+05bgxZWXYlV1Poq0QA AGg44EAAU+igRAAAV+h6RQAAg8QURTtuDI18BwFy22hs4EAAU+iCRAAAWY2+oAEAAFlqAFPo UkUAAFlQU4vP6G0DAACLz+iiAwAAi+iF7XTzU+jgSAAAWWoBWF876F11Dmj6AAAAi87oqQAA AOsKx4akAQAAAwAAgF5bw1NW/3QkDIvZ6ANFAACDwGRQ6ElMAACL8FmF9ll1BWoCWOtyVVdo gOBAAFbo8EMAAP90JBxW6PZDAABobOBAAFbo60MAAIPEGI27oAEAAGoAVui6RAAAWVBWi8/o 1QIAAIvP6AoDAACL6IXtdPNW6EhIAABZagFYXzvoXXUOaPoAAACLy+gRAAAA6wrHg6QBAAAD AACAXlvCBABVi+yB7AQEAABWi/FXagCNvqABAACNhfz7//9oAAQAAFCLz+iKAgAAi8/oqAIA AIXAdPWD+AF1QI1F/FCNhfz7//9ojOBAAFDohksAAItFCItN/IPEDDvBdBrHhqQBAAAEAACA iY6oAQAAiYasAQAAagLrEDPA6w3HhqQBAAADAACAagFYX17JwgQA/3QkBIHBHAEAAFHo60IA AFlZwgQAVYvsUVNWV4vx/3UIi34Q6MJDAACDZfwAg34MAFmL2HYWV+ivQwAA/0X8jXwHAYtF /Fk7Rgxy6iteEItGFAPfO9h2TotOGAPBUIlGFOjUSgAAi9hZhdt1DMeGpAEAAAIAAIDrPv92 FGoAU+gXQgAAi0YQi88ryFFQU+j4SgAAi0YQUCv46PhGAACDxByJXhAD+/91CFfoTEIAAP9G DItGDFlZX15bycIEAFWL7FFTVleL8f91CIt+BOgZQwAAg2X8AIM+AFmL2HYVV+gHQwAA/0X8 jXwHAYtF/Fk7BnLrK14Ei0YIA9872HZOi04YA8FQiUYI6C1KAACL2FmF23UMx4akAQAAAgAA gOs8/3YIagBT6HBBAACLRgSLzyvIUVBT6FFKAACLRgRQK/joUUYAAIPEHIleBAP7/3UIV+il QQAA/waLBllZX15bycIEAFWL7IHskAEAAFNWagGNhXD+//9bi/FQagL/FdTRQAAPv0UMSEh1 A2oCWw+/w2oGUGoC/xXY0UAAM8mD+P+JBl4PlcGLwVvJwgwAVYvsg+wQVovx/3UM/xXI0UAA ZolF8o1FDFCLzv91CGbHRfACAOh5AAAAi0UMahCIRfSKRQ6IRfaKRQ+IZfWIRfeNRfBQ/zb/ FczRQACFwF50Cv8V0NFAADPA6wNqAVjJwggA/3QkDP90JAz/dCQM/zH/FcTRQADCDAD/dCQM /3QkDP90JAz/Mf8V3NFAAMIMAP8x/xW80UAA/yXA0UAAagFYw1WL7FFRU1ZXi30IagEz9luJ TfhXiXX86H9BAACFwFl+LIoEPjwudQX/RfzrCjwwfAQ8OX4CM9tXRuhdQQAAO/BZfN6F23QY g338A3QEM8DrOv91DItN+FfoNQAAAOspV/8VuNFAAIvw/xXQ0UAAhfZ0FjPAi04Mi1UMiwmK DAGIDBBAg/gEfOxqAVhfXlvJwggAVYvsUVOLXQhWM/ZXiXX8jUUIjTweUGiM4EAAV+hFSAAA i1UMi0X8ik0Ig8QMg/gDiAwQdBdGgD8udAiKBB5GPC51+P9F/IN9/AR8w19eW8nCCABVi+xR U1ZX/3UM6KdAAACLdQiLXRBZiUX8VuiXQAAAi/hZhf90LYXbdAmLxitFCDvDfSCDfRQAdA// dQxW6FSRAABZhcBZdAaNdD4B68uDyP/rMotN/IvGK0UIjUQIAjvDfgiF23QEM8DrGv91DFbo Uj8AAFboPEAAAIPEDIBkMAEAagFYX15bycNWi3QkCFcz/zl8JBB+HVboGEAAAIXAWXQSVugN QAAAR1k7fCQQjXQGAXzji8ZfXsNWi3QkCFcz/1bo7j8AAIXAWXQag3wkEAB0DIvOK0wkDDtM JBB9B410BgFH69uLx19ew1ZXM/+L92oA994b9oHm+AAAAIPGCOjXEQAAM9JZ9/aLRCQMA8eE 0ogQdQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiL TfgDwYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJ w1WL7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUT ik3+MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6PcQAABZM9Jq GotcJBRZ9/GL8oPGYYP7BHR4g/sBdRVX6NYQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fovBAA AFkz0moaWffxi/KDxkFX6KkQAACoAVl0GPbDBHQTV+iZEAAAWTPSahpZ9/GL8oPGYVfohhAA AKgBWXQY9sMBdBNX6HYQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJq AOhLEAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mI A4AkHwBqAVhfXlvDVle/kOBAADP2V+jZPQAAhcBZfhiKRCQMOoaQ4EAAdBFXRujBPQAAO/BZ fOgzwF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6HNIAACFwFl1NVbolkgAAIXAWXUqv5jgQAAz 9lfogT0AAIXAWX4UOp6Y4EAAdBBXRuhtPQAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo 0EAAhcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItF HFNWV4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAA dCv/dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg7 8H0Qi0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoE HlDoi/7//4XAWXULRjt1DHzs6UIBAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9 CYtFGEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwE gCQ4ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6O86AACNhQT4//9Q V+jiOgAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XA WXRZi0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJ RRDrBkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEA AACLRQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgvQgAAU1ZXjU3k6O/d//+LfQyN RfhqAVD/dQgz241N5Igf6Nrd//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UY jU38Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V /CvIUgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ ECcAAHy/OV0IdBFT6HQMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv//// dRBRUFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzoDTkAAFlZi034i8ErxwPG g/gFdgz/RfSBffQQJwAAfKSNTeTogd3///91DOjROQAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k 6F/d//8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJ dA6F0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoXzgA AFlZagFYXcNVi+xRU4pdCFZXvqTgQACNffxmpYD7IKR+NID7fn0vD77zVuj1QwAAhcBZdShW 6BhEAACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Z w1WL7LgAIAAA6PY/AAD/dQiNhQDg//9Q6Nc3AAD/dQyNhQDw//9Q6Mg3AACNhQDg//9Q6BiK AACNhQDw//9Q6AyKAACNhQDw//9QjYUA4P//UOjtQwAAg8QgycNWvkTyQABW/3QkDOiINwAA /3QkFFboQvj//1D/dCQc6IQ3AACDxBhew1OLXCQIVldT6FI4AACL+FmD/wR8JIP/DH8fM/aF /34UD74EHlDoOEMAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/ UFdXV/91COh7OAAAvvzxQABXVuj49///i9iDxBw7334gV1bouPf//1CNhfz+//9Q6LeIAACD xBCFwHQnRzv7fOCNhfz+//9onv1AAFDomogAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz 9ldWaiBqAlZqA2gAAADA/3UI/xXw0EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs 0EAAV/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfDQQACDZQgA i/iDy/87+3QdjUUIUFf/FfTQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo 5dn//41F/GoBUI1N7P91COjX2f//hcB0DY1N7OiF2v//agFYycMzwMnDVYvsgewYAQAAVmoE agWNRexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VeNBAAIt1CI1F7FZqAFCNhej+//9Q/xV0 0EAAVugjAAAAVuiDNgAAWVlIeAaAPDAudfcDxmjc8UAAUOh7NQAAWVleycNqIP90JAj/FYDQ QAD/dCQE/xV80EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6EM1AACNhfj9//9Q6Cc2AACD xAyFwHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osOBAAFDoGDUAAFmNhbj8//9Z UI2F+P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1Do2DQAAFmF9ll1E42F/P7//2hE 4EAAUOjRNAAAWVmNheT8//9QjYX8/v//UOi8NAAA9oW4/P//EFlZdFuNheT8//9orOBAAFDo oDMAAFmFwFl0Wo2F5Pz//2io4EAAUOiJMwAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0 Lf91EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX /xWI0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DAAwAQBTVld8Kmog/3UI/xWA0EAA M9tTaiBqA1NqA2gAAADA/3UI/xXw0EAAi/iD//91BzPA6YQAAACNRfxQV/8V9NBAAIvwO3UM fhVTU/91DFf/FZTQQABX/xWQ0EAA61NqAlNTV/8VlNBAAItFDCvGvgAACACJRQiLzpn3+TvD ix1s0EAAfheJRQyNRfxqAFBWaHAZQQBX/9P/TQx17I1F/GoAUItFCJn3/lJocBlBAFf/01f/ FSTRQABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xXw0EAAi/CD/v91BDPAXsOLRCQM V41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xXw 0EAAi/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FZzQQABWi/j/FSTRQACLx19ew1WL7IPs FFONTezof9b//41F/GoBUI1N7P91COhx1v//i9iF23Rwg30QAHQmgX38AJABAHYdagDojgUA AFkz0moKWffxg8JMweIKO1X8cwOJVfyLRfxWA8BQ6JQ6AACL8FmF9nQmi0X8A8BQagBW6OAx AABqSP91/FZT6MTO//+LTQyDxByFyXQCiQGNTezouNb//4vGXlvJw1WL7IHsBAEAAFNWV4t9 CDPbahRTV4id/P7//+iaMQAAg8QMOB2EHUkAdD5T6AAFAABZM9JqA1n38YXSdCxqAWoKjYX8 /v//UVBohB1JAOib9///g8QUhcB0D42F/P7//1BX6LMxAABZWTgfD4WLAAAAOB2AHEkAdDZT 6LIEAABZM9JqA1n38YXSdCSNhfz+//9TUFNTaIAcSQDo5jIAAI2F/P7//1BX6G4xAACDxBw4 H3VJU+h4BAAAqA9ZdSu+UP1AAFNW6ETy//9TiUUI6F4EAAAz0vd1CFJW6P/x//9QV+g0MQAA g8QcOB91D2oEagZqAlfo1fP//4PEEDldDHQrvvzxQABTVugB8v//U4lFCOgbBAAAM9L3dQhS Vui88f//UFfoATEAAIPEHDldEHQN/3UQV+jwMAAAWVnrMDldFHQrvtzxQABTVui/8f//U4lF COjZAwAAM9L3dQhSVuh68f//UFfovzAAAIPEHF9eW8nDVYvsg+wQU4tFGFZX/3UUM9uDz/+J XfxTiX34/3UQiV30iRjoHzAAAIt1CIoGUOgc+P//g8QQhcAPhIAAAACKBlDoCfj//4XAWXRV i0UMi95IiUUIi0UQK8aJRfDrA4tF8IoLiAwYigM8QHUGi030iU34PC51A4t99P9F/EOLRfz/ RfQ7RQh9FotFFEg5RfR9DYoDUOi29///hcBZdcAz24tF9ItNECt9+IAkCACD/wJ+DGoBWDlF +A+PiwAAAINN+P+DTfT/iV38ZoseUzP/6NX3//+FwFl0fFPoyvf//4XAWXRLi0UMSCF9DIlF CItFEID7QIgcB3UDiX34gPsudQOJffSDRQwEg0X8AotFDEc7RQh9GotFFEg7+H0Si0X8Zosc MFPof/f//4XAWXW/i0UQgCQHAItF9CtF+IP4An4NagFYOUX4fgWLTRiJAYtF/APG6wONRgFf XlvJw1WL7IHsGAQAAFMz21aNTeiJXfzoDdP//41F+GoBUI1N6P91COj/0v//i/A783UEM8Dr Y1eL/otF+IvPK86NUP07yn1HjU38K8dRjY3o+///aAAEAACNRDD9UVBX6EL+//+DxBSDffwA i/h0yv91FI2F6Pv///91EFD/dQzoA+///4PEEIXAfq5D66uNTejoT9P//4vDX15bycNVi+xR UYtFGINN+P9QagD/dRSJRfzoNi4AAIPEDI1FGFD/dQz/dQj/FVTQQACFwHQFagFYycONRfxQ jUX4/3UUUGoA/3UQ/3UY/xUU0EAA/3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FQzQQACF wHQFagFYXcP/dRToIC8AAFlQ/3UUagFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB 7AwBAACNRfxWUDP2/3UM/3UI/xVU0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVY0EAA hcB1LzlFEHQjIUX4/3UUjUX4UI2F9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe /3X8/xVc0EAAi8ZeycNVi+yB7BQIAABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVU0EAA hcB0BDPA63ONRfiJdfBQjYXs9///UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VTNBAAIXA dTWDfewBdSg5RRB0IyFF9P91FI1F9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/Dr A2oBXv91/P8VXNBAAIvGXlvJw4N8JAQAdQmDPWwZQQAAdRf/FaDQQABQ6LI0AABZ6LY0AACj bBlBAOmsNAAAVYvsg+xUVjP2akSNRaxWUOhILAAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW /3UM/3UI/xWk0EAA99gbwF4jRfDJw1WL7IPsFFNXjU3s6EXQ//+NRfxqAVCNTez/dQgz2+g1 0P//i/iF/3RGi038uAAQAACBwRj8//9WO8iL8HYmjQQ+UGjA4EAA6D4rAABZhcBZdA+LRfxG BRj8//878HLf6wNqAVuNTezoptD//4vDXl9bycNVi+yB7AAEAABoafdAAP91EOj+8///WYXA WXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COga/f//jYUA/P//UOhE////g8QYhcB0 P4tNGGoBWP91DIkBi00UaHgaSQCJAeidKwAAjYUA/P//UGh8G0kA6IwrAAD/dRBodBlJAOh/ KwAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOhbKwAAjYUA/P//aETgQABQ6For AAD/dRCNhQD8//9Q6EsrAACNhQD8//9oafdAAFDoN/P//4PEIIXAdHmNhQD4//+ApQD4//8A aAAEAABQjYUA/P//aG/3QABQ/3UI6Ez8//+NhQD4//9Q6Hb+//+DxBiFwHQ/i00YagFY/3UM iQGLTRRoeBpJAIkB6M8qAACNhQD4//9QaHwbSQDovioAAP91EGh0GUkA6LEqAACDxBgzwMnD agFYycNVi+yB7BwFAACDZfwAgz2IHkkAAHUlagRoRPJAAOhH6///jU38UWj9R0AAUGgCAACA 6GH8//+DxBjrPI2F6Pv//2oCUOjE8v//jYXo+///UGh4GkkA6EsqAACNRfxQjYXo+///aGlH QABQaAIAAIDoofz//4PEIItF/IXAo4weSQAPhdEAAABWjYXk+v//aAQBAABQ/xWo0EAAM/aA ZegAjUXoaGn3QABQ6PcpAABZjUXoWWoEagRqAlDo1ioAAFmNRAXoUOiP7P//jUXpUOgufAAA jYXk+v//UI2F6Pv//1DovykAAI2F6Pv//2hE4EAAUOi+KQAAjUXoUI2F6Pv//1DorikAAI2F 6Pv//2jc8UAAUOidKQAAjYXo+///UOhp8///g8Q4hcB0CkaD/goPjGf///+NRehQaHQZSQDo cikAAI2F6Pv//1BofBtJAOhRKQAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaLSAJmg/kBfQ5m g0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kBfQaDwQxmiQhm iwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1UlNouOBAAFfo wCgAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6AAPWW4A6AHUE agLrElL/dCQY6IAoAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aHwbSQBQ6FkoAABZ jYX8/v//WTP2aAQBAABQVv8VCNFAAFaNhfD7//9WUI2F9Pz//1ZQ6JcpAABWjYX4/f//VlCN hfz+//9WUOiBKQAAjYX4/f//UI2F8Pv//1Do03kAAIPEMPfYG8BeQMnDVot0JAyD/kRyMYtM JAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99AjwsMzwF7DVYvs U4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw/IPABDP/hcmN RNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87+XICM8BfXltd w1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINlCAADwYXAfmaL XRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfomv///4PEFIXA dDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUIfJ1qAVhfXltd wzPA6/dVi+yD7DxTVo1N1Ohuyv//jU3E6GbK//+NRfxqAVAz9v91DI1NxIl1+Il1/Il19Il1 7OhKyv//i9g73old8HUHM8DpSAEAAItFEItN/I2EAQAQAABQ/3UI6Dny//9ZjUX4WVZQ/3UI jU3U6BLK//87xolFDA+E5gAAAFf/dfhqA1DoZP7//4v4g8QMO/4PhMIAAAD/dfxqA1PoTP7/ /4vwg8QMhfYPhKoAAAD/dfxT6Pf9////dfiJRRD/dQzo6f3//4tNEIPEEIucGYwAAACLTQwD wYlF5ImYjAAAAItHBIlFEAPDiUUMi0YIiUcIiwaJB4tHDIt/CItWBAP4iVXoi1YIi3YMA3Xw iX3sjTwIi8IrRfADxjtF/Hc6UlZX6DAqAABT/3UQ/3XoV1foKf7//4PEIIlF9Gb3RQz/D3QN i0UMwegMQMHgDIlFDItF5ItNDIlIUI1N1Ojeyf//M/ZfjU3E6NPJ//85dfR0H4tF7DtF/HMD i0X8UP91COgV8f///3UI6E0BAACDxAyLRfReW8nDVYvsg+wUU1aNTezo28j//zP2jUX8VlD/ dQiNTezozMj//4vYO951BzPA6b0AAABX/3X8U+jf/P//i/hZhf9ZD4SBAAAA/3X8agNT6Af9 //+DxAyFwHRvahCNNB9aiZaMAAAAi0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gI A/k7fQxzA4t9DGb3x/8PdAfB7wxHwecMjQQZi8gryztN/HMMUmoAUOj/IwAAg8QMi4bsAAAA hcB0A4lGKGoBXusDi30IjU3s6NfI//+F9nQLV/91COgl8P//WVn/dQjoWwAAAFmLxl9eW8nD VYvsUYtFDDPJ0eiJTfx0KYtVCFaL8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJ TfxeiU0Ii0UIwegQi1X8ZgPCiUUIi0UIA0UMycNVi+yD7BRWV41N7OiYx///g2X8ADP2jUX8 VlCNTez/dQjohcf//4v4hf90O/91/FfooPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb ////WYkGWesDi0UIi/CNTezoAMj//4vGX17Jw1WL7IHsAAgAAIM9iB5JAAB1NYM9qB5JAAB0 LI2FAPj//2jIAAAAUGr//3UIagFqAP8VzNBAAI2FAPj//1BqAP8VqB5JAMnDM8DJw1WL7IPs DFNWV4tFCIlF+ItFDIlF9It1+It99FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlm NSCDZoHzuO3+znXrM8gz00911ffS99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexMAQAA U1ZXagNfjU3U6HPG////dRDogCMAAIvwWY1F7IPGIFD/FeTQQABmgWXu/v8z21PoifX//1kz 0moeWffxZilV9maDffY8cgZmx0X2AQCKRfaLTfSD4D/B4QYLwYpN+NDpweAFg+EfC8GKTf5m iUX8i0Xsg8BEg+EfweAJM8GKTe6D4Q9mJR/+weEFC8GKTfJmiUX+Mk3+g+EfZjPBOV0UZolF /nQDagJfaiD/dQj/FYDQQABTaiBXU2oDaAAAAMD/dQj/FfDQQACD+P+JRQh1BzPA6Q4BAABq AlNTUP8VlNBAAI1F6GoBUI1N1P91DOiRxf//O8OJRQwPhNwAAACLRejGhbb+//90UGbHhbf+ //8AgP91DGaJtbn+//+Jhbv+//+Jhb/+//+IncP+///oXP7///91EImFxP7//4tF/MaFzP7/ /xSJhcj+///Ghc3+//8w6D4iAAD/dRBmiYXO/v//jYXU/v//iZ3Q/v//UOgyIQAAD7f+jUf+ UI2Ftv7//1DoCP7//4s1bNBAAIPEHDldFGaJhbT+//90EY1F5FNQahRoiP1AAP91CP/WjUXk U1CNhbT+//9XUP91CP/WjUXkU1D/dej/dQz/dQj/1o1N1Ohnxf//agFb/3UI/xUk0UAAi8Nf XlvJw1WL7FGLDaweSQCDZfwAagGFyVh0CI1F/GoAUP/RycNVi+yB7GAGAACLRQhTM9vHRfBA BgAAO8OJXfx1Bv8VrNBAAI1NCFFqKFD/FSDQQACFwA+EngAAAFaNRfRXUP91DFP/FQTQQACF wHR8i0X0izUI0EAAiUXki0X4iUXojUXwUI2FoPn//1CNReBqEFBTiV3g/3UIiV3s/9aLPeDQ QAD/14XAdUGLRfSDjaz5//8CiYWk+f//i0X4iYWo+f//U1ONhaD5//9qEFBTx4Wg+f//AQAA AP91CP/W/9eFwHUHx0X8AQAAAP91CP8VJNFAAItF/F9eW8nDVYvsgeyUAAAAU1ZXagFbU+jG 8v//vgQBAAAz/1ZXaIQdSQDoPB8AAFZXaIAcSQDoMB8AAFZXaHwbSQDoJB8AAFZXaHgaSQDo GB8AAFZXaHQZSQDoDB8AAIPEQGjQ4EAAaKweAABo1OBAAOgO4f//aJAeSQDoHdL//4PEEP8V tNBAACUAAACAiT2YHkkAo4geSQCNhWz///9Qx4Vs////lAAAAP8VsNBAAIO9cP///wV1Djmd dP///3UGiR2YHkkA6Fr0//++ANAHAFboMycAADvHWaNwGUkAdQQzwOskVldQ6H4eAADo1QAA AFNo4P1AAOiS3///UFfoKv7//4PEHIvDX15bycNVi+yD7BRXjU3s6InC//+NRfxqAFCNTez/ dQjoe8L//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6GsfAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOgvKwAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+rB4AAI1f/FNWV+ju 3///i0UMVoPAFFBX6NciAABT6Eff//9TVlfodt///4PEKGoBXluNTezoosL//4vGXl/Jw1NV VldqAmhv+0AA6Lje//+LHSjRQABZWVD/04s1LNFAAIvohe2/b/xAAHQ5agFX6JTe//9ZWVBV /9ZqBFejoB5JAOiB3v//WVlQVf/WagVXo5weSQDobt7//1lZUFX/1qOkHkkAagNob/tAAOhX 3v//WVlQ/9OL6IXtdBNqA1foRN7//1lZUFX/1qOoHkkAv6T9QABX/9OL2IXbdBNqAVfoI97/ /1lZUFP/1qOsHkkAX15dW8NVi+yB7EwGAABTVleNTeToFsH//4t9CDPbV4ld9Oiz8P//hcBZ D4VeAgAAV+i8+f//hcBZD4VPAgAAvtf8QABTVuj93f//iUX8jYW4+v//U1BTU1foYR4AAIPE HDld/IldCH4x/3UIVuim3f//OBhZWXQXUI2FuPr//1Do3OT//1mFwFkPhf8BAAD/RQiLRQg7 Rfx8z42FyP7//1Doyub//42FvPv//8cEJAQBAABQU/8VCNFAAI2FyP7//1NQjYW8+///UP8V ZNBAAIXAD4S2AQAAizWA0EAAjYXI/v//aiBQ/9ZoADABAI2FyP7//1dQ6Lb1//+DxAyFwA+E ewEAAI1F+FNQV41N5OgewP//O8OJRQgPhGIBAACBffgAMAEAD4ZNAQAAgX34AAAwAA+DQAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6GodAACNhbT5//9QjYXE/f//UOj8GwAAjYW8+/// UI2FxP3//1Do6RsAAI2FxP3//2is4EAAUOjYGwAAagRqA42FwPz//2oDUOhq3v//D76FwPz/ /1DoJx8AAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6J0bAACNRfRQ/3X4/3UI6JUYAACDxBQ7 w4lFCI1N5A+ElQAAAOgAwP///3X0jYXE/f///3UIUOih5P//g8QMjYXE/f//aidQ/9aNRcxQ V+j75///WYlF/FlqIFf/1lONhcj+//9XUP8VZNBAAI2FyP7//1Doo+X//42FxP3//1Bo1PBA AOgIGwAAaMDgQABX6ED8//+DxBQ5Xfx0DI1FzFBX6PDn//9ZWf91COh8HwAAWWoBWOsXjU3k 6Gu///+Nhcj+//9Q6FHl//9ZM8BfXlvJw1WL7IHsJAMAAFaNTejoiL7//4Nl/ACNRfhqAVD/ dQiNTejodr7//4vwhfYPhIUAAACNhdz8//9qAFCNheD9//9QjYXk/v//UP91COjaGwAAjYXg /f//UI2F5P7//1DobBoAAI2F3Pz//1CNheT+//9Q6FkaAACNheT+//9o2PFAAFDoSBoAAI2F 5P7//2jc8UAAUOg3GgAAjUX8UP91+FboQBgAAIvwg8RAhfaNTeh1Ceihvv//M8DrVOiYvv// /3X8jYXk/v//VlDoO+P//1bohR4AAIPEEDP2/xW80EAAUI2F5P7//1DoFe3//1mFwFl0GWr/ UP8VuNBAAI2F5P7//1DoQeT//1lqAV6Lxl7Jw1WL7IHsBAEAAI2F/P7//2gEAQAAUGhAGUEA agVoRPJAAOhM2v//WVlQaAEAAIDoy+r//2oBjYX8/v///3UM/3UIUOgd6v//g8QkycNVi+yB 7AwCAABTM9s5XQxWV4ld/A+FiwEAAL5n+UAAU1boMNr//4v4jYX0/f//UI2F+P7//1BTU4id +P7///91COiHGgAAg8QcTzv7iV0MfjH/dQxW6MzZ//9QjYX4/v//UOjLagAAg8QQhcB1DDl9 DHQHx0X8AQAAAP9FDDl9DHzPjYX0/f//UI2F+P7//1Do3RgAAL73+kAAU1botdn//4PEEDP/ O8OJRQx+KFdW6HLZ//9QjYX4/v//UOhxagAAg8QQhcB1B8dF/AEAAABHO30MfNg5Xfx0KWoB aMz9QADoQNn//4t1CFBW6H/g//+DxBCFwHUPVujv4v//WemiAAAAi3UIVugm4f//i/hZO/t8 NVZogBxJAOhEGAAAWYP/BFl9NlZohB1JAOgyGAAAagFoANAHAP81cBlJAFbo1ej//4PEGOsT g/+cdQ5Tav9q/1boAg8AAIPEEIsVsB5JAGnSLAEAAIH6WBsAAH4XU+gE6///WTPSagVZ9/GD wgdp0ugDAABS/xUg0UAA/wWwHkkAgT2wHkkAECcAAH4GiR2wHkkAagFYX15bycNVi+yB7AwD AABTM9uNhfT8//9TUI2F/P7//1BT/3UI6PwYAACDxBQ5XQx1bTldEHU/jYX8/v//UOhoGAAA O8NZdAeInAX7/v//jYX4/f//U1BTjYX8/v//U1DowRgAAI2F+P3//1Do29///4PEGOsNjYX0 /P//UOjK3///WYXAdBhqAWgA0AcA/zVwGUkA/3UI6NXn//+DxBBqAVhbycNWV4t8JAxqAV5o SvlAAFfoD9///1mFwFl0JWhJ+UAAV+j+3v//WYXAWXQCM/ZWaLtbQABX6H7h//+DxAxqAVhf XsNVi+yB7AwLAACLRRRTVlf/dQwz24kYjYX09P//UOiyFgAAjYX09P//aETgQABQ6LEWAAD/ dRCNhfT0//9Q6KIWAACNhfT4//9oAAQAAFCNhfT0//9TUGgCAACA6MTn//+NhfT4//9QjYX8 /v//UOhhFgAAg8Q0jYX0+P//aAQBAABQjYX8/v//UP8VwNBAAL5n+UAAU1boLdf//4lFFI2F 9Pz//1NQU42F9Pj//1NQ6IsXAACDxBwz/zldFH4rV1bo09b//zgYWVl0E1CNhfT8//9Q6Ane //9ZhcBZdQZHO30UfNo7fRR8JI2F9Pj//2j//EAAUOjn3f//WYXAWXQNjYX0+P//UOh5+P// WVONhfj9//9TUI2F/P7//1CNhfT4//9Q6BYXAACNhfj9//9QjYX8/v//UOioFQAAjYX8/v// UOh2/v//g8QgaOgDAAD/FSDRQABqAVhfXlvJw1WL7IHsCAEAAICl+P7//wCNhfj+//9qAVDo wN3//41F/FCNhfj+//9onFxAAFBoAgAAgOgw5///g8QYaIDuNgD/FSDRQADrwVWL7IN9DAB1 NIN9EAB1CGoF/xUg0UAA/3UI6N/d//+FwFl8FIP4A30P/3UIaIQdSQDo+BQAAFlZagFYXcP/ dQjo0/3//4XAWXQEM8BdwzPAOUUQD5TAXcNVi+yB7AwBAACApfT+//8AU42F9P7//2gEAQAA UGoBaEn5QADocdX//1lZUGhE8kAAaAIAAIDo6+X//42F9P7//1Doef3//w++hfT+//+Knfb+ //9Q6PoXAACDxByDZfgAiEX/ikX4BGE6Rf90PICl9v7//wCIhfT+//+NhfT+//9Q/xXE0EAA g/gDiJ32/v//dRf/dQiNhfT+//9oQl5AAFDo0N7//4PEDP9F+IN9+Bp8sTPAW8nCBABWaGH5 QAD/dCQQ6A0UAACLdCQQVujzFAAAg8QMM8mFwH4LgDwxQHQFQTvIfPVIO8h8BDPAXsONRDEB UP90JBDo6BMAAFlZagFYXsNVi+yB7BgDAABWi3UIjYXo/P//UFbom////1mFwFl1BzPA6boA AACDfRAAdBJW6G+4////dQxW6ADD//+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PjL//9q BGoKjUWcagNQ6BzW//+DxBCNRZyNjez9//9Q6FvQ//+NRmSNjez9//9Q6ArR//9WjY3s/f// 6FXQ//+Njez9///o6Mz//4XAdBCNjez9///odMz//+lr/////3UM6AQUAABZUI2N7P3///91 DOgYzf//jY3s/f//i/DoSsz//zPAhfYPlMBeycNVi+y4YCwAAOjwGgAAU1ZXaAAAEADoEhsA ADPbWTvDiUXodQlfXjPAW8nCBADo//H//4XAdQ1oYOoAAP8VINFAAOvqaADQBwD/NXAZSQDo 7Pj//1lZagHou/3//42FjPP//2gEAQAAUFP/FQjRQACNheD+//9Q6I7c//9ZiV386K3x//+F wHUKaGDqAADpLgMAAI2F4P7//1DoN9z//4XAWXVajYXg/v//U1CNhYzz//9Q/xVk0EAAjYXg /v//aiBQ/xWA0EAAjYXg/v//aAAwAQBQ6AXt//9T6Cbl//8z0rkAKAAA9/GNheD+//+BwgAy AQBSUOjm3f//g8QUU/81cBlJAOjY0v//OUX8WVmJRewPjaQCAABowB4AAI2FoNP//2jA4EAA UOhwFgAAjYWg0///iJ204///UI2F4P7//1Do6vL//2gkCQAAjYWQ9P//U1DoNREAAP91/P81 cBlJAOhL0v//g8QoOBiJReQPhDgCAABQjYX09P//UOhsEQAAU+h95P//M9KDxAz3dew7Vfx1 AUI7Vex8AjPSUv81cBlJAOgJ0v//i/hZWTgfdRBT/zVwGUkA6PXR//9Zi/hZjYXg/v//UI2F PPr//1DoGhEAAI2FWPX//1dQ6A0RAACNhZD0//9XUOgAEQAAagGNhZD0////dehQ6B79//+D xCSFwHQaagFoABAAAFdo1OBAAOgQ0f//g8QQ6Y0BAABTaNTgQADot9H//4NN9P9ZWYlF+Ild 8GgkCQAAjYWQ9P//U1DoRRAAAI2F4P7//1CNhTz6//9Q6JIQAACNhVj1//9XUOiFEAAA/3Xk jYX09P//UOh2EAAAU+iH4///M9KDxCj3dfiL8jt19HUBRjt1+HwCM/ZWaNTgQADoEtH//1CN hZD0//9Q6EEQAABqAY2FkPT///916FDoX/z//4PEHIXAdRD/RfCJdfSDffAFD4xi////g33w BQ+MzgAAAL4I/kAAU1bo99D//1OJRfjoEeP//zPSg8QM93X4O1X4iVX0fAOJXfSNhWDy//9Q jYW0/f//UFfoENf//42FtP3//2g04EAAUOjSDwAA/3X0Vuh90P//UI2FtP3//1DovA8AAGgk CQAAjYWQ9P//U1DoOg8AAI2F4P7//1CNhTz6//9Q6IcPAACNhVj1//9XUOh6DwAAg8RAjYX0 9P///3XkUOhoDwAAjYW0/f//UI2FkPT//1DoVQ8AAGoBjYWQ9P///3XoUOhz+///g8Qc/0X8 i0X8O0XsD4xc/f//aMAnCQD/FSDRQADptPz//1WL7IHsYAUAAGahjBBBAFZXagdmiUWgWTPA jX2i86tmq6GIEEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PYgeSQCJffSJffgPheoBAAA5PaAe SQAPhN4BAACLdQg793QljUXgUI1FgFD/FZjQQACNRYBQjUYCUOh4YAAAWYXAWQ+EsgEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6HEOAABZjYUY////WWoiUGr/Vos1zNBAAGoBV//Wx0X8AgAAALtE4EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FaAeSQA5fQyJRfAPhOkAAAA7x3VhOX34dVxqAWjc8UAA6L0VAABqAplZ9/mNhaT7 //9SUOih2///jYWo/P//U1Dorg0AAI1FoFCNhaj8//9Q6K4NAABqAY2FpPv//1dQjYWo/P// V1D/dQjoI8L//4PEOIlF+Dl98HV/agFonv1AAFfog+D//1mD4AFQjYWg+v//UOhB2////3UI jYWs/f//UOhMDQAAjYWs/f//U1DoTw0AAI1FoFCNhaz9//9Q6D8NAACNhaz9//9TUOgyDQAA jYWg+v//UI2FrP3//1DoHw0AAGoBav+Nhaz9//9q/1Do9QMAAIPESP9F/IN9/AUPjLH+//9b X17Jw1WL7LicQwAA6OsUAACNRQxXUINN/P//dQjHRfiAPgAAagNqAV9X/3UM6CZdAACFwA+F QAEAAI1F+FNQjYVkvP//UI1F/FD/dQzoAF0AADPbOV38iV0ID4YRAQAAVo21eLz///ZG+AKN Rux0E/91EGoCUOiJ////g8QM6dsAAACNhez8//9QjYXw/f//UP826Gnj//+DxAyFwA+FuwAA AP91EI2F8P3//1DoGP3//1lZV2jc8UAAU+hD3///WSPHUI2F5Pr//1DoAtr//4PEEDldEA+E ggAAAFeNheT6//9TUI2F7Pz//1NQjYXw/f//UOiSwP//g8QYV2ie/UAAU+j73v//WSPHUI2F 6Pv//1Doutn///82jYX0/v//UOjGCwAAjYX0/v//aETgQABQ6MULAACNhej7//9QjYX0/v// UOiyCwAAV2r/jYX0/v//av9Q6IkCAACDxDj/RQiDxiCLRQg7RfwPgvf+//9e/3UM6NNbAABb X8nDagFYUGoCagDoev7//4PEDGhAdxsA/xUg0UAAM8Dr5LjIHwAA6FYTAABTVVZXjUQkFGgE AQAAM9tQU/8VCNFAAIs9gNBAAL58G0kAaiBW/9dTjUQkGFZQ/xVk0EAAaiBWiUQkGP/XOVwk EHRWaMAeAACNhCQcAQAAaMDgQABQ6JwPAACNhCQkAQAAiJwkOBEAAFBW6Brs//9oADABAFbo vOX//1Po3d3//zPSuQAoAAD38YHCADIBAFJW6KPW//+DxChqJ1b/1zkdiB5JAL90GUkAdEVW V2h4GkkAaAIAAIDoNtz//2oBaG/7QADoQsv//4PEGFD/FSjRQACL6Ghv/EAAVf8VLNFAADvD dAVqAVP/0FX/FezQQAA5XCQQdQQzwOt1OR2IHkkAdAtTVuiA3f//WVnrXzkdkB5JAHVXiy1A 0EAAagJTU//VU1NTU1NWU2oCaBABAABTV1dQiUQkRP8VRNBAAP90JBCLNUjQQAD/1moBU1P/ 1YvoahBXVf8VONBAAIv4U1NX/xUY0EAAV//WVf/WagFYX15dW4HEyB8AAMNVi+xRoYgQQQCJ RfyKRQgARfyNRfxQ/xXE0EAAg/gDdAyD+AR0B2oBWMnCBABqAI1F/GgOWkAAUOgw1P//g8QM aAB0twH/FSDRQADr4FWL7IHsWAIAAFa+RPJAAI2F1P7//1ZQ6GMJAABqB1boH8r//1CNhdT+ //9Q6F4JAACApaj9//8AjYWo/f//aCwBAABQjYXU/v//aMz9QABQaAIAAIDoddr//2oAjYWo /f//aA5aQABQ6LPT//+DxDgzwF7JwgQAVYvsuNQhAADoCxEAAItFEFNWi3UMM9tXOV0UiXX8 iUX4dRH/dQjoY9z//4XAWQ+FPgEAAL9Q/UAAU1fovMn//1k781mJRQx9D1Po0Nv//zPSWfd1 DIlV/L7c8UAAU1bomMn//zldEFlZiUUMfQ9T6Kvb//8z0ln3dQyJVfiNhfT+//9Q6JvS//+N hez8///HBCQEAQAAUFP/FQjRQACNhfT+//9TUI2F7Pz//1D/FWTQQACFwA+EtwAAAI2F9P7/ /2ogUP8VgNBAAGjAHgAAjYUs3v//aMDgQABQ6NgMAACNhSze//+InUDu//9QjYX0/v//UOhS 6f//U+gg2///M9K5ACgAAPfxjYX0/v//gcIAMgEAUlDo4NP///91/FfoqMj//1CNhfD9//9Q 6NcHAAD/dfhW6JLI//9QjYXw/f//UOjRBwAAg8RAjYXw/f///3UUUI2F9P7//1D/dQjo9uT/ /42F9P7//1DoI9L//4PEFF9eW8nDVYvsgewcAQAAU1ZXjU3o6Fir//8z/zl9DA+FFgEAAFf/ FSDRQAA5PZQeSQB1Wb788UAAV1boS8j//4lFDI2F5P7//1BXV1f/dQjorQgAAIPEHDPbOX0M D47YAAAAU1bo8cf//1CNheT+//9Q6PBYAACDxBCFwHQGQztdDHzfO10MD42uAAAAaiD/dQj/ FYDQQABXaiBqA1dqAWgAAADA/3UI/xXw0EAAg/j/iUUID4SBAAAAjU38UVD/FfTQQAA5ffyL 2Ild+HQHuwAgAADrA8HrE2pkvnAZQQBTVuhQBgAAg8QMV1dX/3UI/xWU0EAAO99+HIldDI1F /FdQaAAACABW/3UI/xVs0EAA/00MdeeLRfjB4xM72HMSjU38VyvDUVBW/3UI/xVs0EAA/3UI /xUk0UAAagFYX15bycNVi+xRoYgQQQCJRfyKRQgARfyNRfxQ/xXE0EAAg/gDdAyD+AR0B2oB WMnCBABqAI1F/Gjfa0AAUOi40P//g8QM6+tWagFeagFW6JCm//9Ggf64CwAAfO9ew1WL7IPs FFNWV4s9INFAAGoBW2jAJwkA/9eNRexQ/xXk0EAAZotF7oTDdOdmg33yBnXggyWUHkkAAGY9 BwCJHZgeSQB1BokdlB5JAGY7w3UGiR2UHkkAM/aNRfxQagBWaBxtQABqAGoA/xXI0EAARoP+ GnzkaEB3GwD/1+hp////av//1+uMVYvsgewUAQAAjYXs/v//VlDoe8///41F8FBoAREAAGiE /0AA6HIDAAD/dfBQjYXs/v//UOiHzv//jYXs/v//agBQ6HHY//+Nhez+//8z9lDoqs///4PE KIXAdR9qZP8VINFAAIvGRoP4ZH8PjYXs/v//UOiHz///WevdagqNRfRqAFDojQQAAIPEDI2F 7P7//8ZF9HfGRfVxaAQBAABQxkX2a/8VqNBAAI2F7P7//2hE4EAAUOjLBAAAjUX0UI2F7P7/ /1DouwQAAIPEEIM9iB5JAABedCSNhez+//9o3PFAAFDonQQAAI2F7P7//2oAUOjC1///g8QQ 6yCNhez+//9okBBBAFDoeQQAAFmNhez+//9ZUP8VKNFAADPAycIEAFWL7FFTVos1yNBAAFeN Rfwz/1BXV2j/FUAAV1f/1o1F/FBXV2iDYEAAV1f/1o1F/FBXV2gBaEAAV1f/1o1F/FBXV2j6 XUAAV1f/1o1F/FBXV2j7bUAAV1f/1o1F/FBXV2jxaUAAV1f/1jPbjUX8UFdTaKRpQABXV//W Q4P7Gnzr6NT9//9fXlvJw1WL7IPsHDPAx0XkEAEAAIlF7IlF8IlF9IlF+IlF/I1F5FDHRegE AAAA/zW0HkkA/xU80EAA6Bzb//+FwHQF6DP////JwgQAaKZvQABodBlJAP8VNNBAAGoAo7Qe SQDonf///8IIAFWL7IHsoAEAAI2FYP7//1BqAv8V1NFAAOiD4///hcB0VOju9///gD3U8EAA AHQPaNTwQADobOj//4XAWXU3gz2QHkkAAHQgg2X4AINl/ACNRfDHRfB0GUkAUMdF9O1vQAD/ FQDQQADohNr//4XAdAXom/7//zPAycIQAFWL7LiMOAEA6OwKAABTVv91DOgRCwAAi9gz9jve WYld9Il1+Il1/HUHM8Dp2wAAAFdogDgBAI2FdMf+/1ZQ6EYCAACDxAwzwI29eMf+/ztFDHNm i00IigwIhMl0DYgMHkZAiXX8O0UMcuk7RQxzSovIi1UIgDwRAHUGQTtNDHLxi9Er0IP6CnMR O8FzwYtVCIoUEIgUHkZA6++BffgQJwAAcw//RfiJR/yJF4PHCIvB65yJdfwz9utIi0X4iXX8 i/jB5wONXDcEU+haCgAAi/CLRfhXiQaNhXTH/v9QjUYEUOizBgAA/3X8jUQ3BP919FDoowYA AItFEIPEHIkYi130U+h9BgAAWYvGX15bycNVi+yD7AxTi10IVleLAzPSi/iNSwTB5wOJVfyJ TfSNdwSJRfg5dQxzBzPA6ZwAAACFwHYji/GJRQiLDjvRcwcrygPRAU38i0YEhcB2AgPQg8YI /00IdeKLRQwrx4PA/DlF/IlFDHMFK0X8A9CLRRAz9iF1/FKJEOidCQAAjXwfBItd+IXbWXYu i030OzFzD4tV/IoUOogUMEb/Rfzr7TPSOVEEdguAJDAARkI7UQRy9YPBCEt11YtN/DtNDHMO A/CKFDmIFkZBO00McvRfXlvJw8z/JRDRQAD/JQzRQAD/JQTRQAD/JQDRQACLVCQEi0wkCPfC AwAAAHU8iwI6AXUuCsB0JjphAXUlCuR0HcHoEDpBAnUZCsB0ETphA3UQg8EEg8IECuR10ov/ M8DDkBvA0eBAw4v/98IBAAAAdBSKAkI6AXXpQQrAdOD3wgIAAAB0qGaLAoPCAjoBddIKwHTK OmEBdckK5HTBg8EC64zMzMzMzMzMzMzMzMyLVCQMi0wkBIXSdEczwIpEJAhXi/mD+gRyLffZ g+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogHR0p1+otEJAhf w4tEJATDzMzMzMzMzMxXi3wkCOtqjaQkAAAAAIv/i0wkBFf3wQMAAAB0D4oBQYTAdDv3wQMA AAB18YsBuv/+/n4D0IPw/zPCg8EEqQABAYF06ItB/ITAdCOE5HQaqQAA/wB0DqkAAAD/dALr zY15/+sNjXn+6wiNef3rA415/ItMJAz3wQMAAAB0GYoRQYTSdGSIF0f3wQMAAAB17usFiReD xwS6//7+fosBA9CD8P8zwosRg8EEqQABAYF04YTSdDSE9nQn98IAAP8AdBL3wgAAAP90AuvH iReLRCQIX8NmiReLRCQIxkcCAF/DZokXi0QkCF/DiBeLRCQIX8OLTCQE98EDAAAAdBSKAUGE wHRA98EDAAAAdfEFAAAAAIsBuv/+/n4D0IPw/zPCg8EEqQABAYF06ItB/ITAdDKE5HQkqQAA /wB0E6kAAAD/dALrzY1B/4tMJAQrwcONQf6LTCQEK8HDjUH9i0wkBCvBw41B/ItMJAQrwcNV i+xRg2X8AFOLXQhWV1Pocf///4P4AVlyIYB7ATp1G4t1DIX2dBBqAlNW6IwQAACDxAyAZgIA Q0PrCotFDIXAdAOAIACDZQwAgDsAi8O+/wAAAIlFCHRliggPttH2guEySQAEdANA6xqA+S90 D4D5XHQKgPkudQuJRfzrBo1IAYlNDECAOAB1z4t9DIlFCIX/dCqDfRAAdB8r+zv+cgKL/ldT /3UQ6BEQAACLRRCDxAyAJAcAi0UIi10M6wqLTRCFyXQDgCEAi338hf90TDv7ckiDfRQAdB8r +zv+cgKL/ldT/3UU6NIPAACLRRSDxAyAJAcAi0UIi30Yhf90RCtF/DvGcwKL8Fb/dfxX6KsP AACDxAyAJD4A6yiLfRSF/3QXK8M7xnMCi/BWU1foiw8AAIPEDIAkPgCLRRiFwHQDgCAAX15b ycNVi+xRgz3UHkkAAFN1HYtFCIP4YQ+MrwAAAIP4eg+PpgAAAIPoIOmeAAAAi10IgfsAAQAA fSiDPbwTQQABfgxqAlPoBxIAAFlZ6wuhsBFBAIoEWIPgAoXAdQSLw+trixWwEUEAi8PB+AgP tsj2REoBgHQOgGUKAIhFCIhdCWoC6wmAZQkAiF0IagFYjU38agFqAGoDUVCNRQhQaAACAAD/ NdQeSQDoVQ8AAIPEIIXAdKmD+AF1Bg+2RfzrDQ+2Rf0Ptk38weAIC8FbycNVi+xRgz3UHkkA AFNWV3Udi0UIg/hBD4yqAAAAg/haD4+hAAAAg8Ag6ZkAAACLXQi/AAEAAGoBO99efSU5NbwT QQB+C1ZT6DcRAABZWesKobARQQCKBFgjxoXAdQSLw+tlixWwEUEAi8PB+AgPtsj2REoBgHQP gGUKAGoCiEUIiF0JWOsJgGUJAIhdCIvGVmoAjU38agNRUI1FCFBX/zXUHkkA6IsOAACDxCCF wHSuO8Z1Bg+2RfzrDQ+2Rf0Ptk38weAIC8FfXlvJw1WL7IPsIItFCFaJReiJReCNRRDHRexC AAAAUI1F4P91DMdF5P///39Q6BMSAACDxAz/TeSL8HgIi0XggCAA6w2NReBQagDo4RAAAFlZ i8ZeycP/dCQE6PAZAABZw8zMzMzMzMzMzMxVi+xXVot1DItNEIt9CIvBi9EDxjv+dgg7+A+C eAEAAPfHAwAAAHUUwekCg+IDg/kIcinzpf8klWh5QACLx7oDAAAAg+kEcgyD4AMDyP8khYB4 QAD/JI14eUAAkP8kjfx4QACQkHhAALx4QADgeEAAI9GKBogHikYBiEcBikYCwekCiEcCg8YD g8cDg/kIcszzpf8klWh5QACNSQAj0YoGiAeKRgHB6QKIRwGDxgKDxwKD+QhypvOl/ySVaHlA AJAj0YoGiAdGwekCR4P5CHKM86X/JJVoeUAAjUkAX3lAAEx5QABEeUAAPHlAADR5QAAseUAA JHlAABx5QACLRI7kiUSP5ItEjuiJRI/oi0SO7IlEj+yLRI7wiUSP8ItEjvSJRI/0i0SO+IlE j/iLRI78iUSP/I0EjQAAAAAD8AP4/ySVaHlAAIv/eHlAAIB5QACMeUAAoHlAAItFCF5fycOQ igaIB4tFCF5fycOQigaIB4pGAYhHAYtFCF5fycONSQCKBogHikYBiEcBikYCiEcCi0UIXl/J w5CNdDH8jXw5/PfHAwAAAHUkwekCg+IDg/kIcg3986X8/ySVAHtAAIv/99n/JI2wekAAjUkA i8e6AwAAAIP5BHIMg+ADK8j/JIUIekAA/ySNAHtAAJAYekAAOHpAAGB6QACKRgMj0YhHA07B 6QJPg/kIcrb986X8/ySVAHtAAI1JAIpGAyPRiEcDikYCwekCiEcCg+4Cg+8Cg/kIcoz986X8 /ySVAHtAAJCKRgMj0YhHA4pGAohHAopGAcHpAohHAYPuA4PvA4P5CA+CWv////3zpfz/JJUA e0AAjUkAtHpAALx6QADEekAAzHpAANR6QADcekAA5HpAAPd6QACLRI4ciUSPHItEjhiJRI8Y i0SOFIlEjxSLRI4QiUSPEItEjgyJRI8Mi0SOCIlEjwiLRI4EiUSPBI0EjQAAAAAD8AP4/ySV AHtAAIv/EHtAABh7QAAoe0AAPHtAAItFCF5fycOQikYDiEcDi0UIXl/Jw41JAIpGA4hHA4pG AohHAotFCF5fycOQikYDiEcDikYCiEcCikYBiEcBi0UIXl/Jw4tEJASjoBBBAMOhoBBBAGnA /UMDAAXDniYAo6AQQQDB+BAl/38AAMPMzMxRPQAQAACNTCQIchSB6QAQAAAtABAAAIUBPQAQ AABz7CvIi8SFAYvhiwiLQARQw2oB/3QkCOiLFgAAWVnDVYvsg+wgi0UIx0XsSQAAAFCJReiJ ReDoh/j//4lF5I1FEFCNReD/dQxQ6LsWAACDxBDJw8zMzMzMzMzMzMzMzMzMzFWL7FdWi3UM 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 X8nDgz28E0EAAX4RaAMBAAD/dCQI6CQJAABZWcOLRCQEiw2wEUEAZosEQSUDAQAAw4M9vBNB AAF+DmoE/3QkCOj5CAAAWVnDi0QkBIsNsBFBAIoEQYPgBMODPbwTQQABfg5qCP90JAjo0QgA AFlZw4tEJASLDbARQQCKBEGD4AjDzMzMzMzMzMzMzMzMzItMJAhXU1aKEYt8JBCE0nRpinEB hPZ0T4v3i0wkFIoHRjjQdBWEwHQLigZGONB0CoTAdfVeW18zwMOKBkY48HXrjX7/imEChOR0 KIoGg8YCOOB1xIpBA4TAdBiKZv+DwQI44HTf67EzwF5bX4rC6UMdAACNR/9eW1/Di8deW1/D VYvsV1ZTi00Q4yaL2Yt9CIv3M8DyrvfZA8uL/ot1DPOmikb/M8k6R/93BHQESUn30YvBW15f ycNVi+xq/2g40kAAaCSoQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VtNBAADPSitSJFQQf SQCLyIHh/wAAAIkNAB9JAMHhCAPKiQ38HkkAwegQo/geSQAz9lboFiYAAFmFwHUIahzosAAA AFmJdfzoViQAAP8VvNBAAKPoM0kA6BQjAACjuB5JAOi9IAAA6P8fAADoHB0AAIl10I1FpFD/ FXDRQADokB8AAIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VbNFAAFDoxu7//4lFoFDoCh0A AItF7IsIiwmJTZhQUejOHQAAWVnDi2Xo/3WY6PwcAACDPcAeSQABdQXogCcAAP90JATosCcA AGj/AAAA/xWwEEEAWVnDgz3AHkkAAXUF6FsnAAD/dCQE6IsnAABZaP8AAAD/FXTRQADDVYvs g+wYU1ZX/3UI6IgBAACL8Fk7NbgxSQCJdQgPhGoBAAAz2zvzD4RWAQAAM9K4wBBBADkwdHKD wDBCPbARQQB88Y1F6FBW/xV40UAAg/gBD4UkAQAAakAzwFm/4DJJAIN96AGJNbgxSQDzq6qJ HeQzSQAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICI4TJJ AARA6+5qQDPAWb/gMkkA86uNNFKJXfzB5gSqjZ7QEEEAgDsAi8t0LIpRAYTSdCUPtgEPtvo7 x3cUi1X8ipK4EEEACJDhMkkAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXMMUkAAQAA AFCjuDFJAOjGAAAAjbbEEEEAv8AxSQClpVmj5DNJAKXrVUFBgHn/AA+FSP///2oBWICI4TJJ AAhAPf8AAABy8VbojAAAAFmj5DNJAMcFzDFJAAEAAADrBokdzDFJADPAv8AxSQCrq6vrDTkd xB5JAHQO6I4AAADosgAAADPA6wODyP9fXlvJw4tEJASDJcQeSQAAg/j+dRDHBcQeSQABAAAA /yWA0UAAg/j9dRDHBcQeSQABAAAA/yV80UAAg/j8dQ+h5B5JAMcFxB5JAAEAAADDi0QkBC2k AwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQEAADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAv+Ay SQDzq6ozwL/AMUkAo7gxSQCjzDFJAKPkM0kAq6urX8NVi+yB7BQFAACNRexWUP81uDFJAP8V eNFAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvGcvSKRfLGhez+//8ghMB0N1NXjVXzD7YK D7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4PhA/OqQkKKQv+EwHXQX1tqAI2F7Pr/ //815DNJAP81uDFJAFCNhez+//9WUGoB6PMlAABqAI2F7P3///81uDFJAFZQjYXs/v//VlBW /zXkM0kA6GgBAABqAI2F7Pz///81uDFJAFZQjYXs/v//VlBoAAIAAP815DNJAOhAAQAAg8Rc M8CNjez6//9mixH2wgF0FoCI4TJJABCKlAXs/f//iJDgMUkA6xz2wgJ0EICI4TJJACCKlAXs /P//6+OAoOAxSQAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiOEySQAQisiAwSCIiOAx SQDrH4P4YXITg/h6dw6AiOEySQAgisiA6SDr4ICg4DFJAABAO8Zyvl7Jw4M9qDFJAAB1Emr9 6Cz8//9ZxwWoMUkAAQAAAMNVi+yDPcwxSQAAV4t9CIl9CHUR/3UQ/3UMV+gqJgAAg8QM62OL VRBWhdJ0PYtNDIoBSg+28PaG4TJJAASIB3QTR0GF0nQZigFKiAdHQYTAdBTrBkdBhMB0EIXS ddLrCoBn/wDrBIBn/gCLwkqFwF50E41KATPAi9HB6QLzq4vKg+ED86qLRQhfXcNVi+xq/2hQ 0kAAaCSoQABkoQAAAABQZIklAAAAAIPsHFNWV4ll6DP/OT3IHkkAdUZXV2oBW1NoSNJAAL4A AQAAVlf/FYjRQACFwHQIiR3IHkkA6yJXV1NoRNJAAFZX/xWE0UAAhcAPhCIBAADHBcgeSQAC AAAAOX0UfhD/dRT/dRDongEAAFlZiUUUocgeSQCD+AJ1Hf91HP91GP91FP91EP91DP91CP8V hNFAAOneAAAAg/gBD4XTAAAAOX0gdQih5B5JAIlFIFdX/3UU/3UQi0Uk99gbwIPgCEBQ/3Ug /xXM0EAAi9iJXeQ73w+EnAAAAIl9/I0EG4PAAyT86F30//+JZeiLxIlF3INN/P/rE2oBWMOL Zegz/4l93INN/P+LXeQ5fdx0ZlP/ddz/dRT/dRBqAf91IP8VzNBAAIXAdE1XV1P/ddz/dQz/ dQj/FYjRQACL8Il12Dv3dDL2RQ0EdEA5fRwPhLIAAAA7dRx/Hv91HP91GFP/ddz/dQz/dQj/ FYjRQACFwA+FjwAAADPAjWXIi03wZIkNAAAAAF9eW8nDx0X8AQAAAI0ENoPAAyT86Knz//+J ZeiL3Ild4INN/P/rEmoBWMOLZegz/zPbg038/4t12DvfdLRWU/915P913P91DP91CP8ViNFA AIXAdJw5fRxXV3UEV1frBv91HP91GFZTaCACAAD/dSD/FdDQQACL8Dv3D4Rx////i8bpbP// /4tUJAiLRCQEhdJWjUr/dA2AOAB0CECL8UmF9nXzgDgAXnUFK0QkBMOLwsNVi+xRi0UIjUgB gfkAAQAAdwyLDbARQQAPtwRB61KLyFaLNbARQQDB+QgPttH2RFYBgF50DoBl/gCITfyIRf1q AusJgGX9AIhF/GoBWI1NCmoBagBqAFFQjUX8UGoB6LUhAACDxByFwHUCycMPt0UKI0UMycNV i+xTVot1DItGDIteEKiCD4TzAAAAqEAPhesAAACoAXQWg2YEAKgQD4TbAAAAi04IJP6JDolG DItGDINmBACDZQwAJO8MAmapDAGJRgx1IoH+QBVBAHQIgf5gFUEAdQtT6B4mAACFwFl1B1bo zyUAAFlm90YMCAFXdGSLRgiLPiv4jUgBiQ6LThhJhf+JTgR+EFdQU+j5IwAAg8QMiUUM6zOD +/90FovDi8vB+AWD4R+LBIWgMEkAjQTI6wW4aBRBAPZABCB0DWoCagBT6CcjAACDxAyLRgiK TQiICOsUagGNRQhfV1BT6KYjAACDxAyJRQw5fQxfdAaDTgwg6w+LRQgl/wAAAOsIDCCJRgyD yP9eW13DVYvsgexIAgAAU1ZXi30MM/aKH0eE24l19Il17Il9DA+E9AYAAItN8DPS6wiLTfCL ddAz0jlV7A+M3AYAAID7IHwTgPt4fw4PvsOKgEjSQACD4A/rAjPAD76ExmjSQADB+ASD+AeJ RdAPh5oGAAD/JIUbkUAAg03w/4lVzIlV2IlV4IlV5IlV/IlV3Ol4BgAAD77Dg+ggdDuD6AN0 LYPoCHQfSEh0EoPoAw+FWQYAAINN/AjpUAYAAINN/ATpRwYAAINN/AHpPgYAAIBN/IDpNQYA AINN/ALpLAYAAID7KnUjjUUQUOj1BgAAhcBZiUXgD40SBgAAg038BPfYiUXg6QQGAACLReAP vsuNBICNREHQ6+mJVfDp7QUAAID7KnUejUUQUOi2BgAAhcBZiUXwD43TBQAAg03w/+nKBQAA jQSJD77LjURB0IlF8Om4BQAAgPtJdC6A+2h0IID7bHQSgPt3D4WgBQAAgE39COmXBQAAg038 EOmOBQAAg038IOmFBQAAgD82dRSAfwE0dQ5HR4BN/YCJfQzpbAUAAIlV0IsNsBFBAIlV3A+2 w/ZEQQGAdBmNRexQ/3UID77DUOh/BQAAih+DxAxHiX0MjUXsUP91CA++w1DoZgUAAIPEDOkl BQAAD77Dg/hnD48cAgAAg/hlD42WAAAAg/hYD4/rAAAAD4R4AgAAg+hDD4SfAAAASEh0cEhI dGyD6AwPhekDAABm90X8MAh1BIBN/QiLdfCD/v91Bb7///9/jUUQUOicBQAAZvdF/BAIWYvI iU34D4T+AQAAhcl1CYsNzBNBAIlN+MdF3AEAAACLwYvWToXSD4TUAQAAZoM4AA+EygEAAEBA 6+fHRcwBAAAAgMMgg038QI29uP3//zvKiX34D43PAAAAx0XwBgAAAOnRAAAAZvdF/DAIdQSA Tf0IZvdF/BAIjUUQUHQ76DAFAABQjYW4/f//UOh1IwAAg8QMiUX0hcB9MsdF2AEAAADrKYPo WnQyg+gJdMVID4ToAQAA6QgDAADo2AQAAFmIhbj9///HRfQBAAAAjYW4/f//iUX46ecCAACN RRBQ6LMEAACFwFl0M4tIBIXJdCz2Rf0IdBcPvwDR6IlN+IlF9MdF3AEAAADptQIAAINl3ACJ TfgPvwDpowIAAKHIE0EAiUX4UOmOAAAAdQyA+2d1B8dF8AEAAACLRRD/dcyDwAiJRRD/dfCL SPiJTbiLQPyJRbwPvsNQjYW4/f//UI1FuFD/FaAXQQCLdfyDxBSB5oAAAAB0FIN98AB1Do2F uP3//1D/FawXQQBZgPtndRKF9nUOjYW4/f//UP8VpBdBAFmAvbj9//8tdQ2ATf0Bjb25/f// iX34V+hh5v//Wen8AQAAg+hpD4TRAAAAg+gFD4SeAAAASA+EhAAAAEh0UYPoAw+E/f3//0hI D4SxAAAAg+gDD4XJAQAAx0XUJwAAAOs8K8HR+Om0AQAAhcl1CYsNyBNBAIlN+IvBi9ZOhdJ0 CIA4AHQDQOvxK8HpjwEAAMdF8AgAAADHRdQHAAAA9kX8gMdF9BAAAAB0XYpF1MZF6jAEUcdF 5AIAAACIRevrSPZF/IDHRfQIAAAAdDuATf0C6zWNRRBQ6BsDAAD2RfwgWXQJZotN7GaJCOsF i03siQjHRdgBAAAA6SMCAACDTfxAx0X0CgAAAPZF/YB0DI1FEFDo7QIAAFnrQfZF/CB0IfZF /ECNRRBQdAzoyAIAAFkPv8CZ6yXovAIAAFkPt8Dr8vZF/ECNRRBQdAjopwIAAFnr4OifAgAA WTPS9kX8QHQbhdJ/F3wEhcBzEffYg9IAi/D32oBN/QGL+usEi/CL+vZF/YB1A4PnAIN98AB9 CcdF8AEAAADrBINl/PeLxgvHdQSDZeQAjUW3iUX4i0Xw/03whcB/BovGC8d0O4tF9JlSUFdW iUXAiVXE6G8hAAD/dcSL2IPDMP91wFdW6O0gAACD+zmL8Iv6fgMDXdSLRfj/TfiIGOu1jUW3 K0X4/0X49kX9AolF9HQZi034gDkwdQSFwHUN/034QItN+MYBMIlF9IN92AAPhfQAAACLXfz2 w0B0JvbHAXQGxkXqLesU9sMBdAbGReor6wn2wwJ0C8ZF6iDHReQBAAAAi3XgK3XkK3X09sMM dRKNRexQ/3UIVmog6BcBAACDxBCNRexQjUXq/3UI/3XkUOgyAQAAg8QQ9sMIdBf2wwR1Eo1F 7FD/dQhWajDo5QAAAIPEEIN93AB0QYN99AB+O4tF9Itd+I14/2aLA0NQjUXIUEPolh8AAFmF wFl+Mo1N7FH/dQhQjUXIUOjYAAAAg8QQi8dPhcB10OsVjUXsUP91CP919P91+Oi6AAAAg8QQ 9kX8BHQSjUXsUP91CFZqIOhxAAAAg8QQi30Mih9HhNuJfQwPhRP5//+LRexfXlvJw5mLQABv ikAAiopAANaKQAANi0AAFYtAAEqLQADdi0AAVYvsi00M/0kEeA6LEYpFCIgC/wEPtsDrC1H/ dQjoiPf//1lZg/j/i0UQdQWDCP9dw/8AXcNWV4t8JBCLx0+FwH4hi3QkGFb/dCQY/3QkFOis ////g8QMgz7/dAeLx0+FwH/jX17DU4tcJAyLw0tWV4XAfiaLfCQci3QkEA++BldG/3QkHFDo df///4PEDIM//3QHi8NLhcB/4l9eW8OLRCQEgwAEiwCLQPzDi0QkBIMACIsIi0H4i1H8w4tE JASDAASLAGaLQPzDVot0JAiF9nQkVujAHwAAWYXAVnQKUOjfHwAAWVlew2oA/zWEMEkA/xWM 0UAAXsP/NVAgSQD/dCQI6AMAAABZWcODfCQE4Hci/3QkBOgcAAAAhcBZdRY5RCQIdBD/dCQE 6HUnAACFwFl13jPAw1aLdCQIOzXAF0EAdwtW6KUiAACFwFl1HIX2dQNqAV6Dxg+D5vBWagD/ NYQwSQD/FZDRQABew1WL7IHsxAEAAIBl6wBTVot1DDPbV4oGiV38hMCJXcwPhOEJAACLfQjr BYt9CDPbgz28E0EAAX4PD7bAaghQ6Ib1//9ZWesPiw2wEUEAD7bAigRBg+AIO8N0Nv9N/FeN RfxXUOglCgAAWVlQ6AYKAAAPtkYBRlDoaez//4PEDIXAdA4PtkYBRlDoV+z//1nr7oA+JQ+F 2QgAAIBlywCAZegAgGXpAIBl8gCAZfEAgGXqADP/gGX7AIld5Ild4Ild9MZF8wGJXdAPtl4B RoM9vBNBAAF+Dw+2w2oEUOjp9P//WVnrD4sNsBFBAA+2w4oEQYPgBIXAdBKLRfT/ReCNBICN REPQiUX062WD+05/PnReg/sqdDKD+0Z0VIP7SXQKg/tMdTf+RfPrRYB+ATZ1LIB+AjSNRgJ1 I/9F0INl2ACDZdwAi/DrJ/5F8usig/todBeD+2x0CoP7d3QI/kXx6w7+RfP+RfvrBv5N8/5N +4B98QAPhE////+AffIAiXUMdRKLRRCJRbyDwASJRRCLQPyJRdSAZfEAgH37AHUUigY8U3QK PEN0BoBN+//rBMZF+wGLXQwPtjODziCD/m6JdcR0KIP+Y3QUg/57dA//dQiNRfxQ6LUIAABZ 6wv/dQj/RfzodggAAFmJRewzwDlF4HQJOUX0D4TcBwAAg/5vD49eAgAAD4QKBQAAg/5jD4Qs AgAAg/5kD4T4BAAAD45qAgAAg/5nfjiD/ml0G4P+bg+FVwIAAIB98gCLffwPhAAHAADpIQcA AGpkXotd7IP7LQ+FfgIAAMZF6QHpegIAAItd7I21PP7//4P7LXUOiJ08/v//jbU9/v//6wWD +yt1F4t9CP9N9P9F/FfozgcAAIvYWYld7OsDi30Ig33gAHQJgX30XQEAAH4Hx0X0XQEAAIM9 vBNBAAF+DGoEU+gJ8///WVnrC6GwEUEAigRYg+AEhcB0IYtF9P9N9IXAdBf/ReSIHkb/RfxX 6HAHAACL2FmJXezruzgdwBNBAHVmi0X0/030hcB0XP9F/FfoTQcAAIvYoMATQQCIBlmJXexG gz28E0EAAX4MagRT6Jvy//9ZWesLobARQQCKBFiD4ASFwHQhi0X0/030hcB0F/9F5IgeRv9F /FfoAgcAAIvYWYld7Ou7g33kAA+EjgAAAIP7ZXQJg/tFD4WAAAAAi0X0/030hcB0dsYGZUb/ RfxX6MsGAACL2FmD+y2JXex1BYgGRusFg/srdR6LRfT/TfSFwHUFIUX06w//RfxX6J4GAACL 2FmJXeyDPbwTQQABfgxqBFPo9PH//1lZ6wuhsBFBAIoEWIPgBIXAdBKLRfT/TfSFwHQI/0Xk iB5G67v/TfxXU+hyBgAAg33kAFlZD4T2BQAAgH3yAA+FTQUAAP9FzIAmAI2FPP7//1APvkXz /3XUSFD/FagXQQCDxAzpKQUAADlF4HUK/0X0x0XgAQAAAIB9+wB+BMZF6gG/2BNBAOkLAQAA i8aD6HAPhKMCAACD6AMPhOgAAABISA+ElgIAAIPoAw+Ew/3//4PoA3QkD7YDO0XsD4U/BQAA /k3rgH3yAA+FwwQAAItFvIlFEOm4BAAAgH37AH4ExkXqAYt9DEeJfQyAP14PhacAAACLx414 AemZAAAAg/srdSL/TfR1DIN94AB0BsZF8QHrEf91CP9F/OhoBQAAi9hZiV3sg/swD4VFAgAA /3UI/0X86E4FAACL2FmA+3iJXex0L4D7WHQqg/54x0XkAQAAAHQIam9e6RYCAAD/dQj/TfxT 6DgFAABZWWowW+n9AQAA/3UI/0X86AkFAABZi9iJXexqeOvPgH37AH4ExkXqAb/QE0EAgE3o /2ogjUWcagBQ6Oza//+DxAyDfcR7dQ6AP111CbJdR8ZFpyDrA4pVy4oHPF10X0c8LXVBhNJ0 PYoPgPlddDZHOtFzBIrB6wSKworROtB3IQ+20g+28CvyRovKi8KD4QezAcHoA9LjjUQFnAgY Qk516DLS67QPtsiK0IvBg+EHswHB6APS441EBZwIGOubgD8AD4QBBAAAg33Ee3UDiX0Mi30I i3XU/038V/917Il10OhTBAAAWVmDfeAAdA6LRfT/TfSFwA+EnAAAAP9F/FfoGgQAAIP4/1mJ Rex0fovIagGD4QdaD75d6NPii8jB+QMPvkwNnDPLhdF0YIB98gB1UoB96gB0QYsNsBFBAIhF yA+2wPZEQQGAdA3/RfxX6MsDAABZiEXJ/zW8E0EAjUXIUI1FwlDoqiAAAGaLRcKDxAxmiQZG RusDiAZGiXXU6WT/////RdDpXP////9N/FdQ6KMDAABZWTl10A+EKAMAAIB98gAPhX8CAAD/ RcyDfcRjD4RyAgAAgH3qAItF1HQJZoMgAOlgAgAAgCAA6VgCAADGRfMBi13sg/stdQbGRekB 6wWD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X86BoDAABZi9iJXeyDfdAAD4QPAQAAgH3x AA+F4wAAAIP+eHVPgz28E0EAAX4PaIAAAABT6FTu//9ZWesNobARQQCKBFglgAAAAIXAD4Sj AAAAi0XYi1XcagRZ6M0gAABTiUXYiVXc6H0CAACL2FmJXezrU4M9vBNBAAF+DGoEU+gI7v// WVnrC6GwEUEAigRYg+AEhcB0XYP+b3UVg/s4fVOLRdiLVdxqA1nofSAAAOsPagBqCv913P91 2OgsIAAAiUXYiVXc/0XkjUPQmQFF2BFV3IN94AB0Bf9N9HQk/3UI/0X86DYCAACL2FmJXezp K/////91CP9N/FPoOQIAAFlZgH3pAA+E3AAAAItF2ItN3PfYg9EAiUXY99mJTdzpxAAAAIB9 8QAPhbIAAACD/nh0P4P+cHQ6gz28E0EAAX4MagRT6EPt//9ZWesLobARQQCKBFiD4ASFwHR2 g/5vdQqD+zh9bMHnA+s/jTy/0efrOIM9vBNBAAF+D2iAAAAAU+gG7f//WVnrDaGwEUEAigRY JYAAAACFwHQ3U8HnBOhEAQAAi9hZiV3s/0Xkg33gAI18H9B0Bf9N9HQk/3UI/0X86FgBAACL 2FmJXezpXP////91CP9N/FPoWwEAAFlZgH3pAHQC99+D/kZ1BINl5ACDfeQAD4TOAAAAgH3y AHUp/0XMg33QAHQQi0XUi03YiQiLTdyJSATrEIB98wCLRdR0BIk46wNmiTj+Rev/RQyLdQzr Qv9F/Ffo4QAAAIvYWQ+2BkY7w4ld7Il1DHVViw2wEUEAD7bD9kRBAYB0GP9F/FfotwAAAFkP tg5GO8iJdQx1Pv9N/IN97P91EIA+JXVNi0UMgHgBbnVEi/CKBoTAD4VW9v//6zD/dQj/Tfz/ dezrBf9N/FdT6IsAAABZWesX/038V1DofQAAAP9N/FdT6HMAAACDxBCDfez/dRGLRcyFwHUN OEXrdQiDyP/rA4tFzF9eW8nDgz28E0EAAVZ+EIt0JAhqBFbojuv//1lZ6w+LdCQIobARQQCK BHCD4ASFwHUGg+bfg+4Hi8Zew4tUJAT/SgR4CYsKD7YBQYkKw1LoFB4AAFnDg3wkBP90D/90 JAj/dCQI6NceAABZWcNWi3QkCFf/dCQQ/wbovv///4v4V+g+4v//WYXAWXXni8dfXsPMzMzM zMzMzI1C/1vDjaQkAAAAAI1kJAAzwIpEJAhTi9jB4AiLVCQI98IDAAAAdBOKCkI42XTRhMl0 UffCAwAAAHXtC9hXi8PB4xBWC9iLCr///v5+i8GL9zPLA/AD+YPx/4Pw/zPPM8aDwgSB4QAB AYF1HCUAAQGBdNMlAAEBAXUIgeYAAACAdcReX1szwMOLQvw42HQ2hMB07zjcdCeE5HTnwegQ ONh0FYTAdNw43HQGhOR01OuWXl+NQv9bw41C/l5fW8ONQv1eX1vDjUL8Xl9bw6G0MUkAhcB0 Av/QaBTgQABoCOBAAOjOAAAAaATgQABoAOBAAOi/AAAAg8QQw2oAagD/dCQM6BUAAACDxAzD agBqAf90JAzoBAAAAIPEDMNXagFfOT00H0kAdRH/dCQI/xWs0EAAUP8VHNFAAIN8JAwAU4tc JBSJPTAfSQCIHSwfSQB1PKGwMUkAhcB0IosNrDFJAFaNcfw78HITiwaFwHQC/9CD7gQ7NbAx SQBz7V5oIOBAAGgY4EAA6CoAAABZWWgo4EAAaCTgQADoGQAAAFlZhdtbdRD/dCQIiT00H0kA /xV00UAAX8NWi3QkCDt0JAxzDYsGhcB0Av/Qg8YE6+1ew1WL7FP/dQjoNQEAAIXAWQ+EIAEA AItYCIXbD4QVAQAAg/sFdQyDYAgAagFY6Q0BAACD+wEPhPYAAACLDTgfSQCJTQiLTQyJDTgf SQCLSASD+QgPhcgAAACLDVgUQQCLFVwUQQAD0VY7yn0VjTRJK9GNNLXoE0EAgyYAg8YMSnX3 iwCLNWQUQQA9jgAAwHUMxwVkFEEAgwAAAOtwPZAAAMB1DMcFZBRBAIEAAADrXT2RAADAdQzH BWQUQQCEAAAA60o9kwAAwHUMxwVkFEEAhQAAAOs3PY0AAMB1DMcFZBRBAIIAAADrJD2PAADA dQzHBWQUQQCGAAAA6xE9kgAAwHUKxwVkFEEAigAAAP81ZBRBAGoI/9NZiTVkFEEAWV7rCINg CABR/9NZi0UIozgfSQCDyP/rCf91DP8VlNFAAFtdw4tUJASLDWAUQQA5FeATQQBWuOATQQB0 FY00SY00teATQQCDwAw7xnMEORB19Y0MSV6NDI3gE0EAO8FzBDkQdAIzwMODPagxSQAAdQXo u+T//1aLNegzSQCKBjwidSWKRgFGPCJ0FYTAdBEPtsBQ6JQbAACFwFl05kbr44A+InUNRusK PCB2BkaAPiB3+ooGhMB0BDwgdumLxl7DUzPbOR2oMUkAVld1Behf5P//izW4HkkAM/+KBjrD dBI8PXQBR1boK9P//1mNdAYB6+iNBL0EAAAAUOjq8P//i/BZO/OJNRQfSQB1CGoJ6BHg//9Z iz24HkkAOB90OVVX6PHS//+L6FlFgD89dCJV6LXw//87w1mJBnUIagno4t///1lX/zbo29H/ /1mDxgRZA/04H3XJXf81uB5JAOhY8P//WYkduB5JAIkeX17HBaQxSQABAAAAW8NVi+xRUVMz 2zkdqDFJAFZXdQXooeP//748H0kAaAQBAABWU/8VCNFAAKHoM0kAiTUkH0kAi/44GHQCi/iN RfhQjUX8UFNTV+hNAAAAi0X4i038jQSIUOgV8P//i/CDxBg783UIagjoQN///1mNRfhQjUX8 UItF/I0EhlBWV+gXAAAAi0X8g8QUSIk1DB9JAF9eowgfSQBbycNVi+yLTRiLRRRTVoMhAIt1 EFeLfQzHAAEAAACLRQiF/3QIiTeDxwSJfQyAOCJ1RIpQAUCA+iJ0KYTSdCUPttL2guEySQAE dAz/AYX2dAaKEIgWRkD/AYX2dNWKEIgWRuvO/wGF9nQEgCYARoA4InVGQOtD/wGF9nQFihCI FkaKEEAPttr2g+EySQAEdAz/AYX2dAWKGIgeRkCA+iB0CYTSdAmA+gl1zITSdQNI6wiF9nQE gGb/AINlGACAOAAPhOAAAACKEID6IHQFgPoJdQNA6/GAOAAPhMgAAACF/3QIiTeDxwSJfQyL VRT/AsdFCAEAAAAz24A4XHUEQEPr94A4InUs9sMBdSUz/zl9GHQNgHgBIo1QAXUEi8LrA4l9 CIt9DDPSOVUYD5TCiVUY0euL00uF0nQOQ4X2dATGBlxG/wFLdfOKEITSdEqDfRgAdQqA+iB0 P4D6CXQ6g30IAHQuhfZ0GQ+22vaD4TJJAAR0BogWRkD/AYoQiBZG6w8PttL2guEySQAEdANA /wH/AUDpWP///4X2dASAJgBG/wHpF////4X/dAODJwCLRRRfXlv/AF3DUVGhQCBJAFNViy1k 0UAAVlcz2zP2M/87w3Uz/9WL8DvzdAzHBUAgSQABAAAA6yj/FWjRQACL+Dv7D4TqAAAAxwVA IEkAAgAAAOmPAAAAg/gBD4WBAAAAO/N1DP/Vi/A78w+EwgAAAGY5HovGdA5AQGY5GHX5QEBm ORh18ivGiz3Q0EAA0fhTU0BTU1BWU1OJRCQ0/9eL6DvrdDJV6ILt//87w1mJRCQQdCNTU1VQ /3QkJFZTU//XhcB1Dv90JBDoMO3//1mJXCQQi1wkEFb/FZzRQACLw+tTg/gCdUw7+3UM/xVo 0UAAi/g7+3Q8OB+Lx3QKQDgYdftAOBh19ivHQIvoVegb7f//i/BZO/N1BDP26wtVV1bo9dL/ /4PEDFf/FZjRQACLxusCM8BfXl1bWVnDg+xEU1VWV2gAAQAA6ODs//+L8FmF9nUIahvoDdz/ /1mJNaAwSQDHBaAxSQAgAAAAjYYAAQAAO/BzGoBmBACDDv/GRgUKoaAwSQCDxggFAAEAAOvi jUQkEFD/FXDRQABmg3wkQgAPhMUAAACLRCREhcAPhLkAAACLMI1oBLgACAAAO/CNHC58Aovw OTWgMUkAfVK/pDBJAGgAAQAA6FDs//+FwFl0OIMFoDFJACCJB42IAAEAADvBcxiAYAQAgwj/ xkAFCosPg8AIgcEAAQAA6+SDxwQ5NaAxSQB8u+sGizWgMUkAM/+F9n5GiwOD+P90NopNAPbB AXQu9sEIdQtQ/xVY0UAAhcB0HovHi8/B+AWD4R+LBIWgMEkAjQTIiwuJCIpNAIhIBEdFg8ME O/58ujPboaAwSQCDPNj/jTTYdU2F28ZGBIF1BWr2WOsKi8NI99gbwIPA9VD/FVzRQACL+IP/ /3QXV/8VWNFAAIXAdAwl/wAAAIk+g/gCdQaATgRA6w+D+AN1CoBOBAjrBIBOBIBDg/sDfJv/ NaAxSQD/FWDRQABfXl1bg8REwzPAagA5RCQIaAAQAAAPlMBQ/xVQ0UAAhcCjhDBJAHQV6IMK AACFwHUP/zWEMEkA/xVU0UAAM8DDagFYw8zMzFWL7FNWV1VqAGoAaESnQAD/dQjonhwAAF1f XluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0QkCItUJBCJArgDAAAAw1NWV4tEJBBQav5oTKdA AGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3QuO3QkJHQojTR2iwyziUwkCIlIDIN8swQA dRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxfXlvDM8Bkiw0AAAAAgXkETKdAAHUQ i1EMi1IMOVEIdQW4AQAAAMNTUbt0FEEA6wpTUbt0FEEAi00IiUsIiUMEiWsMWVvCBADMzFZD MjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4i0UQiUX8jUX4iUP8i3MM i3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT6Kn+//+DxASNaxBW U+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4AAAAAOscuAEA AADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ6Hn+//+D xAhdwgQAocAeSQCD+AF0DYXAdSqDPbQQQQABdSFo/AAAAOgYAAAAoUQgSQBZhcB0Av/QaP8A AADoAgAAAFnDVYvsgeykAQAAi1UIM8m4iBRBADsQdAuDwAhBPRgVQQB88VaL8cHmAzuWiBRB AA+FHAEAAKHAHkkAg/gBD4ToAAAAhcB1DYM9tBBBAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+ //9oBAEAAFBqAP8VCNFAAIXAdRONhVz+//9otNVAAFDos8n//1lZjYVc/v//V1CNvVz+///o jsr//0BZg/g8dimNhVz+//9Q6HvK//+L+I2FXP7//4PoO2oDA/hosNVAAFfo4QEAAIPEEI2F YP///2iU1UAAUOhdyf//jYVg////V1DoYMn//42FYP///2iQ1UAAUOhPyf///7aMFEEAjYVg ////UOg9yf//aBAgAQCNhWD///9oaNVAAFDoXxIAAIPELF/rJo1FCI22jBRBAGoAUP826O7J //9ZUP82avT/FVzRQABQ/xVs0EAAXsnDVYvsav9o0NVAAGgkqEAAZKEAAAAAUGSJJQAAAACD 7BhTVleJZeihSCBJADPbO8N1Po1F5FBqAV5WaEjSQABW/xVA0UAAhcB0BIvG6x2NReRQVmhE 0kAAVlP/FUTRQACFwA+EzgAAAGoCWKNIIEkAg/gCdSSLRRw7w3UFodQeSQD/dRT/dRD/dQz/ dQhQ/xVE0UAA6Z8AAACD+AEPhZQAAAA5XRh1CKHkHkkAiUUYU1P/dRD/dQyLRSD32BvAg+AI QFD/dRj/FczQQACJReA7w3RjiV38jTwAi8eDwAMk/OgU0P//iWXoi/SJddxXU1bolMf//4PE DOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91GP8VzNBAADvDdBD/dRRQVv91 CP8VQNFAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMzMzMzMzMzMzMzMzMyLTCQMV4XJdHpW U4vZi3QkFPfGAwAAAIt8JBB1B8HpAnVv6yGKBkaIB0dJdCWEwHQp98YDAAAAdeuL2cHpAnVR g+MDdA2KBkaIB0eEwHQvS3Xzi0QkEFteX8P3xwMAAAB0EogHR0kPhIoAAAD3xwMAAAB17ovZ wekCdWyIB0dLdfpbXotEJAhfw4kXg8cESXSvuv/+/n6LBgPQg/D/M8KLFoPGBKkAAQGBdN6E 0nQshPZ0HvfCAAD/AHQM98IAAAD/dcaJF+sYgeL//wAAiRfrDoHi/wAAAIkX6wQz0okXg8cE M8BJdAozwIkHg8cESXX4g+MDdYWLRCQQW15fw4tEJARTOwWgMUkAVldzc4vIi/DB+QWD5h+N PI2gMEkAweYDiw/2RDEEAXRWUOgSEQAAg/j/WXUMxwXsHkkACQAAAOtP/3QkGGoA/3QkHFD/ FZTQQACL2IP7/3UI/xXg0EAA6wIzwIXAdAlQ6PMPAABZ6yCLB4BkMAT9jUQwBIvD6xSDJfAe SQAAxwXsHkkACQAAAIPI/19eW8NVi+yB7BQEAACLTQhTOw2gMUkAVlcPg3kBAACLwYvxwfgF g+YfjRyFoDBJAMHmA4sDikQwBKgBD4RXAQAAM/85fRCJffiJffB1BzPA6VcBAACoIHQMagJX UegI////g8QMiwMDxvZABIAPhMEAAACLRQw5fRCJRfyJfQgPhucAAACNhez7//+LTfwrTQw7 TRBzKYtN/P9F/IoJgPkKdQf/RfDGAA1AiAhAi8iNlez7//8ryoH5AAQAAHzMi/iNhez7//8r +I1F9GoAUI2F7Pv//1dQiwP/NDD/FWzQQACFwHRDi0X0AUX4O8d8C4tF/CtFDDtFEHKKM/+L Rfg7xw+FiwAAADl9CHRfagVYOUUIdUzHBeweSQAJAAAAo/AeSQDpgAAAAP8V4NBAAIlFCOvH jU30V1H/dRD/dQz/MP8VbNBAAIXAdAuLRfSJfQiJRfjrp/8V4NBAAIlFCOuc/3UI6GQOAABZ 6z2LA/ZEMARAdAyLRQyAOBoPhM3+///HBeweSQAcAAAAiT3wHkkA6xYrRfDrFIMl8B5JAADH BeweSQAJAAAAg8j/X15bycP/BUwgSQBoABAAAOj+4v//WYtMJASFwIlBCHQNg0kMCMdBGAAQ AADrEYNJDASNQRSJQQjHQRgCAAAAi0EIg2EEAIkBw4tEJAQ7BaAxSQByAzPAw4vIg+AfwfkF iwyNoDBJAIpEwQSD4EDDoYAwSQBWahSFwF51B7gAAgAA6wY7xn0Hi8ajgDBJAGoEUOipDgAA WaN8IEkAhcBZdSFqBFaJNYAwSQDokA4AAFmjfCBJAIXAWXUIahrojdH//1kzybggFUEAixV8 IEkAiQQRg8Agg8EEPaAXQQB86jPSuTAVQQCLwovywfgFg+YfiwSFoDBJAIsE8IP4/3QEhcB1 A4MJ/4PBIEKB+ZAVQQB81F7D6JIPAACAPSwfSQAAdAXplQ4AAMNVi+yLRQiFwHUCXcODPdQe SQAAdRJmi00MZoH5/wB3OWoBiAhYXcONTQiDZQgAUWoA/zW8E0EAUI1FDGoBUGggAgAA/zXk HkkA/xXQ0EAAhcB0BoN9CAB0DccF7B5JACoAAACDyP9dw1NWi0QkGAvAdRiLTCQUi0QkEDPS 9/GL2ItEJAz38YvT60GLyItcJBSLVCQQi0QkDNHp0dvR6tHYC8l19Pfzi/D3ZCQYi8iLRCQU 9+YD0XIOO1QkEHcIcgc7RCQMdgFOM9KLxl5bwhAAzMzMzMzMzMxTi0QkFAvAdRiLTCQQi0Qk DDPS9/GLRCQI9/GLwjPS61CLyItcJBCLVCQMi0QkCNHp0dvR6tHYC8l19Pfzi8j3ZCQUkfdk JBAD0XIOO1QkDHcIcg47RCQIdggrRCQQG1QkFCtEJAgbVCQM99r32IPaAFvCEABoQAEAAGoA /zWEMEkA/xWQ0UAAhcCjeCBJAHUBw4MlcCBJAACDJXQgSQAAagGjbCBJAMcFZCBJABAAAABY w6F0IEkAjQyAoXggSQCNDIg7wXMUi1QkBCtQDIH6AAAQAHIHg8AU6+gzwMNVi+yD7BSLVQyL TQhTVotBEIvyK3EMi1r8g8L8V8HuD4vOi3r8ackEAgAAS4l9/I2MAUQBAACJXfSJTfCLDBP2 wQGJTfh1f8H5BGo/SV+JTQw7z3YDiX0Mi0wTBDtMEwh1SItNDIP5IHMcvwAAAIDT741MAQT3 1yF8sET+CXUri00IITnrJIPB4L8AAACA0++LTQyNTAEE99chvLDEAAAA/gl1BotNCCF5BItM EwiLfBMEiXkEi0wTBIt8EwgDXfiJeQiJXfSL+8H/BE+D/z92A2o/X4tN/IPhAYlN7A+FoAAA ACtV/ItN/MH5BGo/iVX4SVo7yolNDHYFiVUMi8oDXfyL+4ld9MH/BE87+nYCi/o7z3Rri034 i1EEO1EIdUiLTQyD+SBzHLoAAACA0+qNTAEE99IhVLBE/gl1K4tNCCER6ySDweC6AAAAgNPq i00MjUwBBPfSIZSwxAAAAP4JdQaLTQghUQSLTfiLUQiLSQSJSgSLTfiLUQSLSQiJSgiLVfiD fewAdQk5fQwPhIkAAACLTfCNDPmLSQSJSgSLTfCNDPmJSgiJUQSLSgSJUQiLSgQ7Sgh1Y4pM BwSD/yCITQ/+wYhMBwRzJYB9DwB1DrsAAACAi8/T64tNCAkZuwAAAICLz9PrjUSwRAkY6ymA fQ8AdRCNT+C7AAAAgNPri00ICVkEjU/gvwAAAIDT742EsMQAAAAJOItd9ItF8IkaiVwT/P8I D4X6AAAAoXAgSQCFwA+E3wAAAIsNaCBJAIs9TNFAAMHhDwNIDLsAgAAAaABAAABTUf/Xiw1o IEkAoXAgSQC6AAAAgNPqCVAIoXAgSQCLDWggSQCLQBCDpIjEAAAAAKFwIEkAi0AQ/khDoXAg SQCLSBCAeUMAdQmDYAT+oXAgSQCDeAj/dWxTagD/cAz/16FwIEkA/3AQagD/NYQwSQD/FYzR QAChdCBJAIsVeCBJAI0EgMHgAovIoXAgSQAryI1MEexRjUgUUVDoD8f//4tFCIPEDP8NdCBJ ADsFcCBJAHYDg+gUiw14IEkAiQ1sIEkA6wOLRQijcCBJAIk1aCBJAF9eW8nDVYvsg+wUoXQg SQCLFXggSQBTVo0EgFeNPIKLRQiJffyNSBeD4fCJTfDB+QRJg/kgfQ6Dzv/T7oNN+P+JdfTr EIPB4IPI/zP20+iJdfSJRfihbCBJAIvYO9+JXQhzGYtLBIs7I034I/4Lz3ULg8MUO138iV0I cuc7Xfx1eYvaO9iJXQhzFYtLBIs7I034I/4Lz3UFg8MU6+Y72HVZO138cxGDewgAdQiDwxSJ XQjr7Ttd/HUmi9o72IldCHMNg3sIAHUFg8MU6+472HUO6DgCAACL2IXbiV0IdBRT6NoCAABZ i0sQiQGLQxCDOP91BzPA6Q8CAACJHWwgSQCLQxCLEIP6/4lV/HQUi4yQxAAAAIt8kEQjTfgj /gvPdTeLkMQAAACLcEQjVfgjdfSDZfwAjUhEC9aLdfR1F4uRhAAAAP9F/CNV+IPBBIv+IzkL 13Tpi1X8i8oz/2nJBAIAAI2MAUQBAACJTfSLTJBEI851DYuMkMQAAABqICNN+F+FyXwF0eFH 6/eLTfSLVPkEiworTfCL8YlN+MH+BE6D/j9+A2o/Xjv3D4QNAQAAi0oEO0oIdWGD/yB9K7sA AACAi8/T64tN/I18OAT304ld7CNciESJXIhE/g91OItdCItN7CEL6zGNT+C7AAAAgNPri038 jXw4BI2MiMQAAAD30yEZ/g+JXex1C4tdCItN7CFLBOsDi10Ii0oIi3oEg334AIl5BItKBIt6 CIl5CA+ElAAAAItN9It88QSNDPGJegSJSgiJUQSLSgSJUQiLSgQ7Sgh1ZIpMBgSD/iCITQt9 Kf7BgH0LAIhMBgR1C78AAACAi87T7wk7vwAAAICLztPvi038CXyIROsv/sGAfQsAiEwGBHUN jU7gvwAAAIDT7wl7BItN/I28iMQAAACNTuC+AAAAgNPuCTeLTfiFyXQLiQqJTBH86wOLTfiL dfAD0Y1OAYkKiUwy/It19IsOhcmNeQGJPnUaOx1wIEkAdRKLTfw7DWggSQB1B4MlcCBJAACL TfyJCI1CBF9eW8nDoXQgSQCLDWQgSQBWVzP/O8F1MI1EiVDB4AJQ/zV4IEkAV/81hDBJAP8V ONFAADvHdGGDBWQgSQAQo3ggSQChdCBJAIsNeCBJAGjEQQAAagiNBID/NYQwSQCNNIH/FZDR QAA7x4lGEHQqagRoACAAAGgAABAAV/8VPNFAADvHiUYMdRT/dhBX/zWEMEkA/xWM0UAAM8Dr F4NOCP+JPol+BP8FdCBJAItGEIMI/4vGX17DVYvsUYtNCFNWV4txEItBCDPbhcB8BdHgQ+v3 i8NqP2nABAIAAFqNhDBEAQAAiUX8iUAIiUAEg8AISnX0i/tqBMHnDwN5DGgAEAAAaACAAABX /xU80UAAhcB1CIPI/+mTAAAAjZcAcAAAO/p3PI1HEINI+P+DiOwPAAD/jYj8DwAAx0D88A8A AIkIjYj87///iUgEx4DoDwAA8A8AAAUAEAAAjUjwO8p2x4tF/I1PDAX4AQAAagFfiUgEiUEI jUoMiUgIiUEEg2SeRACJvJ7EAAAAikZDisj+wYTAi0UIiE5DdQMJeAS6AAAAgIvL0+r30iFQ CIvDX15bycOhVCBJAIXAdA//dCQE/9CFwFl0BGoBWMMzwMNVi+xTVot1DDPbO/N0FTldEHQQ igY6w3UQi0UIO8N0A2aJGDPAXltdwzkd1B5JAHUTi00IO8t0B2YPtsBmiQFqAVjr4YsNsBFB AA+2wPZEQQGAdE2hvBNBAIP4AX4qOUUQfC8zyTldCA+VwVH/dQhQVmoJ/zXkHkkA/xXM0EAA hcChvBNBAHWdOUUQcgU4XgF1k8cF7B5JACoAAACDyP/rhDPAOV0ID5XAUP91CGoBVmoJ/zXk HkkA/xXM0EAAhcAPhXn////ryszMzMzMzMzMzMzMzMzMzItEJAiLTCQQC8iLTCQMdQmLRCQE 9+HCEABT9+GL2ItEJAj3ZCQUA9iLRCQI9+ED01vCEADMzMzMzMzMzMzMzMyA+UBzFYD5IHMG D6XC0+DDi9AzwIDhH9PiwzPAM9LDVot0JAiLRgyogw+ExAAAAKhAD4W8AAAAqAJ0CgwgiUYM 6a4AAAAMAWapDAGJRgx1CVbov/P//1nrBYtGCIkG/3YY/3YI/3YQ6M4EAACDxAyJRgSFwHRs g/j/dGeLVgz2woJ1NItOEFeD+f90FIv5wf8Fg+Efizy9oDBJAI08z+sFv2gUQQCKTwRfgOGC gPmCdQaAziCJVgyBfhgAAgAAdRSLTgz2wQh0DPbFBHUHx0YYABAAAIsOSIlGBA+2AUGJDl7D 99gbwIPgEIPAEAlGDINmBACDyP9ew1OLXCQIg/v/VnRBi3QkEItGDKgBdQiogHQyqAJ1LoN+ CAB1B1bo8/L//1mLBjtGCHUJg34EAHUUQIkG9kYMQHQR/w6LBjgYdA9AiQaDyP9eW8P/DosG iBiLRgz/RgQk7wwBiUYMi8Ml/wAAAOvhagRqAP90JAzoBAAAAIPEDMMPtkQkBIpMJAyEiOEy SQB1HIN8JAgAdA4PtwRFuhFBACNEJAjrAjPAhcB1AcNqAVjDUzPbOR1YIEkAVld1QmgM1kAA /xUo0UAAi/g7+3RnizUs0UAAaADWQABX/9aFwKNYIEkAdFBo8NVAAFf/1mjc1UAAV6NcIEkA /9ajYCBJAKFcIEkAhcB0Fv/Qi9iF23QOoWAgSQCFwHQFU//Qi9j/dCQY/3QkGP90JBhT/xVY IEkAX15bwzPA6/iLTCQEM9KJDfAeSQC40BdBADsIdCCDwAhCPTgZQQB88YP5E3Idg/kkdxjH BeweSQANAAAAw4sE1dQXQQCj7B5JAMOB+bwAAAByEoH5ygAAAMcF7B5JAAgAAAB2CscF7B5J ABYAAADDi0wkBFY7DaAxSQBXc1WLwYvxwfgFg+YfjTyFoDBJAMHmA4sHA8b2QAQBdDeDOP90 MoM9tBBBAAF1HzPAK8h0EEl0CEl1E1Bq9OsIUGr16wNQavb/FTTRQACLB4MMMP8zwOsUgyXw HkkAAMcF7B5JAAkAAACDyP9fXsOLRCQEOwWgMUkAcxyLyIPgH8H5BYsMjaAwSQD2RMEEAY0E wXQDiwDDgyXwHkkAAMcF7B5JAAkAAACDyP/DU1aLdCQMVw+vdCQUg/7gi953DYX2dQNqAV6D xg+D5vAz/4P+4HcqOx3AF0EAdw1T6JX2//+L+FmF/3UrVmoI/zWEMEkA/xWQ0UAAi/iF/3Ui gz1QIEkAAHQZVugf+///hcBZdBTruVNqAFfoQbT//4PEDIvHX15bwzPA6/hWV2oDM/9eOTWA MEkAfkShfCBJAIsEsIXAdC/2QAyDdA1Q6D0DAACD+P9ZdAFHg/4UfBehfCBJAP80sOjo0v// oXwgSQBZgySwAEY7NYAwSQB8vIvHX17DVot0JAiF9nUJVuiRAAAAWV7DVugjAAAAhcBZdAWD yP9ew/ZGDUB0D/92EOgyAwAA99hZXhvAwzPAXsNTVot0JAwz21eLRgyLyIPhA4D5AnU3ZqkI AXQxi0YIiz4r+IX/fiZXUP92EOjY7f//g8QMO8d1DotGDKiAdA4k/YlGDOsHg04MIIPL/4tG CINmBACJBl+Lw15bw2oB6AIAAABZw1NWVzP2M9sz/zk1gDBJAH5NoXwgSQCLBLCFwHQ4i0gM 9sGDdDCDfCQQAXUPUOgu////g/j/WXQdQ+sag3wkEAB1E/bBAnQOUOgT////g/j/WXUCC/hG OzWAMEkAfLODfCQQAYvDdAKLx19eW8NqAugmwf//WcNVi+yD7AxTVot1CFc7NaAxSQAPg8UB AACLxoPmH8H4BcHmA40chaAwSQCLBIWgMEkAA8aKUAT2wgEPhJ4BAACDZfgAi30Mg30QAIvP dGf2wgJ1YvbCSHQdikAFPAp0Fv9NEIgHiwONTwHHRfgBAAAAxkQwBQqNRfRqAFCLA/91EFH/ NDD/FXDQQACFwHU6/xXg0EAAagVZO8F1FccF7B5JAAkAAACJDfAeSQDpPgEAAIP4bXUHM8Dp NQEAAFDoNfz//1npJgEAAIsDi1X0AVX4jUwwBIpEMASogA+E+AAAAIXSdAmAPwp1BAwE6wIk +4gBi0UMi034iUUQA8g7wYlN+A+DywAAAItFEIoAPBoPhK4AAAA8DXQLiAdH/0UQ6ZEAAABJ OU0QcxiLRRBAgDgKdQaDRRAC617GBw1HiUUQ63ONRfRqAFD/RRCNRf9qAVCLA/80MP8VcNBA AIXAdQr/FeDQQACFwHVHg330AHRBiwP2RDAESHQTikX/PAp0F8YHDYsLR4hEMQXrKTt9DHUL gH3/CnUFxgcK6xhqAWr//3UI6O3q//+DxAyAff8KdATGBw1Hi034OU0QD4JH////6xCLA410 MASKBqhAdQQMAogGK30MiX34i0X46xSDJfAeSQAAxwXsHkkACQAAAIPI/19eW8nDVot0JAhX g8//i0YMqEB0BYPI/+s6qIN0NFboEP3//1aL+Og5AQAA/3YQ6H4AAACDxAyFwH0Fg8//6xKL RhyFwHQLUOh8z///g2YcAFmLx4NmDABfXsOLRCQEOwWgMUkAcz2LyIvQwfkFg+IfiwyNoDBJ APZE0QQBdCVQ6GL7//9ZUP8VoNFAAIXAdQj/FeDQQADrAjPAhcB0EqPwHkkAxwXsHkkACQAA AIPI/8NTVVZXi3wkFDs9oDFJAA+DhgAAAIvHi/fB+AWD5h+NHIWgMEkAweYDiwP2RDAEAXRp V+j++v//g/j/WXQ8g/8BdAWD/wJ1FmoC6Of6//9qAYvo6N76//9ZO8VZdBxX6NL6//9ZUP8V JNFAAIXAdQr/FeDQQACL6OsCM+1X6Dr6//+LA1mAZDAEAIXtdAlV6MH5//9Z6xUzwOsUgyXw HkkAAMcF7B5JAAkAAACDyP9fXl1bw1aLdCQIi0YMqIN0HagIdBn/dgjoTM7//2aBZgz3+zPA WYkGiUYIiUYEXsPMzMzMzP8lsNFAAP8lrNFAAP8lqNFAAP8lSNFAAFWL7FGh1B5JAFMz2zvD iV38dSGLRQiL0DgYdH+KCoD5YXwKgPl6fwWA6SCICkI4GnXq62dWV2oBU1NTav++AAIAAP91 CFZQ6O3B//+L+IPEIDv7dDhX6PDN//87w1mJRfx0KmoBU1dQav//dQhW/zXUHkkA6MDB//+D xCCFwHQN/3X8/3UI6P2u//9ZWf91/OiHzf//i0UIWV9eW8nDzMzMzMzMzMzMzFWL7FdWU4tN EAvJD4SVAAAAi3UIi30MjQXMHkkAg3gIAHVDt0GzWrYgjUkAiiYK5IoHdCEKwHQdRkc4/HIG ONx3AgLmOPhyBjjYdwICxjjEdQlJddczyTjEdEu5/////3JE99nrQDPAM9uL/4oGC8CKH3Qj C9t0H0ZHUVBT6Nyx//+L2IPEBOjSsf//g8QEWTvDdQlJddUzyTvDdAm5/////3IC99mLwVte X8nDzMzMVYvsV1ZTi3UMi30IjQXMHkkAg3gIAHU7sP+L/wrAdC6KBkaKJ0c4xHTyLEE8GhrJ gOEgAsEEQYbgLEE8GhrJgOEgAsEEQTjgdNIawBz/D77A6zS4/wAAADPbi/8KwHQnigZGih9H ONh08lBT6D2x//+L2IPEBOgzsf//g8QEOMN02hvAg9j/W15fycNVi+xRodQeSQBTM9s7w4ld /HUhi0UIi9A4GHR/igqA+UF8CoD5Wn8FgMEgiApCOBp16utnVldqAVNTU2r/vgABAAD/dQhW UOgJwP//i/iDxCA7+3Q4V+gMzP//O8NZiUX8dCpqAVNXUGr//3UIVv811B5JAOjcv///g8Qg hcB0Df91/P91COgZrf//WVn/dfzoo8v//4tFCFlfXlvJwwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHDcAACg3QAAiN0AAHjdAABm3QAAUt0AAELdAAAs3QAAGN0AAALdAADm3AAA2twAANDc AACy3AAAotwAAI7cAABe3AAATNwAADbcAAAm3AAAFNwAAAbcAAD42wAA6tsAAAAAAAAk2gAA MNoAAELaAABO2gAAWtoAAG7aAAB+2gAAjNoAAKLaAACu2gAAvtoAANDaAADg2gAAENoAAADb AAAO2wAAHtsAADDbAABG2wAAWtsAAGrbAAB42wAAjtsAAKDbAAC82wAAzNsAAPrZAADk2QAA ztkAAMDZAAC02QAApNkAAJTZAACC2QAAYNgAAHTZAABm2QAAUNkAAEDZAAAu2QAAHtkAAAjZ AADs2AAA3NgAAM7YAAC62AAAptgAAJ7YAACQ2AAAgNgAAG7YAADy2gAAxt8AALjfAACo3wAA lt8AAITfAAB43wAAat8AAFzfAABO3wAAQN8AADDfAAAe3wAABN8AAOzeAAAO3gAAIt4AADTe AABC3gAATt4AAFjeAABk3gAAdN4AAITeAACQ3gAAnN4AALjeAADS3gAA1t8AAAAAAAD23QAA 4t0AANLdAAAAAAAANAAAgAMAAIB0AACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACAEAAAgAAA AAAAAAAAAAAAAAUAAAAAAAAABwAAAAkAAAAFAAAAAgAAAAIAAAACAAAAAgAAAAwAGQABAAEA AgAOAAoAHwAEAAEAAwAZAAgADwACAAIACwACAAEABgD/////T4FAAGOBQAAAAAAAAAAAAAAA AAD/////MYdAADWHQAD/////5YdAAOmHQAAGAAAGAAEAABAAAwYABgIQBEVFRQUFBQUFNTAA UAAAAAAgKDhQWAcIADcwMFdQBwAAICAIAAAAAAhgaGBgYGAAAHBweHh4eAgHCAAABwAICAgA AAgACAAHCAAAACgAbgB1AGwAbAApAAAAAAAobnVsbCkAAHJ1bnRpbWUgZXJyb3IgAAANCgAA VExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAAAABET01BSU4gZXJyb3INCgAAUjYwMjgN Ci0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAAAFI2MDI3DQotIG5vdCBlbm91Z2gg c3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAAUjYwMjYNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNQ0KLSBwdXJlIHZp cnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Ig X29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8gb3BlbiBjb25z b2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0KAAAAAFI2 MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2DQot IG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJv bm1lbnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2 MDAyDQotIGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFs IEMrKyBSdW50aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAA AAAuLi4APHByb2dyYW0gbmFtZSB1bmtub3duPgAAAAAAAP////+Bq0AAhatAAEdldExhc3RB Y3RpdmVQb3B1cAAAR2V0QWN0aXZlV2luZG93AE1lc3NhZ2VCb3hBAHVzZXIzMi5kbGwAAODW AAAAAAAAAAAAANzbAABk0AAAfNYAAAAAAAAAAAAAuN0AAADQAAA02AAAAAAAAAAAAADG3QAA uNEAACTYAAAAAAAAAAAAAAbeAACo0QAAAAAAAAAAAAAAAAAAAAAAAAAAAABw3AAAoN0AAIjd AAB43QAAZt0AAFLdAABC3QAALN0AABjdAAAC3QAA5twAANrcAADQ3AAAstwAAKLcAACO3AAA XtwAAEzcAAA23AAAJtwAABTcAAAG3AAA+NsAAOrbAAAAAAAAJNoAADDaAABC2gAATtoAAFra AABu2gAAftoAAIzaAACi2gAArtoAAL7aAADQ2gAA4NoAABDaAAAA2wAADtsAAB7bAAAw2wAA RtsAAFrbAABq2wAAeNsAAI7bAACg2wAAvNsAAMzbAAD62QAA5NkAAM7ZAADA2QAAtNkAAKTZ AACU2QAAgtkAAGDYAAB02QAAZtkAAFDZAABA2QAALtkAAB7ZAAAI2QAA7NgAANzYAADO2AAA utgAAKbYAACe2AAAkNgAAIDYAABu2AAA8toAAMbfAAC43wAAqN8AAJbfAACE3wAAeN8AAGrf AABc3wAATt8AAEDfAAAw3wAAHt8AAATfAADs3gAADt4AACLeAAA03gAAQt4AAE7eAABY3gAA ZN4AAHTeAACE3gAAkN4AAJzeAAC43gAA0t4AANbfAAAAAAAA9t0AAOLdAADS3QAAAAAAADQA AIADAACAdAAAgBMAAIAJAACABAAAgG8AAIBzAACAFwAAgBAAAIAAAAAAtABGcmVlTGlicmFy eQA+AUdldFByb2NBZGRyZXNzAADCAUxvYWRMaWJyYXJ5QQAAGwBDbG9zZUhhbmRsZQCWAlNs ZWVwAJ4CVGVybWluYXRlUHJvY2VzcwAAHAJSZWFkUHJvY2Vzc01lbW9yeQDvAU9wZW5Qcm9j ZXNzANkBTW9kdWxlMzJGaXJzdABMAENyZWF0ZVRvb2xoZWxwMzJTbmFwc2hvdAAAJAFHZXRN b2R1bGVGaWxlTmFtZUEAAP4BUHJvY2VzczMyTmV4dAD8AVByb2Nlc3MzMkZpcnN0AADWAU1h cFZpZXdPZkZpbGUANQBDcmVhdGVGaWxlTWFwcGluZ0EAABIBR2V0RmlsZVNpemUANABDcmVh dGVGaWxlQQCwAlVubWFwVmlld09mRmlsZQAbAUdldExvY2FsVGltZQAAGgFHZXRMYXN0RXJy b3IAAMwBTG9jYWxGcmVlAMgBTG9jYWxBbGxvYwAA+ABHZXRDdXJyZW50UHJvY2Vzc0lkANIC V2lkZUNoYXJUb011bHRpQnl0ZQDkAU11bHRpQnl0ZVRvV2lkZUNoYXIAzgBHZXRDb21wdXRl ck5hbWVBAAAoAENvcHlGaWxlQQC5AUlzREJDU0xlYWRCeXRlAADfAldyaXRlRmlsZQAYAlJl YWRGaWxlAABjAUdldFRlbXBGaWxlTmFtZUEAAGUBR2V0VGVtcFBhdGhBAABXAERlbGV0ZUZp bGVBAGgCU2V0RmlsZUF0dHJpYnV0ZXNBAACQAEZpbmRDbG9zZQCdAEZpbmROZXh0RmlsZUEA lABGaW5kRmlyc3RGaWxlQQAAYQJTZXRFbmRPZkZpbGUAAGoCU2V0RmlsZVBvaW50ZXIAABQB R2V0RmlsZVRpbWUAbAJTZXRGaWxlVGltZQBtAUdldFRpY2tDb3VudAAARABDcmVhdGVQcm9j ZXNzQQAAWQFHZXRTeXN0ZW1EaXJlY3RvcnlBAPcAR2V0Q3VycmVudFByb2Nlc3MAdQFHZXRW ZXJzaW9uRXhBAHQBR2V0VmVyc2lvbgAAzgJXYWl0Rm9yU2luZ2xlT2JqZWN0AMoAR2V0Q29t bWFuZExpbmVBAIAARXhwYW5kRW52aXJvbm1lbnRTdHJpbmdzQQAEAUdldERyaXZlVHlwZUEA SgBDcmVhdGVUaHJlYWQAAEtFUk5FTDMyLmRsbAAAWwFSZWdDbG9zZUtleQBmAVJlZ0VudW1L ZXlBAHEBUmVnT3BlbktleUEAZAFSZWdEZWxldGVWYWx1ZUEAagFSZWdFbnVtVmFsdWVBADQA Q2xvc2VTZXJ2aWNlSGFuZGxlAABMAENyZWF0ZVNlcnZpY2VBAABFAU9wZW5TQ01hbmFnZXJB AACzAVN0YXJ0U2VydmljZUN0cmxEaXNwYXRjaGVyQQCuAVNldFNlcnZpY2VTdGF0dXMAAEcB T3BlblNlcnZpY2VBAACOAVJlZ2lzdGVyU2VydmljZUN0cmxIYW5kbGVyQQCdAEZyZWVTaWQA mABFcXVhbFNpZAAAGABBbGxvY2F0ZUFuZEluaXRpYWxpemVTaWQAANAAR2V0VG9rZW5JbmZv cm1hdGlvbgBCAU9wZW5Qcm9jZXNzVG9rZW4AAFwBUmVnQ29ubmVjdFJlZ2lzdHJ5QQCyAVN0 YXJ0U2VydmljZUEAewFSZWdRdWVyeVZhbHVlRXhBAACGAVJlZ1NldFZhbHVlRXhBAABeAVJl Z0NyZWF0ZUtleUEAFwBBZGp1c3RUb2tlblByaXZpbGVnZXMA9QBMb29rdXBQcml2aWxlZ2VW YWx1ZUEAQURWQVBJMzIuZGxsAABXUzJfMzIuZGxsAAARAFdOZXRDbG9zZUVudW0AHABXTmV0 RW51bVJlc291cmNlQQBAAFdOZXRPcGVuRW51bUEATVBSLmRsbAAmAUdldE1vZHVsZUhhbmRs ZUEAAFABR2V0U3RhcnR1cEluZm9BAH0ARXhpdFByb2Nlc3MAvwBHZXRDUEluZm8AuQBHZXRB Q1AAADEBR2V0T0VNQ1AAAL8BTENNYXBTdHJpbmdBAADAAUxDTWFwU3RyaW5nVwAAnwFIZWFw RnJlZQAAmQFIZWFwQWxsb2MArQJVbmhhbmRsZWRFeGNlcHRpb25GaWx0ZXIAALIARnJlZUVu dmlyb25tZW50U3RyaW5nc0EAswBGcmVlRW52aXJvbm1lbnRTdHJpbmdzVwAGAUdldEVudmly b25tZW50U3RyaW5ncwAIAUdldEVudmlyb25tZW50U3RyaW5nc1cAAG0CU2V0SGFuZGxlQ291 bnQAAFIBR2V0U3RkSGFuZGxlAAAVAUdldEZpbGVUeXBlAJ0BSGVhcERlc3Ryb3kAmwFIZWFw Q3JlYXRlAAC/AlZpcnR1YWxGcmVlAC8CUnRsVW53aW5kAFMBR2V0U3RyaW5nVHlwZUEAAFYB R2V0U3RyaW5nVHlwZVcAALsCVmlydHVhbEFsbG9jAACiAUhlYXBSZUFsbG9jAHwCU2V0U3Rk SGFuZGxlAACqAEZsdXNoRmlsZUJ1ZmZlcnMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB7hUAAj69AAAAAAAAAAAAANLBAAAAAAAAAAAAAAAAAAAAAAAAP/UAAQAAAACAA AAAsAAAALS0AAFwAAABRVUlUDQoAAA0KLg0KAAAAREFUQSANCgBIRUxPICVzDQoAAAA+DQoA TUFJTCBGUk9NOiA8AAAAAFJDUFQgVE86PAAAACVkAAAgCQ0KAAAAAC4sKCklJEAhYH4gAC1f AAAuLgAALgAAAFwqLioAAAAAXFwAAAAAAACJFXfvMxmZeBBYuMnymQAABz9W/AeEJiUkH46I CYWJDouPKI0NhT+HhY2NCB8LjQmLAyiOiIkoC4o/g4+Djx+EDI4ojoiJKAWEP48FiAIfJqOn pygIjQU/jwgFix8LjQmLAyiOiIkoC4o/jAaPBwsfC40JiwMojoiJKAuKP4YFBo2NBR8EjQaL AogIKAiNBT+GjwiLHyajp6coCI0FP4aPCAWFBggfBI0GiwKICCgIjQU/jwgNgx8EjQaLAogI KAiNBT8JiwUFCY0fC4sFjQkoCI0FP4yLjIsfC40JiwMojoiJKAuKPw6NBR8LjQmLAyiOiIko C4o/CYsJgx8jI4SLCCiOiIk/hoUIHwSNBosCiAgoCI0FPwmLCA2PHwSNBosCiAgoCI0FPwaP i4aNH4QMjiiOiIkoBYQ/Bo+LCAaPiwiJjwgfC4gIjIqICIwojoiJP4qPBo8Jjx8LiAiMiogI jCiOiIk/ho+JiYOOC40IH4QMjiiOiIkoBYQ/DAmDhIsIDR+EDI4ojoiJKAWEP4aFjoofhAyO KI6IiSgFhD+FBgmIBI0fhAyOKI6IiSgFhD8FhQWFHyMjhIsIKI6IiT+OC42FHyajp6coCI0F PwODAh8mo6enKAiNBT8HjQUfJqOnpygIjQU/jIsGCR+NDYsGjY4FpyQjKI6IiT8JiwUFCY2O jwUfC4gIjIqICIwojoiJPwePCIYLhYyPCIwfjguLCI2GjSiOiIk/B4sHBYsfJqeOCCiOiIk/ jo0GBQePhoYfJqeOCCiOiIk/B4iEjQYLjQaIHyYkpigIjQU/nhakJiSjnhsfBY0GBo8ojYY/ FpUenRiWmBWYn5yVmx8FjQYGjyiNhj+fnp+ZHRYfBY0GBo8ojYY/iAmpB40FjY4LHwWNBgaP KI2GPxaYlp8Yn5mYGRWYHwWNBgaPKI2GPwaPhQmGjwiGjYyIBIuPHwWNBgaPKI2GPwuNBokf iAmNKI6IiT8KCSgEjwKHhY0CH48Jjo+JB4gojYY/DQQNHw0EDakNi4YFBosOhY6LiAiNhiiO iIk/BIsNjYipjogIhogJj4YfBY0GBo8ojYY/jQaLih+EhAWLjoqNBSiOiIk/Bo+GHwaNjoMI jQUojoiJP4aPCY2GH4aLB42OKI6IiT+PjAaNho8fBY0GBo8ojYY/CYsNi4+Qj4yNCI8fB4iO AgWPKIgIjQUoBwk/io8Kj5CJjwaOiwgfjIgmKAcJPwKPBgKPDR8CiY0GKI6IiSgHCT8MhQYI jQkfB4gJDogDKAcJP4+MjQiOgx+FCIuKjwUFBo8EjQkojoiJKAcJP4+KBYsEpx8HiAkOiAMo joiJPwuICYsNj4MfB4goiAiNBSgHCT8LB4aIDAUfB4gJDogDKI6IiT+LhI+GAoqIHyYIKAcJ P4qIBgiNCSanHyaOiIkoBwk/iY8KiAYfB4gHCI0FKAcJP4QOi4UGiB+EiAgNjQYJjwgNhiiO CI0FKAcJPwmPhgUGjx8HiAkOiAMojoiJKAcJP42KiAWFBh+ICYYCBYMIjYoojoiJKAcJPwuL hgIHjwgmJycnHweIjgIFjyiICI0FKAcJPwoGhogJBYUGH4qKiyiKBo+KiIQoBwk/DgcKhQSN CAWFhh8HiI4CBY8oiAiNBSgHCT8OB4qICYWJDh+KCSiICI0FKAcJPwuNHwuNKAcJPw4FkAWN jgKPkAUGAo0OiwiLjx8HiI4CBY8oiAiNBSgHCT+LCAWIhQYfiwgFiIUGqQ6NhoqLDYMojoiJ KAcJP4yIDQmFHweICQ6IAyiOiIk/DouFBogfBQaPCIaJi4aGi4gIKI6IiSgHCT8OBY+Kjo2G HweIjgIFjyiICI0FKAcJPwcGAo2JjYqGBY+Gi4+KHweIjgIFjyiICI0FKAcJPwaPDIuKJSak HweIjgIFjyiICI0FKAcJPwaNiosIiYsGHweIjgIFjyiICI0FKAcJP48JjogFiIUGhh+LiY+L CQ6IAyiOiIk/jwgFjwmNih+PCAWPCY2KKAcJPwcGiAiIBIWGHwKPB4uGKAiNBSgHCT8OjwaK iIYFJR8HiI4CBY8oiAiNBSgHCT+PBQ4HHweIjgIFjyiICI0FKAcJPw4OCQUNH4wNKIgIjQUo Bwk/DgUfDouNhgKOAo8NgyiIBowoBwk/jQWNhQaIHw6IAyWmKAcJP48EjR+Jj4YojoiJKAcJ P4iKi40JjgKDih8HiI4CBY8oiAiNBSgHCT+EjwiNhoaPpx8HiI4CBY8oiAiNBSgHCT8OjwiP hgKNiiiOjQgFBo8Jjx8LiAmLDY+DhigHCT+Ei42Gi42KkIwGAoMOiISGiosfB4iOAgWPKIgI jQUoBwk/iwiEigaFih8HiI4CBY8oiAiNBSgHCT8MhQYIjQ2Fih8HiAkOiAMoBwk/CI0Fi4WG HwiNBYuFhigHCT8OBQaPBI0JH4qICAWIKAcJPw6IjguIHw6IjguIKI6IiSgHCT+PCYqICAKJ H4yIJigHCT8OjYYFBYiFBh8HiI4CBY8oiAiNBSgHCT+EjwkNi4mNAx8HiAkOiAMojoiJPwqK BogJH4yIJigHCT+JjIsIiB8HiI4CBY8oiAiNBSgHCT+OjQgFBoWJBYUGHweIjgIFjyiICI0F KAcJP4YFDouFBogfB4iOAgWPKIgIjQUoBwk/hogJBYUGH4qKiyiKBo+KiIQoBwk/hIOGiI6K j48fB4iOAgWPKIgIjQUoBwk/io8JiI6LCIaKjx8HiI4CBY8oiAiNBSgHCT8IiwkHiAkfCIsJ B4gJKI6IiSgHCT+LiQeNAwWIhQYfCIYoiAiNBSgHCT8OhQaKhYYCH4gHjwkoiwgMiCgHCT8O j4QNi4kfDouNhgKOAo8NgyiOiIkoBwk/iY8GjwWICAUGjwSNCR8HiI4CBY8oiAiNBSgHCT+J hgKOAo0HjwgmJyenHweIjgIFjyiICI0FKAcJP42FBogoByiPHwcGiASLDY0GKAcJPwcGi4mP B4gJiAYOi4YfjAaICI0FKAcJP4mICI8fCYiIAiiOiIkoBwk/CoUGjYqQAh8HiI4CBY8oiAiN BSgHCT+EjwYJiIeFjR+IJigHCT+PCY8Oj4mPBYiFBh8HiI4CBY8oiAiNBSgHCT8OBosFjo8G Hw4GiwWOjwYojoiJKAcJPwmPho8IBY0fB4gJDogDKI6IiT+MCYgOiIaGH4qPBYiEi46NKIkF CSgHCT8FBo+KBR8FBo+KBSiOiIkoBwk/DoUFkISLjAaPHweIjgIFjyiICI0FKAcJP46FCY8K jwaIHweIjgIFjyiICI0FKAcJPwyLCI8Iho0fjYUGiAeNCoaKi40ojoiJKAcJP4SICgWNiqkI iwaPAx8FCY0IKAcJP4sIDIgfjQiNBoyIiYgIBY8CKI6IiSgHCT+FBg6PhouKHweIjgIFjyiI CI0FKAcJPwuPCI+nJh8HiI4CBY8oiAiNBSgHCT8LjwiPJqQfB4iOAgWPKIgIjQUoBwk/jQkJ jQgfhY8FKI6IiSgFhD8KiI0JjY0fhY8FKI6IiSgFhD8KjguPCIwfB48IiwgFCSiOiIk/io+D iB+FCY6IjwUojoiJP5kJi4UfB48IiwgFCSiOiIk/jw2JiwgfB48IiwgFCSiOiIk/B4uFjQiM Bh8HjwiLCAUJKI6IiT+KDYaFCIwfB48IiwgFCSiOiIk/C42PBI0IAguPiB8mp44IKI6IiT8H homGHwuFj4SNiyiOiIk/E5OWlRcXmBYVHxuVn5SdmyiemJk/jIWIDYgIjIYLjQiMHwuFj4SN iyiOiIk/AygNKAmNjR8LhY+EjYsojoiJPwqLCIwJix8LhY+EjYsojoiJPw2EiYsIjB8LhY+E jYsojoiJPwmLjguPCIwKhQgfC4WPhI2LKI6IiT8JiyiMKAsfC4WPhI2LKI6IiT+MBYwfC4WP hI2LKI6IiT+JhyiMhY8IHwuFj4SNiyiOiIk/DYWEjQgFj4gfC4WPhI2LKI6IiT+HiwiMA4Qf C4WPhI2LKI6IiT8JCYyHHwuFj4SNiyiOiIk/DI0IjImLCIwfC4WPhI2LKI6IiT8MhguDHwuF j4SNiyiOiIk/CYuPiIOICIwfC4WPhI2LKI6IiT+GCo4LjwiMHwuFj4SNiyiOiIk/AoMMjYsf C4WPhI2LKI6IiT8LhIyFjwiMHwuFj4SNiyiOiIk/g48IjAmLh4UIHwuFj4SNiyiOiIk/CYuO Dh8LhY+EjYsojoiJPwmPCAOLCoUIHwuFj4SNiyiOiIk/AguFiIOFHwuFj4SNiyiOiIk/joaE jQgfC4WPhI2LKI6IiT8HjwgIiwiMHwuFj4SNiyiOiIk/AguIhQ2PiAuFix8LhY+EjYsojoiJ PwILhYYLjwgNiwiMHwuFj4SNiyiOiIk/hI8IjAePCB8LhY+EjYsojoiJPwyPCIyOC4UIDI8f C4WPhI2LKI6IiT8MjQiMA4uPiIyFjwiMHwuFj4SNiyiOiIk/CYuFjguFCA6IHwuFj4SNiyiO iIk/DogOj4sfC4WPhI2LKI6IiT8Ji44LhQgDi4+IHwuFj4SNiyiOiIk/hI8IjAuFiwwCHwuF j4SNiyiOiIk/BoWPCIqPiwmLHwuFj4SNiyiOiIk/hIUJiwuFjx8LhY+EjYsojoiJPwmLhYOF DI0IjB8LhY+EjYsojoiJPwmLCIOICIwJgx8LhY+EjYsojoiJP4eLhYSNi4mLCB8LhY+EjYso joiJP4OPCIyHi48IjB8LhY+EjYsojoiJPwmGCx8LhY+EjYsojoiJP4SPCIwKi4+Kj4sfC4WP hI2LKI6IiT8Ji4UDiwiJiwgfC4WPhI2LKI6IiT+HiwgDDR8LhY+EjYsojoiJP4YLi4OICIyO C4UIHwuFj4SNiyiOiIk/h4sIC4gIjIOLHwuFj4SNiyiOiIk/C4UChYiOjwiMHwuFj4SNiyiO iIk/CQIFHwuFj4SNiyiOiIk/h4uFA4sIB4sIjB8LhY+EjYsojoiJPwqLCIqPix8LhY+EjYso joiJPwsKhQgfC4WPhI2LKI6IiT+EjYsKHwuFj4SNiyiOiIk/hguLj4kfC4WPhI2LKI6IiT8L hguNCIwfC4WPhI2LKI6IiT+DjwiMg48IhgIfC4WPhI2LKI6IiT+Ji44Lj40JKAOFHwuFj4SN iyiOiIk/C4UKi48IHwuFj4SNiyiOiIk/AguPCIwLjwiHiwiMHwuFj4SNiyiOiIk/hI8IjAqL jwiMCIsIjB8LhY+EjYsojoiJPwILjwiMjo8IHwuFj4SNiyiOiIk/A4uNC4gIjAWPiB8LhY+E jYsojoiJP4OFA4uPiA6LCB8LhY+EjYsojoiJPwmLg4gIjAmDHwuFj4SNiyiOiIk/hI8IjIOL CAWPCIwfC4WPhI2LKI6IiT+DhQOFHwuFj4SNiyiOiIk/DYsIjI4LjQiMg4sfC4WPhI2LKI6I iT+GC4+IiYsIjAOLCIwfC4WPhI2LKI6IiT8/Pz8/Pz8/Pz8/Pz8/IhEXBoiMBo+JLxyLCY2G EReIhI0GF4iLCAUvFIuNhI0GERcXFJudlKYmKI6JCD+dKIsEiD8/KAaNiD8FKAMJhj+LAwM/ io8/BY0GCI0FEZuelJiYHp0oio6PPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/P4kHIz8ojQONPyiGjgY/KAeLDD8oDo8FPz8/ Pz8/Pz8/Pz8/PygFAwU/KAsFiT8oCwWJCT8ohI8OPygNiI4/KAMJhj8oCgeMPyiOBwc/KI4/ KAePhj8oiQeMPyiJB42MPygOj4o/KIkHpj8/P5aIDAWEjwaNEZmLjgaIhogMBRGUiwgNiISG EZ6FBgaNCAUUjQaGi4gIET+fBwcvF48FC4Y/FoUIPxaFCJgIjo0/loOGBY2JEZ6FBgaNCAWe iAgFBogJlo0FEZaNBgSLjo2GP5aIDAWEjwaNEZmLjgaIhogMBRGUnx4RlJ8eJRGUjw4vHIsJ jS8Yj4mNPxaFCJaNBgSLjo2GP5sIBY0GCI0FL5aNBQWLCIyGEZ6PjguNERePBQuGPz8/Pz8/ Pz8biyk/G40JCYgpPxaNIj8chCI/lQgNjQmLBI0Gjw4JjS+Jj4sJqakurYYuPxaNBYUGCI0N L4mPiwmpqS6thi4/Pz8/P48vrYYvrYYvjI+JjT+PL62GL62GLwWIiAk/jy+thi+thi+EjQ6G iwWNP48vrYYvrYYvB48Fjgs/rYYvBo2JiASPCS8FiIgJhj8/Pz8/Pz8/CI2EPwyFCAiDPwiL jo0/C4WJiIUGP40DjosFjT+MiIgNPweIhAyFCT+UiwgTFz+bnS8kKCc/lKYmKJ0Jio0GCC8/ lKYmKJoJjQI/PwuIhC+PBo0vg4iFPwmNBayGLw6NLwwGi40IDYY/DY8GCYsIjD8NiAisBS8N BosIii8FiIgviYWOCz+DiIUGLwePhoaEiAYNPwuICI2DP4aIiY0vh4WNhgWLiAiGPwcJjY+G jS8FBoMvj4yPiwg/hI0JjoiJjS8FiC+Jgy8LiImNBYiECD8FC40vnI8GDY0IL4gML50NjQg/ iwgFBogNhY4Fi4gIL4gIL58dlhk/iY2NBYsIjC8IiAWLjo0/h4WNhgWLiAgIj4sGjT+OiAiM Bo8FhQmPBYuICIY/hoiGrz8KjwePCI2GjS+MiwYJLxSWLwcJj4MOiIM/CYiIiimJgy8OjY+F BYsMhQkvjIsGCS8MBouNCA0/jY+MjQYvBYgvho2NL4OIhT+GB4uOjS+MiwYJhqwvBIiOjwkv jogIjo0GBT8KjwePCI2GjS8Jj4aGrC+GjQODLweLjgWFBo2GPz8/Pz8/Pz+Wg4mPCAWNjj+Z jo8MjY0/HKmWjY6FBo0/logHC4iGPz8/Pz8cBoiJIi8/FYgiLz+WhQ4KjY4FIi8/Pz8VC40v DIgJCYiEiwiML4mPiwkvjo8IrAUvDo0vho0IBS8FiC+thiI/FQuNL48FBY+OC4mNCAU/FQuN LwyLCY0/L4uGLwULjS+IBouMiwiPCS+Jj4sJPy+MiwSNL4OIhS8FC40vrYY/L4uGL48vrYYv DY8IjI0GiIWGLwSLBoWGLwULjwUvrYY/jo8IL4sIDI2OBS+ICC+UiwijI6iZjagmJycnqBMX KD+GBwaNjw0vBQsGiIWMCy+NiY+LCSg/BI0Ggy8/hgeNjouPCS8/CwUFByKoqD+EhIQoPyiO iIk/HIgGL4mIBo0viwgMiAaJjwWLiAgpBwmNj4aNLwSLhosFLz8VC4uGL4uGLz+bL62GL4OI hS+EiIUJDS+thi+LBSg/jQgKiIM/CYuKjT+Ei4YLPwuIB40/jQMHjY4FPz+eCwaLhgWJj4Y/ GI2EL4ONjwY/lo+LCAUvFI8JjQgFiwiNrIYvHY+DP58JCQuPCQmIhImPhj+fBwaLCS8ciIgJ hqwvHY+DPxmPDYMvHY+DP5+GhoWJBwWLiAg/no8IDQmNiY+GP58JCS+WiIUJhqwdj4M/nQeL BwuPCIM/Pz8/PxuPBweDLz8bjwSNL48vPz8hDgYguTo/uTo/B4iGBYmPhgWNBj8/P5SLCIo/ P5uJj4yNF48FCz+Zm5mdqRSNBoaLiAgiL6coJ7k6nogIBY0IBakVgweNIi+JhQkFiwePBgWo jwkFjQYIjwWLBI2iuTq7DoiFCA2PBoOhP56ICAWNCAWpFYMHjSIvBY0DBagLBYkJork6nogI BY0IBakVBo8IhgyNBqmdCI6IDYsIjCIvh4WIBY0NqQcGiwgFjw4Jjbk6uTohGxWZGSAhG52f HSAhqBudnx0gIR6YHZMgrYa5OiEcmBgVID8/IagcmBgVICGoHpgdkyAhqBsVmRkgPz8/nogI BY0IBakVgweNIi+thqK5OrsIj4mNoa2GuTqeiAgFjQgFqRUGjwiGDI0GqZ0IjogNiwiMIi8O j4aNJCW5Op6ICAWNCAWpmx0iLyGthiA/Pz8/Pz8/Pz8/j4UNi4ioA6mEjwQ/j4UNi4ioA6mJ iw2LP48HBwmLjo8Fi4gIqIiOBY0FqYYFBo2PiT8/Pz8/Pz8/P7k6IYsMBo+JjS+GBo6hph2O iw0irYYvC42LjAsFoaYdJy+Eiw0FC6GmHScguTohqIsMBo+JjSA/FQuLhi+Mj4mNL4uGL4mD LwyLBoYFL4SIBoooIQ4GILk6k4iFrAaNLwULjS8MiwaGBS8HCY+DjQYoP5ibnpc/FwaIjAaP iRyLCY2GHYsGPz8/P4aJBQcoP5CfFBemJj+QnxQXnp4/GJgdpiY/GBeWlhSePxgWnZaXpiY/ GJaeG50dpiY/GJaeG50dGBU/GJYXGZWcmxg/GJ8UPxifFJ8XlhSePxifFJ8XlKYmPxifFBmV piY/GJ8UFpUYFj8YnxSUpiY/kJ8UF5k/nxmdFhWWFJ4/n5mYGD+fFBemJj+fFBeenj+fFBeZ PximJpaenxiUPxifFJQYFT+fGBWbFJsWP58UF5UXHT+fFJyeFRYZP58UlJsYo6U/lp6fGKYm PxSWG5SbGKYmPxyplhWYF5Q/HKkXFpgVo6U/n56alJsYpiY/FJ0VFRafkz8UnRWjpT+WlJ2d F6OlPxeenpSbGKMjP5uYmZgYoyM/nxQXFZ4/nxSdpiY/nxSemBiWmBk/HBeplJsYPx0UF6Ol Pxypn5wYFaOlP54Zn5SjpT8YFJ6jpT+Wnp8YPxSbFpWWPxmYnpodmJQYJicnJz8YiAYFiAg/ mY6PDI2NP58IBYsEiwY/FZ+WmpmcFj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz+fGBWbqRSbFigdnxU/ nhuaGZuWFSgdnxU/nhuaGZuWFSiZlj+eG5oZm5YVKJ4Xlj+eG5oZm5YVKBWfFD+bFB4oGBUS P5aZnxYVnhuaKJmWP5aZnxYVnhuaKJ4Xlj+fFJyXFSgdnxU/n5yVnxYdKB2fFT8/Pz8/Pz+W CwmEjweLKA0JCT+ajQYIjQmmJigNCQk/CI0FjweLpiYoDQkJP4YMjigNCQk/Pz8/P5aLBo6P iT8Yi4kNjz+eiA2NFo0NP5SXmpmZpiOkIz+cFpudHKYjpCM/HIUILxmIBIsIjC+eBouJiwiP CT8YiAYFiAg/mY6PDI2NP58IBYsEiwY/nwSOiAiGiAk/HKmWFZgXlD8cqZaNjoUGjT+WiAcL iIY/BIsGhYY/nxQXL5mICIsFiAY/nxQXL5UHDY8FjYY/mwiIjoUJjwWNmxU/F56pjosJCYsI P5aDiY8IBY2OPxUGjQgNL5mLjgaIPxypFxaYFT8vGJgdpiYvPz8/Fo2Mi4YFjQaWjQYEi46N FwaIjo2Ghj8YjQWWC48GjZ8NDT+WGx2NCY0FjZqNg58/lgyOm4YciwmNFwaIBY2OBY0NPxiN BZYLjwaNnI0FmwgMiD8YjQWfB4sehQwMjQYcBo2NPz8/Pz+dExcZmBadFj+emZmcFj+JhouJ CD+LjoSOiAgIP4SLCAKLBz8/Pz8/FwaIjAaPiT+thi8hrYYgP58enh2dHJwbmxqaGZkYmBeX FpYVlRSUE5MSjw6ODY0MjAuLCooJiQiIB4cGhgWFBIQDgwInpyamJaUkpCOjqqg/ho0FhQc/ iwiGBY8JCT8NjYmIP4YIiIgHgz8Hi46PjoU/iosFBYM/BwmPgz8GiI6KPz8/Pz8/Pz8Wjwav Mrw/2HeGPz+5Pz8/Pz8/Pz8/KAaPBj8/hIsIiwiNBSgNCQk/mwgFjQYIjQWcjQWeiAgIjY4F jQ2WBY8FjT8/Px2LBo2OBYgGgz8NCQmOj44LjT8/lo0djQ6FjBcGiwSLCY2MjT+WjRWODhcG iwSLCY2MjT8/Pz8/Pz8/P4QMjiiOiIkoBYQ/P7k6lIsIpiYvmgmNAi8UJignLywvlIsIpiYv nQmKjQYILxSnKKcpKxULjQaNLwiLjoovCI+JjS+Lhi8VhIsILxSLBoWGKhCQkBAqq7k6nogH gwaLjAsFKYmPDY0viwgvn4aLjymPCAiIhQiOjYmNCAUiuTqnKJsvhIsJCS8FBoMviYMvDo2G BS8FiC8HBogFjY4FLwULjS+Fho0GLwwGiIkvhoiJjS8Ei46LiIWGLwSLBoWGKRyFCAmIBI0p losGjo+JKRiLiQ2PKZ6IDY0WjQ0vjwgNL40EjQgviwiOCYUNjS+UpiYomgmNAi+nKBMouTom KJSNCQkvB4+LDS8KiA6GL48GjS+EjwgFjQ25OqYoF4iIBi8JiwyNL4YLiIUJDS8OjS+FCA4J jYaGjQ25OiUoHYgIrAUvj46OhYaNL4mNKBcJjY+GjS+Pjo6Fho0vBQuNL4UIDI+LBi+GC4sF L4SIBgkNuTo/Pz8/Pz8BAAAAEQAAABsAAAAiAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAA pQEAAFMAAAAOAgAADgAAADYCAAAOAAAAXgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAYxgAAJ4BAAAMGgAA9AEAAGkqAAAUAQAA5CsAAJwEAABNWlAA AgAAAAQADwD//wAAuAAAAAAAAABAABoBAAC6EAAOH7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFt IG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BFAABMAQQAnSsEiAAAAAAAAAAA4ACOgQsB AhkAAgAAABQAAAAAAAAIQgAAAEAAAAAgAAAAAEAAABAAAAACAAABAAAAAAAAAAMACgAAAAAA AGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQAAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAA EAAAABAAAAACAAAABiAAAGBEQVRBAAAAAAAQAAAAIAAAABAAAAAIQAAAwC5pZGF0YQAAABAA AAAwAAAAAgAAABhAAADALnJlbG9jAAAAFAAAAEAAAIASAAAAGmAAAPBoyAAAAOgHAAAAagDo BgAAAP8lNDBAAP8lODBAKDBAMAAANDBOMAAAVjAAAAAAAABOMAAAVjAAAAAAAABLRVJORUwz Mi5kbGwAAAAAU2xlZXAAAABFeGl0UHJvY2VzcxAAABAAAAATMBkwyEQAALgCV1HoNgAAAB+Y a5DKU4MISyh1Rlef2v4SM5FrOi7HptQsuhnLPq0xaZZESKk6gr+YOnBZEL0UAaCKzrFKkF38 YI11U2a6VgL8ig6A8UHAweeA8XyIDkZmSnXu3yqYrDNI6DlRp75B8em7Ual7PKG5ubm5uaJT ThW+MtUZuEOHmKey8Lm5uROisrC7ubkZcUbbcar7rgHx0bp+ubm5Rro+ubm7uXW6zyMNU16u P8G/PnW6yRkzU3ZUOZf5UXquOUm/Pq4Zob8eus0vMx0lUya6TbEzId/dUzRxprsLC65Z+b9e rtW/Xt8cbYULG88ZiQtRyRs9GWh8ubm5bYULosJKu7m5Qlx15glTfB0trknxv06n1pEXrkmB v06ukZa/HqqQok67ubkNC3w6CQVtOWm5mbm5zqDBubnouFG/On6/H225RpI/vbm5oqJdu7m5 GxmWohuz7x29QN842Gju3zjs2M+n1iVA7yiuBUi/WLhyh17wrl6vVFGtv1yuJUCuBUhubg8f ot5Jvbm5rkR1yq6v4NE7ODh20UHsfFKoI6eoI52oI5M0M4dIuj6svbm5Rn5oubm5uQnjzD+5 ubO5mbm5Rnhoubm5uQmiuBZERkYZrjHxmaa4yLm5ud84Ph1tRg1A4K04UZHdGNipGmxftbpc /77JYkQoU1xudpwNPlF+ImhIiCumOK8sN+M/5VH71y4SM4qWKfDV6PxKlBwGCmv/JKLMTxaj aT4mHxpJNQUePXXk2OZFApBq0yRBdldC8nZXCLNoV5zldle0MHZXn8J0V7m5ubmK+HZXqZV0 V344dFdAsXZXhAN2V3cFdlfspHZXjVN2V3SPdFecu3ZXuqB2V62IdlfX6HZXlld2V1UjdleY GXZX7iF2V5S/dld/S3ZXfMF2V427dldmnnZX1+B2V7m4ubm5ubm5ubmIRwAAuAIAALm5ublJ Rp25vmLVrjNWAxMZqjPXRpKhvbm5rzhT/6LCJ6O5ud9UN6fUp37BF0aSqb25ua84U52iguqj ubnPTl+pCVQwOVMDbn1oh7G5uTen1Kd+HBkXGUaSsb25uaqw0r+lubkJNW56CXk7aCG5ubl7 quL/pbm5VDC4UZk7GysbRpKJvbm5E2hZu7m5ERsTooJFsbm5HxsbRpJRvbm5VDPJOVG3Dw97 OTyhuVQzybgPpjHxgXtTvUZ4PJm5G2mxu7m5otLNgbm5FUaS6b25uRW2VmiUv7m5yAEXW2/u NLLWv7m5u2ikv7m5yOVzSXNTocjlcWFhNLLWv7m5ve7fOOwFC37vVDPJOVPzeWh5sbm5qXtp ubG5uaLC96W5uRcZRpKBvbm5bbkVF0aSkb25uXloz7G5ubt7FQdoy7+5uVEPabG7ubkXbbtt uWixubm5FxsvuRkRaOW5ubkfZ3VRV3tdcwEja39dZ19ndVEBF2tlcWdXXwE/U11dc2VRFXNd X2tnZQEdU2W5ab25ubhGkr+lublGkrelublueWmxu7m5aCi9ubm+ZrcXbbttuWijubm5O1lZ K2VrUQcxISFfuRkRaDxGRkYfZ3VRV3tdcwEja39dZ19ndVEBF2tlcWdXX/klEQE/U11dc2VR FXNdX2tnZQEXa2VxZ1dfuT4DA0C6YLG7ubk0sh+zubnANrIqs7m5tkZGRqwjyVQ6OFGbNLIf s7m5uTayKrO5uT9GRkauUq7C/6W5uVQ6uFGBaLmrubmuMu82uHy3uDyxp9Qcaxw1hbm5zxhX r89WU1VUOjlRvW6ByjWFubmiwaVe8BEbFaKERbG5uR8bG0aSUb25uWjCqbm5VDypUYVUPLFR PWjIubm5otHxabG7ubkVRpLpvbm5aCy5ublohrm5uWiYqbm5dbpMScmnsEhKAAC4AgAA7Lm5 uWjUu7m5UbVUM8k4UbffOGjeu7m5bsBoUbm5uaLB8Wmxu7m5F225RpKBvbm5aLi7ublC2kbY AVzkQDQ3u7loX7m5uWgpubm5aMupubmn1DzKjbm5uVRap9QQujx7zbm5qpHxrkoRRpLxvbm5 ribBv12rwbFXs2jPubm5rLHxRDjBTVW92HuosfF8CGo/RkZGBRFGkvm9ubm4QfG1o1OTrDHx vcG/UbHBq1OrNLKetbm5OW6QRnR5olHx8Wh8ubm5aGK5ubnIAe3l7e7fOO66YDm7ubmi0s2B ubkRFUaS4b25uTmnsNq5ubkpGVYx8bG5l7m5U3+i0PFpu7m5aPq5ubkXaO65ubnKsbu5udgB 7KJR8dGutV7wBVYY6uXlublR13Xq5blR21Yx8bGZubm5UYnKsbu5ue96rkBe8GhTRkZGujCx u7m5bqdo/bu5uVOpeWgHu7m5uHu4wp61ubk5UYFo+be5ub58t7gsuzp8rR1GksG9ubnfKmiw QEZGojHxsa6h8RkbRpLZvbm5rzinshdGRkZGktG9ubm6MDm7ubl7Psqxu7m5osLNgbm5F17w Bz4Z3zjSRlzkJwk+RpKZvbm587m5ubg+ec6hQ7m5yrmZubnvCl2173obC25UvwrvfhEZbZ9t u229RpKvpbm5rzhTca7R8aJB8ak2t7lDubkXokHxmReiQfGhKaq3FxVGkqelubmvOFPFrqd+ zaKRorm5ublWMRBIvbm5uVGvojEQYGiaRkZGboGu0RC6YLG7ubmuQODsrThTTGh3REZGujCx u7m5fDRGkp+lubm6MKlDubl7PsE7XbXBDVe9sfk+ea5EQBXgaGxGRkbsrThTUgXfHOIVw19L X1FTg+LDc2Pf3VOT4sMBcWFhU6Piw397f2lTs0Q8BW6pBb5kv604UxztXHs+CE0AALgCAAC6 Mkm9ubnfRq6h8aybqBO7O6qh8XkVFUYTcFQzu79Rv74ot1Qzu6lRv754SBnqu7m5uVGpvnhE GRVGE2iqQ70Xbf1tvxdtu2m5ubk4FUYTEL5giTmnsHCxubm+MIkpGRsRGUYTSAu4Q7u4U/u+ YJE5p7A6sbm5Ka8qp7LIsbm5w7n5ubmnvOKxubm+MJEZlL5gmRGiEfGhHRdGUfH5RhNYujSv hbm5FxUXbbEXRlHx6UYTCK84p7Bjsbm5GRUXF229GUYTAK84p7DFsbm5GapzpaKiNq25uaJR 8eGqJbHfKnGum6qVcarbuEO7OVOnlq4h8Yk6ar1e7mo6v7m5rqKGr7m5fvF5xri9ubnvdq4A GxcfbUYVbbttuUYTqAkRbblGGL92rzh7UyauCHW6ySMNUzSuP8G/PnW6yRkzU8yumNG7ubm/ HrpNmRdrZQ1TqXW6TZFrWVH6QKfWGZGiEZlIrkyn1im1vjbpfE6uJ6G/J6nPIfGJX62/LrrL HXtd+1EpHa5J6b486a5dsc9EXVS/3c9WXVjvTbG/TaG/TnW6R0QXG1M5db5HvblTyw24Q7u7 U4/fKqqoqLm5uaqooLm5uTQ5Ab24J0K4ali9ubm4Q7u9U1K4KZf5uCdCOTY50bm5uB9ucA1U OZf5UwKsCQG4fkS4Tr1THEZZtaLSqEJGRqLC5q+5ucq/pbm5Gxde8AU0NfGYqiOtaUm9ubl5 aOa/ubm+fMc9uxHx+bsR8fGqE7V7GzQzubm+POmura4Nqc8up5ax8VW9ti4bH65B8YmuLdG/ Jr5NobmnsAa7ubm/TaG/QfGxuEm1u1GL7ya+aqmuAfGZzyHxoaegxru5uc8uQYlukcrIvbm5 zy5dva4uuyO9vjO9qW69ri4Zrj2xvzHxqb44qa4DrapDra8OUb2qv9847q46rw7ITwAAuAIA AFOzo7m5FxvuCa8Op7Lju7m5G64p6aqkvru5ua4m7yHxgb8tse8tobo6Qbu5uaqkRbu5ua8O p7Jcubm5eWgIvbm52r+4fLe4dL/NFFFmrjw6aKm4cLfNfFF+zXRTtUQwzXxRCrhMsVEQuECx USa4TLNRLLhAs1EyrAS4LjioBZW4LlioBZ+oBYusNBx4rTyoNZuoNYGsPKE5qDWDHHysNavx Nq08qDWrrDWh8citMKg1obggKah1h64ztag1u6g1O6i0oL25uRmxs6i06bu5uQm7tEW7ubmx g6g1rWjLvbm5uHy7uDxIuHSxvRSoFbVo9b25ubgsu6gVkaiUC7u5uahVl6jUAbu5ua48Hmio dY2o9AW7ubnOeqO5ub40/a5ErCTg3TAcKN087C9TUnuuLbGqKeG/IfGpvjqpqinpC+sh8Zk2 MfGhhbm5ubsh8bG+MfGxqa8OU/G6LYF5ublYG22zC17wGR2uI7Vo7ru5uZzsfFYNCQu+arPv I7Ve8KfMbYGFRDO5dUYptQ8Lzwpfs78JwW5WuMHxuVG9tgqqraoNqb5B8am5RY24Q7m5Uaen 1hmRohGZSK4h8aGqKbVqykJGRr4woaY5tafWGZGikZnfKnVvKbXpvxqurb8tsa4B8Ym/A73v LlWrBxe/TrsjvV7srgkZri1Ivy1Azy5Vs78JyW5WqgkZrnOlogkJrq9+1za/ubm5uQUVriHx ib8jvRsaat8cp9a1vxiuPLp8Rka5uTpomb8YNTV8bK48OmiZdb88C786qr+uMfHhcXf+ublG E3hGE2BtuW25rjHxib8zvRlGUfH5RhMgRlHxkUYTKBGiMfGhGW25RlHx+UYTUEZR8ZFGE2BG UfGJRlHx+UYTaL4wOT5oubm5uQmiuGFGRkZqM1BGRntxVXtZa9/duR1zdz9dc3tRcwAAAAC4 AgAAL3NLO7kdc3cfc1EVe2FTczNJO7m5Y1lduRclc1EnWXNlM2VTYzu5FyVzUTNlU2Mdc19n U11/czu5FyVzUT9hZ19zM2VTY7m5X3V/uR91fytfNWthcxldZ1Fzf1Fzcbm5uRNoubm5uQMb vyMVU69GkmdQRkauKLgquxu/Mx1TtUaSZ1BGRgvfHB4oVlq/PB44vxi0LB48vxqqExWqMx0L Az7GBSoQQAAzvnMtQAC9CBBAAOie6v//gL0IEEAAvn0tQADoSer//2oA6DUAAABkdW1teS5l eGUAZTpcd2luZG93c1xTeVN0ZW0zMlxkTGxjYWNoZVxkZGQuZXhlAP8lTEBAAP8lVEBAAAAA YTpcAHgAAAAuZGxsAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAGqeQAACAAAAAQIECAAA AACkAwAAYIJ5giEAAAAAAAAApt8AAAAAAAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAA waPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsA AAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAAQH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAA AAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAAAAC6EUEAuhFBAAAAIAAgACAAIAAgACAAIAAgACAA KAAoACgAKAAoACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAA EAAQABAAEAAQABAAEAAQABAAEAAQABAAhACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAA EAAQAIEAgQCBAIEAgQCBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEA AQAQABAAEAAQABAAEACCAIIAggCCAIIAggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIA AgACAAIAAgACAAIAEAAQABAAEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAAuAAAAAQAAANTSQADE0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAA AAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAAAAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8A AMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEAAMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAA AAAAAAMAAAAHAAAACgAAAIwAAAD/////AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIA AABA1UAACAAAABTVQAAJAAAA6NRAAAoAAADE1EAAEAAAAJjUQAARAAAAaNRAABIAAABE1EAA EwAAABjUQAAYAAAA4NNAABkAAAC400AAGgAAAIDTQAAbAAAASNNAABwAAAAg00AAeAAAABDT QAB5AAAAANNAAHoAAADw0kAA/AAAAOzSQAD/AAAA3NJAAAAAAAAAAAAAgCBJAAAAAACAIEkA AQEAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHAQABBwEAAQcBAAEHAQABBwEAA QcBAAAAAAAAAAAAA+AMAAAAAAAAAAAAAAAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQA AAAYAAAABQAAAA0AAAAGAAAACQAAAAcAAAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAA CwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAADwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIA AAAhAAAADQAAADUAAAACAAAAQQAAAA0AAABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAA DQAAAFcAAAAWAAAAWQAAAAsAAABsAAAADQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYA AAAWAAAAgAAAAAoAAACBAAAACgAAAIIAAAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAA ngAAAA0AAAChAAAAAgAAAKQAAAALAAAApwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsA AAAYBwAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAA4AACABgAAAHgAAIAOAAAA kAAAgBAAAACwAACAagAAAMgAAIAAAAAA1poYNAAAAAAAAAYAAQAAAOAAAIACAAAA+AAAgAMA AAAQAQCABAAAACgBAIAFAAAAQAEAgAYAAABYAQCAAAAAANaaGDQAAAAAAAABAAEAAABwAQCA AAAAANaaGDQAAAAAAAACAAEAAAA4AgCAAgAAAFACAIAAAAAA1poYNAAAAAAAAAEAAQAAAGgC AIAAAAAA1poYNAAAAAAAAAEAxAAAAIACAIAAAAAA1poYNAAAAAAAAAEACQQAAJgCAAAAAAAA 1poYNAAAAAAAAAEACQQAAKgCAAAAAAAA1poYNAAAAAAAAAEACQQAALgCAAAAAAAA1poYNAAA AAAAAAEACQQAAMgCAAAAAAAA1poYNAAAAAAAAAEACQQAANgCAAAAAAAA1poYNAAAAAAAAAEA CQQAAOgCAAAAAAAA1poYNAAAAAAAABcABQAAAPgCAAAGAAAACAMAAAcAAAAYAwAACAAAACgD AAAJAAAAOAMAAAoAAABIAwAACwAAAFgDAAAMAAAAaAMAAA4AAAB4AwAAEAAAAIgDAAARAAAA mAMAABIAAACoAwAAEwAAALgDAAAUAAAAyAMAABUAAADYAwAAGQAAAOgDAAAdAAAA+AMAAB4A AAAIBAAAHwAAABgEAAAEBAAAKAQAABYEAAA4BAAABAgAAEgEAAAWCAAAWAQAAAAAAADWmhg0 AAAAAAAAAQAJBAAAaAQAAAAAAADWmhg0AAAAAAAAAQAJBAAAeAQAAAAAAADWmhg0AAAAAAAA AQAJBAAAiAQAAAAAAADWmhg0AAAAAAAAAQAJBAAAmAQAALBECQDoAgAAAAAAAAAAAACYRwkA KAEAAAAAAAAAAAAA5EgJAOgCAAAAAAAAAAAAAMxLCQDoAQAAAAAAAAAAAAC0TQkAKAEAAAAA AAAAAAAA3E4JAKgOAAAAAAAAAAAAAKxvCQDuAAAAAAAAAAAAAACIaQkA0AAAAAAAAAAAAAAA lGYJANQAAAAAAAAAAAAAAHRyCQBMAQAAAAAAAAAAAAAYYQkA3gAAAAAAAAAAAAAA9GIJAOwA AAAAAAAAAAAAAFhqCQDuAAAAAAAAAAAAAACYZQkA/AAAAAAAAAAAAAAAzG4JAN4AAAAAAAAA AAAAAPhhCQD8AAAAAAAAAAAAAAAkbAkAtgAAAAAAAAAAAAAA3GwJAJwAAAAAAAAAAAAAAMBk CQDWAAAAAAAAAAAAAABIawkA2gAAAAAAAAAAAAAAwHMJAFYBAAAAAAAAAAAAAJxwCQDYAAAA AAAAAAAAAADgYwkA4AAAAAAAAAAAAAAAGHUJAOgAAAAAAAAAAAAAAHRxCQD+AAAAAAAAAAAA AAB4bQkAtAAAAAAAAAAAAAAAaGcJAAABAAAAAAAAAAAAACxuCQCgAAAAAAAAAAAAAABoaAkA IAEAAAAAAAAAAAAAwEgJACIAAAAAAAAAAAAAAIRdCQA+AAAAAAAAAAAAAABcXgkAvAIAAAAA AAAAAAAAxF0JAJUAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAACAAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAgAAAAAAAAACAAAAAAObm4AgAAAAA5u bgCAAAAA7u7m5ggAAADu7ubmCAAAD/7u7m5gAAAP/u7ubmAAAA///+7m4AAAD///7ubgAAAP ///+7mAAAA////7uYAAAD////ubgAAAP///+5uAAAA/////uYAAAD////+5gAAAA////5gAA AAD////mAAAAAAD//wAAAAAAAP//AACAAAAAAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA AIAAAAAIAICAgICAgICAgACAAAAAAIAAAAAAAAAAAAAAgAAAAAAIAAAAAAAAAAAAAIAAAAAA AIAAAACAAAAAAACAAAAAAAAIAICAgACAgIAAAAAAAAAAAIAACAAAAAAAAACAAAAAAAAIiIAA AAAAAAAAh3d3d3d3cAAAAAAAAAAAAI////////9wAICAgICAAACPiIiIiIiIcAAAAAAAAAAA j47u7u7u6HAAAAAAAAAAAI+O7hER7uhwAAAAAAAAAACPjumRER7ocACAgICAgAAAj47pke7u 6HAAAAAAAAAAAI+O7pHhHuhwAAAAAAAAAACPju7u7u7ocAAAAAAAAAAAj3iIiIiIiHAAAAAA AAAAAI////////9wAAAAAAAAAACP////////+AAAAAAAAAAAiIiIiIiIiIgAAAAAAAAAAPgP +A/wB/AH4APgA8ADwAPAA8ADgAPAA4ADwAGAA8AAwAGAAOAMMAzwH/gc+f///PzVVVz+f//4 /z//+P+fz/j/zU1c/+ef/AAAP/wAAH//AADVXwAA//8AAP//AAD//wAA1V8AAP//AAD//wAA //8AAP//AAD//wAA//8AAP//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wAAAIAAAAgAAAAIB3AAgHcAAAB3dwAHd3AAAO/3AA7/cIAA7v8ADu/w h3gO4Hdw7giPiIAIiIgAgI+O7gfuCHdwj47lUHcIcACPjulVAAhwAI+O6V7u6HAAj47uXl7o cACPju7u7uhwAI+IiIiIiHAAj///////cACIiIiIiIiIAPHjAADgwQAA4EAAAOBAAAAAAAAA AAAAAAAAAAAAAAAAAAMAAAADAAAAAwAAAAMAAAADAAAAAwAAAAMAAAADAAAAAAEAAgAgIBAA AQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/ AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAh3d3d3d3d3d3d3d3AAAAAI//////////////9wAAAACP// ////////////cAAAAAj//////////////3AAAAAI////f/d3d3d3//9wAAAACP////////// ////cAAAAAj//////////////3AAAAAI////f/d3d3d3//9wAAAACP//////////////cIAA AAAAAAAA/////////3CHd3d3d3d3cPd3d3d3//9wj////////3D/////////cI+IiIiIiIhw /////////3CPju7u7u7ocPd3d3d3//9wj47uERHu6HD/////////cI+O6ZERHuhw//////// /3CPjumR7u7ocPd3d3d3//9wj47ukeEe6HD/////////cI+O7u7u7uhw/////////3CPeIiI iIiIcP////////9wj////////3D/////////cI/////////4d3d3/4AAAACIiIiIiIiIiP// //+P/3gAAAAACP////93d3f/j/eAAAAAAAj//////////494AAAAAAAI//////////+HgAAA AAAACP//////////iAAAAAAAAAj//////////4AAAAAAAAAIiIiIiIiIiIiAAAAA//////// ///+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH+AAAD/gAAB/4A AA/+AAAf/gAAP/4AAH8oAAAAGAAAADAAAAABAAQAAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACHd3d3d3d3d3cAAACP////// ////cAAACP//////////cAAACP//f/d3d3//cAAACP//////////cAAACP//f/d3d3//cAAA CP//////////cIAAAAAAAAB3d3//cI//////93D/////cI94iIiIh3B3d3//cI+O7u7u6HD/ ////cI+O4REe6HB3d3//cI+OmRER6HD/////cI+OmR7u6HD/////cI+O6R4R6HD/////cI+O 7u7u6HD/////cI94iIiIh3B3////cI////////D///AAAIiIiIiIiIh3//j3AAAACP////// //hwAAAACP////////gAAAAACIiIiIiIiIgAAP///wD4AAAA+AAAAPgAAAD4AAAA+AAAAPgA AAD4AAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAPgAAwD4AAcA+AAPACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAgAAAAAAAAACHd3d3d3cAAI//////9wAAj/f3d3f3AACP//////cAAI /393d39wgAAAAA///3CPd3d3B3d/cI+IiIcP//9wj4Eehwd3f3CPgeGHD///cI94iIcHd39w j////w//AACIiIiIj/+PgAAI/////4gAAAiIiIiIgADgAAAA4AAAAOAAAADgAAAA4AAAAOAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAOADAADgBwAAKAAAADAAAABgAAAA AQAIAAAAAACACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICA AADAwMAAwNzAAPDKpgAEBAQACAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0A QkJCADk5OQCAfP8AUFD/AJMA1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAz AAAAMzMAADNmAAAzmQAAM8wAADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMA AJlmAACZmQAAmcwAAJn/AADMAAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMA AAAzADMAMwBmAE1akAADAAAABAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAAAOH7oOALQJzSG4AUzNIVRoaXMgcHJvZ3JhbSBjYW5ub3Qg YmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAUEUAAEwBBgCX2jg3AAAAAAAAAADgAA4h CwEDCgAMAAAAGAAAAAAAACQQAAAAEAAAACAAAAAAr3wAEAAAABAAAAQAAAAAAAAABAAAAAAA AAAAcAAAAAQAAESDAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAIBoAAG4AAAAAMAAA UAAAAABQAACwDwAAAAAAAAAAAAAAAAAAAAAAAABgAABAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgCAABEAAAAyDAAAHgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAI4KAAAAEAAAABAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLmRhdGEA AAAIAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA0C5pZGF0YQAAKAMAAAAwAAAAEAAA ACAAAAAAAAAAAAAAAAAAAEAAAFAuU0hEQVRBADwAAAAAQAAAABAAAAAwAAAAAAAAAAAAAAAA AABAAADQLnJzcmMAAAAAEAAAAFAAAAAQAAAAQAAAAAAAAAAAAAAAAAAAQAAAQC5yZWxvYwAA lAEAAABgAAAAEAAAAFAAAAAAAAAAAAAAAAAAAEAAAEJz2jg3IAAAACCvMjcqAAAActo4NzcA AAAAAAAAAAAAAElNTTMyLmRsbABLRVJORUwzMi5kbGwAVVNFUjMyLmRsbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABNdWx0aWxpbmd1YWwgTGFuZ3VhZ2UgSW5kaWNhdG9yIERMTACDfCQIAXUYM8A5BRRAr3x1 DqMIQK98i0QkBKMUQK98uAEAAADCDABVi+yDfCQMAHQKi0UIowBAr3zrNoN9CAB0HGoAoRRA r3xQaFIUr3xqAv8VFDGvfKMQQK986wyhEECvfFD/FSgxr3yLRQijBECvfLgBAAAAXcIIAIM9 AECvfAB1BDPA60yDPQhAr3wAdT5qAKEUQK98UGhyE698agr/FRQxr3xqAKMMQK98oRRAr3xQ aJoUr3xqBf8VFDGvfMcFCECvfAEAAACjGECvfLgBAAAAw4M9CECvfAB0HqEMQK98UP8VKDGv fKEYQK98UP8VKDGvfP8NCECvfLgBAAAAw1WL7IPsDFNWV4t1CIvehfZ0X4M9AECvfAB0OP8V LDGvfIv4hf90L1f/FRAxr3yFwHQkjUX0UFf/FSQxr3yJRfz/FeQwr3w7Rfx1BIv36wcz/+sD i338oQRAr3yFwHQV/3UMVmgzBAAAUP8VGDGvfOsDi338hfYPhNYAAAA5NSRAr3wPhMoAAAA7 NQBAr3wPhL4AAABT/xUQMa98hcB0FjsdAECvfHQOOx0kQK98dAaJHShAr3yF/w+ElQAAAFf/ FRAxr3yFwA+EhgAAAFfozgAAAP91/P8VIDGvfIv4jUX4UP81JECvfP8VJDGvfFD/FSAxr3yL 2I1N+FGhAECvfFD/FSQxr3xQ/xUgMa98O8d0BDvfdT3/FeQwr3xQ6KwHAACpAAAIAHQXagCh AECvfGoAaDUEAABQ/xUcMa986xNXoQBAr3xWaDIEAABQ/xUYMa98X15bi+VdwggAiw0EQK98 hcl0FP90JAj/dCQIaDQEAABR/xUYMa98wggAoShAr3zDoSBAr3zDi0QkBKMkQK98wgQAoRxA r3zDoQAgr3zDVYvsg+wMVleLdQiF9g+EkgAAAI1F+FBW/xUkMa98/xXsMK98O0X4dXxW6BYH AACL+Ik1IECvfIX/dGBX6P4GAADHBRxAr3wCAAAAhcB1CscFHECvfAEAAAD/Fegwr3w9tQMA AHUsjUX0jU38UFFX6MUGAACFwHQa9kX8AXQHgA0cQK98BPZF/Ah0B4ANHECvfAhXVuiaBgAA 6wrHBRxAr3wAAAAAX16L5V3CBABVi0QkCIvsg/gBVnQPg/gEdBqD+Ah0JemqAAAA/3UQ/3UM 6Of+///pmgAAAP91EP91DOh8/f//6YoAAACLdQw5NSRAr3x0Djs1AECvfHQGVuj+/v//OTUg QK98dQiLRRCjACCvfP8V5DCvfFDoDwYAAIsNAECvfKkAAAgAdBaFyXQoagBqAGg1BAAAUf8V HDGvfOsWhcl0Ev91EP91DGgyBAAAUf8VGDGvfIsNBECvfIXJdBL/dRD/dQxoMgQAAFH/FRgx r3z/dRD/dQz/dQihDECvfFD/FTAxr3xeXcIMAFWL7FaLdQiF9nwl/3UQ/3UMi0UQJQAAAICD +AEbwAUBAQAAUP81BECvfP8VGDGvfP91EP91DFahEECvfFD/FTAxr3xeXcIMAFWL7FaLdQiF 9nx9g/4FdAeD/gl0HOtxi0UMOwUAQK98dGY5BSRAr3x0XqMoQK9861eLRQw7BQBAr3x0TDkF JECvfHREagCjIECvfFD/FSQxr3w5BQQgr3x0LlCjBCCvfP8VIDGvfDkFACCvfHQaUKMAIK98 /3UMaDUEAAD/NQBAr3z/FRwxr3z/dRD/dQxWoRhAr3xQ/xUwMa98Xl3CDACDPTBAr3wAVnUf agyhLECvfGoIUP8V8DCvfKMwQK98iQChMECvfIlABKEwQK98iwiLRCQIi1EEiVAEizKJMIlB BIkCuAAAAAD/BTRAr3yBPTRAr3z0AQAAfwW4AQAAAF7CBACLVCQEOxUwQK98dC2LSgSLAolI BIsCiQH/DTRAr3x5CscFNECvfAAAAABSoSxAr3xqAFD/FfQwr3zCBACDPTBAr3wAVnQyoTBA r3yLQAQ5BTBAr3x0IotwBFDoof///4vGOTUwQK98de0zwDkFNECvfH4FozRAr3xew1ZXi3wk DIvHa8B4g8AMUGoI/zUsQK98/xXwMK98i/CF9nQGVuj6/v//i8aJfghfXsIEAFWL7FNWV2oA i10YaniL+1P/Ffgwr3yLVRC5HAAAAIvy86X2QgQEdBL/dRRS/3UM/3UI6BcAAACJQ3ShOECv fF8F6AMAAF6JQ3BbXcIUAFWL7IPsCIN9FAEbwFNWQFeJRfxqAGoA/3UQaj9Q/3UM6FMDAACL +IX/dQQzwOt3V+hK////i/CF9nUEM8DrZ2v/cI1eDFdqQP8VADGvfIlF+IXAdQQzwOtNV/91 +P91EGo//3X8/3UM6AsDAACL+IX/dCiLRfiJRfxTg8N4/3UU/3X8/3UM/3UI6CT///+DRfxw /wU4QK98T3Xe/3X4/xX8MK98i8ZfXluL5V3CEABWoSxAr3xXhcB1FWhg6gAAaMBdAABoAAAA BP8VBDGvfKMsQK98hcB1BDPA6y+LdCQMVuiMAgAAi/gzwIX/dBj/dCQQUFejOECvfFboAf// /1dW6FoCAAC4AQAAAF9ewggAU1aLdCQMV1Uz7VWNXgRqMFb/Ffgwr3yLfCQYxwYwAAAAiSuN TwQ5KXQfjUYIxwMQAAAAiSj2AQF0BscAAAIAAPYBAnQEgEgBCIsDDAKJA4tXcIlWEPYBBHQa DASJA/8VNDGvfP90JByJRhT/d3RQ6KQAAACLAwwBiQOLTwiJTgyDfxAAdBaDfxQAdBAMCIkD i08QiU4Yi1cUiVYciwMMIIkDi08YiU4gg39sAHQKDICJA4tPbIlOLIPHHFf/FQgxr3yFwHQQ V4ALQIl+JP8VCDGvfIlGKF1fXlvCDACDPTBAr3wAdCqhMECvfItQBDvQdB6LQgiFwHQXg8IM M8mFwHQO9kIJEHULg8J4QTvIcvIzwMOLQgzr+lWL7IPsMFNWV4t9DItHCIXAdQQzwOs0jXcM M9uFwHQm/3UQVo1N0IPGeFHouP7//41F0FBqAVND/3UI/xU4Ma98OV8Id9q4AQAAAF9eW4vl XcIMAIM9MECvfAB1BDPA6yKhMECvfItABDkFMECvfHUEM8DrDv90JAhQ/3QkDOh9////wggA UzPAVjkFMECvfFd0QIsNMECvfItJBDsNMECvfHQvi1QkEIt5BI1ZDDP2i0kIO850DTlTcHQU g8N4RjvxcvOLzzs9MECvfHXa6wOLQwxfXlvCBABTM8BWOQUwQK98V3RAiw0wQK98i0kEOw0w QK98dC+LeQSNWQwz9otJCDvOdBGLVCQQOVMMdBSDw3hGO/Fy84vPOz0wQK98ddbrA4tDGF9e W8IEAOno+///zP8l3DCvfP8lyDCvfP8lzDCvfP8l0DCvfP8l1DCvfP8l2DCvfMzMzMzMzMzM zMwAAAAAUWBaNQAAAACAGgAAAQAAAA4AAAAAAAAASBoAAIAaAACAGgAAnhAAAPgQAABLEAAA uRIAAK0SAAChEgAApxIAAL8SAABHFwAAFBkAAEYZAACZGQAA7BkAAIUYAABTaGVsbEhvb2su ZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQQJBAFO /f8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --X67zE479640f479mwO62eJDMPnX8295 --X67zE479640f479mwO62eJDMPnX8295 Content-Type: application/octet-stream; name=MGCP_Residential_test_cases.doc Content-Transfer-Encoding: base64 Content-ID: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAjQAAAAAA AAAAEAAAjwAAAAEAAAD+////AAAAAIsAAACMAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAWQAJBAAACBK/AAAAAAAAEAAAAAAABAAA /jAAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAAAAAJBBYAHlQAAJE9AQCRPQEA/iwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAHwEAAAAAAAAfAQAAHwEAAAAAAAAfAQAAAAAAAB8BAAA AAAAAHwEAAAAAAAAfAQAABQAAAAAAAAAAAAAAJAEAAAAAAAAkAQAAAAAAACQBAAAAAAAAJAE AAAAAAAAkAQAABwAAACsBAAAXAAAAJAEAAAAAAAAnUEAAPYAAABIBQAANgEAAH4GAAAAAAAA fgYAAAAAAAB+BgAAAAAAAH4GAAAAAAAAXQcAAKoBAAAHCQAAfAAAAIMJAABAAAAAYkEAAAIA AABkQQAAAAAAAGRBAAAAAAAAZEEAAAAAAABkQQAAAAAAAGRBAAAAAAAAZEEAACQAAACTQgAA 9AEAAIdEAADKAAAAiEEAABUAAAAAAAAAAAAAAAAAAAAAAAAAfAQAAAAAAADDCQAAAAAAAAAA AAAAAAAAAAAAAAAAAABZBwAABAAAAF0HAAAAAAAAwwkAAAAAAADDCQAAAAAAAIhBAAAAAAAA SxQAAAAAAAB8BAAAAAAAAHwEAAAAAAAAfgYAAAAAAAAAAAAAAAAAAH4GAADbAAAAJAUAACQA AABLFAAAAAAAAEsUAAAAAAAASxQAAAAAAADDCQAANgQAAHwEAAAAAAAAfgYAAAAAAAB8BAAA AAAAAH4GAAAAAAAAYkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAQAAAAAAACQBAAAAAAAAHwE AAAAAAAAfAQAAAAAAAB8BAAAAAAAAHwEAAAAAAAAwwkAAAAAAABiQQAAAAAAAEsUAAB2BgAA SxQAAAAAAADBGgAAwggAAEA3AAB8CQAAfAQAAAAAAAB8BAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYkEAAAAAAAB+BgAA AAAAAAgFAAAcAAAAwGuyB6TivgGQBAAAAAAAAJAEAAAAAAAA+Q0AAFIGAAC8QAAApgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATUdDUCBJTlRFUkZBQ0UgRk9SIFRIRSBJTlRFUk5B VElPTkFMIFNPRlRTV0lUQ0ggQ09OU09SVElVTSBDT05UUk9MTEFCTEUgUkVTSURFTlRJQUwg R0FURVdBWQ0NDA0TIFRPQyBcbyAiMS0zIiAUTUdDUCBJTlRFUkZBQ0UgRk9SIFRIRSBJTlRF Uk5BVElPTkFMIFNPRlRTV0lUQ0ggQ09OU09SVElVTSBDT05UUk9MTEFCTEUgUkVTSURFTlRJ QUwgR0FURVdBWQkTIFBBR0VSRUYgX1RvYzQ1ODI2MTA5NiBcaCABFDEVDUludHJvZHVjdGlv bgkTIFBBR0VSRUYgX1RvYzQ1ODI2MTA5NyBcaCABFDMVDU1HQ1A6IHVzYWdlCRMgUEFHRVJF RiBfVG9jNDU4MjYxMDk4IFxoIAEUMxUNQ2FsbCBBZ2VudCBkaXNjb3ZlcnkJEyBQQUdFUkVG IF9Ub2M0NTgyNjEwOTkgXGggARQzFQ1FbmRwb2ludHMgTmFtaW5nCRMgUEFHRVJFRiBfVG9j NDU4MjYxMTAwIFxoIAEUMxUNRGlhbGluZyBQbGFuCRMgUEFHRVJFRiBfVG9jNDU4MjYxMTAx IFxoIAEUMxUNUmVzaWRlbnRpYWwgR2F0ZXdheSBJbnRlcmZhY2UJEyBQQUdFUkVGIF9Ub2M0 NTgyNjExMDIgXGggARQ0FQ1CZWhhdmlvcgkTIFBBR0VSRUYgX1RvYzQ1ODI2MTEwMyBcaCAB FDQVDURldmljZSBTdGFydHVwCRMgUEFHRVJFRiBfVG9jNDU4MjYxMTA0IFxoIAEUNBUNTWFr ZSBDYWxsIGFuZCBSZWNlaXZlIENhbGwJEyBQQUdFUkVGIF9Ub2M0NTgyNjExMDUgXGggARQ0 FQ1DYWxsIFRlYXIgRG93bgkTIFBBR0VSRUYgX1RvYzQ1ODI2MTEwNiBcaCABFDQVDUNhbGwg Rmxvd3MgYW5kIE1lc3NhZ2VzIFRyYWNlCRMgUEFHRVJFRiBfVG9jNDU4MjYxMTA3IFxoIAEU NBUNRGV2aWNlIFN0YXJ0dXAJEyBQQUdFUkVGIF9Ub2M0NTgyNjExMDggXGggARQ1FQ1NYWtl IGFuZCBSZWNlaXZlIENhbGwJEyBQQUdFUkVGIF9Ub2M0NTgyNjExMDkgXGggARQ3FQ1DYWxs IFRlYXIgRG93bgkTIFBBR0VSRUYgX1RvYzQ1ODI2MTExMCBcaCABFDEwFQ0VIA0MDUludHJv ZHVjdGlvbg0NVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGludGVyZmFjZSBleHBlY3Rl ZCBvZiB0aGUgdHJ1bmsgZ2F0ZXdheSBhbmQgdGhlIHJlc2lkZW50aWFsIGdhdGV3YXkgdmlh IHRoZSBNZWRpYSBHYXRld2F5IENvbnRyb2wgUHJvdG9jb2wgKE1HQ1ApIC0gPGRyYWZ0LWh1 aXRlbWEtbWVnYWNvLW1nY3AtdjByMS0wNS50eHQ+Lg0NVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIGludGVyZmFjZSBleHBlY3RlZCBvZiByZXNpZGVudGlhbCBnYXRld2F5cyB0aGF0 IHdpbGwgYmUgY29udHJvbGxlZCBieSB0aGUgVm92aWRhIGNhbGwgYWdlbnQuICAoc29mdHN3 aXRjaCBhbmQgY2FsbCBhZ2VudCBhcmUgdXNlZCBpbnRlcmNoYW5nZWFibHkgaW4gdGhpcyBk b2N1bWVudC4pDU1HQ1A6IHVzYWdlDUNhbGwgQWdlbnQgZGlzY292ZXJ5DUFuIE1HQ1AgZ2F0 ZXdheSBtdXN0IHN1cHBvcnQgYSBtZWFucyB0byBzcGVjaWZ5IHRoZSBJUCBhZGRyZXNzIG9m IHRoZSBjYWxsIGFnZW50IG9yIHRoZSBhYmlsaXR5IHRvIHF1ZXJ5IHRoZSBsb2NhbCBETlMg Zm9yIHRoZSBuYW1lICJjYWxsYWdlbnQiLiAgVGhpcyBpcyB0aGUgbWVjaGFuaXNtIGJ5IHdo aWNoIHRoZSBnYXRld2F5IGxlYXJucyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgY2FsbCBhZ2Vu dCBhcyBuZWVkZWQgdG8gc2VuZCB0aGUgUmVzdGFydEluUHJvZ3Jlc3MuIA1FbmRwb2ludHMg TmFtaW5nDVRoZSBNR0NQIGNvbnRyb2xsYWJsZSBlbnRpdGllcyAoZW5kcG9pbnRzKSBvbiB0 aGUgZ2F0ZXdheSBhcmUgY2hhbm5lbHMuIFRoZSBjYWxsIGFnZW50IHNlbmRzIHRoZSBBdWRp dCBFbmRwb2ludCBhZnRlciByZWNlaXZpbmcgdGhlIFJlc3RhcnRJblByb2dyZXNzIGZyb20g dGhlIGdhdGV3YXkuIFRoZSBnYXRld2F5J3MgZW5kcG9pbnRzIGFyZSBpZGVudGlmaWVkIHRv IHRoZSBjYWxsIGFnZW50IGluIHRoZSByZXNwb25zZSBieSB0aGUgZ2F0ZXdheSB0byB0aGUg QXVkaXRFbmRwb2ludCBjb21tYW5kLiANVGhlICBSZXN0YXJ0SW5Qcm9ncmVzcyBjb21tYW5k IGlzIGFsc28gdXNlZCBieSB0aGUgZ2F0ZXdheSB0byBpbmZvcm0gdGhlIGNhbGwgYWdlbnQg dGhhdCBpdCBjYW1lIHVwLiBUaGUgZW5kcG9pbnQgaWQgaXMgb2YgdGhlIGZvcm06ICI8E0hZ UEVSTElOSyAibWFpbHRvOlN5c3RlbUlkL1N5c3RlbVR5cGUvQmF5TnVtL21vZHVsZS1udW1A aXBBZGRyZXNzIgEUR2F0ZXdheUlkPi88RW5kcG9pbnROdW1iZXI+QDxIb3N0IE5hbWU+FSIu IA1EaWFsaW5nIFBsYW4NVGhlIGNhbGwgYWdlbnQgbXVzdCBzdXBwb3J0IGEgbWVhbnMgdG8g c3BlY2lmeSB0aGUgZGlhbGluZyBwbGFuIGZvciB0aGUgdmFyaW91cyBlbmRwb2ludHMuICBU aGUgQ2FsbCBBZ2VudCBpcyByZXNwb25zaWJsZSBmb3IgbWFwcGluZyB0aGUgZGlhbGVkIG51 bWJlciB0byB0aGUgY29ycmVzcG9uZGluZyBlbmRwb2ludC4NDQxSZXNpZGVudGlhbCBHYXRl d2F5IEludGVyZmFjZQ1CZWhhdmlvcg1EZXZpY2UgU3RhcnR1cA1UaGUgc29mdHN3aXRjaCBl eHBlY3RzIGEgUmVzdGFydEluUHJvZ3Jlc3Mgbm90aWZ5aW5nIGl0IHRoYXQgdGhlIGdhdGV3 YXkgaGFzIGNvbWUgdXAuIFRoZSBzb2Z0c3dpdGNoIHRoZW4gdmVyaWZpZXMgdGhlIHN0YXR1 cyBvZiBtb2R1bGVzIGFuZCBsaW5lcyBieSBzZW5kaW5nIGFwcHJvcHJpYXRlIEF1ZGl0RW5k cG9pbnQgY29tbWFuZHMuICBUaGlzIGlzIGhvdyB0aGUgc29mdHN3aXRjaCBsZWFybnMgYWJv dXQgdGhlIGVuZHBvaW50IGlkcyBvZiBlYWNoIHBhcnRpY3VsYXIgZ2F0ZXdheS4NDU1ha2Ug Q2FsbCBhbmQgUmVjZWl2ZSBDYWxsDVRoZSBzb2Z0c3dpdGNoIGlzc3VlcyBhIENyZWF0ZUNv bm5lY3Rpb24gb24gZWFjaCBvZiB0aGUgdHdvIGVuZHBvaW50cyB3aGljaCB0ZXJtaW5hdGVz IHRvIGEgcGhvbmUgc2V0LiBJdCBub3RlcyB0aGUgbG9jYWwgUlRQIHBvcnQgc3VwcGxpZWQg aW4gdGhlIHJlc3BvbnNlIHRvIHRoZSBmaXJzdCBDcmVhdGVDb25uZWN0aW9uLCBhbmQgc3Vw cGxpZXMgaXQgdG8gdGhlIG90aGVyIGVuZHBvaW50IHZpYSB0aGUgc2Vjb25kIENyZWF0ZUNv bm5lY3Rpb24uIFRoaXMgZW5kcG9pbnQgdXNlcyBpdCBhcyB0aGUgcmVtb3RlIElQIHBvcnRp b24gb2YgdGhlIGNvbm5lY3Rpb24sIGFuZCByZXNwb25kcyB3aXRoIGl0cyBvd24gbG9jYWwg UlRQIHBvcnQuIFRoaXMgaW5mb3JtYXRpb24gaXMgcGFzc2VkIGJhY2sgdG8gdGhlIG9yaWdp bmFsIGVuZHBvaW50IGJ5IHRoZSBzb2Z0c3dpdGNoIGluIHRoZSBNb2RpZnlDb25uZWN0aW9u IGNvbW1hbmQgdG8gY29tcGxldGUgdGhlIGNvbm5lY3Rpb24uDQ1DYWxsIFRlYXIgRG93bg1U aGUgc29mdHN3aXRjaCB0ZXJtaW5hdGVzIGEgY29ubmVjdGlvbiBieSB1c2luZyB0aGUgRGVs ZXRlQ29ubmVjdGlvbiBjb21tYW5kLiBUaGUgQ29ubmVjdGlvbklkIHBhcmFtZXRlciBjb3Jy ZXNwb25kcyB0byB0aGUgQ29ubmVjdGlvbklkIHRoYXQgd2FzIHJldHVybmVkIGJ5IHRoZSBz cGVjaWZpZWQgZW5kcG9pbnQgaW4gcmVzcG9uc2UgdG8gYW4gZWFybGllciBDcmVhdGVDb25u ZWN0aW9uLg0NDUNhbGwgRmxvd3MgYW5kIE1lc3NhZ2VzIFRyYWNlDURldmljZSBTdGFydHVw DQ0BDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0t ICgxKQ1SU0lQIDAgZ3cwLypAbGFiMy5wcml2YXRlLnZvdmlkYS5jb20gTUdDUCAwLjENUk06 IHJlc3RhcnQNLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0t LS0tLSANLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0t LSAoMSBhY2spDTIwMCAwIE9LDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0gDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0tLS0tLS0t LS0tLS0tLS0tLS0gKDIpDUFVRVAgMCBndzAvKkBsYWIzLnByaXZhdGUudm92aWRhLmNvbSBN R0NQIDAuMQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tIA0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0t ICgyIGFjaykNMjAwIDAgT0sNDVo6IGd3MC9lcDBAbGFiMy5wcml2YXRlLnZvdmlkYS5jb20s IGd3MC9lcDFAbGFiMy5wcml2YXRlLnZvdmlkYS5jb20gDS0tLS0tLS0tLS0tLS0tLS0tLS0t ICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0gDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1l c3NhZ2UgLS0tLS0tLS0tLS0tLS0tLS0tLS0gKDMpDVJRTlQgMSBndzAvZXAwQGxhYjMucHJp dmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xDVI6IEwvaGQoTikNWDogNDAwMCAgDS0tLS0tLS0t LS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0t LS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoMyBhY2spDTIwMCAxIE9L ICANLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0t LS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg0KQ1S UU5UIDIgZ3cwL2VwMUBsYWIzLnByaXZhdGUudm92aWRhLmNvbSBNR0NQIDAuMQ1SOiBML2hk KE4pICANWDogNDAwMQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0tLS0tLS0tLS0tLS0t LS0tLS0gKDQgYWNrKQ0yMDAgMiBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0t LS0tLS0tLS0tLS0tLS0tLSAoNSkNUlNJUCAwIGd3MS8qQGxhYjQucHJpdmF0ZS52b3ZpZGEu Y29tIE1HQ1AgMC4xDVJNOiByZXN0YXJ0DS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0gDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0t LS0tLS0tLS0tLS0tLS0tLS0gKDUgYWNrKQ0yMDAgMCBPSw0tLS0tLS0tLS0tLS0tLS0tLS0t LSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tIA0tLS0tLS0tLS0tLS0tLS0tLS0tLSBt ZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg2KQ1BVUVQIDMgZ3cxLypAbGFiNC5wcml2 YXRlLnZvdmlkYS5jb20gTUdDUCAwLjENLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBlbmQgICAt LS0tLS0tLS0tLS0tLS0tLS0tLSANLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0t LS0tLS0tLS0tLS0tLS0tLSAoNiBhY2spDTIwMCAzIE9LDQ1aOiBndzEvZXAwQGxhYjQucHJp dmF0ZS52b3ZpZGEuY29tLCBndzEvZXAxQGxhYjQucHJpdmF0ZS52b3ZpZGEuY29tIA0tLS0t LS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tIA0tLS0tLS0t LS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg3KQ1SUU5UIDQg Z3cxL2VwMEBsYWI0LnByaXZhdGUudm92aWRhLmNvbSBNR0NQIDAuMQ1SOiBML2hkKE4pIA1Y OiA0MDAyIA0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0tLS0tLS0tLS0tLS0tLS0tLS0g KDcgYWNrKQ0yMDAgNCBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0t LS0tLS0tLS0tLSAoOCkNUlFOVCA1IGd3MS9lcDFAbGFiNC5wcml2YXRlLnZvdmlkYS5jb20g TUdDUCAwLjENUjogTC9oZChOKSAgDVg6IDQwMDMNLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBl bmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdl IC0tLS0tLS0tLS0tLS0tLS0tLS0tICg4IGFjaykNMjAwIDUgT0sgIA0tLS0tLS0tLS0tLS0t LS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDU1ha2UgYW5kIFJlY2VpdmUg Q2FsbA0NAQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0t LS0tICgxKQ1OVEZZIDEgZ3cwL2VwMEBsYWIzLnByaXZhdGUudm92aWRhLmNvbSBNR0NQIDAu MQ1POiBML2hkIA1YOiA0MDAwDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0t LS0tLS0tLS0tLSAoMSBhY2spDTIwMCAxIE9LICANLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBl bmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdl IC0tLS0tLS0tLS0tLS0tLS0tLS0tICgyKQ1SUU5UIDYgZ3cwL2VwMEBsYWIzLnByaXZhdGUu dm92aWRhLmNvbSBNR0NQIDAuMSANUjogTC9odShOKSBEL1goRCkgIA1TOiBML2RsICANRDog WzAtOV1bMC05XVswLTldWzAtOV0gDVg6IDQwMDQNLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBl bmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdl IC0tLS0tLS0tLS0tLS0tLS0tLS0tICgyIGFjaykNMjAwIDYgT0sgIA0tLS0tLS0tLS0tLS0t LS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDS0tLS0tLS0tLS0tLS0tLS0t LS0tIG1lc3NhZ2UgLS0tLS0tLS0tLS0tLS0tLS0tLS0gKDMpDU5URlkgMiBndzAvZXAwQGxh YjMucHJpdmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xIA1POiBELzUgRC8wIEQvMCBELzEgIA1Y OiA0MDA0DS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAo MyBhY2spDTIwMCAyIE9LICANLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBlbmQgICAtLS0tLS0t LS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0t LS0tLS0tLS0tICg0KQ1DUkNYIDcgZ3cwL2VwMEBsYWIzLnByaXZhdGUudm92aWRhLmNvbSBN R0NQIDAuMSANQzogMiANTTogc2VuZHJlY3YgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5k ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAt LS0tLS0tLS0tLS0tLS0tLS0tLSAoNCBhY2spDTIwMCA3IE9LDQ12PTAgDW89dGVzdElEIDEy ODUzOCAxMDAwIElOIElQNCBsYWIzLnByaXZhdGUudm92aWRhLmNvbSANcz10ZXN0IHNlc3Np b24gDWM9SU4gSVA0IGxhYjMucHJpdmF0ZS52b3ZpZGEuY29tDW09YXVkaW8gNjA1MCBSVFAv QVZQIDAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAo NSkNUlFOVCA4IGd3MC9lcDBAbGFiMy5wcml2YXRlLnZvdmlkYS5jb20gTUdDUCAwLjEgDVI6 IEwvaHUoTikgIA1TOiBHL3J0IA1YOiA0MDA1IA0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVu ZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2Ug LS0tLS0tLS0tLS0tLS0tLS0tLS0gKDUgYWNrKQ0yMDAgOCBPSyAgDS0tLS0tLS0tLS0tLS0t LS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0t LS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoNikNUlFOVCA5IGd3MS9lcDBAbGFi NC5wcml2YXRlLnZvdmlkYS5jb20gTUdDUCAwLjEgDVI6IEwvaGQoTikgIA1TOiBML3JnICAN WDogNDAwNg0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0tLS0tLS0tLS0tLS0tLS0tLS0g KDYgYWNrKQ0yMDAgOSBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0t LS0tLS0tLS0tLSAoNykNTlRGWSAxIGd3MS9lcDBAbGFiNC5wcml2YXRlLnZvdmlkYS5jb20g TUdDUCAwLjEgDU86IEwvaGQgIA1YOiA0MDA2DS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5k ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAt LS0tLS0tLS0tLS0tLS0tLS0tLSAoNyBhY2spDTIwMCAxIE9LICANLS0tLS0tLS0tLS0tLS0t LS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0t LSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg4KQ1DUkNYIDEwIGd3MS9lcDBAbGFi NC5wcml2YXRlLnZvdmlkYS5jb20gTUdDUCAwLjEgDUM6IDIgDU06IHNlbmRyZWN2IA12PTAg DW89dGVzdElEIDEyODUzOCAxMDAwIElOIElQNCBsYWIzLnByaXZhdGUudm92aWRhLmNvbSAN cz10ZXN0IHNlc3Npb24gDWM9SU4gSVA0IGxhYjMucHJpdmF0ZS52b3ZpZGEuY29tDW09YXVk aW8gNjA1MCBSVFAvQVZQIDAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0t LS0tLS0tLS0tLSAoOCBhY2spDTIwMCAxMCBPSw0Ndj0wIA1vPXRlc3RJRCAxMjg1MzggMTAw MCBJTiBJUDQgbGFiNC5wcml2YXRlLnZvdmlkYS5jb20Ncz10ZXN0IHNlc3Npb24gDWM9SU4g SVA0IGxhYjQucHJpdmF0ZS52b3ZpZGEuY29tDW09YXVkaW8gNjA2MCBSVFAvQVZQIDAgDS0t LS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0t LS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoOSkNTURDWCAx MSBndzAvZXAwQGxhYjMucHJpdmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xIA1DOiAyIA1JOiAg DU06IHNlbmRyZWN2IA12PTAgDW89dGVzdElEIDEyODUzOCAxMDAwIElOIElQNCBsYWI0LnBy aXZhdGUudm92aWRhLmNvbQ1zPXRlc3Qgc2Vzc2lvbiANYz1JTiBJUDQgbGFiNC5wcml2YXRl LnZvdmlkYS5jb20NbT1hdWRpbyA2MDYwIFJUUC9BVlAgMCANLS0tLS0tLS0tLS0tLS0tLS0t LS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBt ZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg5IGFjaykNMjAwIDExIE9LICANLS0tLS0t LS0tLS0tLS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0t LS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICgxMCkNUlFOVCAxMiBn dzAvZXAwQGxhYjMucHJpdmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xIA1SOiBML2h1KE4pIEQv WChOKSAgDVg6IDQwMDcNLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0t LS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0t LS0tLS0tICgxMCBhY2spDTIwMCAxMiBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5k ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAt LS0tLS0tLS0tLS0tLS0tLS0tLSAoMTEpDVJRTlQgMTMgZ3cxL2VwMEBsYWI0LnByaXZhdGUu dm92aWRhLmNvbSBNR0NQIDAuMSANUjogTC9odShOKSBEL1goTikgIA1YOiA0MDA4DS0tLS0t LS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0t LS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoMTEgYWNrKQ0yMDAg MTMgT0sgIA0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tDQ1DYWxsIFRlYXIgRG93bg0BDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1lc3NhZ2UgLS0t LS0tLS0tLS0tLS0tLS0tLS0gKDEpDU5URlkgMiBndzEvZXAwQGxhYjQucHJpdmF0ZS52b3Zp ZGEuY29tIE1HQ1AgMC4xIA1POiBML2h1ICANWDogNDAwOA0tLS0tLS0tLS0tLS0tLS0tLS0t LSAgIGVuZCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDS0tLS0tLS0tLS0tLS0tLS0tLS0tIG1l c3NhZ2UgLS0tLS0tLS0tLS0tLS0tLS0tLS0gKDEgYWNrKQ0yMDAgMiBPSyAgDS0tLS0tLS0t LS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0t LS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoMikNRExDWCAxNCBndzEv ZXAwQGxhYjQucHJpdmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xIA1DOiAyIA1JOiAgDS0tLS0t LS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0t LS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoMiBhY2spDTIwMCAx NCBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAo MykNUlFOVCAxNSB0ZXN0SUQgTUdDUCAwLjEgDVI6IEwvaGQoTikgIA1YOiA0MDA5DS0tLS0t LS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0t LS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoMyBhY2spDTIwMCAx NSBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAo NCkNRExDWCAxNiBndzAvZXAwQGxhYjMucHJpdmF0ZS52b3ZpZGEuY29tIE1HQ1AgMC4xIA1D OiAyIA1JOiAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tLS0t LSAoNCBhY2spDTIwMCAxNiBPSyAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgZW5kICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2FnZSAtLS0tLS0t LS0tLS0tLS0tLS0tLSAoNSkNTlRGWSAzIGd3MC9lcDBAbGFiMy5wcml2YXRlLnZvdmlkYS5j b20gTUdDUCAwLjEgDU86IEwvaHUgIA1YOiA0MDA3DS0tLS0tLS0tLS0tLS0tLS0tLS0tICAg ZW5kICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NLS0tLS0tLS0tLS0tLS0tLS0tLS0gbWVzc2Fn ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAoNSBhY2spDTIwMCAzIE9LICANLS0tLS0tLS0tLS0t LS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0t LS0tLSBtZXNzYWdlIC0tLS0tLS0tLS0tLS0tLS0tLS0tICg2KQ1SUU5UIDE3IHRlc3RJRCBN R0NQIDAuMSANUjogTC9oZChOKQ1YOiA0MDEwICANLS0tLS0tLS0tLS0tLS0tLS0tLS0gICBl bmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0tLS0tLS0tLS0tLS0tLS0tLS0tLSBtZXNzYWdl IC0tLS0tLS0tLS0tLS0tLS0tLS0tICg2IGFjaykNMjAwIDE3IE9LICANLS0tLS0tLS0tLS0t LS0tLS0tLS0gICBlbmQgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0NDQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABfBAAAYAQAAG4EAABvBAAAywQAAMwE AADmBAAA5wQAAOgEAADpBAAA6gQAAPgEAAD5BAAAEwUAABQFAAAVBQAAFgUAABcFAAAkBQAA JQUAAD8FAABABQAAQQUAAEIFAABDBQAAWQUAAFoFAAB0BQAAdQUAAHYFAAB3BQAAeAUAAIoF AACLBQAApQUAAKYFAACnBQAAqAUAAKkFAAC3BQAAuAUAANIFAADTBQAA1AUAANUFAADWBQAA 9QUAAPYFAAAQBgAAEQYAABIGAAATBgAAFAYAAB4GAAAfBgAAOQYAADoGAAA7BgAAPAYAAD0G AABNBgAATgYAAGgGAAAA+gD69/D35vD38Pfw99zw9/D38PfS8Pfw9/D3yPD38Pfw977w9/D3 8Pe08Pfw9/D3qvD38Pfw96Dw9/D38PcAEwIIgQNqawMAAAYIAVUIAW1IAAQTAgiBA2ruAgAA BggBVQgBbUgABBMCCIEDanECAAAGCAFVCAFtSAAEEwIIgQNq9AEAAAYIAVUIAW1IAAQTAgiB A2p3AQAABggBVQgBbUgABBMCCIEDavoAAAAGCAFVCAFtSAAEEwIIgQNqfQAAAAYIAVUIAW1I AAQTAgiBA2oAAAAABggBVQgBbUgABA0DagAAAABVCAFtSAAEBG1IAAQACQNqAAAAAFUIAQA/ AAQAAFwEAABdBAAAXwQAAOsEAAAYBQAARAUAAHkFAACqBQAA1wUAABUGAAA+BgAAbQYAAKgG AADXBgAAFQcAAEQHAAB6BwAAqgcAAK0HAAD8AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAACrAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQwAARcaAAAABALpdNwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRMADcYFAAG2 IQoABRIADcYFAAG2IQoAAQAAAwEAAyQBABMABAAAXAQAAF0EAABfBAAA6wQAABgFAABEBQAA eQUAAKoFAADXBQAAFQYAAD4GAABtBgAAqAYAANcGAAAVBwAARAcAAHoHAACqBwAArQcAAK8H AAC8BwAAvQcAAHYIAAB3CAAAOAkAAEQJAABZCQAAaAoAAHkKAACYCwAAkAwAAJ0MAABUDQAA VQ0AAHQNAAB9DQAAjA0AAKQOAAClDgAAwA4AALUQAAC2EAAAxRAAAKYRAACnEQAAqBEAAMYR AADVEQAA1hEAANgRAADZEQAADxIAAD0SAABJEgAAfBIAALYSAAC/EgAA8hIAACgTAABWEwAA iRMAAMMTAADMEwAAzRMAABIUAABFFAAAexQAAKsUAAC2FAAAwBQAAPIUAAAsFQAANxUAAGkV AACfFQAAzxUAANwVAADkFQAAFhYAAFAWAABbFgAAjRYAAMMWAADxFgAA/RYAADAXAABqFwAA cxcAAKYXAADcFwAAChgAAD0YAAB3GAAAgBgAAIEYAADGGAAA/v78/Pz8+vr6/Pz6+vr8+vr6 AAD3AAAAAPf0APQAAPQAAPf39AAA9AAA9AAAAPf0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUCAgAFAQUCAQAFAAMCEwADAhIAAgEBYGgG AABpBgAAagYAAGsGAABsBgAAiAYAAIkGAACjBgAApAYAAKUGAACmBgAApwYAALcGAAC4BgAA 0gYAANMGAADUBgAA1QYAANYGAAD1BgAA9gYAABAHAAARBwAAEgcAABMHAAAUBwAAJAcAACUH AAA/BwAAQAcAAEEHAABCBwAAQwcAAFoHAABbBwAAdQcAAHYHAAB3BwAAeAcAAHkHAACJBwAA igcAAKQHAAClBwAApgcAAKgHAACpBwAAqgcAAKsHAAAfDAAAIAwAAGIMAABjDAAAZAwAAIsM AACMDAAA1hEAANcRAADZEQAA9e7r7uvu6+Hu6+7r7uvX7uvu6+7rze7r7uvu68Pu6+7r7uu5 7uvu6+7rr+7r7uuqAKoAoqqfqgCaAAAAAAAAAAAAAAAAAAAACQNqMggAAFUIAQQwSg8AAA8C CIEDalMHAAAGCAFVCAEJA2oAAAAAVQgBEwIIgQNq1gYAAAYIAVUIAW1IAAQTAgiBA2pZBgAA BggBVQgBbUgABBMCCIEDatwFAAAGCAFVCAFtSAAEEwIIgQNqXwUAAAYIAVUIAW1IAAQTAgiB A2riBAAABggBVQgBbUgABBMCCIEDamUEAAAGCAFVCAFtSAAEBG1IAAQADQNqAAAAAFUIAW1I AAQTAgiBA2roAwAABggBVQgBbUgABAA6rQcAAK8HAAC8BwAAvQcAAHYIAAB3CAAAOAkAAEQJ AABZCQAAaAoAAHkKAACYCwAAkAwAAJ0MAABUDQAAVQ0AAHQNAAB9DQAAjA0AAKQOAAClDgAA wA4AAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAD7AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAAAAAEMBAEXGgAAAAQDAXTcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAECAAABAQAAAQAAABXADgAA tRAAALYQAADFEAAAphEAAKcRAACoEQAAxhEAANURAADWEQAA2BEAANkRAAAPEgAAPRIAAEkS AAB8EgAAthIAAL8SAADyEgAAKBMAAFYTAACJEwAAwxMAAMwTAADNEwAAEhQAAEUUAAB7FAAA qxQAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAMAAA+E bvsDAgAHJAEAAQEAAAECAAABAAAAHKsUAAC2FAAAwBQAAPIUAAAsFQAANxUAAGkVAACfFQAA zxUAANwVAADkFQAAFhYAAFAWAABbFgAAjRYAAMMWAADxFgAA/RYAADAXAABqFwAAcxcAAKYX AADcFwAAChgAAD0YAAB3GAAAgBgAAIEYAADGGAAA+RgAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAdxhgAAPkY AAAvGQAAXxkAAGsZAAB0GQAAphkAAOAZAADrGQAAHRoAAFMaAACDGgAAkBoAAJgaAADKGgAA BBsAAA8bAABBGwAAVxsAAFgbAABaGwAAkBsAAMAbAADJGwAA0RsAAAMcAAA9HAAASBwAAHoc AACwHAAA4RwAAPUcAAD/HAAAGB0AACAdAABSHQAAjB0AAJcdAADJHQAA/x0AADAeAABFHgAA TR4AAH8eAAC5HgAAxB4AAPYeAAAsHwAAXR8AAGMfAABwHwAAoh8AANwfAADlHwAA5h8AAOsf AAAgIAAAMCAAAFEgAABpIAAAmyAAANEgAAACIQAADyEAABghAAAhIQAAUyEAAI0hAACYIQAA yiEAAAAiAAAxIgAAPiIAAEgiAABQIgAAgiIAALwiAADHIgAA+SIAAC8jAABgIwAAaiMAAHIj AACkIwAA3iMAAOkjAAAbJAAAUSQAAIMkAACJJAAAliQAAJskAADQJAAA4CQAAAElAAAZJQAA SyUAAIUlAACPJQAAkCUAAJUlAAAAAAAAAAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABQICAAUBAGT5GAAALxkAAF8ZAABrGQAAdBkAAKYZAADgGQAA6xkAAB0a AABTGgAAgxoAAJAaAACYGgAAyhoAAAQbAAAPGwAAQRsAAFcbAABYGwAAWhsAAJAbAADAGwAA yRsAANEbAAADHAAAPRwAAEgcAAB6HAAAsBwAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAD4Rg+gMCAAckAQABAAAAHNkRAABBGwAA WBsAAFkbAABaGwAAUSoAAGAqAABhKgAA/DAAAP0wAAD+MAAA9wDy7PcA3/fsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGANqrz8AAE9KAwBRSgMAVQgBaAgAbkgJBAAKQioBaAgAbkgJBAAJA2oTIwAAVQgB D09KAwBRSgMAaAgAbkgJBAAKsBwAAOEcAAD1HAAA/xwAABgdAAAgHQAAUh0AAIwdAACXHQAA yR0AAP8dAAAwHgAARR4AAE0eAAB/HgAAuR4AAMQeAAD2HgAALB8AAF0fAABjHwAAcB8AAKIf AADcHwAA5R8AAOYfAADrHwAAICAAADAgAABRIAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAB1RIAAAaSAAAJsg AADRIAAAAiEAAA8hAAAYIQAAISEAAFMhAACNIQAAmCEAAMohAAAAIgAAMSIAAD4iAABIIgAA UCIAAIIiAAC8IgAAxyIAAPkiAAAvIwAAYCMAAGojAAByIwAApCMAAN4jAADpIwAAGyQAAFEk AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAAHVEkAACDJAAAiSQAAJYkAACbJAAA0CQAAOAkAAABJQAAGSUAAEsl AACFJQAAjyUAAJAlAACVJQAAySUAANklAAD6JQAAEiYAAEQmAAB6JgAArCYAALImAAC3JgAA xCYAAMkmAAD9JgAADScAAC4nAABGJwAAeCcAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAdlSUAAMklAADZJQAA +iUAABImAABEJgAAeiYAAKwmAACyJgAAtyYAAMQmAADJJgAA/SYAAA0nAAAuJwAARicAAHgn AACyJwAAvicAAPAnAAAnKAAAWSgAAG0oAAB1KAAApygAAOIoAADuKAAAICkAAFcpAACJKQAA nSkAAKUpAADXKQAAEioAAB4qAABQKgAAUSoAAGAqAABiKgAAmCoAAMkqAADTKgAA2yoAAA0r AABHKwAAUisAAIQrAAC6KwAA7CsAAPIrAAD3KwAAKSwAAGMsAABvLAAAoSwAANcsAADwLAAA /SwAAAUtAAA3LQAAcS0AAH0tAACvLQAA5S0AABcuAAAdLgAAIi4AAFQuAACOLgAAmi4AAMwu AAACLwAAMy8AAD0vAABFLwAAdy8AALEvAAC8LwAA7i8AACQwAAA9MAAASDAAAFIwAACEMAAA vjAAAMowAAD8MAAA/TAAAP4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABQICAAUBAFh4JwAAsicAAL4nAADwJwAAJygAAFkoAABtKAAAdSgAAKcoAADiKAAA 7igAACApAABXKQAAiSkAAJ0pAAClKQAA1ykAABIqAAAeKgAAUCoAAFEqAABgKgAAYioAAJgq AADJKgAA0yoAANsqAAANKwAARysAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAD4QU+wMCAAckAQABAAAAHEcrAABSKwAAhCsAALor AADsKwAA8isAAPcrAAApLAAAYywAAG8sAAChLAAA1ywAAPAsAAD9LAAABS0AADctAABxLQAA fS0AAK8tAADlLQAAFy4AAB0uAAAiLgAAVC4AAI4uAACaLgAAzC4AAAIvAAAzLwAAPS8AAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAAdPS8AAEUvAAB3LwAAsS8AALwvAADuLwAAJDAAAD0wAABIMAAAUjAAAIQw AAC+MAAAyjAAAPwwAAD9MAAA/jAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAADEkAA+EYPoAAQAAAA8cAB+w0C8gsOA9IbAIByKw CAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABf AFQAbwBjADQANQA4ADIANgAxADAAOQA2AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCq AEupCwIAAAAIAAAADgAAAF8AVABvAGMANAA1ADgAMgA2ADEAMAA5ADcAAAB9AAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADUAOAAyADYAMQAw ADkAOAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQA bwBjADQANQA4ADIANgAxADAAOQA5AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEup CwIAAAAIAAAADgAAAF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADAAAAB9AAAARAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADUAOAAyADYAMQAxADAA MQAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBj ADQANQA4ADIANgAxADEAMAAyAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIA AAAIAAAADgAAAF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADMAAAB9AAAARAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ yep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADUAOAAyADYAMQAxADAANAAA AH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQA NQA4ADIANgAxADEAMAA1AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAI AAAADgAAAF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADYAAAB9AAAARAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5 +brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADUAOAAyADYAMQAxADAANwAAAH0A AABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQANQA4 ADIANgAxADEAMAA4AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAA DgAAAF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADkAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO EYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADUAOAAyADYAMQAxADEAMAAAAN8AAABE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtuAAAA bQBhAGkAbAB0AG8AOgBTAHkAcwB0AGUAbQBJAGQALwBTAHkAcwB0AGUAbQBUAHkAcABlAC8A QgBhAHkATgB1AG0ALwBtAG8AZAB1AGwAZQAtAG4AdQBtAEAAaQBwAEEAZABkAHIAZQBzAHMA AADhGgAARABkACADWAIAAAAAAAAAAAAAAAAAAAAA4C4oI3gDKgMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8ABPCGAAAAsgQK8AgAAAABBAAAAAoAAGMAC/BiAAAABEEBAAAA BcE+AAAABgECAAAAgQERAAAQvwEAABAA/wEAAAgAaABpAGcAaAAgAGwAZQB2AGUAbAAgAG0A cwBnACAAZgBsAG8AdwBcAGkAbQBnADAAMAAxAC4AZwBpAGYAAAAAABDwBAAAAAAAAIBiAAfw BxoAAAYGwPX+shqRMMuY3WBQTLDglv8A4xkAAAEAAAB2CAAAAAAYARBuHvDbGQAAT0MiECBE 43FRYnY7yo8Gc8D1/rIakTDLmN1gUEyw4Jb/iVBORw0KGgoAAAANSUhEUgAAAyAAAAJYCAMA AACtqHJCAAADAFBMVEUAAAAzM8zMzP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARTBVmAAAAAWJLR0QAiAUdSAAAFmhJREFUeJzt nYt228iuBfsM//+fb64lkuBDIAmRanTvqjVx7FjKuCCU9YhElwEAPlJqfwEAmSEQAAcCAXAg EAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIB cCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAH AgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQ AAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFw IBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAIdc gZRSVu+Y97pnx75P/T3RZJs4kezLMl2Mv3e5Ivts7IdO3Xf8spom+7LWkytD3tHdz863h2pf y6PsfSdIqprsy/o3pteozBVHsi/xQdb23V59bi/mtKLJvqy/gf3/rN6/JZ7cA6ztx1/dsbmY S1rPZF9WGW9TTYEoFbK27ziQYSma1zPZl/W67l0EknZ097O27zmQlWjaG5PJviqZGxm7yNhv b0mn9cz1ZZWR8UZp2m8sT7Cx71V/K0ogAE2SK5Dygdpf12+QsW9JNOUXBZAFAgFwIBAABwIB cCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAHAgFwIBAABwIBcCAQAAcCAXAgEAAH AgFwIBAABwIBcHgokP9V5hkr7LOZWp4xfCqQ/6pSOxAZ+8qmFgKpPyzsk5laCKT+sLBPZmoh kPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzs k5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA 6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBP ZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKp Pyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6Z qYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+ sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2Sm FgKpPyzsk5laCKT+sLBPZmohkPrDwj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkPrD wj6ZqYVA6g8L+2SmFgKpPyzsk5laCKT+sLBPZmohkBuHVf4xuZfy+vDfO//+qEx0a38jBBIk 9Yr8xfEuwnz8+m/xq0f7WyGQIKlXZG5jHYj5iEAaMLUQyF3DMlce49v3H02fIZA2TC0Ectew dgIZTCGvX9wHacHUQiB3DetjILdce2S3vxcCCZJ5RfYC2bmT3qn9vRBIkNQrUub7G38fllLG N+ODvt8Vktr+VggkSOoVmbb/yyuKNu17MrUQyI3DKhH38zklt78RAgnS44qcv+HVo31KUwuB 1B7W+fsmPdqnNLUQSO1hnb/73qN9SlMLgYSHVW6mLftHIZAg28H9W6z/yvh7eb/9e2/vVJco r//MX5XuJpbx2tFbWo+z+XjyI6oH8vGyPjA/yd/lvfnbGg+klNev99vXG/On61OZYZwdmDlr tjvp5ovb3ZLPU9g5+eFwageyf1nvuWwu71OxjN8Qf2L9o0De81oPbTUgc6oLE5vn9XQgN9jv fB/dWC8DcSaQM5APl/VOINvL+/T3wz4Dmd9fBbL97lreszVXz6//3p8q40ev6/BfXIPcYj9/ 1TufLfPnxonMo5m052F8iCdFIJvL+r9j888X9/by7juQl/48v00g83SW/82fWtyo/8k1yC32 08LsrImRngOxc5h/212Rh1fljKlzWXuBHF/cm8u7w0DK/A1yHcjOqczEymJi8wY1Gcj2+/76 O+7yW0YpZk3mMpIHsnNZf7iJZU7pXdwKgUxK8wc7gZgr0nkxVu+t/raGbmLtXbKLGxrLqSzm MZ80fyA7l/WHQMY3Rxf3+vLuLJDFBboNxH5mMalxFczEzKf+ey/RprVkgby/4PevzXKPn7Vm cyDjAMy7uQP5cFnPqW9PeeLiXl/evQUyfSNYDm11bTCfytwp3X5zKdPCLQY2jyxbILPneKNi cfHO3ySnfzlY3CUvs7MdStI76Wcv6625e3FvbmGt7FsP5HY+fPt8clj17EvZLEQK+x/+S/qR fdOBlJ/x6LDy2f9yVU6Y/vayXvo3Hcj9+N9OcwVyj+/pK5Aur0GO7QnkAscvmCrm0IrDfCiT +YmNV5571Zj9jfBkxSCpV2TsYP3i2/Fl6mM74cM3pLa/FQIJknpFypTBMAdSFoHYo510Zn8r BBIk84qMx8BavL8MpBBIE6YWArlrWHuBfLgG4T5IblMLgdw1rPWB3ac7HPY+yPzJzuzvhUCC ZF6R9ZGqdwMxEfVlfy8EEiT1ipijU483pczhFQf7MG+H9rdCIEFSr8i89w8dWjG1fU+mFgK5 cVhl8ZuafT+mFgL5clhPHYi3Dfs+TS0E8tWw4ncoerDv1dRCIF8MK/60qh7s+zW1EEh4WNPz D+96knVT9o9CIEGSrQjXIH2aWgjkm2ERSJemFgL5blgE0qGphUC+HRaBdGdqIZD6w8I+mamF QOoPC/tkphYCqT8s7JOZWgik/rCwT2ZqIZD6w8I+mamFQOoPC/tkphYCqT8s7JOZWgik/rCw T2ZqIZD6w8I+mamFQG4c1uLQo+aZjONzfufXqXNcrMymlnPWZ5+QPZ8hOhqf1CvyOu7VfFi4 +ZhYZTwu6fvwi+MRsnqyv5XGArnymoXxLN+M5zOpV8QcEmsRyJjLHEbwCY6p7W+lrUCmMC4U IhhIKau389hebwmkFVPLyUDW7x2eJz4cj8wrYg+qOL6xR5Eb74IMBJLd1HL2GuTibSwC2Q1k IJAWTC0EctewxrvgNpDlnfSBQLKaBo4gsGjhffuZR7GOnMfbUIN9bHfx7vhhb/a30tY1yMDD vKeG5Rx69J7X5aa2v5XWArn8KK9kIN6hR6NXGi3Z3wiBBEm4Ihy0oT9TC4F8Naxbrhmate/V 1EIgXwzr4h2zzuz7NbXkebLimQZTrcj0BcceI9xyNKFU9o9CINsznFqUZCvCNUifppYkgUyb 5q9cuhUhkB5NLYkCWb+3Q8IVIZD+TC2JAjlxG0tnRbTtCWRzegI5RseeQPbOcuL5Xjorom1P IHtn2Vx9nH14tPVhnYVAKnDN+vSDNtcDOfXPATorom3faiDzK6wPT3l5JgRyiI49gez93QRy gI59S4GU8bkUA4EQiIap5fAlDsU8vPRkIKfQWRFt+6YCKQRydlgPo2PfVCDvtwRy8hWF41ET ze3F9zeZYm6wRgaU3P5GGguEa5BTw5qPWLJ6bzyqyXjck+kAcj3Z30pDgUzf+Kbn2p4ylAzk 78107JLVt5Txlur4md7sb6WlQP64fIkKBvIuwx4Xyx4Fi0DaMbUQyF3D2jtw3PrIiotkurK/ l9YCuX6nUjWQ9/3vT4FwZMUmTC15nqw4n/dzjplXZHrEyr5Z3EkfCKQNU0u+QLyHylKviA1k sI/tLt4dIlfIDdjfCoF4Z202kLJ979MfhEhtfysEsj75ySd8JVyRxQtYPspHrzSy2z8EgaxO ffYJX/lW5I7FP0s++05NLUkCOfmEr2wrEn3SSIxs9t2aWpIE8n7bViDHT8+/l1z2HZta0gTS 3jXI9PqVDy+Vv8zRmFLZPwqBrE9+8glfyVaEa5A+TS05Anmd5/hM6VaEQHo0tRDIl8MikP5M LXkC4VY49klMLXkCOYPOimjbE0gQnRXRtieQIDor0pD9+7Fu88H4ZP/h/EPYqUwtBFJ/WE3b m6csjx/vPG/oYiEEEiTlivyMlPZl9RzNORDzEYGsIRAR+/cTCd7vDtODkaunZhPICgIRsV+9 TsG+0HiOg/sgGwhExH68KTWsAwlfeyQwtRBI/WG1bF/WBzPav5PelqmFQOoPq2n78UGsYZjv grzfmCc8t2VqIZD6w2raftr+O5+URiBBUq7Iz8hkb3Iw1x+dmFoIpP6wGrR/+Fn+BBIk0YpU II39468TI5AgaVakCknsg3e8GzK1EEj9YbVlPz0y9dXr7w35TC0EUn9YrdlzDfI9BNK1PYF8 C4F0bk8g30Eg2LdraiGQ+sPCPpmphUDqDwv7ZKYWAqk/LOyTmVoIpP6wsE9maiGQ+sPCPpmp hUDqDwv7ZKYWAqk/LOyTmVoIpP6wsE9maiGQ+sNq3H46juL0B+MPezHPR7z2/C0CCZJ0RX5E Svv5sAzLF9+OPxW+lPmYJ6cLIZAgKVfkZ6S0f3cwzL+NPy9sGAOxRztpwtRCIPWH1bL98mfn vf5oWAZSCGQLgYjY20PxTgeM278G4T6IgUBE7LeBjPfZzX2QYbhw7ZHA1EIg9YfVsv2pQMzV SxOmFgKpP6ym7d8Hqh7fHcyRFe3Du9deg0ggQVKuyM9IaT/v/Y0vMiSQIClX5GcktV89yNuB qYVA6g9L0t69viGQIF2tiLa9e6eEQIJ0tSLa9u6TswgkSFcrom3vHFexuqmFQOoPqy37u444 6hVCIEFyrEgturLnJtYTdLUi2vbcSX+CrlZE256HeZ+gqxXBPquphUDqDwv7ZKYWAqk/LOyT mVoIpP6wsE9maiGQ+sPCPpmphUDqDwv7ZKYWAqk/LOyTmVoIpP6wsE9maiGQ+sPCPpmphUDq Dwv7ZKYWAqk/LOyTmVoIpP6wsE9maiGQ+sPCPpmphUDqDwv7ZKYWAqk/LOyTmVoIpP6wsE9m aiGQ+sNq3P794tliPxjfHX9WSPFfYpvM1EIg9YfVtP24+/bnTE2Hsp4Kef/UEAKZxvbMX5ty RX5GSvsyv10EMuYyh3Hh2L0EEiTlivyMjPbFBvI+0rvJgUA+QCAi9juBLH5YyHgXZCCQBQQi Ym9+MsjHQNY/BTe9qYVA6g+rZfu9QJZ30gcC2YFAVOxtIIN9bHfx7vhhG6YWAqk/rKbtnZ8w Ff+RUwQSJOWK/Iyk9p9/wtSVK41MphYCqT8sSXu3HQIJ0tWKaNu7zzwhkCBdrYi2vfPTQaqb WvIE4v1AlZGuVuQyOezv+sE53uVNINszHIzsRY4VqUVX9u5FTSCb089P4fEK6WpFLtOVfebL 2ZIokPV7O3S1Ipfpyp4foHPt9Ic3S//oakUuo2NPIJvTE8gxOvYEsneWMj0T9CM6K6JtTyB7 Z9lcfZx9oLD1YZ2FQCpwzvr4Adj1GS7P5MyjvLUHRyAappYz1uf+jWJ5lsszIZBDdOzbCuTk v1Esz3N5JgRyiI59e4Gs3zs8z+WZEMghOvbtBXL1NhZPVsS+XVMLgdw7rCdJaj8fHG5o9siK Jx4r3cHM4MS/UayG9ghJV+RHpLSfV0P5yIrXrj4GAtGxHzMYlI+sePUGFoHI2I/HL7Hv6x1Z kUAuDOs5MtrvBCJ4ZEUCuTCs58hoX8qqCckjKxLIhWE9R0b7vUA4suIx3wTidJhxRX5HSnt7 E2tYHk7RvDt+2IapJWEgzrealCvyM1Lac2TFEATyAEnty+K3xWeu/MtAIlNLjkCmf2p9f/Tp dElX5Ed0ZZ/5OXeWFIFM/xp7dG+uqxW5TFf27rULgaxOXQqBHNOVvfuoKIGsTj12QSAeXdm7 /3DQbCCn73RdD4RrkENy2F9/0qtPQlPLxcv8oae7l/czEqYXLn44XY4VqUVX9p3exHry9SAn /u6uVuQyXdl3cyf97COwq3OdO9nq/3R4kq5W5DJd2ffyMO/pR2BXZzt3suX/6fgv72pFLqNj 31QgJx+BXZ3tywl9QGdFtO2bCuT9lkAIRMXUciYQrkFODuthdOwbCuT0I7Crc305oQ/orIi2 fUuB/HH5SZkEgn27phYCuX1Yj6Fj31og15/XTyDYt2tqSfFkxdPorIi2PYEE0VkRbXsCCaKz Itr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNueQILorIi2PYEE0VkRbXsC CaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNueQILorIi2PYEE0VkR bXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNueQILorIi2PYEE 0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNueQILorIi2 PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNueQILo rIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRWRNue QILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8gQXRW RNueQILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiuibU8g QXRWRNueQILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5AgOiui bU8gQXRWRNueQILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2J5Ag OiuibU8gQXRWRNueQILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCdFdG2 J5AgOiuibU8gQXRWRNueQILorIi2PYEE0VkRbXsCCaKzItr2BBJEZ0W07QkkiM6KaNsTSBCd FdG2J5Ag/6vMM1bYZzO1PGP4UCAAfUAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAO BALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAg AA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALg QCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4E AuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAA DgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBA IAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC 4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAOBALgQCAADgQC4EAgAA4EAuBAIAAO BALg8H+WEoJtGaeb4QAAAABJRU5ErkJggpwcAABEAGQAIANYAgAAAAAAAAAAAAAAAAAAAADg LigjigOKAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8IYAAACyBArwCAAA AAIEAAAACgAAYwAL8GIAAAAEQQIAAAAFwT4AAAAGAQIAAACBAREAABC/AQAAEAD/AQAACABo AGkAZwBoACAAbABlAHYAZQBsACAAbQBzAGcAIABmAGwAbwB3AFwAaQBtAGcAMAAwADIALgBn AGkAZgAAAAAAEPAEAAAAAQAAgGIAB/DCGwAABgZiaBzEjIum1XjwYuvqz+61/wCeGwAAAQAA AFcjAAAAABgBEG4e8JYbAABx+zMXnl8MuhB7Zjt48wLQYmgcxIyLptV48GLr6s/utf+JUE5H DQoaCgAAAA1JSERSAAADIAAAAlgIAwAAAK2ockIAAAMAUExURQAAADMzzMzM/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFMFWYA AAABYktHRACIBR1IAAAYI0lEQVR4nO2djXqjyhEFyfL+75zEEnBAqAWjQX1mqPpuduW15Lha U/rBgIcRAN4yZH8DAM4QCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACB AAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhA AIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQ CEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEA BBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAA gQAEEAhAAIEABBAIQACBAAQQCECAVyDDMGwuyKXu2bHvU39P1Gwlzph9W9LF9HeXS2SfF/ux U/cdP1dTs29rO7lh9B1dfXYeHtK+l0vZeyQwVTX7tv43pseo5InD7Fu8kK19t0+fr3ezrajZ t/U3sP/P6vmX8eQuYGs//a87Xu7mwdbT7NsaptdUcyB3KmRr33Eg41rU19Ps23o8964CsR1d fbb2PQeyEbV9MWn2Xd3mRcYut7F/fSVt6+n1bQ0T04tS2weWK3ix71X/VZRAAJrEK5DhDdnf 12+4jX1LopbfFIALBAIQQCAAAQQCEEAgAAEEAhBAIAABBAIQQCAAAQQCEEAgAAEEAhBAIAAB BAIQQCAAAQQCEEAgAAEEAhBAIAABBAIQQCAAAQQCEHBRIP9J5hor7N1MlWsMrwrkXyrZgdzG PtlUIZD8YWFvZqoQSP6wsDczVQgkf1jYm5kqBJI/LOzNTBUCyR8W9mamCoHkDwt7M1OFQPKH hb2ZqUIg+cPC3sxUIZD8YWFvZqoQSP6wsDczVQgkf1jYm5kqBJI/LOzNTBUCyR8W9mamCoHk Dwt7M1OFQPKHhb2ZqUIg+cPC3sxUIZD8YWFvZqoQSP6wsDczVQgkf1jYm5kqBJI/LOzNTBUC yR8W9mamCoHkDwt7M1OFQPKHhb2ZqUIg+cPC3sxUIZD8YWFvZqoQSP6wsDczVQgkf1jYm5kq BJI/LOzNTBUCyR8W9mamCoHkDwt7M1OFQPKHhb2ZqUIg+cPC3sxUIZD8YWFvZqoQSP6wsDcz VQgkf1jYm5kqBJI/LOzNTBUCyR8W9mamCoHkDwt7M1OFQPKHhb2ZqUIg+cPC3sxUIZD8YWFv ZqoQSP6wsDczVQgkf1jYm5kqBJI/LOzNTBUCqT6sYRyGYR7B4/KT5dLwvFZ39lUgkEIaWCJ/ q375Yy7k77/nvw7PK/RnXwkCKaSBJfJn/mjjGcgzjbmXqZPTM2rAvhIEUoj/EhmGlz+3gQwE Ym6qEEjdYe0FMr/Kev6jfLIz+1oQSCH+S2Q3kHEdyOrvruxrQSCF+C8RAqkBgRTSwBJ59LBs pZouzu89pnjOF9KAfSUIpJAGlsiy7gueI5q378NUIZDqwxpWf93NvgdThUDyh/XHgZdcHdt7 mSoEkj+sP4bP70o6tvcyVQgkf1h/zHtr3dLey1QhkG+HNVSmLftrIJBCOl4iPIP4mCoEkj+s P3gP4mOqEEj+sP5gK5aPqUIg+cP648DEOrb3MlUIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB 5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgRSfVirU4/K LojL+UafF84elt6EfRUIpJDXwf1vkf0bpr+H559/l/audYrh8Z98qYPHpD+X/nJqk/lMpMMS z3wu0hr2j+82+OwyoX9vr/6J9EDe3tcfzA/yd3+/fLXGAxmGx/+efz7+kH/dXkuGcXRgctOD ZzWZk/j7eNCz/gzLSXrPn9QhsP+3u0reT2Hn6h+Hkx3I/n295/Jyfx+KZXpA/In1jwJ5zms7 tM2A5FonJrbM60wg08up+fL0QuqCQNTr9XH0xXodSDABz0De3Nc7gbze34cfD/sMZLm8CeT1 0XV4zlaenh//PT81TB89nsPPP4PsBKLnep/fgozVAnneu/LYuv3ssHxumsgymll7GcabeCwC ebmv/302f393v97ffQfy0F/m9xLIMp31f8unVi/qS59B9CSKO4GMVwQiD6ubz4r0EojOYflr d4lcvFSOmAb3dRTI57v75f7uMJBheYDcBrJzLZnYsJrYsoJqBLL+LSGrN+njJYG8Pu5vH3HX DxnDIMtkKcM8kJ37+s1LLLlmdHffIZBZaflgJxB5Il0WxubS5qsVvcR6nsx9fpO+bNtdXRzn ir61n+7cl3t29UJjPZXVPJar+geyc1+/CWT649Pdvb2/OwtkdYe+BqKfWU1qWgoyMfnUv+ci emnty1OPfnsu0l37f9P/Xhb39Fk1WwKZBiAXvQN5c18vqb9e88Ddvb2/ewtkfiBYD23zbLBc S96Uvj64DPOCWw1sGdm3px49/6RxzH5yGtZ37/IgOUwvMlZvyYfFWYdi+ib96H39ah7e3S+v sDb2rQdSnTcPn5+GVf1M1T+xH4aXBVFk72/6lk/2TQcy/IwPw/r/Va4xzrH/5VI5YPrb+3rt 33Qg9YkfTt8M6zHUa4wvtn9bw3H7Rkz3+WxPICcITz1a7RykTdlfAzsrFuK5RBp+Bqlg36Gp QiA1hkUgXZkqBFJnWATSkalCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzs zUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj1Ya1OPTqf6Oe5 Q6PstHt6/60m7KtAIIU0sEQeJy5ZzqU4FaJnNJnOBNSffSUIpJAGloieEuv5D0szo5755/SM GrCvBIEU4r9E1ucZfYxiE8hAIOamCoHUHdbmpIrjdKKs7TNIyf7x/va1IJBC/JfIbiDrtySr K/ZlXwsCKcR/iUy//YNAvoFACmlgiTzPKjoP4fmWY3nvMZ/FmvcgrqYKgVQeVnDq0RvY92Gq EEj1Yb0/9egd7HswVQgkf1h/HHjJ1bG9l6lCIPnD+uPAubU6tvcyVQgkf1h/fDqtYt/2XqYK gXw7rFpnHP145lFL+2toLpDPd972BqWjiel4iRwYcMf2XqbKsS2XRx7f1jf5Zjzv6XiJHBhu x/ZepsqhHw7LD7cOrnwCOcuByXZs72WqHAxke+njbcqHE3GfJXJv+/YCOfsai0Cwb9dUIZC6 w7qS+9j/3PTbDY7PI0bZipXKfezbegYZ2cx7aliXcR/71gI5vZWXQLBv2FQhkNrDuo772BNI IfdZIve2J5BC7rNE7m3fWiDnKQjkSINNLJHtSUuG5Xeorz8+e8xhE/ZVIJDXGxz6UUsDS2Q+ JZaeneH54Xwqh+njczNqwL4SBPJy/SmMuJAGlshypgY9i8kSyPpkWadowL4SBPJy/WF5wG06 kPkcJuvTK+rpTPSap/C3rwWBvFz/zY/wN/gvETkv1jYQPVnWOBYU4m9fCwJ5uX5Xgehb8LeB 8BLL1lQxCWQ8tr+X/xKR8yeuzkK6fpM+6umsD+NvXwsC2bvJzi6Sx7AalgQiGvMf8vHp5xAC SeCc9eGfFZ4P5MhW3uzBnTqzYvUTK7Zg34epcsp6OPy64L6BzM8hpyfwkSbsezBVCKTOsOo/ X7Rk35mp8tF6egEtPwQ+wN0COb9JqgBb+95MlU/W87al9U+CP3GvnRU/dd23fX+myudABgKJ h/X5ia9n+x5NlQPPIONIIMGw5leGR7dKf6Ip+2toLBCeQeJh8QzSmaly6E267Gl32c9BDuG6 RAikK1Pl6FlNThreLBA283ZlqhBI9WFdxn3sWwvk/CsIAsG+XVPFZ2fF5bbvc7zPErm3PYFE Nw02ld1nidzbnkCimxLIG+5jTyDbqx/c4es+S+Te9gSyufbRHb7us0TubU8gm2sf3eHrPkvk 3vYEsrn20R2+7rNE7m1PIJtrH93hq4klMh2A/lSbt1pPezTKWy6OSbc0VSwCObzDVwNLZApA z4ulGx+G5/kcHg8Ip6bUgH0lCGT3Np9v1MASGRb7VSBz/HMYnBfL1VQhkLrDWj8VjpsPCKQJ U8UnkCMvyf2XyBTI/BprWJ1RcVhegRGIraniE8gR/JfIIC+v3gUyEoi3qUIgdYc1vRWfLr++ SR8JxN1UIZDKw1peQo3zW5DpeWO5OH3Ym30lCKSQBpbIsupf1v+3Rx02YF8JAimkiSUyrP5a fea7Q9ebsK8CgRTiu0Q4Jr0jU4VAagyLs5p0ZaoQyPfD4rxYnZkqBPLtsOYTIp4/h+I+TdnL HMZlA/e3+2gSSCGeS4RnkPXuZquPi/bRJJBCXJcIgdTdR5NACvFdIjcPpPI+mgRSiPES+QHG 9vMLqbHKPpoEUojxEvkBxvZHAjmxCxqBFGK8RH6Asf1eIF/so0kghRgvkR/gbP983yEXv9lH k0AKcV4i1+NsX3cfTQIpxHmJXI+3fc19NAmkEO8lcjU92u+nQyCF9LhE7m2//+RCIIX0uETu bb+/lw6BFNLjErm3/f4OmgRSSI9LpE37Wrsu7+/CTCCFOC2R39Oj/f6e0ARSSI9L5N72+5uA CaSQHpfIve3ZzFuVHpcI9namCoHkDwt7M1OFQPKH1Yf98+32MH8kh+vLRq83Pxq0MlUIJH9Y PdhP52OY31VMl2VX92l3eHtThUDyh9WD/bD8OV18pDH3sj7tibWpQiD5w+rAftBAnplsAhkI RAd2zZc1XiI/wNh+L5Bx/YrrzK/VIpBCjJfIDzC2H/TFlRxXqIGs/rY2VQgkf1gd2BPISQjk Zvart+fjfB6T5b3HfHoT3oMso6qO8xK5Hmf74Jj09kwVAskfVh/2749Jb85UIZD8YTVsf9EZ VwmkEMMl8kPs7A++o2jOVCGQ/GE1ar9/rFMPpgqB5A+rSfv9Y2X7MFUIJH9YLdqv9s6tflA6 gRTitER+j5k9zyBfQCB3sCeQYgjkHvYEUgiBYN+uqUIg+cPC3sxUIZD8YfVh/zjafLnjZQvX +uMDr8sIpBDvJXI1zvbPo8+H1X7tzw9Xv4ptOLI4CKQQ5yVyPc722+Uvx93KYSHTYYbmpgqB 5A+rA/vpoI9xTmE5/c/6UFuOB3mM4Zova7xEfoCxfRCI/jrocTxWCIEUYrxEfoCx/fYdx/tA eIn1GMM1X9Z4ifwAY/uXQKZzxK3epI96IiBjU4VA8ofVg728xJr+ZdquO7/0el488BxCIIU4 L5HrcbY/9ybc3FQhkPxh9WEvpzRp3VQhkPxh3dmeX6BTlR6XyL3t99+QEEghPS6Re9vvH3RF IIX0uETubb9/ZDuBFNLjEmnTvtKR6PuHpGebKgSSP6w72+8f2E4ghfS4RO5tv39YO4EU0uMS ubc9m3mr0uMSwd7OVCGQ/GFhb2aqEEj1Ya0Ozn68xp533Nscn31uz6Um7KtAIIU0sES2B2dP gYxy6OnczLk5NWBfCQIppIEl8npw9iqQJZ1D+323Zl8JAinEf4m8Hlo3zi+l1oGc3zPc374W BFKI/xKRX1n5MZCzhfjb14JACvFfItM7j/HQMwiBWJoqBFJ3WHLKguVUUKv35uP2o47sa0Eg ezfZ37FzRQNLZFg9izy3+O5s5p3+6cSEGrCvBIG83uDtnp1KA0uk7sHZrdn3YaqYBDKHERfS xBKpeXB2e/Y9mCpGgWwv7eC7ROo/X7Rk35mpYhTIgddYtkvk7AapImztezNVCKTCsD5uXKiD qX1/popJIKPsxBRguUQObH2rg6V9j6aKUyDbhbZ78PIOucOav++j3+4n3k6IQBI4uGHm7KPk +UAOLJD0wb0Z1snZFONp36GpcmzT/qHVu7rJ6Zk0HMiHTW/VcLXvzlQ5tPfEcORnFOvbnJ5J 04GwmbcrU+VgINtLH29zeiaNB/IL7mPfXiBnX2PddmfFK7mPPYEUcp8lcm/7n5se38a438KR n1GsIBDs2zVVbDbzHuI+S+Te9q0FcnorL4Fg37CpQiC1h3Ud97EnkELus0TubU8ghdxnidzb vrVAzvNNIEGH91ki97YnkPjGBHJzewKJb0wgN7cnkO3Vp8Mpnh+9u959lsi97Qlkc+31GdEJ 5O72BLK59jAQyGfuY08gm2tPXRBIxH3smw3kor15H79No5dAnu+lhtXvCFneX01nHJ3fdx2e lbd9Te1mAzm8Q2/Bm/T5cKxgeN5L5Kky/09+B8Lm/NXTKno8KhydkrP92vVbbQIp/NrOS0TM JZBxtVLmR4B5hZw5VNfZfl3Ft9otBXJ0C+zrvM7SRSDDSyDP1x26ePoLZHgJ5CvthgI5vAV2 c7NjV1v/P33+4sZLZLYYdwNZL6FhfjvXeSCF2k0FcnAL7OZmx652FuMlMokfDeTkQM3tDwdy TLupQEYxJZCP4u8CWX9mvEsgZdqNBcIzyMFhPc2H1YuJ8fkP81bQ+eL0YQ/2qr2SK9JuKJBR rY/fnzcOZIg+PPeU0ZB9Xe2WAinQG28YiExI3XfmcOpJoxH72toEUojtEile9F3Yf8H+3FoL 5PyD3r0CObXDSHf2X7E/udYCKfC+5staLpGTh+t3Zv8l+7MjkEIcl8h8PouhEk3Y15LdlyaQ QpyWiMjG67pz++/Ynx2BFOK6RAiklP3JEUghvkuEQMroYytWgfc1X7bHJYK9nalCIPnDwt7M VCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9 malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8L ezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskf FvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSS PyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UI JH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aq EEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7M VCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9 malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8L ezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskf FvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSS PyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UI JH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9manSWCDJXGOFvZupco3hRYEA 9AGBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAE EAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACB AAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhA AIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQ CEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEA BBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAA gQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAAIEABBAI QACBAAQQCEAAgQAEEAhAAIEABBAIQACBAAQQCEAAgQAEEAhAwH8BSnR4IydjSnIAAAAASUVO RK5CYII7GgAARABkACADWAIAAAAAAAAAAAAAAAAAAAAA4C4oI5YDlgMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA8ABPCGAAAAsgQK8AgAAAADBAAAAAoAAGMAC/BiAAAABEED AAAABcE+AAAABgECAAAAgQERAAAQvwEAABAA/wEAAAgAaABpAGcAaAAgAGwAZQB2AGUAbAAg AG0AcwBnACAAZgBsAG8AdwBcAGkAbQBnADAAMAAzAC4AZwBpAGYAAAAAABDwBAAAAAIAAIBi AAfwYRkAAAYGfwkHB6p5vFvo7m9r5eSl4f8APRkAAAEAAADzPwAAAAAYARBuHvA1GQAA/Zww DQyYyXRwgeFBBAR5IH8JBweqebxb6O5va+XkpeH/iVBORw0KGgoAAAANSUhEUgAAAyAAAAJY CAMAAACtqHJCAAADAFBMVEUAAAAzM8zMzP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARTBVmAAAAAWJLR0QAiAUdSAAAFcJJREFU eJztnYl26kgSBTXN///zdBstVwupBYm8VRVxum38DD6OVAUCDKJ7AcBHuuxfAMAZAgEIIBCA AAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQgg EIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIB CCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAA AgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQ gAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEIIBCAAAIBCCAQgAACAQggEIAAAgEI 8Aqk67rFCTlVPRv2depviZqtxBGzX0u6GD5XuUS2Wdm/KnXf8HM1Nfu1lpPrXr6ju5+Nq4e0 3+VRtq4JTFXNfq1/x/Qelew4zH7FB1naV7v7XG9mW1GzX+tvYP/Nqv9kPLkHWNoP/1fHajN3 tp5mv1Y33KYaA2mpkKV9xYG85qK+nma/1nvfOwvEdnT3s7SvOZCFqO2NSbPfqpkbGZs0Y7++ JW3r6fVrdQPDjVLbK5YnWNnXqr8WJRCAIvEKpPtA9u/1G5qxL0nU8pcCcIFAAAIIBCCAQAAC CAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBA AAIIBCCAQAACHgrkf8k8Y4W9m6nyjOFTgfyTSnYgzdgnmyoEkj8s7M1MFQLJHxb2ZqYKgeQP C3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJ Hxb2ZqYKgeQPC3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNVCCR/WNibmSoE kj8s7M1MFQLJHxb2ZqYKgeQPC3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNV CCR/WNibmSoEkj8s7M1MFQLJHxb2ZqYKgeQPC3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9m qhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJHxb2ZqYKgeQPC3szU4VA8oeFvZmpQiD5w8Le zFQhkPxhYW9mqhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJHxb2ZqYKgeQPC3szU4VA8oeF vZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJHxb2ZqYKgeQP C3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJ Hxb2ZqYKgeQPq3D77tV13bjJ36d7plNdf64iTBUCyR9W0fZ/q376MBby91//r11/hlJMFQLJ H1bR9n9b+t1GH0ifxtjL0MmJNUEgF7FcIj/D0b7rVh+XgXQEsoZAGrHfCmS8ldX/o3yzDFOF QPKHVbL9ZiCveSCzzyWYKgSSP6yS7QnkGgTSiv27h+lRquHkeN9jiOdMIQRyEcsl8jMs7ad1 f2ofYW2qEEj+sEq0lxq62acaTBUCyR9WgfanbjAVZ6oQSP6wirPvzt2jKM5UIZD8YRVmPz7P qlpThUDyh1WWvT758Bb8TJXSA/l3wP90w+eu//h3autcp+je/8mPsgtEvDb05tbDbD6efY/R PmsP8nFb75gf5G97r35a4YF03fv//uP7g/zr8lwyjKMDk4u6BSK/3OYq+TyFjbPvDkfsUwLZ 3tZbLqvtfSiW4Qrxo/Wd/CiQfl7LoS0GJOc6MbFpXq6BqNf6enRlPQ8kmMB+ILf+0eOA6cJn J5D19j58fVhnINPpRSDra9eun63snt//9d/qhq/e+3DvPYh66XXr8rvd9L1hItNoRu1pGB/i SX5F4Ydt/c+++efNvd7edQfy1p/mtwpkms78v+lbsxv1RexBxl92cf033d2YpKdAdA7Tp80l 8vBSOWIabOsokP3NvdreFQbSTVeQy0A2ziUT62YTm1ZQkYGsr/eX17jzq4yuk2UylWEeyMa2 /nATS84Zbe4WAhmVpi82ApEd6bQwFqcWP62gm1hbW3Z2Q2M+ldk8prP6B7KxrT8EMnzY29zL 7V1ZILMNug5EvzOb1LAUZGLyrX/6RbRqzSyQ/hfu/18t7uG7ajYFMgxATnoH8mFbT6mvz3lg cy+3d22BjFcE86Et9gbTueRO6frKpRsX3Gxg08jcApk8hxsVs807XUmOfzmY3SXvJmcdiumd 9KPbem0ebu7VLayFfemB3M6Hq88nh5Vn33WrBWFh/8O/pO/ZFx1I9zMeHZaf/S+XygHT327r uX/RgdxPfHXqFcg9vod3IFXuQfbtCeQE9QVyh/37mInTgRW74YiKr/Gf3l9yZMUJAmnFfnha rx6kQY7ZMHwhByf1N1UIJH9YRdt3r+EocXIUE9ldTEeT46ANAoE0Yj/sN8aT24Fw2J8FBNKI /eFAThVCIBdxXCK/w9G+W6QxD6TTPQiBCATSiL0cHW4KZHZHffxwohACuYjjEvkdlvbdeJCT 8QiK8sY50z/xBjrLsT2B5RL5GZb2l+5jmJsqBJI/rMLtO/lYh6lCIPnDatI+vMFFIBepaom0 bT/eRTE0VQgkf1hN2su9eDtThUDyh1WW/d1PLTc0VQgkf1hN2rMHeYKqlkjb9twHeYKqlkjb 9jyK9QRVLZG27cMVQiAXqWqJYO9qqhBI/rCwNzNVCCR/WNibmSoEkj8s7M1MFQLJHxb2ZqYK geQPC3szU4VA8oeFvZmpQiD5w8LezFQhkPxhYW9mqhBI/rCwNzNVjllHT03evsDV0cS0s0Ta ti8skL1n729d5JvxfKadJdK2fVmBzI/fcsyQQLAv11Q5GMjy1O5lrg8nop0l0rZ9eYGcvY1F INiXa6oQyL3DepJ27H9u+u3L6d8HI+ZRrGesCrfvDyo6vD3IuHL+TnT9cUhfyyXlbKrwMO/t w3oMS/v3u6+tD149nBji6V7T+7S5myqHtvnpR3kJpBl7fV+p4ZTmMoVR8dHdCeTEsJ7D0X7j rUHm/0Qg25c4PItTOC6R3+Fo3+keZPbeOWMgr1kyJZgqBHL3sJ7D0f5IIK/qAznPhUCONOi4 RH6Ho/1wF3z9XlLDnfQXgWxwOpBjf2pxXCK/w9K+v98hJ7txvzGdHL4sw1QxCWQMIy7Econ8 DEv7aWutttv195wikNX5xywIpDT7bvZp9p0zfzozMlWMAjlwG8t0ifyIquydb0orBJI/rKNU ZR9uaALZusiB53tVtUROU5V9eF1IIFsXWY2sO0jpwzqKRyBHt8pRDE2Vc9v8c/PLM576scOP /jyxHo8lkkVV9uG2LjWQ6Ulou+c882P7n00gO1RlH25pAtn62QSyQ1X2zttZ2bXuhhe7vAiE QNowVfasx8eW5s/z34MnK2JfrqmyH0hHIEeH9TDt2BcVSP+RQA4M6++DPGemfzXEMI3h5urF ZymZ299IYYGwBzk0rNl1yWv54tPxH/oniNdmfysFBfKaXQs++HeQQ1gvEXkJ3ftrff3Qawwo fhZSsfa3UlIgf5zepA0G0r/wYdpnbAfyxbPAne3vhUAu4rxE5LV1cSCXC3G2v5fSAjl8y2q6 xJWx7OO8RIabomMS85doz+6912d/L6UFcp5vAvF9js7+TazlHmR2R/3kH1uLsr8XAokuGqwg 6yUigbxPTA/zymMcXXf5brq1/a0QSHTRYgP59j7GHtb2NZkqHoEcfcKX4RKZvYDlivtxDO3r NFUsAjn8hC+/JXL5HvcF/OwrNVVMAjn4hC+3JbL37ON7cbOv1lQxCaT/WFYg+0/Pvxcv+4pN FZtAytuDdPKg1C3sjcnK/lEIZHn2g0/4Mlsi7EHqNFU8AnlfZv9CdkuEQGo0VQjky2ERSH2m ik8g3ArH3sRU8QnkCO0skbbtCeQi7SyRtu0J5CLtLJG27QnkIu0skbbtCeQi7SyRtu0J5CLt LJG27QnkIu0skbbtCeQi7SyRtu0J5CLmS2Q4bmL/lbzgVk7xklt7U4VAbhtWX8FLjt/QjS8G G74/HuOkNvtbIZCLWC8RWfnDa2/faUzHO+mmT7XZ3wqBXMR5icyfsf8ewiKQjkCKMFUI5K5h jfczXlMg462s/gxST2X290IgF3FeIp3cvBoDec0DmX2uyv5eCOQizktkuEc+nCaQ6xDIRayX yPgg1nRoxdf40O+hVxSXbH8rBHIR6yUyrfuHXmVobV+TqUIgNw5r9iBvc/b1mCoEkj2s47ub Gu0tTRUCyR7W8fskNdpbmioEkj2s4wfXqtHe0lQhkOxhHT2uYp32lqYKgVwe1i2HGxXKsn8U ArlIjUuEm1h2pgqBZA+LO+l2pgqBZA+Lh3ntTBUCyR8W9mamCoHkDwt7M1OFQPKHhb2ZqUIg +cPC3sxUIZD8YWFvZqoQSP6wsDczVQgkf1jYm5kqBJI/LOzNTBUCyR8W9mamCoHcOKzZYa/k OVbT8Ua78W3V67O/EQK5iPUSmQ5gMn0cj5I1FjIdT64u+1shkItYL5HloUeHQMaDmXx76Dhr +1shkIs4L5HVoUcXxyElkGJMFQK5a1jTodynW1Z6HNLp4O8EYm6qEMhdwzoSyItASjBVCOSu YW0FMr+T/iKQMkwVArltWP39DjnZjfuN6eTwZW32t0IgF7FeIsGhR+85Fqm1/a0QyEXMl8jn Q49e3WmUZH8jBHIRwyXy0IGqC7Gv01QhkK+GdcueoVj7Wk0VAvliWJefVVWFfb2mCoFcHtZ4 RMRfHVrRyv5RCOQiZkuEPUidpgqBfDMsAqnSVCGQ74ZFIBWaKgTy7bAIpDpThUDyh4W9malC IPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNT hUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZm pgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzs zUwVn0COHICznSXStj2BrC9w6Bi17SyRtu0JZHX+6T2To0LaWSJt2xPI6vxjFgSCfbapYhTI gdtY7SyRtu0JZHV+AtmnHXsC2bpIN77N+EfaWSJt2xPI1kVWu4+j78xU+rCOQiAJHLM++iZh 0wVOz+TQO5G1s0Tati8skDPvozdc5PRMCGSXduzLCuTg3yjmlzk9EwLZpR378gJZntq9zOmZ EMgu7diXF8jZ21g8WRH7ck0VArl3WE/Sjv3PTY8+YPqphSN/o5hBINiXa6rYPMx7iHaWSNv2 pQVy+lFeAsG+YFOFQO4e1nO0Y08gF2lnibRtTyAXaWeJtG1fWiDn+SaQoMN2lkjb9gQSX5hA GrcnkPjCBNK4PYEsz/73Z8jhthWBtG5PIItzd7O/1RNI6/YEsjh31xHIPu3YE8ji3EMXBBLR jn2xgTz0bN7/fip7kF3asS82kMNP6L1wJ318OVbwB8l2lkjb9gRy8We3s0Tati8pkKOPwC4u dWEqBIK9h6myZ334EdjFxc4P5chTvdpZIm3bFxXIwUdgFxf7ckIfaGeJtG1fVCD9RwIhkFZM lSOBsAc5OKyHace+oEAOPwK7uNSXE/pAO0ukbfuSAvnjxOEa+gucH8oR2lkibdsTyEXaWSJt 25cWyKkj/rwvcWUs+7SzRNq2Ly2Q8xAI9uWaKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDy h4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB 5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwV AskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZ KgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3 M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFh b2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnD wt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDy h4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB 5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwV AskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3M1UIJH9Y2JuZ KgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFhb2aqEEj+sLA3 M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnDwt7MVCGQ/GFh b2aqEEj+sLA3M1UIJH9Y2JuZKgSSPyzszUwVAskfFvZmpgqB5A8LezNThUDyh4W9malCIPnD wt7MVCkskGSescLezVR5xvChQADqgEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAII BCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAA AggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCA QAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggE IIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAAC CAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBA AAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQg gEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAIIBCCAQAACCAQggEAAAggEIIBAAAII BCDg/wbDiYqV0aG7AAAAAElFTkSuQmCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAHAAKAAEA WwAPAAIAAAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAEAG1ICQRIAAFA AQACAEgAAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYAEwA1CIFD ShwAS0gcAE9KAgBRSgIAAEYAAkABAAIARgAAAAkASABlAGEAZABpAG4AZwAgADIAAAAQAAIA BiQBE6TwABSkPABAJgESADUIgTYIgUNKGABPSgIAUUoCAEAAAwABAAIAQAAAAAkASABlAGEA ZABpAG4AZwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIMAENKGABPSgIAUUoCAMAABAABAAIA wAAAAAkASABlAGEAZABpAG4AZwAgADQAAACOAAQABiQBQCYDQyQBRcaAAAACABzINqYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAANADUIgVfKBwECAB3INqYAMAAFAAEAAgAwAAAACQBIAGUAYQBkAGkAbgBnACAA NQAAAAsABQADJAMGJAFAJgQAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwA dAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAoAFVAogDxACgA AAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+KgFCKgI2ACdAogABATYAAAARAEMAbwBtAG0A ZQBuAHQAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAQAQ0oQACwAHgABABIBLAAAAAwAQwBvAG0A bQBlAG4AdAAgAFQAZQB4AHQAAAACABEAAAAsABNAAQACACwAAQAFAFQATwBDACAAMQAAAAoA EgATpHgAFKR4AAYANQiBOwiBJgAUQAEAAgAmAAEABQBUAE8AQwAgADIAAAAGABMAD4TIAAMA OgiBACYAFQABAAIAJgABAAUAVABPAEMAIAAzAAAABgAUAA+EkAEDADYIgQAmABYAAQACACYA AQAFAFQATwBDACAANAAAAAYAFQAPhFgCBABDShIAJgAXAAEAAgAmAAEABQBUAE8AQwAgADUA AAAGABYAD4QgAwQAQ0oSACYAGAABAAIAJgABAAUAVABPAEMAIAA2AAAABgAXAA+E6AMEAENK EgAmABkAAQACACYAAQAFAFQATwBDACAANwAAAAYAGAAPhLAEBABDShIAJgAaAAEAAgAmAAEA BQBUAE8AQwAgADgAAAAGABkAD4R4BQQAQ0oSACYAGwABAAIAJgABAAUAVABPAEMAIAA5AAAA BgAaAA+EQAYEAENKEgAsAP4PAQACACwAAAAHAFAAaQBjAHQAdQByAGUAAAAMABsAAyQBBiQB E6Q8AAAAAAAAAP4sAAAEAABUAAAAAP////8ABAAAaAYAANkRAAD+MAAAGQAAABwAAAAiAAAA AAQAAK0HAADADgAAqxQAAPkYAACwHAAAUSAAAFEkAAB4JwAARysAAD0vAAD+MAAAGgAAAB0A AAAeAAAAHwAAACEAAAAjAAAAJAAAACUAAAAnAAAAKAAAACkAAAAABAAAxhgAAJUlAAD+MAAA GwAAACAAAAAmAAAA//8CAAAABwBVAG4AawBuAG8AdwBuAAYAcwBhAG4AawBhAHIAXwAAAG4A AADLAAAA5wAAAOkAAAD4AAAAFAEAABYBAAAkAQAAQAEAAEIBAABZAQAAdQEAAHcBAACKAQAA pgEAAKgBAAC3AQAA0wEAANUBAAD1AQAAEQIAABMCAAAeAgAAOgIAADwCAABNAgAAaQIAAGsC AACIAgAApAIAAKYCAAC3AgAA0wIAANUCAAD1AgAAEQMAABMDAAAkAwAAQAMAAEIDAABaAwAA dgMAAHgDAACJAwAApQMAAKgDAACqAwAAHwgAAGMIAACLCAAA/iwAABMNdP8TJdT/lcATJdT/ lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcATJdT/ lcATJdT/lcATJdT/lcATJdT/lcATJdT/lcCVjBNYlP+VjA8AAPA4AAAAAAAG8BgAAAACCAAA AgAAAE4AAAABAAAAAQAAAE8AAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQ AAjwCAAAAAEAAABOBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAP////+wAAAAAAAA AAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQ AMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP4sAAD//w8AAAANAF8AVABv AGMANAA1ADgAMgA2ADEAMAA5ADYADQBfAFQAbwBjADQANQA4ADIANgAxADAAOQA3AA0AXwBU AG8AYwA0ADUAOAAyADYAMQAwADkAOAANAF8AVABvAGMANAA1ADgAMgA2ADEAMAA5ADkADQBf AFQAbwBjADQANQA4ADIANgAxADEAMAAwAA0AXwBUAG8AYwA0ADUAOAAyADYAMQAxADAAMQAN AF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADIADQBfAFQAbwBjADQANQA4ADIANgAxADEAMAAz AA0AXwBUAG8AYwA0ADUAOAAyADYAMQAxADAANAANAF8AVABvAGMANAA1ADgAMgA2ADEAMQAw ADUADQBfAFQAbwBjADQANQA4ADIANgAxADEAMAA2AA0AXwBUAG8AYwA0ADUAOAAyADYAMQAx ADAANwANAF8AVABvAGMANAA1ADgAMgA2ADEAMQAwADgADQBfAFQAbwBjADQANQA4ADIANgAx ADEAMAA5AA0AXwBUAG8AYwA0ADUAOAAyADYAMQAxADEAMAAAAAAArwMAADgFAABEBQAAaAYA AJAIAABWCQAAdAkAAH0JAAClCgAAtgwAAKgNAADGDQAAQRcAAFEmAAAALQAAAAAAAAEAAAAC AAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAAWwAA ALsDAABDBQAAWAUAAHgGAACcCAAAcwkAAHwJAACLCQAAvwoAAMQMAADFDQAA1A0AAFYXAABf JgAAAC0AAAAAAADyBAAA/AQAAN4FAADnBQAAVAYAAGUGAAD9BgAADgcAAIAHAACNBwAAnQcA AK4HAABkCAAAbQgAAHAIAAB+CAAAkAkAAJoJAAClCQAAtgkAAOYJAADwCQAANgoAAEMKAABf CgAAaQoAAMQKAADOCgAA2AoAAOgKAABpCwAAeQsAALALAADACwAAbgwAAHgMAACADAAAkAwA AMkMAADTDAAA+QwAAAkNAAAXDQAAIw0AAEENAABNDQAAlA0AAKQNAACxDgAAtA4AAFYPAABq DwAAvg8AAMEPAACwEAAAshAAACcRAAAqEQAA1BEAANYRAABLEgAAThIAAGUTAABoEwAAchQA AHUUAABkFQAAZhUAANsVAADeFQAAiBYAAIoWAAD/FgAAAhcAAMUXAADHFwAAOBgAADsYAADm GAAA6BgAAIcZAACKGQAAOxoAAD4aAAC0GgAAtxoAAGYbAABuGwAA1xsAANobAADrGwAA8xsA ACAcAAAmHAAAMBwAADQcAABRHAAAWBwAAAcdAAAJHQAAFB0AABYdAACIHQAAix0AADYeAAA4 HgAAQx4AAEUeAAC3HgAAuh4AAGUfAABnHwAA2R8AANwfAACMIAAAlCAAAJsgAACjIAAA0CAA ANYgAADgIAAA5CAAAAEhAAAIIQAAgCEAAIMhAACVIQAAnSEAAMkhAADPIQAA2SEAAN0hAAD6 IQAAASIAALoiAADCIgAAySIAANEiAAD9IgAAAyMAAA0jAAARIwAALiMAADUjAACtIwAAsCMA AF4kAABgJAAA3SQAAOAkAACOJQAAkCUAAA0mAAAQJgAAziYAANAmAABCJwAARScAAF4oAABh KAAA3ygAAOUoAAD1KAAA9ygAAGwpAABvKQAAiSoAAIwqAAA4KwAAOisAAKwrAACvKwAALCwA ADIsAABCLAAARCwAALksAAC8LAAAAC0AAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAbAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAAAAAA8gQAAPwEAACYBwAArgcAAPwKAAALCwAA7g0AAPUNAABcDgAAYw4AAJEOAACY DgAA0g4AANkOAAAHDwAADg8AAFYPAACIDwAAng8AAKUPAAAlEAAALBAAAFoQAABhEAAAsBAA ALMQAADTEAAA2hAAAAcRAAAOEQAAShEAAFERAAB+EQAAhREAANQRAADXEQAA9xEAAP4RAAAr EgAAMhIAAG4SAAB1EgAAohIAAKkSAAAQEwAAFxMAAEUTAABMEwAAhhMAAI0TAAC7EwAAwhMA AB0UAAAkFAAAUhQAAFkUAADZFAAA4BQAAA4VAAAVFQAAZBUAAGcVAACHFQAAjhUAALsVAADC FQAA/hUAAAUWAAAyFgAAORYAAIgWAACLFgAAqxYAALIWAADfFgAA5hYAACIXAAApFwAAbxcA AHYXAADkFwAA6xcAABgYAAAfGAAAWxgAAGIYAACPGAAAlhgAAOYYAADpGAAAMxkAADoZAABn GQAAbhkAAKoZAACxGQAA3hkAAOUZAABgGgAAZxoAAJQaAACbGgAA1xoAAN4aAAALGwAAEhsA AIMbAACKGwAAtxsAAL4bAADmGwAA5xsAAOsbAADsGwAAIBwAACEcAAAwHAAAMRwAAFEcAABS HAAAfBwAAIMcAACwHAAAtxwAAAcdAAAKHQAANB0AADsdAABoHQAAbx0AAKsdAACyHQAA3x0A AOYdAAA2HgAAOR4AAGMeAABqHgAAlx4AAJ4eAADaHgAA4R4AAA4fAAAVHwAAhR8AAIwfAAC5 HwAAwB8AAPwfAAADIAAAMCAAADcgAACWIAAAlyAAAJsgAACcIAAA0CAAANEgAADgIAAA4SAA AAEhAAACIQAALCEAADMhAABgIQAAZyEAAJAhAACRIQAAlSEAAJYhAADJIQAAyiEAANkhAADa IQAA+iEAAPshAAAlIgAALCIAAFkiAABgIgAAxCIAAMUiAADJIgAAyiIAAP0iAAD+IgAADSMA AA4jAAAuIwAALyMAAFkjAABgIwAAjSMAAJQjAADRIwAA2CMAAAUkAAAMJAAAXiQAAGEkAACI JAAAjyQAALwkAADDJAAAASUAAAglAAA1JQAAPCUAAI4lAACRJQAAuCUAAL8lAADsJQAA8yUA ADEmAAA4JgAAdyYAAH4mAADuJgAA9SYAACInAAApJwAAZScAAGwnAACZJwAAoCcAAAooAAAR KAAAPigAAEUoAACCKAAAiSgAALYoAAC9KAAA9SgAAPgoAAAYKQAAHykAAEwpAABTKQAAkCkA AJcpAADEKQAAyykAADUqAAA8KgAAaSoAAHAqAACtKgAAtCoAAOEqAADoKgAAWCsAAF8rAACM KwAAkysAAM8rAADWKwAAAywAAAosAABCLAAARSwAAGUsAABsLAAAmSwAAKAsAADdLAAA5CwA AAAtAAAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcABAAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcA//8UAAAAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgA2AEMAOgBc AFAAcgBvAGoAZQBjAHQAcwBcAHMAbwBmAHQAcwB3AGkAdABjAGgAXABNAEcAQwBQACAAUgBl AHMAaQBkAGUAbgB0AGkAYQBsACAAdABlAHMAdAAgAGMAYQBzAGUAcwAuAGQAbwBjABIAUABy AGUAZgBlAHIAcgBlAGQAIABDAHUAcwB0AG8AbQBlAHIARABDADoAXAB3AGkAbgBkAG8AdwBz AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAg AE0ARwBDAFAAIABSAGUAcwBpAGQAZQBuAHQAaQBhAGwAIAB0AGUAcwB0ACAAYwBhAHMAZQBz AC4AYQBzAGQAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgBEAEMAOgBc AHcAaQBuAGQAbwB3AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABz AGEAdgBlACAAbwBmACAATQBHAEMAUAAgAFIAZQBzAGkAZABlAG4AdABpAGEAbAAgAHQAZQBz AHQAIABjAGEAcwBlAHMALgBhAHMAZAASAFAAcgBlAGYAZQByAHIAZQBkACAAQwB1AHMAdABv AG0AZQByAEQAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBj AG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABNAEcAQwBQACAAUgBlAHMAaQBkAGUAbgB0 AGkAYQBsACAAdABlAHMAdAAgAGMAYQBzAGUAcwAuAGEAcwBkABIAUAByAGUAZgBlAHIAcgBl AGQAIABDAHUAcwB0AG8AbQBlAHIARABDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAE0ARwBDAFAAIABS AGUAcwBpAGQAZQBuAHQAaQBhAGwAIAB0AGUAcwB0ACAAYwBhAHMAZQBzAC4AYQBzAGQAEgBQ AHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgBEAEMAOgBcAHcAaQBuAGQAbwB3 AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm ACAATQBHAEMAUAAgAFIAZQBzAGkAZABlAG4AdABpAGEAbAAgAHQAZQBzAHQAIABjAGEAcwBl AHMALgBhAHMAZAASAFAAcgBlAGYAZQByAHIAZQBkACAAQwB1AHMAdABvAG0AZQByADYAQwA6 AFwAUAByAG8AagBlAGMAdABzAFwAcwBvAGYAdABzAHcAaQB0AGMAaABcAE0ARwBDAFAAIABS AGUAcwBpAGQAZQBuAHQAaQBhAGwAIAB0AGUAcwB0ACAAYwBhAHMAZQBzAC4AZABvAGMAEgBQ AHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgBEAEMAOgBcAHcAaQBuAGQAbwB3 AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm ACAATQBHAEMAUAAgAFIAZQBzAGkAZABlAG4AdABpAGEAbAAgAHQAZQBzAHQAIABjAGEAcwBl AHMALgBhAHMAZAASAFAAcgBlAGYAZQByAHIAZQBkACAAQwB1AHMAdABvAG0AZQByADYAQwA6 AFwAUAByAG8AagBlAGMAdABzAFwAcwBvAGYAdABzAHcAaQB0AGMAaABcAE0ARwBDAFAAIABS AGUAcwBpAGQAZQBuAHQAaQBhAGwAIAB0AGUAcwB0ACAAYwBhAHMAZQBzAC4AZABvAGMAEgBQ AHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgA2AEMAOgBcAFAAcgBvAGoAZQBj AHQAcwBcAHMAbwBmAHQAcwB3AGkAdABjAGgAXABNAEcAQwBQACAAUgBlAHMAaQBkAGUAbgB0 AGkAYQBsACAAdABlAHMAdAAgAGMAYQBzAGUAcwAuAGQAbwBjAFAA/v//////////DwAAAAAA AAAAAAAAAAAAAAABAFFwiAEPAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQDWFrEBAQAJBP8PAAAA AAAAAAAAAAAAAAAAAAEA7WvRAZi3zkb/DwAAAAAAAAAAAAAAAAAAAAABAJ4V+gHA8Xzs/w8A AAAAAAAAAAAAAAAAAAAAAQBkSmsDengcNP8PAAAAAAAAAAAAAAAAAAAAAAEAelt1Aw8ACQT/ D/8P/w//D/8P/w//D/8P/w8BAPUiXQQEpOKV/w8AAAAAAAAAAAAAAAAAAAAAAQCCbygF6BkQ Iv8PAAAAAAAAAAAAAAAAAAAAAAEAK2tbB+SJWkT/DwAAAAAAAAAAAAAAAAAAAAABAMl7zgiY klZZ/w8AAAAAAAAAAAAAAAAAAAAAAQDnCkcJiP4i+/8PAAAAAAAAAAAAAAAAAAAAAAEALQDt CbT7Nrn/DwAAAAAAAAAAAAAAAAAAAAABAP9WGwpg/A5y/w8AAAAAAAAAAAAAAAAAAAAAAQA3 W9wK6K2QIP8P/w//D/8P/w//D/8P/w//DwAAzxMODMxITjL/DwAAAAAAAAAAAAAAAAAAAAAB ALtsPwzm4ZpD/w8AAAAAAAAAAAAAAAAAAAAAAQAFSjoTOBIO8P8PAAAAAAAAAAAAAAAAAAAA AAEAeSYIFB5PqGX/D/8P/w//D/8P/w//D/8P/w8BAA8OdRRaqBwn/w8AAAAAAAAAAAAAAAAA AAAAAQC4KzkWkDTy8/8PAAAAAAAAAAAAAAAAAAAAAAEAeV/QFg8ACQT/DwAAAAAAAAAAAAAA AAAAAAABAAckOhh8F4TI/w8AAAAAAAAAAAAAAAAAAAAAAQD1LGkY2Lzi6/8PAAAAAAAAAAAA AAAAAAAAAAEABQmaGJa52IT/DwAAAAAAAAAAAAAAAAAAAAABAHR2GBn+lage/w8AAAAAAAAA AAAAAAAAAAAAAQBXbhwZPnHOu/8PAAAAAAAAAAAAAAAAAAAAAAEAYzWWGaK6vob/DwAAAAAA AAAAAAAAAAAAAAABAD4pvhrmrPiz/w8AAAAAAAAAAAAAAAAAAAAAAQBMcagd9A4cjf8PAAAA AAAAAAAAAAAAAAAAAAEALWGsHmZ9dGr/DwAAAAAAAAAAAAAAAAAAAAABAEIbyx4BAAkE/w8A AAAAAAAAAAAAAAAAAAAAAQBXTKEhAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAkWquJHhJWCD/ DwAAAAAAAAAAAAAAAAAAAAABACJddiUe5F41/w8AAAAAAAAAAAAAAAAAAAAAAQCxAtgljOV4 +/8P/w//D/8P/w//D/8P/w//DwEApUK3L/ZnWv7/DwAAAAAAAAAAAAAAAAAAAAABALlBLTHo rZAg/w//D/8P/w//D/8P/w//D/8PAADCWNgx2LIipf8PAAAAAAAAAAAAAAAAAAAAAAEAEgFe MsxITjL/DwAAAAAAAAAAAAAAAAAAAAABAEYZ8DRuEyaP/w8AAAAAAAAAAAAAAAAAAAAAAQDy J+s1ng5+Wv8PAAAAAAAAAAAAAAAAAAAAAAEATGoANnBu+mr/DwAAAAAAAAAAAAAAAAAAAAAB AIwDbDYAqq6P/w8AAAAAAAAAAAAAAAAAAAAAAQBBEdo2fHJEWv8PAAAAAAAAAAAAAAAAAAAA AAEAoXT/N4ImajT/DwAAAAAAAAAAAAAAAAAAAAABAEkJ2Tic09Co/w8AAAAAAAAAAAAAAAAA AAAAAQDGbIk5vJ24eP8PAAAAAAAAAAAAAAAAAAAAAAEA1hE6OhEACQT/DwAAAAAAAAAAAAAA AAAAAAABAMB2gDoBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQDEDrI6DwAJBP8PAAAAAAAAAAAA AAAAAAAAAAEAAwFOPhEACQT/DwAAAAAAAAAAAAAAAAAAAAABAG46e0HYwc6m/w8AAAAAAAAA AAAAAAAAAAAAAQAiR5dDOmgQT/8PAAAAAAAAAAAAAAAAAAAAAAEApx6+Q2TTGln/DwAAAAAA AAAAAAAAAAAAAAABAAtl3kbI1QBA/w8AAAAAAAAAAAAAAAAAAAAAAQCdUzdHdIg40/8PAAAA AAAAAAAAAAAAAAAAAAEAISebSFQE+Kb/DwAAAAAAAAAAAAAAAAAAAAABANwwiEmy4EZN/w8A AAAAAAAAAAAAAAAAAAAAAQBzRAlMWk7+Vf8PAAAAAAAAAAAAAAAAAAAAAAEADEZGUMxITjL/ DwAAAAAAAAAAAAAAAAAAAAABAEgld1D6oGbL/w8AAAAAAAAAAAAAAAAAAAAAAQD+MYlRzJrI Kv8PAAAAAAAAAAAAAAAAAAAAAAEAy1xbVA8ACQT/DwAAAAAAAAAAAAAAAAAAAAABALJ/L1ZY yFpa/w8AAAAAAAAAAAAAAAAAAAAAAQBgAWdZmhYQwf8PAAAAAAAAAAAAAAAAAAAAAAEAzydC X3Q2dMz/DwAAAAAAAAAAAAAAAAAAAAABANw3v2ARAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQCk evxjkj/KiP8PAAAAAAAAAAAAAAAAAAAAAAEAyTMRZwEACQT/DwAAAAAAAAAAAAAAAAAAAAAB ADcFXGcBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQD0RGxoNkIaA/8PAAAAAAAAAAAAAAAAAAAA AAEA5yo4auhAtjv/DwAAAAAAAAAAAAAAAAAAAAABAFV/u21+TfRh/w8AAAAAAAAAAAAAAAAA AAAAAQBmbJpuFwAJBP8P/w//D/8P/w//D/8P/w//DwEAOieUcOx8LDv/DwAAAAAAAAAAAAAA AAAAAAABAOAAuXLEz1CY/w8AAAAAAAAAAAAAAAAAAAAAAQA6VRt1BIC2uv8PAAAAAAAAAAAA AAAAAAAAAAEAXiV6dYBnyov/DwAAAAAAAAAAAAAAAAAAAAABADQcHX0PAAkE/w//D/8P/w// D/8P/w//D/8PAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAqAAEAAAAAQAEAAAAA AAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwfwAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAAxAAAA+EhgERhHr+FcYFAAGGAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AxAAAA+EhgERhHr+FcYFAAGGAQZvKAABAAAAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAA AA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAA D4SVARGEa/4VxgUAAZUBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SG ARGEev4VxgUAAYYBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SVARGE a/4VxgUAAZUBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4V xgUAAYYBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUA AYYBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SVARGEa/4VxgUAAZUB Bm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8o AAEAAAABAAAAAEABAAAAAAAAAAAAAAAAANACAAAACAAAD4TQAhGEMP0CAAAALgABAAAAAEAB AwAAAAAAAAAAAAAAANACAAAACAAAD4SgBRGEMP0EAAAALgABAC4AAQAAAABAAQMFAAAAAAAA AAAAAADQAgAAAAgAAA+EcAgRhDD9BgAAAC4AAQAuAAIALgABAAAAAEABAwUHAAAAAAAAAAAA ANACAAAACAAAD4RACxGEMP0IAAAALgABAC4AAgAuAAMALgABAAAAAEABAwUHCQAAAAAAAAAA ANACAAAACAAAD4QQDhGEMP0KAAAALgABAC4AAgAuAAMALgAEAC4AAQAAAABAAQMFBwkLAAAA AAAAAADQAgAAAAgAAA+E4BARhDD9DAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAAEAB AwUHCQsNAAAAAAAAANACAAAACAAAD4SwExGEMP0OAAAALgABAC4AAgAuAAMALgAEAC4ABQAu AAYALgABAAAAAEABAwUHCQsNDwAAAAAAANACAAAACAAAD4SAFhGEMP0QAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgAHAC4AAQAAAABAAQMFBwkLDQ8RAAAAAADQAgAAAAgAAA+EUBkR hDD9EgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgAAAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEALQB/AAAAAAABAAAAAAAAAAAA AAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAA AAAAAAADEAAAD4SVARGEa/4VxgUAAZUBBm8oAAEAAAABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADEAAAD4Q4BBGEmP4VxgUAATgEBm8oAAIAAAAuAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAA AAMQAAAPhIYBEYR6/hXGBQABhgEGbygAAQAAAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQ AAAPhIYBEYR6/hXGBQABhgEGbygAAQAAAAIAAAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAP hGgBEYSY/gIAAAAuAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhMIBEYQ+/hXGBQAB wgEGbygAAQAAAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEG bygAAQAAAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEGbygA AQAAAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEGbygAAQAA AH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhJUBEYRr/hXGBQABlQEGbygAAQAAAH8A AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEGbygAAQAAAH8AAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhMIBEYQ+/hXGBQABwgEGbygAAQAAAH8AAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhJUBEYRr/hXGBQABlQEGbygAAQAAAH8AAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEGbygAAQAAAAEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/B/AAAA AAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SVARGEa/4VxgUAAZUBBm8oAAEAAAB/AAAAAAAB AAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8oAAEAAAABAAAAAAACAAAA AAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAMAKAAAACkAfwAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxAAAA+EhgERhHr+FcYFAAGGAQZvKAABAAAAAQAAAABAAQAAAAAA AAAAAAAAAADQAgAAAAgAAA+E0AIRhDD9AgAAAC4AAQAAAABAAQMAAAAAAAAAAAAAAADQAgAA AAgAAA+EoAURhDD9BAAAAC4AAQAuAAEAAAAAQAEDBQAAAAAAAAAAAAAA0AIAAAAIAAAPhHAI EYQw/QYAAAAuAAEALgACAC4AAQAAAABAAQMFBwAAAAAAAAAAAADQAgAAAAgAAA+EQAsRhDD9 CAAAAC4AAQAuAAIALgADAC4AAQAAAABAAQMFBwkAAAAAAAAAAADQAgAAAAgAAA+EEA4RhDD9 CgAAAC4AAQAuAAIALgADAC4ABAAuAAEAAAAAQAEDBQcJCwAAAAAAAAAA0AIAAAAIAAAPhOAQ EYQw/QwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAABAAQMFBwkLDQAAAAAAAADQAgAA AAgAAA+EsBMRhDD9DgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAABAAQMFBwkL DQ8AAAAAAADQAgAAAAgAAA+EgBYRhDD9EAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwAuAAEAAAAAQAEDBQcJCw0PEQAAAAAA0AIAAAAIAAAPhFAZEYQw/RIAAAAuAAEALgACAC4A AwAuAAQALgAFAC4ABgAuAAcALgAIAC4AfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E swERhE3+FcYFAAGzAQZvKAABAAAAAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAER hJj+FcYFAAFoAQZvKAABAC0AfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+ElQERhGv+ FcYFAAGVAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EhgERhHr+FcYF AAGGAQZvKAABAAAAAwAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E2AkRhJj+FcYFAAHY CQZvKAABAC0AfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EhgERhHr+FcYFAAGGAQZv KAABAAAAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EoAURhDD9FcYFAAGgBQZvKAAC AAAALgB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8oAAEA AAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8oAAEAAAB/ AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8oAAEAAAABAAAA AAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAApAAEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAA AAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAApAH8AAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAQAAAAEAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhDgEEYSY/hXGBQABOAQGbygAAgAAACkAfwAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxAAAA+EwgERhD7+FcYFAAHCAQZvKAABAAAAfwAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAxAAAA+EhgERhHr+FcYFAAGGAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxAAAA+EwgERhD7+FcYFAAHCAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAAxAAAA+EwgERhD7+FcYFAAHCAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAAxAAAA+EhgERhHr+FcYFAAGGAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AxAAAA+ElQERhGv+FcYFAAGVAQZvKAABAAAAAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAxAA AA+EaAERhJj+FcYFAAFoAQZvKAABAC0AfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E hgERhHr+FcYFAAGGAQZvKAABAAAAfwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EhgER hHr+FcYFAAGGAQZvKAABAAAAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+ FcYFAAFoAQYCAAAALgB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUA AYYBBm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SVARGEa/4VxgUAAZUB Bm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8o AAEAAAACAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIA AAApAH8AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhIYBEYR6/hXGBQABhgEGbygAAQAA AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBv KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAt/B/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYB Bm8oAAEAAAB/AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8o AAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAAA AQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAAKQB/ AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEAAAB/AAAA AAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4SGARGEev4VxgUAAYYBBm8oAAEAAAADAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAADEAAAD4Q4BBGEmP4VxgUAATgEBm8oAAIAAAApAH8AAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhJUBEYRr/hXGBQABlQEGbygAAQAAAAEAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAAC4AUgAAAHpbdQMAAAAA AAAAAAAAAAB5JggUAAAAAAAAAAAAAAAAZmyabgAAAAAAAAAAAAAAADQcHX0AAAAAAAAAAAAA AADEDrI6AAAAAAAAAAAAAAAAeV/QFgAAAAAAAAAAAAAAAHlf0BYAAAAA/J3FAAkAAABRcIgB AAAAAAAAAAAAAAAAuUEtMQAAAAAAAAAAAAAAADdb3AoAAAAAAAAAAAAAAAA3BVxnAAAAAAAA AAAAAAAA1haxAQAAAAAAAAAAAAAAAMB2gDoAAAAAAAAAAAAAAADLXFtUAAAAAAAAAAAAAAAA 1hE6OgAAAAAAAAAAAAAAANw3v2AAAAAAAAAAAAAAAAADAU4+AAAAAAAAAAAAAAAADEZGUAAA AAAAAAAAAAAAAM8TDgwAAAAAAAAAAAAAAAASAV4yAAAAAAAAAAAAAAAATGoANgAAAAAAAAAA AAAAAMkzEWcAAAAAAAAAAAAAAAD+////AAAAAIShxQABAAAA/v///wAAAADgocUAAQAAALts PwwAAAAAAAAAAAAAAAA6J5RwAAAAAAAAAAAAAAAA7WvRAQAAAAAAAAAAAAAAAOcqOGoAAAAA AAAAAAAAAABuOntBAAAAAAAAAAAAAAAAuCs5FgAAAAAAAAAAAAAAAGRKawMAAAAAAAAAAAAA AAChdP83AAAAAAAAAAAAAAAApHr8YwAAAAAAAAAAAAAAAExxqB0AAAAAAAAAAAAAAADJe84I AAAAAAAAAAAAAAAAjANsNgAAAAAAAAAAAAAAAPIn6zUAAAAAAAAAAAAAAABjNZYZAAAAAAAA AAAAAAAASQnZOAAAAAAAAAAAAAAAAHNECUwAAAAAAAAAAAAAAAB0dhgZAAAAAAAAAAAAAAAA sn8vVgAAAAAAAAAAAAAAAAtl3kYAAAAAAAAAAAAAAAD/VhsKAAAAAAAAAAAAAAAAxmyJOQAA AAAAAAAAAAAAAP4xiVEAAAAAAAAAAAAAAAAFSjoTAAAAAAAAAAAAAAAAkWquJAAAAAAAAAAA AAAAAC0A7QkAAAAAAAAAAAAAAABgAWdZAAAAAAAAAAAAAAAApx6+QwAAAAAAAAAAAAAAACJd diUAAAAAAAAAAAAAAAAra1sHAAAAAAAAAAAAAAAARhnwNAAAAAAAAAAAAAAAAF4lenUAAAAA AAAAAAAAAACCbygFAAAAAAAAAAAAAAAALWGsHgAAAAAAAAAAAAAAAAUJmhgAAAAAAAAAAAAA AAD1LGkYAAAAAAAAAAAAAAAADw51FAAAAAAAAAAAAAAAAFduHBkAAAAAAAAAAAAAAADgALly AAAAAAAAAAAAAAAA9SJdBAAAAAAAAAAAAAAAAEgld1AAAAAAAAAAAAAAAACeFfoBAAAAAAAA AAAAAAAA5wpHCQAAAAAAAAAAAAAAAKVCty8AAAAAAAAAAAAAAADPJ0JfAAAAAAAAAAAAAAAA 3DCISQAAAAAAAAAAAAAAAPREbGgAAAAAAAAAAAAAAAAhJ5tIAAAAAAAAAAAAAAAAwljYMQAA AAAAAAAAAAAAAJ1TN0cAAAAAAAAAAAAAAAAHJDoYAAAAAAAAAAAAAAAAPim+GgAAAAAAAAAA AAAAACJHl0MAAAAAAAAAAAAAAABXTKEhAAAAAAAAAAAAAAAAOlUbdQAAAAAAAAAAAAAAAFV/ u20AAAAAAAAAAAAAAABCG8seAAAAAAAAAAAAAAAAQRHaNgAAAAAAAAAAAAAAALEC2CUAAAAA AAAAAAAAAAD/////////////////////////////////////SJ7FACAAAAABAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAJSexQAhAAAAAQAAAAAA AQMAAAAAAAAAAAAAAAAAAAAAABAAAA+EGAMRhFD+FcYFAAEYAwYEAAAALgABAC4A5J7FACIA AAABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAAEAAAD4TIBBGECP4VxgUAAcgEBgYAAAAuAAEA LgACAC4AOJ/FACMAAAABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAAAEAAAD4TABhGEeP0VxgUA AcAGBggAAAAuAAEALgACAC4AAwAuAJCfxQAkAAAAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAA ABAAAA+EuAgRhOj8FcYFAAG4CAYKAAAALgABAC4AAgAuAAMALgAEAC4A7J/FACUAAAABAAAA AAABAwUHCQsAAAAAAAAAAAAAAAAAEAAAD4SwChGEWPwVxgUAAbAKBgwAAAAuAAEALgACAC4A AwAuAAQALgAFAC4ATKDFACYAAAABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAAEAAAD4SoDBGE yPsVxgUAAagMBg4AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuALCgxQAnAAAAAQAAAAAA AQMFBwkLDQ8AAAAAAAAAAAAAABAAAA+EoA4RhDj7FcYFAAGgDgYQAAAALgABAC4AAgAuAAMA LgAEAC4ABQAuAAYALgAHAC4AGKHFACgAAAABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAAEAAA D4TgEBGEYPoVxgUAAeAQBhIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4A //////////////////////////////////////////////////////////////////////// /////////////5ChxQAgAAAAAQAAABdAAAAAAAAAAAAAAAAAAAAgAQAACwgAAA+EIAERhOD+ T0oBAFFKAQBvKAABALfw/////+yhxQAgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+E0AIRhJj+T0oBAFFKAQBvKAABALfw//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////UAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QAGAAQBWDwAA Vg8AACihNQEBAAEAVg8AAAAAAABWDwAAAAAAAAIQAAAAAAAAAP4sAABAAAAIAEAAAAQAAABH FpABAAACAgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAA AAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEAwAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAA AEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABABxCIgYAADQAgAAaAEAAAAAMBU4JlBLOCZL GjhGBQBdAAAAggYAABklAAABABIAAAAEAAMQTwAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAADB IgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0 AIAAMjAAABAAGQBkAAAAGQAAAI4tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAA8ATQBH AEMAUAAgAFQAZQBzAHQAIABjAGEAcwBlAHMAAAAmAG0AZwBjAHAAIABnAGEAdABlAHcAYQB5 ACAAcABhAHIAYQBtAGUAdABlAHIAIABjAG8AbQBtAGEAbgBkACAAZABlAHYAaQBjAGUAIAAA AAkATAB1AGEAbgAgAEQAYQBuAGcAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBt AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAA AAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADYAgAAEgAAAAEAAACYAAAAAgAAAKAA AAADAAAAuAAAAAQAAADEAAAABQAAANgAAAAGAAAACAEAAAcAAAAwAgAACAAAAEQCAAAJAAAA YAIAABIAAABsAgAACgAAAIgCAAALAAAAlAIAAAwAAACgAgAADQAAAKwCAAAOAAAAuAIAAA8A AADAAgAAEAAAAMgCAAATAAAA0AIAAAIAAADkBAAAHgAAABAAAABNR0NQIFRlc3QgY2FzZXMA HgAAAAEAAAAAR0NQHgAAAAoAAABMdWFuIERhbmcAY2EeAAAAJwAAAG1nY3AgZ2F0ZXdheSBw YXJhbWV0ZXIgY29tbWFuZCBkZXZpY2UgACAeAAAAIAEAAE1HQ1AgZ2F0ZXdheSBpbXBsZW1l bnRhdGlvbiBpbnRlcmZhY2UNRXh0ZW5zaW9ucyB0byBNR0NQDU1HQ1AgaW50ZXJmYWNlIGZv ciBzYXJhcy1zczcgY29udHJvbGxhYmxlIHRydW5rIGdhdGV3YXlzIA0NVGhlIGZvbGxvd2lu ZyBNR0NQIGNvbW1hbmRzIG9wZXJhdGUgb24gZW5kcG9pbnRzDQ1Db250aW51aXR5IFRlc3Rz OiBUaGUgZGV2aWNlIHNlcnZlciByZXF1ZXN0cyBjb250aW51aXR5IHRlc3RzIHRvIGJlIHBl cmZvcm1lZCBvbiBhbiBlbmRwb2ludCBieSBzZW5kaW5nIGEgTm90aWZ5UmVxdWVzdC4gAB4A AAALAAAATm9ybWFsLmRvdAB5HgAAABMAAABQcmVmZXJyZWQgQ3VzdG9tZXIAZR4AAAACAAAA NQBlZh4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAGVAAAAAAG7w/QwAAABAAAAAAIK3xsrd vgFAAAAAAFj3+mLdvgFAAAAAAAAU/6PivgEDAAAAAQAAAAMAAACCBgAAAwAAABklAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjwBAAD4AAAADAAAAAEA AABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACcAAAA EAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwAAAAMAAAA2AAAAAIAAADkBAAAHgAAAAIA AAAgAGwAAwAAAE8AAAADAAAAEgAAAAMAAACOLQAAAwAAAOgQCAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEAAAAE1HQ1AgVGVzdCBjYXNlcwAMEAAAAgAAAB4A AAAGAAAAVGl0bGUAAwAAAAEAAAAAAMACAAAEAAAAAAAAACgAAAABAAAAUgAAAAIAAABaAAAA AwAAALIAAAACAAAAAgAAAAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwACAAAA 5AQAAEEAAABOAAAAewAyADEAQwBDADIAQQA4ADQALQBGADIAMABGAC0AMQAxAEQAMgAtAEEA NABGAEQALQAwADAAMQAwADQAQgAyADkAMgA3AEQAQwB9AAAAAABBAAAABAIAABgAAAADAAAA CgB6AAMAAAAwAAAAAwAAAAAAAAADAAAABQAAAB8AAAA3AAAAbQBhAGkAbAB0AG8AOgBTAHkA cwB0AGUAbQBJAGQALwBTAHkAcwB0AGUAbQBUAHkAcABlAC8AQgBhAHkATgB1AG0ALwBtAG8A ZAB1AGwAZQAtAG4AdQBtAEAAaQBwAEEAZABkAHIAZQBzAHMAAAAAAB8AAAABAAAAAAAAAAMA AAA+AEUAAwAAANYRAAADAAAAAQQAAAMAAAABAAAAHwAAAB8AAABoAGkAZwBoACAAbABlAHYA ZQBsACAAbQBzAGcAIABmAGwAbwB3AFwAaQBtAGcAMAAwADEALgBnAGkAZgAAAAAAHwAAAAEA AAAAAAAAAwAAAD4ARgADAAAAWBsAAAMAAAACBAAAAwAAAAEAAAAfAAAAHwAAAGgAaQBnAGgA IABsAGUAdgBlAGwAIABtAHMAZwAgAGYAbABvAHcAXABpAG0AZwAwADAAMgAuAGcAaQBmAAAA AAAfAAAAAQAAAAAAAAADAAAAPgBHAAMAAABgKgAAAwAAAAMEAAADAAAAAQAAAB8AAAAfAAAA aABpAGcAaAAgAGwAZQB2AGUAbAAgAG0AcwBnACAAZgBsAG8AdwBcAGkAbQBnADAAMAAzAC4A ZwBpAGYAAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA CQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA JAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAAP7///8sAAAALQAAAC4AAAAvAAAAMAAAADEA AAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA PwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwA AABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAP7///9ZAAAA WgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcA AABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA dQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAA/v///3wAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIA AAD+////hAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAP7////9/////f///44AAAD+//// /v////7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAA wAAAAAAAAEYAAAAAoM6sFWPdvgHgfw8IpOK+AZAAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKwAAAOpZ AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYAAAAUUUAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQYAAAAFAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeVAAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAAoAAIB////////////////FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA ewAAAAAQAAAgAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAvAAAA/v///zgAAgEEAAAA//////////81AAAANgAAADcAAAD+//// //////////////////////////+DAAAAABAAAP////8BAEMAbwBtAHAATwBiAGoAAAD///// ////////////////////////////////////////////////////////EgACAQIAAAAHAAAA ////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAABqAAAA/////08A YgBqAGUAYwB0AFAAbwBvAGwAAAD///////////////////////////////////////////// //////////8WAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADgfw8IpOK+AeB/ Dwik4r4B////////////////AQAAAP7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8BAP7/AwoAAP// //8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dv cmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAD== --X67zE479640f479mwO62eJDMPnX8295-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 23 08:02:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NF2crP008582; Thu, 23 May 2002 08:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NF2cTX008581; Thu, 23 May 2002 08:02: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.3+Sun/8.12.3) with ESMTP id g4NF2XrP008574 for ; Thu, 23 May 2002 08:02:33 -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 IAA05305 for ; Thu, 23 May 2002 08:02:39 -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 JAA14114 for ; Thu, 23 May 2002 09:03:23 -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 LAA13485; Thu, 23 May 2002 11:02:18 -0400 (EDT) Message-Id: <200205231502.LAA13485@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IPv6 Node Information Queries to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 23 May 2002 11:02:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Version 6 Working Group to consider IPv6 Node Information Queries as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 6, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-09.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 23 08:34:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFY4rP008688; Thu, 23 May 2002 08:34:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFY48l008687; Thu, 23 May 2002 08:34:04 -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.3+Sun/8.12.3) with ESMTP id g4NFY1rP008680 for ; Thu, 23 May 2002 08:34:01 -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 IAA22891 for ; Thu, 23 May 2002 08:34:07 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02944 for ; Thu, 23 May 2002 08:34:06 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4NFY50E013585 for ; Thu, 23 May 2002 17:34:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 23 17:34:04 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4R4VB>; Thu, 23 May 2002 17:30:54 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F067A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: MLD comments on cellular host drafts - seeking feedback Date: Thu, 23 May 2002 17:33:57 +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 Hi, I've tried to summarise the current situation with MLD and see how we can move forward with the next revisions of the draft. Jari will send another emails for the rest of the issues discussed. First let me summarise the comments: - MLD must be used for all multicast addresses except the all nodes multicast address. This is what RFC2710 says. My understanding (please correct me if I'm wrong) was that the need for using MLD for link-scope addresses was to allow for the cases where L2 switches snoop MLD reports. As far as the cellular host is concerned, we are dealing with p2p links where the neighbour is a default router. So for link local traffic in general the notion of multicast does not exist (even if, for example an RS is sent to the all routers multicast address, it is going to one router). And there are no switches that will need to snoop MLD traffic. Sending MLD reports for link local addresses, will not only increase the use of BW on the links but is unnecessary for this p2p link. However, MLD will be necessary for multicast addresses with scopes larger than the link scope. So based on the dicussion above, we have a number of choices for the next update: 1. Suggest that MLD must be used even for link local addresses in p2p links within cellular networks (3GPP). pros: We follow RFC 2710. cons: Waste of expensive BW unnecessarily 2. We suggest that for these p2p links, with no switches snooping MLD traffic, MLD should only be used for multicast addresses with scopes larger than link-local. pros: We save expensive BW cons: We don't follow RFC2710, but then again RFC2710 does not make a clear distinction between these p2p links and other multicast links. 3. We suggest that this exception (of not using MLD for link-local multicast traffic) can be made, until RFC2710 is updated to explain why the mandate was placed and whether there should be any exceptions to that mandate. pros: We also minimise the scope of the exception to 3GPP only. cons: We still don't follow this particular part of RFC2710 I look forward to your choices from the above selection :) or even new suggestions. 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 Thu May 23 15:18:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NMIdrP012523; Thu, 23 May 2002 15:18:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NMIcqK012522; Thu, 23 May 2002 15:18: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.3+Sun/8.12.3) with ESMTP id g4NMIYrP012515 for ; Thu, 23 May 2002 15:18:35 -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 PAA20401 for ; Thu, 23 May 2002 15:18:40 -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 QAA27471 for ; Thu, 23 May 2002 16:18:37 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id A06EE6A906; Fri, 24 May 2002 01:18:30 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E9D726A904; Fri, 24 May 2002 01:18:28 +0300 (EEST) Message-ID: <3CED6AF6.8010303@kolumbus.fi> Date: Fri, 24 May 2002 01:19:34 +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: Margaret Wasserman Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Cellular host issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret's e-mail and the following discussion raised a number of questions about the cellular host document. In the following we try summarize the feedback and propose modifications to the document to address the concerns. The concerns were as follows: 1) Document status should be visible 2) DNS recursive query recommendation 3) Whether NUD needs to be done or not 4) Speculation of AH's fate should not be included 5) Correspondent node functionality to be discussed or not 6) Tunneling avoidance over air recommendation 7) Place of the 6to4 recommendation 8) Editorial comments 9) MLD issues (dealt in Hesham's e-mail) Based on our understanding of the discussion on the list, we have formulated proposed answers and new text to handle these concerns. Please take a look at this and let us know if they are acceptable: 1) Document status should be visible We will put the status back to the document. The following statement will be added to the introduction chapter: "This document is informational in nature, and it is not intended to replace, update, or contradict any IPv6 standards documents [RFC-2026]." 2) DNS recursive query recommendation We need to clarify that the use of the recursive queries is not intended to limit the functionality of the cellular hosts or restrict the service providers to deploy DNS servers capable of answering recursive queries. The old text "If DNS is used, a cellular host should perform DNS requests in the recursive mode, to limit signaling over the air interface." will be changed to "If DNS is used, a cellular host can perform DNS requests in the recursive mode, to limit signaling over the air interface. Both the iterative and the recursive approach should be supported, however, as the specifications require implementation of the iterative approach, and allow the recursive approach as an option. Furthermore, recursive queries may not be supported by all DNS servers." 3) Whether NUD needs to be done or not Based on the discussion on the list, 3GPP connections appear to be able to ensure host - GGSN e2e two-way reachability, all the way up to ensuring that GGSN IP layer is reachable. The text has been clarified to state that it is mandatory to implement not just ND in general but also NUD. Requirements for NUD the advice information from other layers have been listed, and their use has been strongly recommended. "2.4 RFC2461 - Neighbor Discovery for IPv6 Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6. 2.4.1 Neighbor Discovery in 3GPP Networks In GPRS and UMTS networks, some Neighbor Discovery messages can cause unnecessary traffic and consume valuable (limited) bandwidth. GPRS and UMTS links resemble a point-to-point link; hence, the host's only neighbor on the cellular link is the default router that is already known through Router Discovery. Therefore, while the host must support Neighbor Solicitation and Advertisement messages, their use in address resolution and next-hop determination is not necessary and the host may choose to not initiate them. The host must support the Neighbour Solicitation and Advertisement messages for neighbour unreachability detection as specified in [RFC-2461]. However, it is strongly recommended that forward progress information from other layers is made available to the IP layer. This is done in order to suppress the sending of these messages when two-way reachability between the peer IP layers has been already assured using other means." 4) Speculation of AH's fate should not be included The following part of the text will be deleted: "The IPsec WG has discussed the role of AH in the future, and it is possible that it will be made optional in the future versions of the IPsec protocol set. Implementers are recommended to take this in account." 5) Correspondent node functionality to be discussed or not Based on the e-mail discussion and input from the ADs, it would be inappropriate to refer to an I-D in a normative way, hence it is hard to add anything. (Note: we are working hard to complete the MIPv6 specification -- even if it is not ready today, it will get done sooner or later. At that point a bis cellular host draft and/or general ipv6 node requirements document can be issued with MIPv6 included.) 6) Tunneling avoidance over air recommendation The intention was to talk about use, not implementation. However, it is perhaps best that both this and the 6to4 recommendation are dealt with by the ngtrans WG team, and we can thus leave both 2.11 and 2.13 out of the document. 7) Place of the 6to4 recommendation We will leave this recommendation out, and to be handled by the effort in the ngtrans WG. 8) Editorial comments We have tried to correct the editorial comments. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 23 17:55:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O0tgrP013133; Thu, 23 May 2002 17:55:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O0tfoS013132; Thu, 23 May 2002 17:55: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.3+Sun/8.12.3) with ESMTP id g4O0tcrP013125 for ; Thu, 23 May 2002 17:55: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 RAA25447 for ; Thu, 23 May 2002 17:55:44 -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 SAA06756 for ; Thu, 23 May 2002 18:55:43 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17B3Ms-0001GT-00; Thu, 23 May 2002 17:55:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jari Arkko Cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host issues References: <3CED6AF6.8010303@kolumbus.fi> Message-Id: Date: Thu, 23 May 2002 17:55:42 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "If DNS is used, a cellular host can perform DNS requests > in the recursive mode, to limit signaling over the air > interface. Both the iterative and the recursive approach > should be supported, however, as the specifications require > implementation of the iterative approach, and allow the > recursive approach as an option. Furthermore, recursive > queries may not be supported by all DNS servers." [ feel free to ignore this, but ] you may want to note that one can not trust (in the dnssec sense) the result from a query that caused recursion. one has to do the traversal. there has been some discussion of the device having a trust association (see TSIG) with a (caching recursive) server which does the checking for one, but it has not converged. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 00:58:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O7wfrP014093; Fri, 24 May 2002 00:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O7wfQd014092; Fri, 24 May 2002 00:58:41 -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.3+Sun/8.12.3) with ESMTP id g4O7wcrP014085 for ; Fri, 24 May 2002 00:58:38 -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 AAA15917 for ; Fri, 24 May 2002 00:58:42 -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 BAA23673 for ; Fri, 24 May 2002 01:58:41 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F3C066A907; Fri, 24 May 2002 10:58:39 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 244796A904; Fri, 24 May 2002 10:58:34 +0300 (EEST) Message-ID: <3CEDF2EC.4000200@kolumbus.fi> Date: Fri, 24 May 2002 10:59: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: Randy Bush Cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host issues References: <3CED6AF6.8010303@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: > you may want to note that one can not trust (in the dnssec sense) > the result from a query that caused recursion. Good point, thanks. I will add a note about this to the text: "... Furthermore, recursive queries may not be supported by all DNS servers, and may not be always possible with secure DNS." 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 May 24 06:46:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ODkbrP015252; Fri, 24 May 2002 06:46:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ODkbsS015251; Fri, 24 May 2002 06:46: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.3+Sun/8.12.3) with ESMTP id g4ODkYrP015244 for ; Fri, 24 May 2002 06:46:34 -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 GAA11395 for ; Fri, 24 May 2002 06:46:38 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03460 for ; Fri, 24 May 2002 07:47:24 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17BFOu-000LZb-00; Fri, 24 May 2002 06:46:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jari Arkko Cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host issues References: <3CED6AF6.8010303@kolumbus.fi> <3CEDF2EC.4000200@kolumbus.fi> Message-Id: Date: Fri, 24 May 2002 06:46:37 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> you may want to note that one can not trust (in the dnssec sense) >> the result from a query that caused recursion. > Good point, thanks. I will add a note about this to the text: > "... Furthermore, recursive queries may not be > supported by all DNS servers, and may not be > always possible with secure DNS." well, they're *possible*. they're just not secure. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 08:35:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFZirP015734; Fri, 24 May 2002 08:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OFZhT0015733; Fri, 24 May 2002 08:35: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.3+Sun/8.12.3) with ESMTP id g4OFZerP015726 for ; Fri, 24 May 2002 08:35: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 IAA08216 for ; Fri, 24 May 2002 08:35:46 -0700 (PDT) From: juha.wiljakka@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22414 for ; Fri, 24 May 2002 08:35:45 -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 g4OFbDa02881 for ; Fri, 24 May 2002 18:37:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 May 2002 18:35:43 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 May 2002 18:35:43 +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: MLD comments on cellular host drafts - seeking feedback Date: Fri, 24 May 2002 18:35:43 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FCE4B4B@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MLD comments on cellular host drafts - seeking feedback Thread-Index: AcICb5RaS7+E8HpMTj2vpnMTUJTTQgAyMRcw To: , X-OriginalArrivalTime: 24 May 2002 15:35:43.0892 (UTC) FILETIME=[AAD4CD40:01C20338] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4OFZfrP015727 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, this was a good summary. So how about going for alternative 3? Cheers, -Juha W.- -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: 23 May, 2002 18:34 I've tried to summarise the current situation with MLD and see how we can move forward with the next revisions of the draft. Jari will send another emails for the rest of the issues discussed. First let me summarise the comments: - MLD must be used for all multicast addresses except the all nodes multicast address. This is what RFC2710 says. My understanding (please correct me if I'm wrong) was that the need for using MLD for link-scope addresses was to allow for the cases where L2 switches snoop MLD reports. As far as the cellular host is concerned, we are dealing with p2p links where the neighbour is a default router. So for link local traffic in general the notion of multicast does not exist (even if, for example an RS is sent to the all routers multicast address, it is going to one router). And there are no switches that will need to snoop MLD traffic. Sending MLD reports for link local addresses, will not only increase the use of BW on the links but is unnecessary for this p2p link. However, MLD will be necessary for multicast addresses with scopes larger than the link scope. So based on the dicussion above, we have a number of choices for the next update: 1. Suggest that MLD must be used even for link local addresses in p2p links within cellular networks (3GPP). pros: We follow RFC 2710. cons: Waste of expensive BW unnecessarily 2. We suggest that for these p2p links, with no switches snooping MLD traffic, MLD should only be used for multicast addresses with scopes larger than link-local. pros: We save expensive BW cons: We don't follow RFC2710, but then again RFC2710 does not make a clear distinction between these p2p links and other multicast links. 3. We suggest that this exception (of not using MLD for link-local multicast traffic) can be made, until RFC2710 is updated to explain why the mandate was placed and whether there should be any exceptions to that mandate. pros: We also minimise the scope of the exception to 3GPP only. cons: We still don't follow this particular part of RFC2710 I look forward to your choices from the above selection :) or even new suggestions. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 08:58:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFwrrP015866; Fri, 24 May 2002 08:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OFwr0n015865; Fri, 24 May 2002 08:58: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.3+Sun/8.12.3) with ESMTP id g4OFworP015858 for ; Fri, 24 May 2002 08:58:50 -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 IAA21991 for ; Fri, 24 May 2002 08:58:55 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04978 for ; Fri, 24 May 2002 09:58:55 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id LAA05572 for ; Fri, 24 May 2002 11:58:53 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Fri, 24 May 2002 09:02:16 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FCE4B4B@esebe005.NOE.Nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The L2 p2p link ends at the BTS (?) , but the L3 subnet ends at GGSN (?) which is a router. BTS supports multiple p2p links, any of them can have a mcast listener. So the BTS needs a way to figure out to which L2 p2p link a mcast packet needs to be forwarded. Without MLD support, how does the L2 switch know there is a mcast listener in the link so it can copy a packet to that link ? The only other way would be to manually configure the L2 switch - not scalable. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of juha.wiljakka@nokia.com Sent: Friday, May 24, 2002 8:36 AM To: hesham.soliman@era.ericsson.se; ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Hesham, this was a good summary. So how about going for alternative 3? Cheers, -Juha W.- -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: 23 May, 2002 18:34 I've tried to summarise the current situation with MLD and see how we can move forward with the next revisions of the draft. Jari will send another emails for the rest of the issues discussed. First let me summarise the comments: - MLD must be used for all multicast addresses except the all nodes multicast address. This is what RFC2710 says. My understanding (please correct me if I'm wrong) was that the need for using MLD for link-scope addresses was to allow for the cases where L2 switches snoop MLD reports. As far as the cellular host is concerned, we are dealing with p2p links where the neighbour is a default router. So for link local traffic in general the notion of multicast does not exist (even if, for example an RS is sent to the all routers multicast address, it is going to one router). And there are no switches that will need to snoop MLD traffic. Sending MLD reports for link local addresses, will not only increase the use of BW on the links but is unnecessary for this p2p link. However, MLD will be necessary for multicast addresses with scopes larger than the link scope. So based on the dicussion above, we have a number of choices for the next update: 1. Suggest that MLD must be used even for link local addresses in p2p links within cellular networks (3GPP). pros: We follow RFC 2710. cons: Waste of expensive BW unnecessarily 2. We suggest that for these p2p links, with no switches snooping MLD traffic, MLD should only be used for multicast addresses with scopes larger than link-local. pros: We save expensive BW cons: We don't follow RFC2710, but then again RFC2710 does not make a clear distinction between these p2p links and other multicast links. 3. We suggest that this exception (of not using MLD for link-local multicast traffic) can be made, until RFC2710 is updated to explain why the mandate was placed and whether there should be any exceptions to that mandate. pros: We also minimise the scope of the exception to 3GPP only. cons: We still don't follow this particular part of RFC2710 I look forward to your choices from the above selection :) or even new suggestions. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 11:15:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIFurP016793; Fri, 24 May 2002 11:15:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIFuC0016792; Fri, 24 May 2002 11:15:56 -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.3+Sun/8.12.3) with ESMTP id g4OIFqrP016785 for ; Fri, 24 May 2002 11:15:52 -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 LAA19739 for ; Fri, 24 May 2002 11:15:57 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28946 for ; Fri, 24 May 2002 12:15:56 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4OIFt6n011847 for ; Fri, 24 May 2002 20:15:55 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 24 20:15:54 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:04:51 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F068E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dr. Subrata Goswami'" , ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Fri, 24 May 2002 20:15:53 +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 > The L2 p2p link ends at the BTS (?) , but the L3 subnet > ends at GGSN (?) => Not quite. The 'link', as seen by the IP stack, is p2p between the host and the GGSN. > which is a router. BTS supports multiple p2p links, any of > them can have a > mcast listener. So the BTS needs a way to figure out to > which L2 p2p link a > mcast packet needs to be forwarded. Without MLD support, > how does the L2 > switch know there is a mcast listener in the link so it can > copy a packet > to that link ? The only other way would be to manually > configure the L2 > switch - not scalable. => The BTS (node B) is not a switch and doesn't even terminate the radio link, so it can't route traffic directly between hosts. The _only_ node that can do that is the default router (GGSN). You can think of it as any p2p link used today. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 11:17:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIHurP016810; Fri, 24 May 2002 11:17:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIHuw7016809; Fri, 24 May 2002 11:17: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.3+Sun/8.12.3) with ESMTP id g4OIHrrP016802 for ; Fri, 24 May 2002 11:17:53 -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 LAA08745 for ; Fri, 24 May 2002 11:17:57 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16412 for ; Fri, 24 May 2002 12:17:55 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4OIHhmG003936 for ; Fri, 24 May 2002 20:17:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 24 20:17:42 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:06:39 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F068F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'juha.wiljakka@nokia.com'" , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Fri, 24 May 2002 20:17:40 +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 > > this was a good summary. So how about going for alternative 3? > => I think either 2 or 3 are fine. So, yes, 3 is ok. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 11:54:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIsRrP017214; Fri, 24 May 2002 11:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIsQb2017213; Fri, 24 May 2002 11:54: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.3+Sun/8.12.3) with ESMTP id g4OIsNrP017206 for ; Fri, 24 May 2002 11:54:23 -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 LAA06577 for ; Fri, 24 May 2002 11:54:28 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20439 for ; Fri, 24 May 2002 12:55:10 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id OAA09789 for ; Fri, 24 May 2002 14:54:22 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Fri, 24 May 2002 11:57:44 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0691@Esealnt861.al.sw.ericsson.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I do not think we can ignore the rest of the network. The SGSN needs a mechanism to populate its forwarding table with mcast addresses - that is where MLD snooping comes in. Is the following a good representation of a cellular network ? IPL1 IPR1 Mobile 1--------(SGSN)------\ (GGSN)--> Mobile 2--------(SGSN)------/ IPL2 IPR2 I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same link as SGSN are L2 devices. So if Mobile 1 subscribes to a link-local group and so does Mobile 2, then we need mcast forwarding between them. Next question would be what are IPL1, IPL2, and IPRx - global, site-scope,link-local unicat addresses ? Subrata. -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Friday, May 24, 2002 11:28 AM To: 'Dr. Subrata Goswami'; Hesham Soliman (ERA) Subject: RE: MLD comments on cellular host drafts - seeking feedback > Are you sure that the BTS does not terminate the radio link > - physically => Yes. I'm assuming you're still talking about WCDMA. > that looks like the spot for termination. Okay, if the IP > stack sees a L3 > p2p link, then the IP address on the GGSN interface is same > for a number of > mobile hosts - right ? So the GGSN has to know which of the mobiles > connected to it need mcast group traffic, right ? => But we're not talking about mcast addresses in general, we're talking about link-local mcast addresses. For those addresses you don't need to join on a p2p link. Similarly > the SGSN also > needs to know which links it needs to copy an mcast group packet to. => No. The SGSN is not involved in any routing. The _only_ node that does routing is the GGSN. We can ignore the rest of the network as far as the IETF is concerned. Or at least as far this WG is concerned. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 24 13:56:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OKuZrP017768; Fri, 24 May 2002 13:56:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OKuZeU017767; Fri, 24 May 2002 13:56: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.3+Sun/8.12.3) with ESMTP id g4OKuWrP017760 for ; Fri, 24 May 2002 13:56:32 -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 NAA27290 for ; Fri, 24 May 2002 13:56:36 -0700 (PDT) Received: from mhs99ykf.rim.net (c109.rim.net [206.51.26.109]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09809 for ; Fri, 24 May 2002 14:56:36 -0600 (MDT) Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 52BA0B4822 for ; Fri, 24 May 2002 16:56:35 -0400 (EDT) Received: from PGS02YKF.rim.net ([10.101.20.231]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2002052416563404175 ; Fri, 24 May 2002 16:56:35 -0400 Received: from xch02ykf.rim.net [10.101.20.37] by PGS02YKF.rim.net [10.101.20.231] (CMSPraetor 5.10.4411) with ESMTP id 4EF5082186E6492290799C53BE592D91 ; Fri, 24 May 2002 16:56:29 -0400 Received: by xch02ykf.rim.net with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 16:56:30 -0400 From: Craig Dunk To: "Dr. Subrata Goswami" , Message-ID: <05BEA41254F24A4CBA66E811CDD3AD9C02BEEC61@xch08ykf> Subject: Device to GGSN as point to point (was: MLD comments on cellular h ost drafts - seeking feedback) Date: Fri, 24 May 2002 16:56:28 -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 Someone may need to correct this, but, I think the misunderstanding comes from the nature of the link between the mobile and the GGSN. Conceptually it is more like the device making a phone call to the ggsn: it doesn't matter how many phone switches are between the endpoints, they don't come into play in the packet forwarding, only the GGSN does. However, in this case the "phone calls" are called pdp contexts and pass through the SGSN. In that case I think the answer to your question about scope is that the addresses of the SGSN can be any scope, but they are conceptually below the point to point relationship that exists between the device and GGSN. Craig. -----Original Message----- From: Dr. Subrata Goswami [mailto:sgoswami@umich.edu] Sent: May 24, 2002 2:58 PM To: ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback I do not think we can ignore the rest of the network. The SGSN needs a mechanism to populate its forwarding table with mcast addresses - that is where MLD snooping comes in. Is the following a good representation of a cellular network ? IPL1 IPR1 Mobile 1--------(SGSN)------\ (GGSN)--> Mobile 2--------(SGSN)------/ IPL2 IPR2 I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same link as SGSN are L2 devices. So if Mobile 1 subscribes to a link-local group and so does Mobile 2, then we need mcast forwarding between them. Next question would be what are IPL1, IPL2, and IPRx - global, site-scope,link-local unicat addresses ? Subrata. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 26 07:03:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4QE3NrP020488; Sun, 26 May 2002 07:03:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4QE3NxK020487; Sun, 26 May 2002 07:03: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.3+Sun/8.12.3) with ESMTP id g4QE3JrP020480 for ; Sun, 26 May 2002 07:03:20 -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 HAA09265 for ; Sun, 26 May 2002 07:03:23 -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 IAA19682 for ; Sun, 26 May 2002 08:03:18 -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 g4QE3Gn31548 for ; Sun, 26 May 2002 16:03:16 +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 QAA26896 for ; Sun, 26 May 2002 16:03:16 +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.11.3/8.11.3) with ESMTP id g4QE3GT34039 for ; Sun, 26 May 2002 16:03:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205261403.g4QE3GT34039@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: DAD or DIIDD Date: Sun, 26 May 2002 16:03:16 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the Mobile IPv6, the home agent provides a neighbor discovery proxy service (RFC 2461 7.2.8: basically it answers to Neighbor Solicitations as for one of its addresses but with a short delay (collision avoidance) and with always the Override flag set to zero). So if someone tries to perform a DAD over one of these proxied addresses, the DAD should fail. But what happens if the DAD is performed for the associated link-local address? To summary the debate in the mobile-ip list, the question is "the mobile node returning at home may or may not use the link-local address which is associated to its home address, i.e. shares the interface ID?" This raises a question I summarize by DAD or DIIDD (Duplicated Address Detection of Duplicated Interface ID Detection). The two references are subtilely incoherent: RFC 2373 (and last I-D draft-ietf-ipngwg-addr-arch-v3-07.txt): 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. ... In many cases an interface's identifier will be the same as that interface's link-layer address. RFC 2462 4. PROTOCOL OVERVIEW For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually. In contrast, all addresses obtained manually or via stateful address autoconfiguration should be tested for uniqueness individually. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. and in 5.4. Duplicate Address Detection ... Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. We have two solutions to solve this issue: - the first one is to affirm that DAD is not a DIIDD: * removal of the uniqueness of IIDs in address architecture (only link-local addresses must be unique) * removal of the "same interface identifier" considerations in RFC 2462 * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses Implementation changes are: - for stateless configuration or stateless configuration-like mechanisms the only difference is the removal of the MAY in 5.4. - for other mechanisms the DAD detection for the address itself doesn't change but this choice makes clear the associated link-local address should not be object of a DAD. This is the simpler fix but IMHO not the best. - the other option is to change the DAD in a DIIDD: * no change in address architecture (cf an Erik Nordmark's argument about architectural purity) * the "a set addresses formed from the same interface identifier" is in totally abusive way applied even for a set of one address so DAD for the associated link-local address becomes mandatory and DAD for the address itself MAY be skipped. Implementation changes are: - for stateless configuration: no difference - for stateless configuration-like mechanisms: the rule to apply is the same than for stateless configuration (i.e. clarification) - for other mechanisms the DAD for the associated link-local address is mandatory but the DAD for the address itself becomes optional (or will become optional in X years for compatibility). This choice has a real impact on router implementations, I'd like to get a feed-back from router vendors (is it acceptable?) Regards Francis.Dupont@enst-bretagne.fr PS: I believe we should solve this issue before the next IETF meeting! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 26 07:26:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4QEQQrP020531; Sun, 26 May 2002 07:26:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4QEQP6h020530; Sun, 26 May 2002 07:26:25 -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.3+Sun/8.12.3) with ESMTP id g4QEQMrP020523 for ; Sun, 26 May 2002 07:26:22 -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 HAA07923 for ; Sun, 26 May 2002 07:26:22 -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 IAA07348 for ; Sun, 26 May 2002 08:26:21 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8B0294B22 for ; Sun, 26 May 2002 23:26:17 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Sun, 26 May 2002 16:03:16 +0200. <200205261403.g4QE3GT34039@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD or DIIDD From: itojun@iijlab.net Date: Sun, 26 May 2002 23:26:17 +0900 Message-ID: <28345.1022423177@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We have two solutions to solve this issue: > - the first one is to affirm that DAD is not a DIIDD: > * removal of the uniqueness of IIDs in address architecture > (only link-local addresses must be unique) > * removal of the "same interface identifier" considerations in RFC 2462 > * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses > Implementation changes are: > - for stateless configuration or stateless configuration-like mechanisms > the only difference is the removal of the MAY in 5.4. > - for other mechanisms the DAD detection for the address itself doesn't > change but this choice makes clear the associated link-local address > should not be object of a DAD. > This is the simpler fix but IMHO not the best. i vote for this (DAD is DAD, not DIIDD). this is future-proven even if we have other address architecture (which does not use /64). 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 May 26 13:23:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4QKNarP020865; Sun, 26 May 2002 13:23:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4QKNaJd020864; Sun, 26 May 2002 13:23: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.3+Sun/8.12.3) with ESMTP id g4QKNXrP020857 for ; Sun, 26 May 2002 13:23: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 NAA14536 for ; Sun, 26 May 2002 13:23:38 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20040 for ; Sun, 26 May 2002 13:23:38 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id QAA19309 for ; Sun, 26 May 2002 16:23:36 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: DAD or DIIDD Date: Sun, 26 May 2002 13:27:32 -0700 Message-ID: <000001c204f3$c5df3960$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <200205261403.g4QE3GT34039@givry.rennes.enst-bretagne.fr> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, is the following question equivalent to what you are asking ? Does the Home Agent do a Neighbor Advertisement proxy for link-local addresses of mobile nodes which are away ? Related question, does MIPv6 allow link-local addresses as Home Addresses ? The mobile node, when it returns may use a different interface to connect to the home network. The Home Agent does not know how many interfaces the mobile device has, nor should it. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Francis Dupont Sent: Sunday, May 26, 2002 7:03 AM To: ipng@sunroof.eng.sun.com Subject: DAD or DIIDD In the Mobile IPv6, the home agent provides a neighbor discovery proxy service (RFC 2461 7.2.8: basically it answers to Neighbor Solicitations as for one of its addresses but with a short delay (collision avoidance) and with always the Override flag set to zero). So if someone tries to perform a DAD over one of these proxied addresses, the DAD should fail. But what happens if the DAD is performed for the associated link-local address? To summary the debate in the mobile-ip list, the question is "the mobile node returning at home may or may not use the link-local address which is associated to its home address, i.e. shares the interface ID?" This raises a question I summarize by DAD or DIIDD (Duplicated Address Detection of Duplicated Interface ID Detection). The two references are subtilely incoherent: RFC 2373 (and last I-D draft-ietf-ipngwg-addr-arch-v3-07.txt): 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. ... In many cases an interface's identifier will be the same as that interface's link-layer address. RFC 2462 4. PROTOCOL OVERVIEW For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually. In contrast, all addresses obtained manually or via stateful address autoconfiguration should be tested for uniqueness individually. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. and in 5.4. Duplicate Address Detection ... Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. We have two solutions to solve this issue: - the first one is to affirm that DAD is not a DIIDD: * removal of the uniqueness of IIDs in address architecture (only link-local addresses must be unique) * removal of the "same interface identifier" considerations in RFC 2462 * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses Implementation changes are: - for stateless configuration or stateless configuration-like mechanisms the only difference is the removal of the MAY in 5.4. - for other mechanisms the DAD detection for the address itself doesn't change but this choice makes clear the associated link-local address should not be object of a DAD. This is the simpler fix but IMHO not the best. - the other option is to change the DAD in a DIIDD: * no change in address architecture (cf an Erik Nordmark's argument about architectural purity) * the "a set addresses formed from the same interface identifier" is in totally abusive way applied even for a set of one address so DAD for the associated link-local address becomes mandatory and DAD for the address itself MAY be skipped. Implementation changes are: - for stateless configuration: no difference - for stateless configuration-like mechanisms: the rule to apply is the same than for stateless configuration (i.e. clarification) - for other mechanisms the DAD for the associated link-local address is mandatory but the DAD for the address itself becomes optional (or will become optional in X years for compatibility). This choice has a real impact on router implementations, I'd like to get a feed-back from router vendors (is it acceptable?) Regards Francis.Dupont@enst-bretagne.fr PS: I believe we should solve this issue before the next IETF meeting! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 26 22:14:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R5EBrP021513; Sun, 26 May 2002 22:14:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R5EBgF021512; Sun, 26 May 2002 22:14:11 -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.3+Sun/8.12.3) with ESMTP id g4R5E8rP021505 for ; Sun, 26 May 2002 22:14:08 -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 WAA02776 for ; Sun, 26 May 2002 22:14:12 -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 XAA12382 for ; Sun, 26 May 2002 23:14: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 g4R5Dtn06093; Mon, 27 May 2002 07:13: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 HAA00282; Mon, 27 May 2002 07:13: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.11.3/8.11.3) with ESMTP id g4R5DrT36327; Mon, 27 May 2002 07:13:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205270513.g4R5DrT36327@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dr. Subrata Goswami" cc: ipng@sunroof.eng.sun.com Subject: Re: DAD or DIIDD In-reply-to: Your message of Sun, 26 May 2002 13:27:32 PDT. <000001c204f3$c5df3960$6600a8c0@SGOSWAMIPCL> Date: Mon, 27 May 2002 07:13:53 +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: Francis, is the following question equivalent to what you are asking ? => no, my question is a general one. 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 May 27 00:56:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R7uOrP021688; Mon, 27 May 2002 00:56:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R7uOQ1021687; Mon, 27 May 2002 00:56: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.3+Sun/8.12.3) with ESMTP id g4R7uLrP021680 for ; Mon, 27 May 2002 00:56:21 -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 AAA22835 for ; Mon, 27 May 2002 00:56:24 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15197 for ; Mon, 27 May 2002 01:56:24 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id DAA10213 for ; Mon, 27 May 2002 03:56:23 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: DAD or DIIDD Date: Mon, 27 May 2002 01:00:20 -0700 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.2910.0) In-Reply-To: <200205270513.g4R5DrT36327@givry.rennes.enst-bretagne.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, should/does the HA proxy for the link-local address in the home network ? Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Sunday, May 26, 2002 10:14 PM To: Dr. Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: DAD or DIIDD In your previous mail you wrote: Francis, is the following question equivalent to what you are asking ? => no, my question is a general one. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 02:52:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R9qDrP021988; Mon, 27 May 2002 02:52:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R9qDBk021987; Mon, 27 May 2002 02:52: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.3+Sun/8.12.3) with ESMTP id g4R9qArP021980 for ; Mon, 27 May 2002 02:52: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 CAA09901 for ; Mon, 27 May 2002 02:52:15 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12720 for ; Mon, 27 May 2002 03:52:11 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4R9q46n027371 for ; Mon, 27 May 2002 11:52:09 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 27 11:52:03 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 11:40:57 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0693@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dr. Subrata Goswami'" , ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Mon, 27 May 2002 11:51:55 +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 > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. => I don't know if my earlier message failed to convey the picture but please ignore the SGSN, it is irrelevant to this discussion. All traffic MUST go to the GGSN and get routed there. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. => No. See my comment above. No routing before the GGSN. and Mobile 1 _cannot_ communicate to Mobile 2 using link-local addresses. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 03:10:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RAAxrP022052; Mon, 27 May 2002 03:10:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RAAxs5022051; Mon, 27 May 2002 03:10:59 -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.3+Sun/8.12.3) with ESMTP id g4RAAurP022044 for ; Mon, 27 May 2002 03:10: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 DAA12519 for ; Mon, 27 May 2002 03:10:59 -0700 (PDT) From: lassi.hippelainen@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 EAA20846 for ; Mon, 27 May 2002 04:11:50 -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 g4RABKq28270 for ; Mon, 27 May 2002 13:11:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 May 2002 13:10:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 27 May 2002 13:10: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: MLD comments on cellular host drafts - seeking feedback Date: Mon, 27 May 2002 13:10:51 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MLD comments on cellular host drafts - seeking feedback Thread-Index: AcIDVgle4aemkNOaT9a6g0ahEH/6VACDbT8Q To: X-OriginalArrivalTime: 27 May 2002 10:10:56.0439 (UTC) FILETIME=[CAA4B470:01C20566] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4RAAurP022045 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, that isn't the correct model. 3GPP uses a "stratified" model. The link layer from the mobiles ends in the GGSN. There is also another link layer, between the SGSN and the GGSN, but that is in the lower stratum that is invisible to the mobiles. Always think about the mobile-GGSN link as a single hop. The difference is architecturally important. For example, the mobiles are *not* neighbors to each other, even when they are connected to the same Access Point (in 3GPP terminology). The links are only point-to-point, and nobody else is present. The reason is security. There can be 100k or more mobiles connected to a single AP. If they were all on the same link, any multicast operation could crash the GGSN, because it might have to replicate the packet 100k times. Also, any mobile could launch multicast-based DoS attacks against the GGSN or other mobiles. In brief, 3GPP networks cannot handle multicast (or DAD) in Ethernet manner. The numbers differ by severals orders of magnitude. -- Lassi > -----Original Message----- > From: ext Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Friday, May 24, 2002 9:58 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. Next question would be what are IPL1, IPL2, and IPRx - global, > site-scope,link-local unicat addresses ? > > Subrata. > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Friday, May 24, 2002 11:28 AM > To: 'Dr. Subrata Goswami'; Hesham Soliman (ERA) > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > > Are you sure that the BTS does not terminate the radio link > > - physically > > => Yes. I'm assuming you're still talking about WCDMA. > > > that looks like the spot for termination. Okay, if the IP > > stack sees a L3 > > p2p link, then the IP address on the GGSN interface is same > > for a number of > > mobile hosts - right ? So the GGSN has to know which of > the mobiles > > connected to it need mcast group traffic, right ? > > => But we're not talking about mcast addresses in general, > we're talking about link-local mcast addresses. For those > addresses you don't need to join on a p2p link. > > Similarly > > the SGSN also > > needs to know which links it needs to copy an mcast group > packet to. > > => No. The SGSN is not involved in any routing. The > _only_ node that does routing is the GGSN. We can > ignore the rest of the network as far as the IETF > is concerned. Or at least as far this WG is concerned. > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 03:18:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RAI4rP022075; Mon, 27 May 2002 03:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RAI3Eh022074; Mon, 27 May 2002 03:18:03 -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.3+Sun/8.12.3) with ESMTP id g4RAHvrP022067 for ; Mon, 27 May 2002 03:17: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 DAA06149 for ; Mon, 27 May 2002 03:18:00 -0700 (PDT) From: lassi.hippelainen@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23432 for ; Mon, 27 May 2002 04:18:52 -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 g4RAGk906146 for ; Mon, 27 May 2002 13:16:46 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 May 2002 13:17:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 27 May 2002 13:17:57 +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: Date: Mon, 27 May 2002 13:17:57 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcIFZ8S0J9gIgHFQEdaLxwBQBF1Fmw== To: X-OriginalArrivalTime: 27 May 2002 10:17:57.0919 (UTC) FILETIME=[C5DD72F0:01C20567] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4RAHxrP022068 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there support in this WG for making route optimization a MUST in all IPv6 hosts ? The ball is really in this WG's court. This is really a "do you really want ubiquitous end to end functionality or not?" question I'm not sure if that rule could be enforced. If a node keeps on sending to home address, it's a problem for the home network, but not for the sender. Is there a business reason for honouring an optimization? Why would a "free" ad-driven service (e.g. sports news) care about the well being of someone else's network? Why should it put effort in the authentication computations, if there is no benefit for itself? -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 03:24:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RAOxrP022109; Mon, 27 May 2002 03:24:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RAOwpa022108; Mon, 27 May 2002 03:24:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RAOtrP022101 for ; Mon, 27 May 2002 03:24: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 DAA12136 for ; Mon, 27 May 2002 03:24:58 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25787 for ; Mon, 27 May 2002 04:25:50 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4RAOu6n012275 for ; Mon, 27 May 2002 12:24:56 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 27 12:24:55 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4435S>; Mon, 27 May 2002 12:24:55 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0699@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'lassi.hippelainen@nokia.com'" , ipng@sunroof.eng.sun.com Subject: RE: Date: Mon, 27 May 2002 12:24:50 +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 > > > Is there support in this WG for making route optimization > a MUST in all IPv6 hosts ? The ball is really in this WG's > court. This is really a "do you really want ubiquitous end > to end functionality or not?" question > > I'm not sure if that rule could be enforced. If a node > keeps on sending to home address, it's a problem for the > home network, but not for the sender. > > Is there a business reason for honouring an optimization? > Why would a "free" ad-driven service (e.g. sports news) > care about the well being of someone else's network? Why > should it put effort in the authentication computations, if > there is no benefit for itself? => Not only, but there are also rules for MUSTs and SHOULDs. My understanding is that we only mandate things (MUST) if not doing it will break communication. MIP was designed to make ensure that it works with or without RO. So according to my understanding of the use of keywords, it should not be a must. Of course it is an important feature and therefore SHOULD is appropriate IMHO. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 03:55:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RAtOrP022145; Mon, 27 May 2002 03:55:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RAtOcq022144; Mon, 27 May 2002 03:55:24 -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.3+Sun/8.12.3) with ESMTP id g4RAtLrP022137 for ; Mon, 27 May 2002 03:55:21 -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 DAA13550 for ; Mon, 27 May 2002 03:55:25 -0700 (PDT) From: lassi.hippelainen@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 DAA10937 for ; Mon, 27 May 2002 03:55:23 -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 g4RAtkq03644 for ; Mon, 27 May 2002 13:55:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 May 2002 13:55:22 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 27 May 2002 13:55:22 +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: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) Date: Mon, 27 May 2002 13:55:22 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) Thread-Index: AcIB/jG0czOVvZPeTci8wzMcu5Lo5ADaa73w To: X-OriginalArrivalTime: 27 May 2002 10:55:22.0512 (UTC) FILETIME=[FFBF2900:01C2056C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4RAtLrP022138 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catchin up with mail... But first, let me remind that the original text is raw. In security analysis you first try to find all holes, then try to plug them, and only finally estimate how real the remaining danger is. My text is still in the first phase, where paranoia is cranked up to maximum. > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 23, 2002 5:04 AM > To: Hippelainen Lassi (NET/Helsinki) > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Security considerations over RFC3041 (was: IPv6 w.g. Last > Call on "IPv6 for...) > > > lassi.hippelainen@nokia.com writes: > > > 2. Packet filtering > > > A stateless filter cannot test the lowest address bits, because > > being stateless it does not know which suffices are in use at any > > moment. > > What do you mean by a stateless filter? To avoid market bullsh!t, I classify firewalls and such things to three major groups: - Stateless filters examine each packet independently. Example: Access Control Lists. Stateless filters have static rules and are easy to scale to parallel clusters, but aren't sophisticated. - Stateful filters are aware of higher layer entities, like TCP sessions. Example: firewall with "Stateful Inspection". More effective, but far more difficult to run in clusters. - Content filters are in the application layer. Example: e-mail scanners. In this context a stateless filter is happily unaware of any dynamic changes in network topology, like new node addresses. > > Previously the stateless filter could limit subnet address > > scans effectively by passing only a very small set of > > suffices. After RFC3041 it will pass a scan of up to 2^64 > > addresses. If the scanned node connects using a slow PPP link > > (e.g. a 3GPP mobile node), the scan will block its link. > > I don't follow what you mean here. Could you please explain. If you know you have only 6 nodes in a subnet (e.g. a PAN), you can allocate a /125 mask and throw away all packets outside that range. But with RFC3041 the limit is /64. You can't even try to detect a random scan, because the range of possible addresses is so wide. An intrusion detector can't store each probed address for later analysis, because there are so many possible addresses. > > 3. The suffix as a covert channel > > Not sure this is a much of an issue personally. Seems like there are > more effective and less painful ways of compromising communication > channels. Possibly, but in paranoid mode you list the dangers first, and think about relevance only after the remedies have been identified. Anyway, not analysing a possible risk, because there are so many others around, doesn't sound wise... > > 4. Leaking the global identity > > > The new "random" addresses are created in a deterministic manner > > (RFC3041 3.2.1. "When Stable Storage Is Present"). The software > > vendor can therefore predict every future suffix used by the node, > > or identify the node as soon as one suffix has been detected. > > I don't follow this. Knowing the algorithm and knowing one point in > the sequence space isn't sufficient to predict future (or determine > past) values of the interface identifier. You also need to know some > other state information (e.g., the MAC address), which is not > generally available. Sorry for an ambiguous expression. That paragraph is a summary of the ones that follow. But you can't trust that your MAC remains secret. It has a structure and some published identifiers. As mentioned below, most of it can be guessed rather easily. > > The suffix sequence can be seeded using the Ethernet address *and* > > the serial number of the software licence, leaking even more > > identity information than what a single fixed address would. Both of > > these identifiers can be narrowed down to a rather small subset of > > the available namespace by guessing. The time when the node came > > on-line for the first time can be used as guidance. > > Again, knowing one point in the sequence of random numbers is not > enough to figure out what previous or fugute values will be. Also 3041 > says nothing about using software licence number to seed the sequence. The RFC may not mention software serial numbers, but they aren't prohibited either. They can't be. The stack vendor can use any parameters and algorithm that seem useful, without most of the users noticing anything strange. In this case the threat model is a vendor that wants to track customers, with the lame excuse of detecting pirated copies. > > If the suffix is generated using MD5 as suggested in RFC3041, an > > ephemeral identity can be recovered by anyone, by brute forcing the > > missing 64 bits of initial state from two consecutive suffices. The > > processing expense is not prohibitively high, and is getting lower > > all the time. This works also in the "absence of stable storage" > > mode. > > It's prohibitive enough that folks won't bother to do this on a > massive scale (i.e., for lots of addresses). That seems good enough > for the purposes defined in the 3041. > > Thomas Again, the reality check isn't included in the fragment... Anyway, the knee-jerk reaction of the cryptologic tribe would be to recommend SHA-1 rather than MD5. RFC3041 publishes 64 bits of the internal state. With MD5 that leaves only 64 bits secret, and that isn't secure anymore. Current security erosion rate being one bit per year, 64 bits becomes crackable with home computers before IPv6 has taken over from IPv4. With SHA-1 you would have 96 bits of remaining secret. -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 08:40:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RFedrP022589; Mon, 27 May 2002 08:40:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RFedr3022588; Mon, 27 May 2002 08:40: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.3+Sun/8.12.3) with ESMTP id g4RFearP022581 for ; Mon, 27 May 2002 08:40:36 -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 IAA21227 for ; Mon, 27 May 2002 08:40:40 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06171 for ; Mon, 27 May 2002 09:40:40 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id LAA13045 for ; Mon, 27 May 2002 11:40:38 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Mon, 27 May 2002 08:44:30 -0700 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.2910.0) In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0693@Esealnt861.al.sw.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. => I don't know if my earlier message failed to convey the picture but please ignore the SGSN, it is irrelevant to this discussion. All traffic MUST go to the GGSN and get routed there. That was exactly the point was making , till GGSN everything is on L2 - hence on the same link. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. => No. See my comment above. No routing before the GGSN. and Mobile 1 _cannot_ communicate to Mobile 2 using link-local addresses. Again, I am saying the same thing, GGSN (and SGSN) needs to know who are subscribing to the mcast group. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 08:49:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RFndrP022612; Mon, 27 May 2002 08:49:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RFndPr022611; Mon, 27 May 2002 08:49:39 -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.3+Sun/8.12.3) with ESMTP id g4RFnarP022604 for ; Mon, 27 May 2002 08:49: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 IAA18510 for ; Mon, 27 May 2002 08:49:40 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08963 for ; Mon, 27 May 2002 09:49:40 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id LAA13902; Mon, 27 May 2002 11:49:36 -0400 (EDT) From: "Dr. Subrata Goswami" To: , Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Mon, 27 May 2002 08:53:28 -0700 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.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Sorry, that isn't the correct model. Then it is the correct model, if you read my email it was mentioned that SGSN is an L2 device. Also as one SGSN supports multiple mobiles - it needs to know somehow which mobiles are part of an mcast group and that can be done by MLD. The p2p link to GGSN can be in L2 - in L3 it is still on the same link if they are part of the same subnet. Subrata > -----Original Message----- > From: ext Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Friday, May 24, 2002 9:58 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. Next question would be what are IPL1, IPL2, and IPRx - global, > site-scope,link-local unicat addresses ? > > Subrata. > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Friday, May 24, 2002 11:28 AM > To: 'Dr. Subrata Goswami'; Hesham Soliman (ERA) > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > > Are you sure that the BTS does not terminate the radio link > > - physically > > => Yes. I'm assuming you're still talking about WCDMA. > > > that looks like the spot for termination. Okay, if the IP > > stack sees a L3 > > p2p link, then the IP address on the GGSN interface is same > > for a number of > > mobile hosts - right ? So the GGSN has to know which of > the mobiles > > connected to it need mcast group traffic, right ? > > => But we're not talking about mcast addresses in general, > we're talking about link-local mcast addresses. For those > addresses you don't need to join on a p2p link. > > Similarly > > the SGSN also > > needs to know which links it needs to copy an mcast group > packet to. > > => No. The SGSN is not involved in any routing. The > _only_ node that does routing is the GGSN. We can > ignore the rest of the network as far as the IETF > is concerned. Or at least as far this WG is concerned. > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 27 09:52:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RGqSrP022723; Mon, 27 May 2002 09:52:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RGqS6X022722; Mon, 27 May 2002 09:52: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.3+Sun/8.12.3) with ESMTP id g4RGqPrP022715 for ; Mon, 27 May 2002 09:52:25 -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 JAA01042 for ; Mon, 27 May 2002 09:52:30 -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 KAA29863 for ; Mon, 27 May 2002 10:52:29 -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 JAA25579 for ; Mon, 27 May 2002 09:52:29 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4RGqQq04156; Mon, 27 May 2002 09:52:26 -0700 X-mProtect: <200205271652> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7PWD7i; Mon, 27 May 2002 09:52:23 PDT Message-ID: <3CF26434.27D67E10@iprg.nokia.com> Date: Mon, 27 May 2002 09:52:04 -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: lassi.hippelainen@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Lassi, You have expressed exactly the reason for mandating "route optimization". It's because a node that does not handle the Binding Update causes remote nodes to do extra work with no noticeable local effects. It's for the overall health of the IPv6 Internet that nodes should be required to implement Binding Update and along with it the lightweight Return Routability tests. Regards, Charlie P. lassi.hippelainen@nokia.com wrote: > > Is there support in this WG for making route optimization a MUST in all IPv6 hosts ? The ball is really in this WG's court. This is really a "do you really want ubiquitous end to end functionality or not?" question > > I'm not sure if that rule could be enforced. If a node keeps on sending to home address, it's a problem for the home network, but not for the sender. > > Is there a business reason for honouring an optimization? Why would a "free" ad-driven service (e.g. sports news) care about the well being of someone else's network? Why should it put effort in the authentication computations, if there is no benefit for itself? > > -- Lassi > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 27 15:24:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RMOYrP022922; Mon, 27 May 2002 15:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4RMOYLM022921; Mon, 27 May 2002 15:24: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.3+Sun/8.12.3) with ESMTP id g4RMOVrP022914 for ; Mon, 27 May 2002 15:24: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 PAA16780 for ; Mon, 27 May 2002 15:24:35 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02691 for ; Mon, 27 May 2002 16:24:35 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id SAA22249 for ; Mon, 27 May 2002 18:24:34 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Mon, 27 May 2002 15:28:23 -0700 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.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agreed that the SGSN do not know how to multicast. If it were able to, as Ethernet switches do, then scaling would not be a problem. If the mobile-to-GGSN subnet is /127, as you are hinting, then all the mobiles either have the same IP or the GGSN has 100K IP interfaces. My suggestions would be to not limit the L3 capability to what is available today in 3G L2 switches. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of lassi.hippelainen@nokia.com Sent: Monday, May 27, 2002 3:11 AM To: ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Sorry, that isn't the correct model. 3GPP uses a "stratified" model. The link layer from the mobiles ends in the GGSN. There is also another link layer, between the SGSN and the GGSN, but that is in the lower stratum that is invisible to the mobiles. Always think about the mobile-GGSN link as a single hop. The difference is architecturally important. For example, the mobiles are *not* neighbors to each other, even when they are connected to the same Access Point (in 3GPP terminology). The links are only point-to-point, and nobody else is present. The reason is security. There can be 100k or more mobiles connected to a single AP. If they were all on the same link, any multicast operation could crash the GGSN, because it might have to replicate the packet 100k times. Also, any mobile could launch multicast-based DoS attacks against the GGSN or other mobiles. In brief, 3GPP networks cannot handle multicast (or DAD) in Ethernet manner. The numbers differ by severals orders of magnitude. -- Lassi > -----Original Message----- > From: ext Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Friday, May 24, 2002 9:58 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. Next question would be what are IPL1, IPL2, and IPRx - global, > site-scope,link-local unicat addresses ? > > Subrata. > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Friday, May 24, 2002 11:28 AM > To: 'Dr. Subrata Goswami'; Hesham Soliman (ERA) > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > > Are you sure that the BTS does not terminate the radio link > > - physically > > => Yes. I'm assuming you're still talking about WCDMA. > > > that looks like the spot for termination. Okay, if the IP > > stack sees a L3 > > p2p link, then the IP address on the GGSN interface is same > > for a number of > > mobile hosts - right ? So the GGSN has to know which of > the mobiles > > connected to it need mcast group traffic, right ? > > => But we're not talking about mcast addresses in general, > we're talking about link-local mcast addresses. For those > addresses you don't need to join on a p2p link. > > Similarly > > the SGSN also > > needs to know which links it needs to copy an mcast group > packet to. > > => No. The SGSN is not involved in any routing. The > _only_ node that does routing is the GGSN. We can > ignore the rest of the network as far as the IETF > is concerned. Or at least as far this WG is concerned. > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 02:18:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4S9IqrP023693; Tue, 28 May 2002 02:18:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4S9IqDf023692; Tue, 28 May 2002 02:18: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.3+Sun/8.12.3) with ESMTP id g4S9InrP023685 for ; Tue, 28 May 2002 02:18:49 -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 CAA05844 for ; Tue, 28 May 2002 02:18:54 -0700 (PDT) Received: from wireless (wireless.cs.twsu.edu [156.26.10.125]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03399 for ; Tue, 28 May 2002 02:18:53 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=basit) by wireless with esmtp (Exim 3.35 #1 (Debian)) id 17Cdxz-0000gg-00 for ; Tue, 28 May 2002 05:12:35 -0500 Date: Tue, 28 May 2002 05:12:35 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless To: ipng@sunroof.eng.sun.com Subject: anycast emulation for multicast. 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 Hi! Can we use IP anycast to emulate multicast ? like in a set of nodes, instead of multicasting to a group of nodes sendor performs anycast , then the reciever further performs anycast and vice versa , unless somehow we will be able to detect that no more anycast is possible , in this case , how can we guarantee that anycast won't back to the previous sender again ? thanks - basit MS computer science wichita state university -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 03:26:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SAQGrP023748; Tue, 28 May 2002 03:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SAQGUS023747; Tue, 28 May 2002 03:26: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.3+Sun/8.12.3) with ESMTP id g4SAQDrP023740 for ; Tue, 28 May 2002 03:26: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 DAA12691 for ; Tue, 28 May 2002 03:26:16 -0700 (PDT) Received: from peoplemail.com.cn ([202.99.23.242]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA14588 for ; Tue, 28 May 2002 03:26:14 -0700 (PDT) Received: from peter([210.72.13.221]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm3c3cf372ac; Tue, 28 May 2002 10:26:03 -0000 Message-ID: <029901c20632$52367fb0$dd0d48d2@peter> From: "Feng Yanjun" To: "Abdul Basit" , References: Subject: Re: anycast emulation for multicast. Date: Tue, 28 May 2002 18:27:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g4SAQDrP023741 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, IMO, it is possible in theory, however, it is impossible in practice. - anycast is implemented by Routing System, so it is a very very difficult task to Routeing System. - how to grantd that there is not deadlock? - it is time consuming to implement by this mean. BRs -Feng Yanjun -------------------------- Feng Yanjun Computer Network Information Center(CNIC) Chinese Academy of Sciences Beijing, China Tel : 86-10-62657502 Mail: fengyj@sanfront.com.cn Web : www.cnic.ac.cn ----- Original Message ----- From: "Abdul Basit" To: Sent: Tuesday, May 28, 2002 6:12 PM Subject: anycast emulation for multicast. > > Hi! > > Can we use IP anycast to emulate multicast ? > like in a set of nodes, instead of multicasting to a group of nodes > sendor performs anycast , then the reciever further performs anycast > and vice versa , unless somehow we will be able to detect that > no more anycast is possible , in this case , how can we guarantee > that anycast won't back to the previous sender again ? > > thanks > - basit > MS computer science > wichita state university > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 28 04:44:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SBifrP023851; Tue, 28 May 2002 04:44:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SBifeV023850; Tue, 28 May 2002 04:44:41 -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.3+Sun/8.12.3) with ESMTP id g4SBicrP023843 for ; Tue, 28 May 2002 04:44:38 -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 EAA15585 for ; Tue, 28 May 2002 04:44:41 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10376 for ; Tue, 28 May 2002 05:44:40 -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 g4SBiOmH016288; Tue, 28 May 2002 13:44:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 13:44:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06A2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dr. Subrata Goswami'" , lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Tue, 28 May 2002 13:44:18 +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 > > Sorry, that isn't the correct model. > > Then it is the correct model, if you read my email it was > mentioned that > SGSN is an L2 device. Also as one SGSN supports multiple > mobiles - it needs > to know somehow which mobiles are part of an mcast group > and that can be > done by MLD. => No. The model is not correct as we tried to explain. The SGSN does not 'see' the mobile's traffic and does not do any 'L2 switching'. So your conclusion is not correct. For more information, please refer to 3GPP specs: TS 23.060 (any revision will explain this issue clearly). Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 10:15:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHF2rP024393; Tue, 28 May 2002 10:15:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SHF26N024392; Tue, 28 May 2002 10: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.3+Sun/8.12.3) with ESMTP id g4SHExrP024385 for ; Tue, 28 May 2002 10:14: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 KAA16651 for ; Tue, 28 May 2002 10:15:02 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24855 for ; Tue, 28 May 2002 11:15:56 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id NAA25779 for ; Tue, 28 May 2002 13:15:00 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Tue, 28 May 2002 10:18:54 -0700 Message-ID: <000601c2066b$beef5b20$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F06A2@Esealnt861.al.sw.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, SGSN "sees" the mobile's traffic - as it passes through it. SGSN being an L2 device for IP, it is capable of doing L2 switching (if the 3gpp spec does not prohibit and the vendor innovates). The following is the protocol stack for the SGSN (user plane, from the TS 23.060 you referred, btw the 3GPP web-site needs better navigation). ------------- --------------- |SNDCP GTP-U| |GTP-U GTP-U | |LLC UDP | |UDP/IP UDP/IP| |BSSGP IP | |AAL5 L2 | |FR L2 | |ATM L1 | |L1 L1 | --------------- ------------ GPRS-SGSN UMTS-SGSN >From the above, it is possible to make GPRS-SGSN to mcast as it detunnels the IP packets. In case of UMTS, the same functionality can be in the UTRAN. Subrata -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Tuesday, May 28, 2002 4:44 AM To: 'Dr. Subrata Goswami'; lassi.hippelainen@nokia.com; ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback > > Sorry, that isn't the correct model. > > Then it is the correct model, if you read my email it was > mentioned that > SGSN is an L2 device. Also as one SGSN supports multiple > mobiles - it needs > to know somehow which mobiles are part of an mcast group > and that can be > done by MLD. => No. The model is not correct as we tried to explain. The SGSN does not 'see' the mobile's traffic and does not do any 'L2 switching'. So your conclusion is not correct. For more information, please refer to 3GPP specs: TS 23.060 (any revision will explain this issue clearly). Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 10:37:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHb0rP024555; Tue, 28 May 2002 10:37:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SHb0i7024554; Tue, 28 May 2002 10:37:00 -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.3+Sun/8.12.3) with ESMTP id g4SHaxrP024547 for ; Tue, 28 May 2002 10:36:59 -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 g4SHaJaU000940 for ; Tue, 28 May 2002 10:36:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4SHaJNm000939 for ipng@sunroof.eng.sun.com; Tue, 28 May 2002 10:36:19 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R7pcrP021669 for ; Mon, 27 May 2002 00:51:39 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4R7pdg12089; Mon, 27 May 2002 09:51:39 +0200 (MEST) Date: Mon, 27 May 2002 09:50:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DAD or DIIDD To: Francis Dupont Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200205261403.g4QE3GT34039@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > * no change in address architecture (cf an Erik Nordmark's argument > about architectural purity) FWIW My brief note on the mobile-ip list didn't really argue for one option or the other (of the two options that you've carefully analyzed) but merely point out that the mobile-ip discussion wasn't consistent with the text, and as I understand it, the intent in RFC 2373. I personally think the simpler approach of just saying that we do DAD (and not DIIDD) makes sense at this point in time. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 10:37:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHbYrP024565; Tue, 28 May 2002 10:37:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SHbYVM024564; Tue, 28 May 2002 10:37:34 -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.3+Sun/8.12.3) with ESMTP id g4SHbXrP024557 for ; Tue, 28 May 2002 10:37:33 -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 g4SHaraU000948 for ; Tue, 28 May 2002 10:36:53 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4SHarKQ000947 for ipng@sunroof.eng.sun.com; Tue, 28 May 2002 10:36:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4RFt7rP022632 for ; Mon, 27 May 2002 08:55: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 IAA19072 for ; Mon, 27 May 2002 08:55:11 -0700 (PDT) Received: from mel.alcatel.fr (mel.alcatel.fr [64.208.49.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26348 for ; Mon, 27 May 2002 09:56:03 -0600 (MDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g4RFt9O3030067 for ; Mon, 27 May 2002 17:55:09 +0200 Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA22649 for ; Mon, 27 May 2002 17:55:04 +0200 (MET DST) Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA23520 for ; Mon, 27 May 2002 17:55:07 +0200 (METDST) Message-ID: <3CF255FA.59B0BE6C@nmu.alcatel.fr> Date: Mon, 27 May 2002 17:51:22 +0200 From: christophe preguica X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Configured Tunnel Content-Type: multipart/mixed; boundary="------------C5AA21DDF3BAB0BB76C84C6E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------C5AA21DDF3BAB0BB76C84C6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Do we allow unidirectional tunnels ? router A------------------->------------------router B dual stack dual stack A tunnel is configured on A with: IPv4 source @ = Av4 IPv4 destination @ = Bv4 There is not a configured tunnel on B with A as destination. When a packet is received by B from A (IPv6 packet encapsulated in IPv4), do we need to check whether or not a tunnel is configured from B to A (after decapsulation) before forwarding the packet to the IPv6 next hop? Kind regards, Christophe. --------------C5AA21DDF3BAB0BB76C84C6E Content-Type: text/x-vcard; charset=us-ascii; name="christophe.preguica.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for christophe preguica Content-Disposition: attachment; filename="christophe.preguica.vcf" begin:vcard n:; x-mozilla-html:FALSE org:Alcatel;Enabling Software version:2.1 email;internet:christophe.preguica@alcatel.fr title:Christophe Preguiça adr;quoted-printable:;;Route de Nozay=0D=0A91460 Marcoussis;;;;France end:vcard --------------C5AA21DDF3BAB0BB76C84C6E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 11:13:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SID0rP025031; Tue, 28 May 2002 11:13:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SICxAA025030; Tue, 28 May 2002 11:12:59 -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.3+Sun/8.12.3) with ESMTP id g4SICtrP025023 for ; Tue, 28 May 2002 11:12: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 LAA08443 for ; Tue, 28 May 2002 11:12:59 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21607 for ; Tue, 28 May 2002 11:12:59 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 11:12:58 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 11:12:58 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 May 2002 11:12:58 -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); Tue, 28 May 2002 11:12:57 -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); Tue, 28 May 2002 11:12:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD or DIIDD Date: Tue, 28 May 2002 11:12:57 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD or DIIDD Thread-Index: AcIGbqotTX+z+yB4REGIB80gYBfRCAAA5VVg From: "Dave Thaler" To: "Erik Nordmark" , "Francis Dupont" Cc: X-OriginalArrivalTime: 28 May 2002 18:12:57.0722 (UTC) FILETIME=[4B7C05A0:01C20673] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4SICurP025024 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] [...] > I personally think the simpler approach of just saying that we do DAD > (and not DIIDD) makes sense at this point in time. I agree. The mobile-ip question is actually identical to the multilink subnet question I raised at the Interim meeting in Seattle. (The mobile-ip use is just a special case of the generic multilink subnet spec.) It is simpler to just require DAD, and indeed it would be good if an update to 2462 removed the problematic text. -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 May 28 16:50:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SNo0rP026862; Tue, 28 May 2002 16:50:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SNo0xh026861; Tue, 28 May 2002 16:50: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.3+Sun/8.12.3) with ESMTP id g4SNnurP026854 for ; Tue, 28 May 2002 16:49: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 QAA11361 for ; Tue, 28 May 2002 16:50:00 -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 QAA26858 for ; Tue, 28 May 2002 16:49:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7F1CF4B22; Wed, 29 May 2002 08:49:54 +0900 (JST) To: christophe preguica Cc: ipng@sunroof.eng.sun.com In-reply-to: Christophe.Preguica's message of Mon, 27 May 2002 17:51:22 +0200. <3CF255FA.59B0BE6C@nmu.alcatel.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Configured Tunnel From: itojun@iijlab.net Date: Wed, 29 May 2002 08:49:54 +0900 Message-ID: <24257.1022629794@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Do we allow unidirectional tunnels ? if my understanding is correct, RFC1993/2893 describes unidirectional tunnels, however, most of implementations in the wild implements bidirectional tunnels. 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 May 28 22:27:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T5RkrP027232; Tue, 28 May 2002 22:27:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T5RkQk027231; Tue, 28 May 2002 22:27: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.3+Sun/8.12.3) with ESMTP id g4T5RhrP027224 for ; Tue, 28 May 2002 22:27:43 -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 WAA25089 for ; Tue, 28 May 2002 22:27:47 -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 WAA12924 for ; Tue, 28 May 2002 22:27:46 -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 g4T5S8q06288 for ; Wed, 29 May 2002 08:28:09 +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, 29 May 2002 08:27:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 08:27:45 +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: Mandating Route Optimization Date: Wed, 29 May 2002 08:27:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcIFaRntyie2CXTgRM+y15KdAFbHowBYiTMA To: , , X-OriginalArrivalTime: 29 May 2002 05:27:45.0179 (UTC) FILETIME=[8FE3AEB0:01C206D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4T5RhrP027225 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, > => Not only, but there are also rules for MUSTs and SHOULDs. > My understanding is that we only mandate things (MUST) if > not doing it will break communication. MIP was designed to > make ensure that it works with or without RO. So according > to my understanding of the use of keywords, it should not > be a must. Of course it is an important feature and therefore > SHOULD is appropriate IMHO. That is my understanding. However, I would like that the SHOULD should have teeth to it. What I mean is that we should make a strong case on how RO will help hosts, lead to better operation, 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 Tue May 28 22:52:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T5qErP027270; Tue, 28 May 2002 22:52:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T5qEeU027269; Tue, 28 May 2002 22:52: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.3+Sun/8.12.3) with ESMTP id g4T5qBrP027262 for ; Tue, 28 May 2002 22:52:11 -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 WAA01266 for ; Tue, 28 May 2002 22:52:15 -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 XAA09256 for ; Tue, 28 May 2002 23:52:14 -0600 (MDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4T5qDmG021239; Wed, 29 May 2002 07:52:13 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 07:52:13 +0200 Message-ID: From: "Peter Hedman (EMP)" To: "'Dr. Subrata Goswami'" , ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Wed, 29 May 2002 07:52:21 +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 Hi, I think it is worth looking into figure 2 in draft-ietf-ipv6-3gpp-recommend-02.txt. Unless this figure gets corrupt in the mail you'll see that there are 2 different IP layers and the cellular host draft is talking about the IP layer between MS and GGSN. /Peter ------ | | | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) | | |------| ------------- | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> | v4/6 | | v4/6 | |------| ------------- ------------- |------ | | | | \ Relay / | | \ Relay / | | | | | | | \ / | | \ / | | | | | | | \ / | | \ / | | | | | PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | | | | | | | | | | | | | |------| |------|------| |------|------| |------| | | | | | UDP |- - -| UDP | UDP |- - -| UDP | | | | | |------| |------|------| |------| | | RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | | | | | | v4/6 | | v4/6 | v4/6 | |v4/6 | | |------| |------|------| |------|------| |------|------| | MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 | |------| |------|------| |------|------| |------|------| | L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 | ------ ------------- ------------- ------------- UE UTRAN SGSN GGSN > -----Original Message----- > From: Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: den 28 maj 2002 19:19 > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > Hesham, SGSN "sees" the mobile's traffic - as it passes through it. > SGSN being an L2 device for IP, it is capable of doing L2 > switching (if > the 3gpp spec does not prohibit and the vendor innovates). The > following is the protocol stack for the SGSN (user plane, from the TS > 23.060 you referred, btw the 3GPP web-site needs better navigation). > > ------------- --------------- > |SNDCP GTP-U| |GTP-U GTP-U | > |LLC UDP | |UDP/IP UDP/IP| > |BSSGP IP | |AAL5 L2 | > |FR L2 | |ATM L1 | > |L1 L1 | --------------- > ------------ > GPRS-SGSN UMTS-SGSN > > From the above, it is possible to make GPRS-SGSN to mcast as it > detunnels the IP packets. > > In case of UMTS, the same functionality can be in the UTRAN. > > Subrata > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, May 28, 2002 4:44 AM > To: 'Dr. Subrata Goswami'; lassi.hippelainen@nokia.com; > ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > Sorry, that isn't the correct model. > > > > Then it is the correct model, if you read my email it was > > mentioned that > > SGSN is an L2 device. Also as one SGSN supports multiple > > mobiles - it needs > > to know somehow which mobiles are part of an mcast group > > and that can be > > done by MLD. > > => No. The model is not correct as we tried to > explain. The SGSN does not 'see' the mobile's > traffic and does not do any 'L2 switching'. > So your conclusion is not correct. > > For more information, please refer to 3GPP > specs: TS 23.060 (any revision will explain > this issue clearly). > > Hesham > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 28 22:53:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T5rarP027287; Tue, 28 May 2002 22:53:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T5raAM027286; Tue, 28 May 2002 22:53:36 -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.3+Sun/8.12.3) with ESMTP id g4T5rXrP027279 for ; Tue, 28 May 2002 22:53: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 WAA26592 for ; Tue, 28 May 2002 22:53:37 -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 XAA15177 for ; Tue, 28 May 2002 23:53:36 -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 WAA14291; Tue, 28 May 2002 22:53:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4T5rXo10630; Tue, 28 May 2002 22:53:33 -0700 X-mProtect: <200205290553> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdazQ14k; Tue, 28 May 2002 22:53:31 PDT Message-ID: <3CF46CC3.F19F0272@iprg.nokia.com> Date: Tue, 28 May 2002 22:53:07 -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: john.loughney@nokia.com CC: hesham.soliman@era.ericsson.se, lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Hesham and John, Your analysis about MUST/SHOULD would imply that hosts SHOULD implement TCP's particular flow control mechanism, whereas in fact they MUST, for the health of the Internet. Thus, I do not believe that you have put forward the correct basis for making the determination. I think that we can mandate this behavior on the basis that the future Internet will suffer to the extent that we do not. Maybe we have enough remote bandwidth today to place delay bounds that people today find acceptable, but there is not any assurance whatsoever that this will be the case 10 years from now, nor even 2 years from now if we solve the problems of really reliable interactive voice and video within the nearer term future. Yet, IPv6 is supposed to last for many more years than that. While I do not think that the case for mandating Route Optimization is as strong as for mandating flow control under TCP, I think it is very strong nonetheless, exactly because noncompliant hosts will have distant and negative effects on many other nodes in the Internet. In fact, I would say that the problems introduced by failure to implement Route Optimization will motivate the introduction of kludgy substitutes, much as the lack of address space for IPv4 has motivated the introduction of NATs. We have to do better. I would say that the case for Route Optimization is at least as strong as for IPsec and for stateless address autoconfiguration, if not as strong as the case for TCP. And, none of these four examples fit within the guidelines that are suggested by Hesham. Regards, Charlie P. john.loughney@nokia.com wrote: > Hi Hesham, > > > => Not only, but there are also rules for MUSTs and SHOULDs. > > My understanding is that we only mandate things (MUST) if > > not doing it will break communication. MIP was designed to > > make ensure that it works with or without RO. So according > > to my understanding of the use of keywords, it should not > > be a must. Of course it is an important feature and therefore > > SHOULD is appropriate IMHO. > > That is my understanding. However, I would like that the SHOULD > should have teeth to it. What I mean is that we should make > a strong case on how RO will help hosts, lead to better operation, > 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 May 28 23:19:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T6JFrP027355; Tue, 28 May 2002 23:19:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T6JFxW027354; Tue, 28 May 2002 23:19: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.3+Sun/8.12.3) with ESMTP id g4T6JCrP027347 for ; Tue, 28 May 2002 23:19: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 XAA01712 for ; Tue, 28 May 2002 23:19:17 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04606 for ; Wed, 29 May 2002 00:20:12 -0600 (MDT) Message-ID: <019001c206d8$7d65c780$396015ac@T23KEMPF> From: "James Kempf" To: , , , References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> Subject: Re: Mandating Route Optimization Date: Tue, 28 May 2002 23:01:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, that is correct. Something that is a MUST shouldn't just be an optimization, it should be necessary for correct, interoperable implementation. This leaves open whether to make it MAY or SHOULD. By making it SHOULD, we make a strong statement that it is necessary for best operation. MAY leaves the case too weak, people will feel free to ignore it. jak ----- Original Message ----- From: To: ; ; Sent: Tuesday, May 28, 2002 10:27 PM Subject: Mandating Route Optimization > Hi Hesham, > > > => Not only, but there are also rules for MUSTs and SHOULDs. > > My understanding is that we only mandate things (MUST) if > > not doing it will break communication. MIP was designed to > > make ensure that it works with or without RO. So according > > to my understanding of the use of keywords, it should not > > be a must. Of course it is an important feature and therefore > > SHOULD is appropriate IMHO. > > That is my understanding. However, I would like that the SHOULD > should have teeth to it. What I mean is that we should make > a strong case on how RO will help hosts, lead to better operation, > 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 Wed May 29 00:23:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7NxrP027436; Wed, 29 May 2002 00:23:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T7NxdG027435; Wed, 29 May 2002 00:23:59 -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.3+Sun/8.12.3) with ESMTP id g4T7NurP027428 for ; Wed, 29 May 2002 00:23:56 -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 AAA13123 for ; Wed, 29 May 2002 00:23:59 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09517 for ; Wed, 29 May 2002 01:23:58 -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 g4T7Nv6n029083; Wed, 29 May 2002 09:23:57 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 09:23:57 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06A5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'john.loughney@nokia.com'" , "Hesham Soliman (ERA)" , lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Mandating Route Optimization Date: Wed, 29 May 2002 09:23:47 +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 Hi John, > > => Not only, but there are also rules for MUSTs and SHOULDs. > > My understanding is that we only mandate things (MUST) if > > not doing it will break communication. MIP was designed to > > make ensure that it works with or without RO. So according > > to my understanding of the use of keywords, it should not > > be a must. Of course it is an important feature and therefore > > SHOULD is appropriate IMHO. > > That is my understanding. However, I would like that the SHOULD > should have teeth to it. What I mean is that we should make > a strong case on how RO will help hosts, lead to better operation, > etc. => Fully agree. 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 May 29 00:33:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7XArP027453; Wed, 29 May 2002 00:33:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T7XAPZ027452; Wed, 29 May 2002 00:33: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.3+Sun/8.12.3) with ESMTP id g4T7X7rP027445 for ; Wed, 29 May 2002 00:33: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 AAA14465 for ; Wed, 29 May 2002 00:33:09 -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 AAA05147 for ; Wed, 29 May 2002 00:33:03 -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 g4T7XPq08459 for ; Wed, 29 May 2002 10:33:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 May 2002 10:32: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, 29 May 2002 10:32:55 +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: Mandating Route Optimization Date: Wed, 29 May 2002 10:32:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6529F@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcIG2Ltebs075Mg2Ssy0m68u8L666QACgQug To: , , , X-OriginalArrivalTime: 29 May 2002 07:32:55.0311 (UTC) FILETIME=[0C46E1F0:01C206E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4T7X8rP027446 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, > Yes, that is correct. Something that is a MUST shouldn't just be an > optimization, it should be necessary for correct, interoperable > implementation. > > This leaves open whether to make it MAY or SHOULD. By making > it SHOULD, we make a strong statement that it is necessary for > best operation. MAY leaves the case too weak, people will feel > free to ignore it. One thing that would be interesting would be to have some simulations on how RO (& how lack of RO) would effect the Internet. A better case could be made for RO if simulations would point to a more stable Internet if RO is mandated. As Charlie pointed out, this may be analagous to congestion control in TCP. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 00:52:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7qkrP027584; Wed, 29 May 2002 00:52:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T7qkwR027583; Wed, 29 May 2002 00:52: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.3+Sun/8.12.3) with ESMTP id g4T7qhrP027576 for ; Wed, 29 May 2002 00:52: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 AAA29977 for ; Wed, 29 May 2002 00:52:47 -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 BAA20990 for ; Wed, 29 May 2002 01:52:46 -0600 (MDT) Message-ID: <01b001c206e5$87a721f0$396015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , Cc: , , References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> <3CF46CC3.F19F0272@iprg.nokia.com> Subject: Re: Mandating Route Optimization Date: Wed, 29 May 2002 00:50:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, TCP flow control was implemented in response to congestion collapse in the late '80s. If something like that happens as a result of widespread Mobile IP implementation, you can be sure that it will become a MUST. :-) But, for now, it is very easy to see the extra amount of work route optimization would add to implementing an IPv6 stack, but very hard to see what effect lack of route optimization would have on traffic flow in the Internet when mobile nodes are widespread (though, of course, everyone has an opinion). So making it a SHOULD seems like the best tradeoff. It is really too bad that there is not some kind of large scale, supercomputer simulation of the Internet that we could tweak when these kinds of questions come up. This would allow the IETF to base decisons on some kind of data (though people do argue about simulations) rather than just on intuition. jak ----- Original Message ----- From: "Charlie Perkins" To: Cc: ; ; Sent: Tuesday, May 28, 2002 10:53 PM Subject: Re: Mandating Route Optimization > > Hello Hesham and John, > > Your analysis about MUST/SHOULD would imply that hosts > SHOULD implement TCP's particular flow control mechanism, > whereas in fact they MUST, for the health of the Internet. > Thus, I do not believe that you have put forward the correct > basis for making the determination. I think that we can mandate > this behavior on the basis that the future Internet will suffer to > the extent that we do not. Maybe we have enough remote > bandwidth today to place delay bounds that people today > find acceptable, but there is not any assurance whatsoever > that this will be the case 10 years from now, nor even 2 years > from now if we solve the problems of really reliable interactive > voice and video within the nearer term future. Yet, IPv6 is > supposed to last for many more years than that. > > While I do not think that the case for mandating Route > Optimization is as strong as for mandating flow control > under TCP, I think it is very strong nonetheless, exactly > because noncompliant hosts will have distant and negative > effects on many other nodes in the Internet. In fact, I would > say that the problems introduced by failure to implement > Route Optimization will motivate the introduction of kludgy > substitutes, much as the lack of address space for IPv4 has > motivated the introduction of NATs. > > We have to do better. I would say that the case for Route > Optimization is at least as strong as for IPsec and for > stateless address autoconfiguration, if not as strong as > the case for TCP. And, none of these four examples > fit within the guidelines that are suggested by Hesham. > > Regards, > Charlie P. > > > john.loughney@nokia.com wrote: > > > Hi Hesham, > > > > > => Not only, but there are also rules for MUSTs and SHOULDs. > > > My understanding is that we only mandate things (MUST) if > > > not doing it will break communication. MIP was designed to > > > make ensure that it works with or without RO. So according > > > to my understanding of the use of keywords, it should not > > > be a must. Of course it is an important feature and therefore > > > SHOULD is appropriate IMHO. > > > > That is my understanding. However, I would like that the SHOULD > > should have teeth to it. What I mean is that we should make > > a strong case on how RO will help hosts, lead to better operation, > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 00:54:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7ssrP027601; Wed, 29 May 2002 00:54:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T7ss0S027600; Wed, 29 May 2002 00:54: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.3+Sun/8.12.3) with ESMTP id g4T7sprP027593 for ; Wed, 29 May 2002 00:54: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 AAA18183 for ; Wed, 29 May 2002 00:54:55 -0700 (PDT) From: lassi.hippelainen@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 BAA21911 for ; Wed, 29 May 2002 01:54:53 -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 g4T7uPa11107 for ; Wed, 29 May 2002 10:56:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 29 May 2002 10:54:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 10:54:52 +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: MLD comments on cellular host drafts - seeking feedback Date: Wed, 29 May 2002 10:54:51 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MLD comments on cellular host drafts - seeking feedback Thread-Index: AcIGa+ne6FEfPsW/RGq4YP5SdiN0oAAd38bA To: X-OriginalArrivalTime: 29 May 2002 07:54:52.0340 (UTC) FILETIME=[1D498F40:01C206E6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4T7sprP027594 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ...but how about mobility? The SGSN isn't an anchor point. It may change at any moment, when the mobile does an SGSN handover to another Routing Area. The new SGSN doesn't have a clue about what mcast groups the mobile has joined somewhere else. The old SGSN might inform the new one about the groups, but that is architecturally messy. So far GPRS is pretty agnostic about what protocol the mobile uses - IPv4, IPv6, X.25(!), or even PPP. Integrating IPv6 mcast functions would violate the idea. It would also mean that the SGSN has an IP interface that the mobile can see. That violates the stratified model. The feature would still need to be standardised as an extra parameter in GTP-C. Not all SGSNs in a network come from the same vendor. 3GPP does have an unwritten prohibition: disallow non-standard features that would lock an operator to a single vendor. -- Lassi > -----Original Message----- > From: ext Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Tuesday, May 28, 2002 8:19 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > Hesham, SGSN "sees" the mobile's traffic - as it passes through it. > SGSN being an L2 device for IP, it is capable of doing L2 > switching (if > the 3gpp spec does not prohibit and the vendor innovates). The > following is the protocol stack for the SGSN (user plane, from the TS > 23.060 you referred, btw the 3GPP web-site needs better navigation). > > ------------- --------------- > |SNDCP GTP-U| |GTP-U GTP-U | > |LLC UDP | |UDP/IP UDP/IP| > |BSSGP IP | |AAL5 L2 | > |FR L2 | |ATM L1 | > |L1 L1 | --------------- > ------------ > GPRS-SGSN UMTS-SGSN > > From the above, it is possible to make GPRS-SGSN to mcast as it > detunnels the IP packets. > > In case of UMTS, the same functionality can be in the UTRAN. > > Subrata > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, May 28, 2002 4:44 AM > To: 'Dr. Subrata Goswami'; lassi.hippelainen@nokia.com; > ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > Sorry, that isn't the correct model. > > > > Then it is the correct model, if you read my email it was > > mentioned that > > SGSN is an L2 device. Also as one SGSN supports multiple > > mobiles - it needs > > to know somehow which mobiles are part of an mcast group > > and that can be > > done by MLD. > > => No. The model is not correct as we tried to > explain. The SGSN does not 'see' the mobile's > traffic and does not do any 'L2 switching'. > So your conclusion is not correct. > > For more information, please refer to 3GPP > specs: TS 23.060 (any revision will explain > this issue clearly). > > Hesham > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 02:20:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T9KIrP027691; Wed, 29 May 2002 02:20:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T9KISS027690; Wed, 29 May 2002 02:20: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.3+Sun/8.12.3) with ESMTP id g4T9KErP027683 for ; Wed, 29 May 2002 02:20: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 CAA19233 for ; Wed, 29 May 2002 02:20: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 CAA28528 for ; Wed, 29 May 2002 02:20:18 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 604B94B22 for ; Wed, 29 May 2002 18:20:14 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: charliep's message of Tue, 28 May 2002 22:53:07 MST. <3CF46CC3.F19F0272@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: Mandating Route Optimization From: itojun@iijlab.net Date: Wed, 29 May 2002 18:20:14 +0900 Message-ID: <29018.1022664014@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We have to do better. I would say that the case for Route >Optimization is at least as strong as for IPsec and for >stateless address autoconfiguration, if not as strong as >the case for TCP. And, none of these four examples >fit within the guidelines that are suggested by Hesham. please be aware of already-deployed IPv6 codebase. WinXP is shipping, MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. even home address option (which is a MUST) is changing. i don't think it a good situation for implementers. 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 May 29 03:26:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TAQUrP027740; Wed, 29 May 2002 03:26:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TAQTaf027739; Wed, 29 May 2002 03:26: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.3+Sun/8.12.3) with ESMTP id g4TAQQrP027732 for ; Wed, 29 May 2002 03:26: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 DAA10004 for ; Wed, 29 May 2002 03:26:30 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29233 for ; Wed, 29 May 2002 03:26:29 -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 g4TAQJ6n003287; Wed, 29 May 2002 12:26:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 12:26:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06A7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'lassi.hippelainen@nokia.com'" , ipng@sunroof.eng.sun.com Subject: RE: MLD comments on cellular host drafts - seeking feedback Date: Wed, 29 May 2002 12:26:10 +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 Lassi and Subrata, You are right of course, but I think we can get into this endless loop of discussions because of a simple fact: We are not discussing the way 3GPP _can_ or might work. We are discussing the facts as we have them today. So can we accept that this _is_ the way 3GPP networks work (as described by Lassi and myself in earlier emails) and go from there? If this simple fact can't be accepted then we're not going to end up with a resolution. Hesham > -----Original Message----- > From: lassi.hippelainen@nokia.com > [mailto:lassi.hippelainen@nokia.com] > Sent: Wednesday, May 29, 2002 9:55 AM > To: ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > ...but how about mobility? > > The SGSN isn't an anchor point. It may change at any > moment, when the mobile does an SGSN handover to another > Routing Area. The new SGSN doesn't have a clue about what > mcast groups the mobile has joined somewhere else. > > The old SGSN might inform the new one about the groups, but > that is architecturally messy. So far GPRS is pretty > agnostic about what protocol the mobile uses - IPv4, IPv6, > X.25(!), or even PPP. Integrating IPv6 mcast functions > would violate the idea. It would also mean that the SGSN > has an IP interface that the mobile can see. That violates > the stratified model. > > The feature would still need to be standardised as an extra > parameter in GTP-C. Not all SGSNs in a network come from > the same vendor. 3GPP does have an unwritten prohibition: > disallow non-standard features that would lock an operator > to a single vendor. > > -- Lassi > > > -----Original Message----- > > From: ext Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > > Sent: Tuesday, May 28, 2002 8:19 PM > > To: ipng@sunroof.eng.sun.com > > Subject: RE: MLD comments on cellular host drafts - > seeking feedback > > > > > > Hesham, SGSN "sees" the mobile's traffic - as it passes > through it. > > SGSN being an L2 device for IP, it is capable of doing L2 > > switching (if > > the 3gpp spec does not prohibit and the vendor innovates). The > > following is the protocol stack for the SGSN (user plane, > from the TS > > 23.060 you referred, btw the 3GPP web-site needs better > navigation). > > > > ------------- --------------- > > |SNDCP GTP-U| |GTP-U GTP-U | > > |LLC UDP | |UDP/IP UDP/IP| > > |BSSGP IP | |AAL5 L2 | > > |FR L2 | |ATM L1 | > > |L1 L1 | --------------- > > ------------ > > GPRS-SGSN UMTS-SGSN > > > > From the above, it is possible to make GPRS-SGSN to mcast as it > > detunnels the IP packets. > > > > In case of UMTS, the same functionality can be in the UTRAN. > > > > Subrata > > > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, May 28, 2002 4:44 AM > To: 'Dr. Subrata Goswami'; lassi.hippelainen@nokia.com; > ipng@sunroof.eng.sun.com > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > Sorry, that isn't the correct model. > > > > Then it is the correct model, if you read my email it was > > mentioned that > > SGSN is an L2 device. Also as one SGSN supports multiple > > mobiles - it needs > > to know somehow which mobiles are part of an mcast group > > and that can be > > done by MLD. > > => No. The model is not correct as we tried to > explain. The SGSN does not 'see' the mobile's > traffic and does not do any 'L2 switching'. > So your conclusion is not correct. > > For more information, please refer to 3GPP > specs: TS 23.060 (any revision will explain > this issue clearly). > > Hesham > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 06:45:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TDjVrP028197; Wed, 29 May 2002 06:45:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TDjVnq028196; Wed, 29 May 2002 06:45: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.3+Sun/8.12.3) with ESMTP id g4TDjRrP028189 for ; Wed, 29 May 2002 06:45:27 -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 GAA09180 for ; Wed, 29 May 2002 06:45:30 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16514 for ; Wed, 29 May 2002 07:45:29 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TDjMZ28061; Wed, 29 May 2002 08:45:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 08:45:10 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03E5A58F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Charlie Perkins , john.loughney@nokia.com Cc: hesham.soliman@era.ericsson.se, lassi.hippelainen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Mandating Route Optimization Date: Wed, 29 May 2002 08:45:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20717.0B8EB7E0" 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_01C20717.0B8EB7E0 Content-Type: text/plain; charset="iso-8859-1" Pros for the mandate: -------------------- Although this may not, initially, seem to be a pro section, it really is. Are these solutions "kludgy", in your opinion, because they are not end to end :)? Is that what you mean by kludgy :)? What are these proposed substitutes and what WG are they being addressed in :)? It does sound to me that some WG will need to take on such work to facilitate multiple systems wishing to provide route optimization to their clients. Operators have no control over whether route optimization is deployed on correspondent nodes or not. It also seems to me that later end to end arguments against these alternate solutions would seem to be ludicrous based upon the decision to NOT make an end to end route optimization a ubiquitous part of IPv6. I.e. you self-proclaimed end to enders had better speak up now or forever hold your peace. I also find it a bit rediculous that people sell IPv6 saying that route optimized mobility is "built-in" to IPv6 when it really is no better than IPv4 in this regard. I.e. ubiquitous route optimization helps the IPv6 business case. Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. Cons: ---- I must also say that even if the end to end solution were ubiquitous and mandated there may still be adequate reasons (location privacy, speed, security, more optimizations with other IETF soft-state technologies) to use the non end to end solutions. Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. --------- I hope this helps people understand just exactly what is being decided here :) - Charlie Perkins wrote - > Route Optimization will motivate the introduction of kludgy > substitutes, much as the lack of address space for IPv4 has > motivated the introduction of NATs. > ------_=_NextPart_001_01C20717.0B8EB7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Mandating Route Optimization

Pros for the mandate:
--------------------
Although this may not, initially, seem to be a pro = section, it really is.

Are these solutions "kludgy", in your = opinion, because they are not end to end :)?

Is that what you mean by kludgy :)?

What are these proposed substitutes and what WG are = they being addressed in :)?

It does sound to me that some WG will need to take on = such work to facilitate multiple systems wishing to provide route = optimization to their clients. Operators have no control over whether = route optimization is deployed on correspondent nodes or not. =

It also seems to me that later end to end arguments = against these alternate solutions would seem to be ludicrous based upon = the decision to NOT make an end to end route optimization a ubiquitous = part of IPv6. I.e. you self-proclaimed end to enders had better speak = up now or forever hold your peace.

I also find it a bit rediculous that people sell IPv6 = saying that route optimized mobility is "built-in" to IPv6 = when it really is no better than IPv4 in this regard. I.e. ubiquitous = route optimization helps the IPv6 business case.

Making RO a must places control of low cost = diversion/indirection technologies with Operating System manufacturers. =


Cons:
----
I must also say that even if the end to end solution = were ubiquitous and mandated there may still be adequate reasons = (location privacy, speed, security, more optimizations with other IETF = soft-state technologies) to use the non end to end = solutions.

Making RO a must places control of low cost = diversion/indirection technologies with Operating System = manufacturers.


---------

I hope this helps people understand just exactly what = is being decided here :)

- Charlie Perkins wrote -
> Route Optimization will motivate the = introduction of kludgy
> substitutes, much as the lack of address space = for IPv4 has
> motivated the introduction of NATs.
>

------_=_NextPart_001_01C20717.0B8EB7E0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 07:41:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TEfRrP028304; Wed, 29 May 2002 07:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TEfR8w028303; Wed, 29 May 2002 07: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TEfNrP028296 for ; Wed, 29 May 2002 07:41:23 -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 HAA13553 for ; Wed, 29 May 2002 07:41:27 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23695 for ; Wed, 29 May 2002 07:41:27 -0700 (PDT) Received: from kenawang ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA18924; Wed, 29 May 2002 07:40:07 -0700 (PDT) Message-Id: <4.2.2.20020529101904.0304d530@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 29 May 2002 10:38:33 -0400 To: Jari Arkko From: Margaret Wasserman Subject: Re: Cellular host issues Cc: Hesham@piuha.net, Soliman@piuha.net, ipng@sunroof.eng.sun.com In-Reply-To: <3CED6792.40103@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, Here is my feedback on your suggested changes. I've only included the changes that were related to my feedback. Most of them look good. >1) Document status should be visible > > We will put the status back to the document. > The following statement will be added to the > introduction chapter: > > "This document is informational in nature, and it > is not intended to replace, update, or contradict > any IPv6 standards documents [RFC-2026]." Looks good to me. >3) Whether NUD needs to be done or not > > Based on the discussion on the list, 3GPP connections appear to > be able to ensure host - GGSN e2e two-way reachability, > all the way up to ensuring that GGSN IP layer is reachable. I am not sure about this... What I understood from the discussion is that the SGSN will know if the GGSN becomes unreachable. Although this may be over the SGSN <-> GGSN IP layer, this is all at layer 2 WRT the IP link between the handset and the GGSN. The absense of third-party (SGSN) notification that there is a problem can not be considered positive proof of reachability. Also, I don't understand how anything involving the SGSN can prove two-way reachability at the IP layer between the GGSN and the handset. Could someone elaborate on this mechanism, or give me a pointer to the specification that explains it? NUD should only be updated to indicate that a neighbor is reachable when two-way reachability can be confirmed at or above the IPv6 layer -- for instance, a TCP acknowledgement received for previously unacknowledged data will prove that there was two way reachability at the time that data was sent. I think that we should be fairly explicit in defining what 3GPP layers could be used to update NUD, if any. Regardless, though, of whether a 3GPP layer can update NUD, the TCP layer and some UDP applications should be able to do so. So, if the TCP layer is implemented properly, NUD messages can be supressed for all TCP applications (i.e. web browsing, e-mail, etc.). Therefore, I think that it is most useful to state that 3GPP host stacks should include a TCP that provides reachabilty advice to NUD. > The text has been clarified to state that it is mandatory to > implement not just ND in general but also NUD. Requirements for > NUD the advice information from other layers have been listed, > and their use has been strongly recommended. > > "2.4 RFC2461 - Neighbor Discovery for IPv6 > > Neighbor Discovery is described in [RFC-2461]. This > specification is a mandatory part of IPv6. > > 2.4.1 Neighbor Discovery in 3GPP Networks > > In GPRS and UMTS networks, some Neighbor Discovery > messages can cause unnecessary traffic and consume > valuable (limited) bandwidth. GPRS and UMTS links > resemble a point-to-point link; hence, the host's > only neighbor on the cellular link is the default > router that is already known through Router Discovery. > Therefore, while the host must support Neighbor > Solicitation and Advertisement messages, their use > in address resolution and next-hop determination is > not necessary and the host may choose to not initiate > them. I don't think that we should include the last sentence of this paragraph. > The host must support the Neighbour Solicitation and > Advertisement messages for neighbour unreachability > detection as specified in [RFC-2461]. However, it > is strongly recommended that forward progress > information from other layers is made available to the > IP layer. This is done in order to suppress the sending of these > messages when two-way reachability between the peer IP > layers has been already assured using other means." I would much prefer a section that read: 2.4.1 Neighbor Discovery in 3GPP Networks The host must support the Neighbor Solicitation and Advertisement messages for neighbor unreachability detection as specified in [RFC-2461]. In GPRS and UMTS networks, it is very desireable to conserve bandwidth. Therefore, hosts stacks used in these environments should include a mechanism in upper layer protocols (such as TCP) to provide reachability confirmation when two-way reachability can be confirmed (see RFC-2461, section 7.3.1). These confirmations will allow the suppression of most NUD-related messages. [If there are any upper-layer 3GPP protocols that can provide reachability confirmation, meeting the definition in the ND spec, we should mention them here.] Please note that the IPv6 specs consistenly misspell neighbour as "neighbor" :-). We should also use that spelling in this specification. >4) Speculation of AH's fate should not be included > > The following part of the text will be deleted: "The > IPsec WG has discussed the role of AH in the future, > and it is possible that it will be made optional in > the future versions of the IPsec protocol set. > Implementers are recommended to take this in account." Fine. >5) Correspondent node functionality to be discussed or not > > Based on the e-mail discussion and input from the ADs, > it would be inappropriate to refer to an I-D in a normative > way, hence it is hard to add anything. (Note: we are > working hard to complete the MIPv6 specification -- even > if it is not ready today, it will get done sooner or > later. At that point a bis cellular host draft and/or > general ipv6 node requirements document can be issued > with MIPv6 included.) Okay. >6) Tunneling avoidance over air recommendation > > The intention was to talk about use, not > implementation. However, it is perhaps best that > both this and the 6to4 recommendation are dealt with > by the ngtrans WG team, and we can thus leave both > 2.11 and 2.13 out of the document. Sounds good. >7) Place of the 6to4 recommendation > > We will leave this recommendation out, and to be handled by the > effort in the ngtrans WG. Sounds good. >8) Editorial comments > > We have tried to correct the editorial comments. 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 Wed May 29 08:40:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TFeerP028397; Wed, 29 May 2002 08:40:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TFedD6028396; Wed, 29 May 2002 08:40: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.3+Sun/8.12.3) with ESMTP id g4TFeWrP028381; Wed, 29 May 2002 08:40: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 IAA05529; Wed, 29 May 2002 08:40:37 -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 IAA17590; Wed, 29 May 2002 08:40:37 -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 IAA05094; Wed, 29 May 2002 08:40:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TFeat18376; Wed, 29 May 2002 08:40:36 -0700 X-mProtect: <200205291540> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGk3fbX; Wed, 29 May 2002 08:40:34 PDT Message-ID: <3CF4F673.607A7AA0@iprg.nokia.com> Date: Wed, 29 May 2002 08:40:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <4DA6EA82906FD511BE2F00508BCF0538044F06AB@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 Hello Hesham, I CC:'d the IPv6 mailing list... "Hesham Soliman (ERA)" wrote: > => I think the HA must defend all addresses, including > the link-local one. This is related to RFC3041 and > Francis' discussion on the IPv6 list. A node implementing > RFC 3041 might form a global address that belongs to one of > the other MN's Home addresses. Hence, if the HA does not > defend all addresses, a MN might 'lose' one of its > home addresses to another node on the home link. I'd rather prohibit such behavior. I don't see the need for it. I am surprised that RFC 3041 would allow such behavior. Can you point out the offending part of the specification? What was the justification for enabling this? Aren't there "enough" random numbers in 2^64 to avoid clobbering addresses used by other nodes? sheesh... Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 09:36:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGaErP028692; Wed, 29 May 2002 09:36:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TGaE2c028691; Wed, 29 May 2002 09:36: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.3+Sun/8.12.3) with ESMTP id g4TGaArP028684 for ; Wed, 29 May 2002 09:36: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 JAA29531 for ; Wed, 29 May 2002 09:36: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 KAA12451 for ; Wed, 29 May 2002 10:36: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 JAA08071; Wed, 29 May 2002 09:36:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TGaCW16613; Wed, 29 May 2002 09:36:12 -0700 X-mProtect: <200205291636> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdD63OIU; Wed, 29 May 2002 09:36:10 PDT Message-ID: <3CF5037A.9B7B7890@iprg.nokia.com> Date: Wed, 29 May 2002 09:36:10 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> <3CF46CC3.F19F0272@iprg.nokia.com> <01b001c206e5$87a721f0$396015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jim, There are at least three kinds of inputs to this process: data, facts, and opinions. I've lumped together "intuition" and "expertise" under "opinions", and I point out that it is a mistake to deprecate the latter in the way that some readers of your note may tend to do. With this in mind, I have some comments on your message. James Kempf wrote: > TCP flow control was implemented in response to congestion collapse in > the late '80s. If something like that happens as a result of widespread > Mobile IP implementation, you can be sure that it will become a MUST. Presumably, you are not suggesting that we have to get burned first before taking action. Instead, you probably mean to suggest that the threat is not assuredly imminent. > But, for now, it is very easy to see the extra amount of work route > optimization would add to implementing an IPv6 stack, but very hard to > see what effect lack of route optimization would have on traffic flow in > the Internet when mobile nodes are widespread Here are some facts: A. A mobile device transmitting data to a correspondent node will require forward and reverse tunneling through the home network unless it can establish a binding cache entry at the correspondent node. B. This can increase the total capacity requirement for the communications by an arbitrary amount, depending on the layout with respect to the home network. That could easily mean a factor of "thousands". Opinion: A typical multiplier for (B) will be about 2. The actual number depends on the relative placement of the nodes, and the multiplier will be higher whenever a mobile device needs to communicate with a local correspondent. Thus, the scenario where people would expect the most responsive communications will offer counterintuitive behavior. Solutions for this problem include: - restricted mobility - transient IP addresses = subcase: EIDs to replace IP addresses as identifiers - reengineering human intuition - proxy agents These are good for more startups and full employment (like NATs are), but most of them are bad for the Internet. Opinion: The probability is very high that the future Internet will be predominately composed of mobile devices. If you think otherwise, try counting your mobile Internet nodes versus your stationary ones, and then lump in 1 billion mobile telephones into the overall mix. Opinion: We should expect to see new applications related to messaging and multimedia and data mining. These new applications should not be encumbered with a legacy (created by us right now) that assures long delay paths crossing the Internet multiple times. > (though, of course, > everyone has an opinion). So making it a SHOULD seems like the best > tradeoff. I disagree with this. It is about the same as saying that a device can be IPv6 compliant even if the engineering budget and marketing timetable for the vendor persuaded management to delete features that did not harm the device itself, only other devices. I believe this leads to the phenomenon called the "tragedy of the commons". Making it a SHOULD means you cannot fault any vendor for making devices that continually cause extra work for numerous remote Internet nodes. > It is really too bad that there is not some kind of large scale, > supercomputer simulation of the Internet that we could tweak when these > kinds of questions come up. This would allow the IETF to base decisons > on some kind of data (though people do argue about simulations) rather > than just on intuition. Well, I agree that it would be a lot better if we had this information. In the meantime, I guess the best we can do is try to understand the problem, given the best factual basis we have, and using the best expertise we can gather to improve the future scalability of using mobile devices in the Internet -- that is, the scalability of almost the entire future Internet. I'd be interested to find out which of my opinions (or facts!) you think is leading me to the wrong conclusion... Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 20:52:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3qWrP001170; Wed, 29 May 2002 20:52:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U3qWqI001169; Wed, 29 May 2002 20:52: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.3+Sun/8.12.3) with ESMTP id g4U3qRrP001162 for ; Wed, 29 May 2002 20:52:28 -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 UAA08084 for ; Wed, 29 May 2002 20:52:33 -0700 (PDT) From: zhang.hongyuan@zte.com.cn Received: from mail2.zte.com.cn ([210.21.227.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21601 for ; Wed, 29 May 2002 21:53:29 -0600 (MDT) Subject: About Home Address Option in Mobile IPv6 To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Thu, 30 May 2002 11:34:55 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 5.0.6a |January 17, 2001) at 2002-05-30 11:56:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I am now reading "draft-ietf-mobileip-ipv6-16.txt". My questions are as follows: 1. Am I reading the latest draft? 2.Is it necessary to have a Home Address Option, since the Binding Update Destination Option already has a Home Address field which gives the home address of the mobile node? It will be redundant for the Binding Update to include a Home Address Option, why there is the redundancy? 3.It is stated in section 5.1.6 of the draft that: "A Binding Update message to the correspondent node MUST NOT include the Home Address option in order to avoid reflection attacks..." which contradicts the statement made in section 8.2 that: "Before accepting a Binding Update option received in any packet, the receiving node MUST validate the Binding Update according to the following tests: -... - The packet MUST contain a Home Address option. ..." If both statements are true, according to them, all Binding Updates sent to the correspondent node (not including the home agent) will be discarded. What's wrong? Thanks! ZHANG Hongyuan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 20:58:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3wlrP001292; Wed, 29 May 2002 20:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U3wluM001291; Wed, 29 May 2002 20: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3wgrP001284 for ; Wed, 29 May 2002 20:58: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 UAA21675 for ; Wed, 29 May 2002 20:58:48 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27271 for ; Wed, 29 May 2002 21:58:47 -0600 (MDT) Message-ID: <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> <3CF46CC3.F19F0272@iprg.nokia.com> <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> Subject: Re: Mandating Route Optimization Date: Wed, 29 May 2002 20:56:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, > There are at least three kinds of inputs to this process: > data, facts, and opinions. > I've lumped together "intuition" and "expertise" under > "opinions", and I point out that it is a mistake to > deprecate the latter in the way that some readers of > your note may tend to do. With this in mind, I have > some comments on your message. > It was not the intent of my note to deprecate opinions. The opinion of a knowledgable person is always valuable. > > TCP flow control was implemented in response to congestion collapse in > > the late '80s. If something like that happens as a result of widespread > > Mobile IP implementation, you can be sure that it will become a MUST. > > Presumably, you are not suggesting that we have to get burned first > before taking action. Instead, you probably mean to suggest that > the threat is not assuredly imminent. > Human nature being what it is, the hard task in front of of your nose gets more attention than the vague threat somewhere in the future, regrettably. Otherwise, we would have see strong measures in place for solving global warming back in the mid 1990's. > > But, for now, it is very easy to see the extra amount of work route > > optimization would add to implementing an IPv6 stack, but very hard to > > see what effect lack of route optimization would have on traffic flow in > > the Internet when mobile nodes are widespread > > Here are some facts: > > A. A mobile device transmitting data to a correspondent node will > require forward and reverse tunneling through the home network > unless it can establish a binding cache entry at the correspondent > node. > > B. This can increase the total capacity requirement for the > communications by an arbitrary amount, depending on the > layout with respect to the home network. That could easily > mean a factor of "thousands". > > Opinion: > > A typical multiplier for (B) will be about 2. The actual > number depends on the relative placement of the nodes, and > the multiplier will be higher whenever a mobile device needs to > communicate with a local correspondent. > We are talking about adding the tunnel header, right? If so and if you mean the relative volume of the data traffic will be increased by a factor of 2, that, of course, depends on the packet size. If the packet is a 40 byte VoIP packet, then I agree with you. If it is a 1500 byte HTTP packet (most common size on the Internet today, I'm told) then the relative increase won't be nearly as large. People are more likely to look at the latter than the former when they consider route optimization because most of the traffic now is of that nature. This may be shortsighted, but it is how practical-minded people (which means most engineers) tend to think > Thus, the scenario where people would expect the most > responsive communications will offer counterintuitive > behavior. > > Solutions for this problem include: > - restricted mobility > - transient IP addresses > = subcase: EIDs to replace IP addresses as identifiers > - reengineering human intuition > - proxy agents > > These are good for more startups and full employment (like > NATs are), but most of them are bad for the Internet. > > Opinion: > > The probability is very high that the future Internet will > be predominately composed of mobile devices. If you think > otherwise, try counting your mobile Internet nodes versus > your stationary ones, and then lump in 1 billion mobile > telephones into the overall mix. > My opinion is that, in the near future, again unfortunately, most of these devices will likely be GPRS nodes (aside: this text is coming to you courtesy of Docomo's wCDMA GPRS network). And most of them won't be doing VoIP. So Mobile IP won't likely play a big role immediately, though it will in the intermediate term. VoIP (where, in my opinion, route optimization is critical) probably will be important in the longer term. But this is pretty crystal ball. > Opinion: > > We should expect to see new applications related to messaging > and multimedia and data mining. These new applications should > not be encumbered with a legacy (created by us right now) that > assures long delay paths crossing the Internet multiple times. > > > (though, of course, > > everyone has an opinion). So making it a SHOULD seems like the best > > tradeoff. > > I disagree with this. It is about the same as saying that a device > can be IPv6 compliant even if the engineering budget and marketing > timetable for the vendor persuaded management to delete features > that did not harm the device itself, only other devices. > I guess I don't follow your logic. RFC 2119 is fairly explicit about what SHOULD and MUST mean, and, to me, the text on SHOULD closely matches what route optimization provides. I think we disagree here. > I believe this leads to the phenomenon called the "tragedy of > the commons". > > Making it a SHOULD means you cannot fault any vendor for making > devices that continually cause extra work for numerous remote > Internet nodes. > > > It is really too bad that there is not some kind of large scale, > > supercomputer simulation of the Internet that we could tweak when these > > kinds of questions come up. This would allow the IETF to base decisons > > on some kind of data (though people do argue about simulations) rather > > than just on intuition. > > Well, I agree that it would be a lot better if we had this > information. In the meantime, I guess the best we can do is > try to understand the problem, given the best factual basis > we have, and using the best expertise we can gather to improve > the future scalability of using mobile devices in the Internet -- > that is, the scalability of almost the entire future Internet. > > I'd be interested to find out which of my opinions (or facts!) > you think is leading me to the wrong conclusion... > I don't think your conclusion is entirely wrong (and that is my opinion). As I mentioned in the original note, it is possible that your opinion on the effect of lack of route optimization may happen. Where we disagree, I think, is in the difficulty of judging how likely it is and when it might occur. It is necssary to balance that uncertainty against the certainty of imposing additional requirements on people's IPv6 stacks. Since we are trying to get people to implement and deploy IPv6, we need to try to minimize the number of requirements. Of course, this leaves it up to the implementor's and deployer's judgement about when to implement and deploy route optimization. The view I have is that standards can always be updated. 3GPP is unfortuantely much better at realizing this than we are, which is perhaps why they are able to get their standards completed more quickly. Making route optimization SHOULD establishes a pretty strong stake in the ground about what the WG thinks is desirable. All things considered, I think that should be enough for now. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 21:18:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U4IrrP001498; Wed, 29 May 2002 21:18:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U4Irco001497; Wed, 29 May 2002 21:18: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.3+Sun/8.12.3) with ESMTP id g4U4IorP001490 for ; Wed, 29 May 2002 21:18: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 VAA06022 for ; Wed, 29 May 2002 21:18:54 -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 VAA12141 for ; Wed, 29 May 2002 21:18:53 -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 g4U4JHq17866 for ; Thu, 30 May 2002 07:19:17 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 07:18:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 07:18:51 +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: Mandating Route Optimization Date: Thu, 30 May 2002 07:18:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652A2@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcIG8o46RG2Tbbi3S1OvcT6U1nZZHwAnleQw To: , X-OriginalArrivalTime: 30 May 2002 04:18:51.0683 (UTC) FILETIME=[1A8BFF30:01C20791] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4U4IorP001491 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > please be aware of already-deployed IPv6 codebase. WinXP is shipping, > MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. > even home address option (which is a MUST) is changing. > i don't think it a good situation for implementers. I think that this will not be a significant problem - I assume that there will be more IPv6 implementations coming than what what exists already. Of course, the existing implementations may not support Mobile IP and I think that will be something that we have to live with. 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 May 29 21:30:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U4U9rP001575; Wed, 29 May 2002 21:30:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U4U8EV001573; Wed, 29 May 2002 21:30: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.3+Sun/8.12.3) with ESMTP id g4U4U3rP001562 for ; Wed, 29 May 2002 21:30: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 VAA27377 for ; Wed, 29 May 2002 21:30:07 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21107 for ; Wed, 29 May 2002 21:30:06 -0700 (PDT) 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 g4U4Sr926002 for ; Thu, 30 May 2002 07:28:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 07:30:04 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 07:30:04 +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: Mandating Route Optimization Date: Thu, 30 May 2002 07:30:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652A5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcIHFxjHb5skT/ASSuiGCfT6da0R+gAezpJA To: Cc: X-OriginalArrivalTime: 30 May 2002 04:30:04.0822 (UTC) FILETIME=[ABC4DB60:01C20792] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4U4U3rP001566 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Glenn, I support your analysis. John -----Original Message----- From: ext Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: 29 May, 2002 16:45 To: Perkins Charles (IPRG); Loughney John (NRC/Helsinki) Cc: hesham.soliman@era.ericsson.se; Hippelainen Lassi (NET/Helsinki); ipng@sunroof.eng.sun.com Subject: RE: Mandating Route Optimization Pros for the mandate: -------------------- Although this may not, initially, seem to be a pro section, it really is. Are these solutions "kludgy", in your opinion, because they are not end to end :)? Is that what you mean by kludgy :)? What are these proposed substitutes and what WG are they being addressed in :)? It does sound to me that some WG will need to take on such work to facilitate multiple systems wishing to provide route optimization to their clients. Operators have no control over whether route optimization is deployed on correspondent nodes or not. It also seems to me that later end to end arguments against these alternate solutions would seem to be ludicrous based upon the decision to NOT make an end to end route optimization a ubiquitous part of IPv6. I.e. you self-proclaimed end to enders had better speak up now or forever hold your peace. I also find it a bit rediculous that people sell IPv6 saying that route optimized mobility is "built-in" to IPv6 when it really is no better than IPv4 in this regard. I.e. ubiquitous route optimization helps the IPv6 business case. Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. Cons: ---- I must also say that even if the end to end solution were ubiquitous and mandated there may still be adequate reasons (location privacy, speed, security, more optimizations with other IETF soft-state technologies) to use the non end to end solutions. Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. --------- I hope this helps people understand just exactly what is being decided here :) - Charlie Perkins wrote - > Route Optimization will motivate the introduction of kludgy > substitutes, much as the lack of address space for IPv4 has > motivated the introduction of NATs. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 21:43:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U4hLrP001621; Wed, 29 May 2002 21:43:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U4hL2K001620; Wed, 29 May 2002 21:43: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.3+Sun/8.12.3) with ESMTP id g4U4hHrP001613 for ; Wed, 29 May 2002 21:43:17 -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 VAA29448 for ; Wed, 29 May 2002 21:43:22 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08273 for ; Wed, 29 May 2002 22:44:19 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KICC5ZHM4Q8ZGUOE@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 30 May 2002 14:42:25 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id CAECE130003; Thu, 30 May 2002 04:42:21 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by splat.its.monash.edu.au (Postfix) with ESMTP id 6186A130003; Thu, 30 May 2002 14:42:18 +1000 (EST) Date: Thu, 30 May 2002 14:43:04 +1000 From: Brett Pentland Subject: Re: Mandating Route Optimization X-Sender: "Brett Pentland" To: James Kempf Cc: "Charles E. Perkins" , ipng@sunroof.eng.sun.com Message-id: <3CF5ADD8.44F36F36@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: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> <3CF46CC3.F19F0272@iprg.nokia.com> <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Sorry if I'm butting in or completely off the mark but I got the impression from Charles' email that when talking about a capactity multiplier, he was referring to the number of links that packets have to traverse to get to their destination, rather than the overhead imposed by tunnelling headers. For example, a route optimised VoIP stream might use up 30 kb/s on, say, two links rather than on twenty. Cheers, Brett. James Kempf wrote: > > > But, for now, it is very easy to see the extra amount of work > route > > > optimization would add to implementing an IPv6 stack, but very hard > to > > > see what effect lack of route optimization would have on traffic > flow in > > > the Internet when mobile nodes are widespread > > > > Here are some facts: > > > > A. A mobile device transmitting data to a correspondent node will > > require forward and reverse tunneling through the home network > > unless it can establish a binding cache entry at the correspondent > > node. > > > > B. This can increase the total capacity requirement for the > > communications by an arbitrary amount, depending on the > > layout with respect to the home network. That could easily > > mean a factor of "thousands". > > > > Opinion: > > > > A typical multiplier for (B) will be about 2. The actual > > number depends on the relative placement of the nodes, and > > the multiplier will be higher whenever a mobile device needs to > > communicate with a local correspondent. > > > > We are talking about adding the tunnel header, right? > If so and if you mean the relative volume of the data traffic > will be increased by a factor of 2, that, of course, depends on the > packet size. If the packet is a 40 byte VoIP packet, then I agree > with you. If it is a 1500 byte HTTP packet (most common size > on the Internet today, I'm told) then the relative increase won't be > nearly as large. People are more likely to look at the latter than the > former when they consider route optimization because most of the traffic > now is of that nature. This may be shortsighted, but it is > how practical-minded people (which means most engineers) > tend to think > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@eng.monash.edu.au CTIE - Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering PO Box 35, Monash University, VIC, 3800, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-5358 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 29 22:02:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U52srP001664; Wed, 29 May 2002 22:02:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U52sos001663; Wed, 29 May 2002 22:02: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.3+Sun/8.12.3) with ESMTP id g4U52prP001656 for ; Wed, 29 May 2002 22:02: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 WAA02541 for ; Wed, 29 May 2002 22:02:55 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02495 for ; Wed, 29 May 2002 22:02:55 -0700 (PDT) Message-ID: <019601c20797$012e68b0$b36015ac@T23KEMPF> From: "James Kempf" To: "Brett Pentland" Cc: "Charles E. Perkins" , References: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD7B@esebe004.NOE.Nokia.com> <3CF46CC3.F19F0272@iprg.nokia.com> <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> <3CF5ADD8.44F36F36@eng.monash.edu.au> Subject: Re: Mandating Route Optimization Date: Wed, 29 May 2002 22:00:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brett, OK, thanx that wasn't clear to me. I agree that the number of links will increase. Route optimization certainly will help, and I am not disputing that. jak ----- Original Message ----- From: "Brett Pentland" To: "James Kempf" Cc: "Charles E. Perkins" ; Sent: Wednesday, May 29, 2002 9:43 PM Subject: Re: Mandating Route Optimization > Hi, > > Sorry if I'm butting in or completely off the mark but I got the > impression from Charles' email that when talking about a capactity > multiplier, he was referring to the number of links that packets have to > traverse to get to their destination, rather than the overhead imposed > by tunnelling headers. For example, a route optimised VoIP stream might > use up 30 kb/s on, say, two links rather than on twenty. > > Cheers, > Brett. > > James Kempf wrote: > > > > > But, for now, it is very easy to see the extra amount of work > > route > > > > optimization would add to implementing an IPv6 stack, but very hard > > to > > > > see what effect lack of route optimization would have on traffic > > flow in > > > > the Internet when mobile nodes are widespread > > > > > > Here are some facts: > > > > > > A. A mobile device transmitting data to a correspondent node will > > > require forward and reverse tunneling through the home network > > > unless it can establish a binding cache entry at the correspondent > > > node. > > > > > > B. This can increase the total capacity requirement for the > > > communications by an arbitrary amount, depending on the > > > layout with respect to the home network. That could easily > > > mean a factor of "thousands". > > > > > > Opinion: > > > > > > A typical multiplier for (B) will be about 2. The actual > > > number depends on the relative placement of the nodes, and > > > the multiplier will be higher whenever a mobile device needs to > > > communicate with a local correspondent. > > > > > > > We are talking about adding the tunnel header, right? > > If so and if you mean the relative volume of the data traffic > > will be increased by a factor of 2, that, of course, depends on the > > packet size. If the packet is a 40 byte VoIP packet, then I agree > > with you. If it is a 1500 byte HTTP packet (most common size > > on the Internet today, I'm told) then the relative increase won't be > > nearly as large. People are more likely to look at the latter than the > > former when they consider route optimization because most of the traffic > > now is of that nature. This may be shortsighted, but it is > > how practical-minded people (which means most engineers) > > tend to think > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Brett Pentland brett.pentland@eng.monash.edu.au > CTIE - Centre for Telecommunications and Information Engineering > Department of Electrical and Computer Systems Engineering > PO Box 35, Monash University, VIC, 3800, Australia > Phone : +61 3 9905-5245 Fax : +61 3 9905-5358 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 00:27:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U7RcrP001895; Thu, 30 May 2002 00:27:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U7Rc4Q001894; Thu, 30 May 2002 00: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.3+Sun/8.12.3) with ESMTP id g4U7RZrP001887 for ; Thu, 30 May 2002 00:27:35 -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 AAA24532 for ; Thu, 30 May 2002 00:27:35 -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 AAA13330 for ; Thu, 30 May 2002 00:27:34 -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 g4U7Rpq04101 for ; Thu, 30 May 2002 10:27:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 10:27:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 10:27:25 +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: Cellular host issues Date: Thu, 30 May 2002 10:27:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cellular host issues Thread-Index: AcIHH1DRAZpjqQaPRpC0U0KdzHlwEAAiiVkg To: , Cc: , , X-OriginalArrivalTime: 30 May 2002 07:27:25.0059 (UTC) FILETIME=[71D82D30:01C207AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4U7RZrP001888 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > > "2.4 RFC2461 - Neighbor Discovery for IPv6 > > > > Neighbor Discovery is described in [RFC-2461]. This > > specification is a mandatory part of IPv6. > > > > 2.4.1 Neighbor Discovery in 3GPP Networks > > > > In GPRS and UMTS networks, some Neighbor Discovery > > messages can cause unnecessary traffic and consume > > valuable (limited) bandwidth. GPRS and UMTS links > > resemble a point-to-point link; hence, the host's > > only neighbor on the cellular link is the default > > router that is already known through Router Discovery. > > Therefore, while the host must support Neighbor > > Solicitation and Advertisement messages, their use > > in address resolution and next-hop determination is > > not necessary and the host may choose to not initiate > > them. > > I don't think that we should include the last sentence of > this paragraph. Can you detail what your objection to the last sentence is? > 2.4.1 Neighbor Discovery in 3GPP Networks > > The host must support the Neighbor Solicitation and > Advertisement messages for neighbor unreachability > detection as specified in [RFC-2461]. > > In GPRS and UMTS networks, it is very desireable to > conserve bandwidth. Therefore, hosts stacks used in > these environments should include a mechanism in > upper layer protocols (such as TCP) to provide > reachability confirmation when two-way reachability > can be confirmed (see RFC-2461, section 7.3.1). > These confirmations will allow the suppression of > most NUD-related messages. My feeling is that upper-layer protocols are out of scope of this document, and I am uncomfortable making a recommendation on including them in this document. I think that it would be possible to say that, when available, these mechanisms can be used, something like this: In GPRS and UMTS networks, some Neighbor Discovery messages can cause unnecessary traffic and consume valuable (limited) bandwidth. GPRS and UMTS links resemble a point-to-point link; hence, the host's only neighbor on the cellular link is the default router that is already known through Router Discovery. Additionally, upper-layer protocols can provide reachability confirmation when two-way reachability can be confirmed (see RFC-2461, section 7.3.1). These confirmations allow the suppression of most NUD-related messages. Therefore, while the host must support Neighbor Solicitation and Advertisement messages, their use in address resolution and next-hop determination is not necessary and the host may choose to not initiate them. > [If there are any upper-layer 3GPP protocols that can > provide reachability confirmation, meeting the definition > in the ND spec, we should mention them here.] I don't have the 3GPP documentation in front of me, perhaps one of the other authors can comment here. > Please note that the IPv6 specs consistenly misspell neighbour as > "neighbor" :-). We should also use that spelling in this > specification. Actually, Neighbour is the correct spelling in British English, so I would not classify it as a misspelling (I think that several of the authors of the document have been taught British English). However, we should be consistant in the document. 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 May 30 01:04:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U84irP001973; Thu, 30 May 2002 01:04:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U84iIe001972; Thu, 30 May 2002 01: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.3+Sun/8.12.3) with ESMTP id g4U84frP001965 for ; Thu, 30 May 2002 01:04:41 -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 BAA01279 for ; Thu, 30 May 2002 01:04:41 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26571 for ; Thu, 30 May 2002 02:04: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 g4U854q08733 for ; Thu, 30 May 2002 11:05:04 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 11:04: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, 30 May 2002 11:04:38 +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: MLD comments on cellular host drafts - seeking feedback Date: Thu, 30 May 2002 11:03:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652B5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MLD comments on cellular host drafts - seeking feedback Thread-Index: AcIG+6KJyRhAyHQlQr2PCdxXIMRRJgAtG6xg To: , , X-OriginalArrivalTime: 30 May 2002 08:04:38.0841 (UTC) FILETIME=[A5484290:01C207B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4U84frP001966 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Just to add on to Hesham's mail: > You are right of course, but I think we can get > into this endless loop of discussions because > of a simple fact: We are not discussing > the way 3GPP _can_ or might work. We are > discussing the facts as we have them today. > So can we accept that this _is_ the way 3GPP > networks work (as described by Lassi and myself > in earlier emails) and go from there? > If this simple fact can't be accepted then we're > not going to end up with a resolution. This document is not intending to describe new behavior for IPv6 or 3GPP networks. The focus is what is needed on the cellular host so that the cellular host behaves like a proper IPv6 node, when attached to a 3GPP network. Doing anything more than this is simply out of scope for this document. 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 May 30 01:14:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U8EerP001998; Thu, 30 May 2002 01:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U8EetN001997; Thu, 30 May 2002 01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U8EbrP001990 for ; Thu, 30 May 2002 01:14:37 -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 BAA01886 for ; Thu, 30 May 2002 01:14:37 -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 BAA03199 for ; Thu, 30 May 2002 01:14:37 -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 RAA15120; Thu, 30 May 2002 17:14:35 +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 RAA25094; Thu, 30 May 2002 17:14:35 +0900 (JST) Date: Thu, 30 May 2002 17:14:05 +0900 (JST) Message-Id: <20020530.171405.08368244.keiichi@iij.ad.jp> To: charliep@iprg.nokia.com, kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> References: <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> 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 I fully agree with James. Even without supporting RO, the CN can communicate with any MNs using a bidir-tunnel (which is your concern, though). >From an implementor's point of view, manating RO will pose noticeable extra work to all IPv6 implementors. It is not so easy to implement RO (which means implementing the RR procedure and BCE management). Can't we deploy RO gradually? At the initial stage, the IPv6 nodes which support RO may be restricted to some domains (such as an IP telephone carrier). But even in such an environment, we are able to communicate with those nodes using our nodes which are not support RO. If people want to communicate with moving nodes and want to comunicate with nodes even when they are moving, more need for supporting RO is raised. Some time ago, the MIP6 draft said that all IPv6 nodes had to support HAO. Because of this, some implementations currently shipped process HAO. This is bad. Bad because processing unverified HAO has threats already discussed in mobile-ip WG. We now have a option not to mandate HAO processing. In this case, we communicate with those not supporint RO using bidir-tunnel. I think more needs for mobility applications will make 'SHOLD' to 'MUST' in fact, like the TCP flowcontrol. 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 May 30 04:34:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UBY7rP002411; Thu, 30 May 2002 04:34:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UBY7Ow002410; Thu, 30 May 2002 04:34: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.3+Sun/8.12.3) with ESMTP id g4UBY4rP002403 for ; Thu, 30 May 2002 04:34: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 EAA22027 for ; Thu, 30 May 2002 04:34:04 -0700 (PDT) From: adamson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00425 for ; Thu, 30 May 2002 04:34:03 -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 g4UBXxFD125264 for ; Thu, 30 May 2002 07:34:03 -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 g4UBXwV113558 for ; Thu, 30 May 2002 07:33:58 -0400 Importance: Normal Sensitivity: Subject: IPv6 MIBs - internet draft status To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 30 May 2002 07:33:56 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 05/30/2002 07:33:58 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE15ADFAE4A208f9e8a93df938690918c0ABBE15ADFAE4A20" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE15ADFAE4A208f9e8a93df938690918c0ABBE15ADFAE4A20 Content-type: text/plain; charset=US-ASCII We are preparing to implement support for management data in the revised version-neutral MIBs. Two of the drafts (revisions of RFC2011 and RFC2096) have been removed from the index of internet drafts because their expiration date has passed. The drafts that are revisions of RFC2012 and RFC2013 will also be removed soon. There are many comments in the drafts that still need to be resolved and some of the compliance statements are not up to date. Will the IPv6 MIB Design Team be doing any further work on the MIB internet drafts in the near future? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --0__=0ABBE15ADFAE4A208f9e8a93df938690918c0ABBE15ADFAE4A20 Content-type: text/html; charset=US-ASCII Content-Disposition: inline
We are preparing to implement support for management data in the revised version-neutral MIBs. Two of the drafts (revisions of RFC2011 and RFC2096) have been removed from the index of internet drafts because their expiration date has passed. The drafts that are revisions of RFC2012 and RFC2013 will also be removed soon. There are many comments in the drafts that still need to be resolved and some of the compliance statements are not up to date. Will the IPv6 MIB Design Team be doing any further work on the MIB internet drafts in the near future? Thanks!

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com --0__=0ABBE15ADFAE4A208f9e8a93df938690918c0ABBE15ADFAE4A20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 05:27:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UCRxrP002509; Thu, 30 May 2002 05:27:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UCRwha002508; Thu, 30 May 2002 05:27: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.3+Sun/8.12.3) with ESMTP id g4UCRtrP002501 for ; Thu, 30 May 2002 05:27:55 -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 FAA28161 for ; Thu, 30 May 2002 05:27:55 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23451 for ; Thu, 30 May 2002 06:27:54 -0600 (MDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4UCRqPI004717; Thu, 30 May 2002 05:27:53 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AGU09724 (AUTH raraghun); Thu, 30 May 2002 17:54:52 +0530 (IST) Message-ID: <3CF61AC4.F50C52B2@cisco.com> Date: Thu, 30 May 2002 17:57:48 +0530 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: adamson@us.ibm.com CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MIBs - internet draft status References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Kristine, The work on the update drafts for 2011, 2012, 2013 and 2096, has just been restarted by the IPv6 MIB design team - and the comments received on the mailing list are being actively looked into. We do intend to submit the updated version of the drafts as soon as these comments have been addressed (we should have some status by the Japan IETF). In case you need to have a look at the old drafts, they are still available at http://www.icir.org/fenner/mibs/v6/ HTH.. -Rajiv. adamson@us.ibm.com wrote: > > We are preparing to implement support for management data in the > revised version-neutral MIBs. Two of the drafts (revisions of RFC2011 > and RFC2096) have been removed from the index of internet drafts > because their expiration date has passed. The drafts that are > revisions of RFC2012 and RFC2013 will also be removed soon. There are > many comments in the drafts that still need to be resolved and some of > the compliance statements are not up to date. Will the IPv6 MIB Design > Team be doing any further work on the MIB internet drafts in the near > future? Thanks! > > Kristine Adamson > IBM Communications Server for MVS: TCP/IP Development > Internet e-mail:adamson@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 05:44:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UCinrP002540; Thu, 30 May 2002 05:44:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UCinkQ002539; Thu, 30 May 2002 05:44: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.3+Sun/8.12.3) with ESMTP id g4UCijrP002532 for ; Thu, 30 May 2002 05:44:45 -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 FAA01294 for ; Thu, 30 May 2002 05:44:45 -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 GAA19090 for ; Thu, 30 May 2002 06:44:45 -0600 (MDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA24197; Thu, 30 May 2002 05:43:32 -0700 (PDT) Message-Id: <4.2.2.20020530084145.00a961c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 30 May 2002 08:44:15 -0400 To: adamson@us.ibm.com From: Margaret Wasserman Subject: Re: IPv6 MIBs - internet draft status Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Kristine, 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. Thanks, Margaret At 07:33 AM 5/30/02 , adamson@us.ibm.com wrote: >We are preparing to implement support for management data in the revised version-neutral MIBs. Two of the drafts (revisions of RFC2011 and RFC2096) have been removed from the index of internet drafts because their expiration date has passed. The drafts that are revisions of RFC2012 and RFC2013 will also be removed soon. There are many comments in the drafts that still need to be resolved and some of the compliance statements are not up to date. Will the IPv6 MIB Design Team be doing any further work on the MIB internet drafts in the near future? Thanks! > >Kristine Adamson >IBM Communications Server for MVS: TCP/IP Development >Internet e-mail:adamson@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 06:05:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UD5NrP002566; Thu, 30 May 2002 06:05:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UD5N9J002565; Thu, 30 May 2002 06:05: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.3+Sun/8.12.3) with ESMTP id g4UD5KrP002558 for ; Thu, 30 May 2002 06:05:20 -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 GAA14320 for ; Thu, 30 May 2002 06:05:20 -0700 (PDT) From: adamson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11351 for ; Thu, 30 May 2002 07:06:19 -0600 (MDT) 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 g4UD5JFD091792 for ; Thu, 30 May 2002 09:05:19 -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 g4UD5GV257488 for ; Thu, 30 May 2002 09:05:16 -0400 Importance: Normal Sensitivity: Subject: Re: IPv6 MIBs - internet draft status To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 30 May 2002 09:05:15 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 05/30/2002 09:05:15 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE15ADFD4E6938f9e8a93df938690918c0ABBE15ADFD4E693" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE15ADFD4E6938f9e8a93df938690918c0ABBE15ADFD4E693 Content-type: text/plain; charset=US-ASCII Thanks to everyone who responded regarding my status questions on the revised MIBs. Does anyone know if the IPv6 MIB design team is planning on scheduling a session at the Japan IETF to discuss the revised MIBs? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --0__=0ABBE15ADFD4E6938f9e8a93df938690918c0ABBE15ADFD4E693 Content-type: text/html; charset=US-ASCII Content-Disposition: inline
Thanks to everyone who responded regarding my status questions on the revised MIBs. Does anyone know if the IPv6 MIB design team is planning on scheduling a session at the Japan IETF to discuss the revised MIBs? Thanks!

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com --0__=0ABBE15ADFD4E6938f9e8a93df938690918c0ABBE15ADFD4E693-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 06:14:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDERrP002624; Thu, 30 May 2002 06:14:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UDEQ9f002623; Thu, 30 May 2002 06:14: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.3+Sun/8.12.3) with ESMTP id g4UDENrP002613 for ; Thu, 30 May 2002 06:14: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 GAA15739 for ; Thu, 30 May 2002 06:14:24 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03944 for ; Thu, 30 May 2002 07:14:24 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 30 May 2002 09:14:23 -0400 Message-ID: <3CF624FD.CD023C4@nc.rr.com> Date: Thu, 30 May 2002 09:11:25 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adamson@us.ibm.com CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MIBs - internet draft status References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kristine, We will probably have a slot in one of the IPv6 WG sessions to discuss the mib work. It may also be presented at the ops area meeting (if held). At least, that is what we have done in the past. Regards, Brian adamson@us.ibm.com wrote: > > Thanks to everyone who responded regarding my status questions on the > revised MIBs. Does anyone know if the IPv6 MIB design team is planning > on scheduling a session at the Japan IETF to discuss the revised MIBs? > Thanks! > > Kristine Adamson > IBM Communications Server for MVS: TCP/IP Development > Internet e-mail:adamson@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 06:45:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDjArP002853; Thu, 30 May 2002 06:45:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UDjADQ002852; Thu, 30 May 2002 06:45: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.3+Sun/8.12.3) with ESMTP id g4UDj5rP002845 for ; Thu, 30 May 2002 06:45:07 -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 GAA23010 for ; Thu, 30 May 2002 06:45:04 -0700 (PDT) From: lassi.hippelainen@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 HAA06580 for ; Thu, 30 May 2002 07:45:03 -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 g4UDjRq21848 for ; Thu, 30 May 2002 16:45:27 +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, 30 May 2002 16:45:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 16:45:02 +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: Mandating Route Optimization Date: Thu, 30 May 2002 16:45:01 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcIHL1Cwf36xo1sdTvGc10rwxGW/7QAqXyWQ To: Cc: X-OriginalArrivalTime: 30 May 2002 13:45:02.0316 (UTC) FILETIME=[329F3AC0:01C207E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4UDj7rP002846 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, sorry to trip a player in the same team, but there is a certain satisfaction not unlike playing chess against a Grand Master and not losing on the first move... > -----Original Message----- > From: Perkins Charles (IPRG) <...> > Here are some facts: > > A. A mobile device transmitting data to a correspondent node will > require forward and reverse tunneling through the home network > unless it can establish a binding cache entry at the correspondent > node. > > B. This can increase the total capacity requirement for the > communications by an arbitrary amount, depending on the > layout with respect to the home network. That could easily > mean a factor of "thousands". > > Opinion: > > A typical multiplier for (B) will be about 2. The actual > number depends on the relative placement of the nodes, and > the multiplier will be higher whenever a mobile device needs to > communicate with a local correspondent. Suppose the mobile end subscribes to local services using the CoA in stead of the Home Address. The local service doesn't have to know about the home address at all. While having your beer in the pub (for privacy reasons you actually don't even *want* to use the HA route!) you can check the latest results of Swamp Soccer World Championships (http://www.swampsoccer.net/) using the optimal route. Multiplier 1. But of course you'll lose the connection, if you happen to do a handover out of the pub WLAN, so better sit down and order more beer. Or be prepared to click 'reload' at the new address. > Thus, the scenario where people would expect the most > responsive communications will offer counterintuitive > behavior. Now we're getting to percentages of traffic. How many services need to follow you while moving? How many are used while being static for the duration of the service session? Most of us don't browse the web while walking or driving! > Solutions for this problem include: > - restricted mobility > - transient IP addresses > = subcase: EIDs to replace IP addresses as identifiers > - reengineering human intuition > - proxy agents > > These are good for more startups and full employment (like > NATs are), but most of them are bad for the Internet. Thus far the Internet services have all been start-ups. IMHO, they still will be for a long time. They are still looking for the best feel, which leads back to my previous comment. And the kids are learning fast to "reengineer human intuition" to what is available. The text messaging tornado was driven by kids, not business users. As a system architect I respect your arguments, but the wicked service providers seem to have triumphed over them all... <...> > Making it a SHOULD means you cannot fault any vendor for making > devices that continually cause extra work for numerous remote > Internet nodes. Making it a MUST wouldn't change anything. There is no Internet Police that could enforce a MUST. We can't even claim that they will lose business, if they don't comply, because there is no MIPv6 business to lose. Out of the three known tools of statesmanship, Threats and Blackmail are powerless. The only one left is Bribing. Therefore I was asking, if there is a business reason for the fixed, free-for-all, financed-by-ads services to support MIP. What will they win, if they do it? -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 08:13:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UFD8rP003173; Thu, 30 May 2002 08:13:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UFD8Bf003172; Thu, 30 May 2002 08:13: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.3+Sun/8.12.3) with ESMTP id g4UFD4rP003165 for ; Thu, 30 May 2002 08:13:04 -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 IAA16431 for ; Thu, 30 May 2002 08:13:04 -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 JAA06262 for ; Thu, 30 May 2002 09:13:02 -0600 (MDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA26316; Thu, 30 May 2002 08:11:48 -0700 (PDT) Message-Id: <4.2.2.20020530081653.01f094b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 30 May 2002 11:05:33 -0400 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Cellular host issues Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2E@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Therefore, while the host must support Neighbor > > > Solicitation and Advertisement messages, their use > > > in address resolution and next-hop determination is > > > not necessary and the host may choose to not initiate > > > them. > > > > I don't think that we should include the last sentence of > > this paragraph. > >Can you detail what your objection to the last sentence is? Saying that a host "may choose to not initiate" NUD messages is the same thing as saying that a host may choose not to comply with the NUD portions of RFC 2461, which clearly indicates that hosts send NUD-related NA and NS messages in certain situations, such as when an IPv6 packet is sent to/through a neighbor whose neighbor cache entry is in the PROBE state. I object to telling cellular host implementers that they don't have to comply with portions of RFC 2461. RFC 2461 is a mandatory, core IPv6 specification, and all IPv6 nodes should comply with it. Your suggested text will not result in a significant decrease in traffic over the wireless interface. In fact, the suggested text will not result in the elimination of _any_ NUD messages in the most typical case where everything is working properly. And, even if we do form a rough consensus (despite my objections) that cellular hosts do not have to comply fully with the NUD-related portions of RFC 2461, your proposed text is insufficient to specify what cellular hosts should/shouldn't implement. If a host fully complies with RFC 2461, with the single exception that it doesn't initiate any NUD-related NS or NA messages, it could reach a point where it can't send any IPv6 packets at all. Let me explain further... Lets assume that a cellular host (CH) is attempting to establish communication with a web server on the Internet (WS), using a 3GPP GGSN as its default gateway, of course. Let's further assume that the neighbor cache on the CH already includes an entry for the GGSN, with the IsRouter bit set, due to previous Router Advertisements received from the GGSN -- otherwise, the CH wouldn't have an IPv6 address. This entry will be in the STALE state, as defined in RFC 2461 section 6.3.4. First, let's look at what happens when all is going well... ND indicates that address resolution is unnecessary when the link-layer address of the neighbor is already known. This would apply in the 3GPP case, so no address resolution step would be required for CH to determine the link-layer address of the GGSN. When the CH attempts to connect to the WS, with the neighbor cache entry in the stale state, no NUD NS will be sent. The HTTP/TCP/IPv6 packet will be sent to the WS, and the neighbor cache entry will be moved to the DELAY state. As long as a TCP acknowledgement is received, and upper layer advice provided to ND, within 5 seconds, no NUD messages are require. Going forward, the neighbor cache will continue to be updated by the TCP layer whenever a newill proceed without any NUD messages at all. IMPORTANT POINT: No NS or NA messages are sent, at all, in the case where full connectivity exists between the CH, the GGSN and the WS. This would be true even if we were willing to initiate NUD messages, so your proposed optimization does not actually save any bandwidth in normal operation. But, what will happen when something goes wrong? Let's assume that there is a network failure, perhaps between the GGSN and the WS, that is preventing traffic from passing between the CH and the WS. The CH may make repeated attempts to connect, over an extended period of time (greater than 35 seconds), with the neighbor cache entry progressing from the REACHABLE state, to the STALE state, to the DELAY state, to the PROBE state. At that point, no HTTP/TCP/IPv6 packets will be sent (for any traffic to or through the GGSN -- which is all traffic that the CH might send) until two-way reachability can be established between the CH and the GGSN. This would normally happen through the GGSN's response to a NUD NS message sent by the CH, but what happens if the CH chooses not initiate those messages, as suggested in the cellular host draft? Nothing. No IPv6 packets will ever be sent by the CH again, until it is rebooted. Obviously this is not a desireable outcome. So, along with your statement that the cellular host may choose not to initiate NUD-related NS messages, you would also need some changes to the NUD state machine to avoid entering the PROBE state. This is a non-trivial change to ND, and I don't think that we should suggest it in this document. Margaret > > 2.4.1 Neighbor Discovery in 3GPP Networks > > > > The host must support the Neighbor Solicitation and > > Advertisement messages for neighbor unreachability > > detection as specified in [RFC-2461]. > > > > In GPRS and UMTS networks, it is very desireable to > > conserve bandwidth. Therefore, hosts stacks used in > > these environments should include a mechanism in > > upper layer protocols (such as TCP) to provide > > reachability confirmation when two-way reachability > > can be confirmed (see RFC-2461, section 7.3.1). > > These confirmations will allow the suppression of > > most NUD-related messages. > >My feeling is that upper-layer protocols are out of scope of >this document, and I am uncomfortable making a recommendation on >including them in this document. I think that it would be possible >to say that, when available, these mechanisms can be used, >something like this: > > In GPRS and UMTS networks, some Neighbor Discovery > messages can cause unnecessary traffic and consume > valuable (limited) bandwidth. GPRS and UMTS links > resemble a point-to-point link; hence, the host's > only neighbor on the cellular link is the default > router that is already known through Router Discovery. > Additionally, upper-layer protocols can provide > reachability confirmation when two-way reachability > can be confirmed (see RFC-2461, section 7.3.1). > These confirmations allow the suppression of > most NUD-related messages. Therefore, while the host must > support Neighbor Solicitation and Advertisement messages, > their use in address resolution and next-hop determination is > not necessary and the host may choose to not initiate > them. > > > [If there are any upper-layer 3GPP protocols that can > > provide reachability confirmation, meeting the definition > > in the ND spec, we should mention them here.] > >I don't have the 3GPP documentation in front of me, perhaps one of the other >authors can comment here. > > > Please note that the IPv6 specs consistenly misspell neighbour as > > "neighbor" :-). We should also use that spelling in this > > specification. > >Actually, Neighbour is the correct spelling in British English, >so I would not classify it as a misspelling (I think that several >of the authors of the document have been taught British English). >However, we should be consistant in the document. > >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 May 30 08:30:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UFUBrP003223; Thu, 30 May 2002 08:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UFUBxY003222; Thu, 30 May 2002 08:30:11 -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.3+Sun/8.12.3) with ESMTP id g4UFU5rP003198 for ; Thu, 30 May 2002 08:30: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 IAA26714 for ; Thu, 30 May 2002 08:30:04 -0700 (PDT) Received: from cichlid.adsl.duke.edu (uds159-58.dial.hccnet.nl [62.251.58.159]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21090 for ; Thu, 30 May 2002 09:30: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 g4UFI4x06038; Thu, 30 May 2002 11:18:05 -0400 Message-Id: <200205301518.g4UFI4x06038@cichlid.adsl.duke.edu> To: john.loughney@nokia.com cc: mrw@windriver.com, jari.arkko@piuha.net, Hesham@piuha.net, Soliman@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Cellular host issues In-Reply-To: Message from john.loughney@nokia.com of "Thu, 30 May 2002 10:27:24 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2E@esebe004.NOE.Nokia.com> Date: Thu, 30 May 2002 11:18:04 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Speaking individually, as someone involved in the original NUD discussions... > Hi Margaret, > > > "2.4 RFC2461 - Neighbor Discovery for IPv6 > > > > > > Neighbor Discovery is described in [RFC-2461]. This > > > specification is a mandatory part of IPv6. > > > > > > 2.4.1 Neighbor Discovery in 3GPP Networks > > > > > > In GPRS and UMTS networks, some Neighbor Discovery > > > messages can cause unnecessary traffic and consume > > > valuable (limited) bandwidth. GPRS and UMTS links > > > resemble a point-to-point link; hence, the host's > > > only neighbor on the cellular link is the default > > > router that is already known through Router Discovery. > > > Therefore, while the host must support Neighbor > > > Solicitation and Advertisement messages, their use > > > in address resolution and next-hop determination is > > > not necessary and the host may choose to not initiate > > > them. > > > > I don't think that we should include the last sentence of > > this paragraph. Some of the thinking behind NUD is: 1) it's intended to test end-2-end IP connectivity at the neighbor-to-neighbor level. Even of L2 can indicate to L3 when the L2 link "goes away", that doesn't mean NUD is not necessary. The IP module on the neighbor may not be functioning properly, even though the L2 link is up. NUD detects such situations. 2) If NUD indicates there is a problem with neighbor connectivity, there are some steps to take to try and find an alternate path. Rerunning ND may result in a new link-layer address being found for the destination that reestablishes connectivity. Or, perhaps the neighbor is actually a router and an alternate router can be found. 3) NUD is only used if there is IP traffic thorough some neighbor, but the upper layers (TCP, specifically) are not telling the IP/NUD layer that ACKS are coming back. I.e., normally, if there is (say) TCP usage, NUD won't need to be used at all. So no extra/unnecessary traffic. >From the above, I don't quite buy the argument that NUD is not needed on the link for the reasons given in the document. On the other hand, I understand that things are more complex in some scenarios (like the target of the document at issue). Specifically: 1) 3GPP will be using lots of UDP (RTP and friends) and maybe not so much TCP? So upper layer hints may not be readily available (or, in anycase, there is no document explainig how to do this). 2) If (and only if) there is only a single p2p (e.g., no other interfaces to other networks), there is presumably no recovery possible in the case that NUD fails. So one could argue, what's the point? But the celluar document could do a better job of explaining these issues and the tradeoffs than it does. > My feeling is that upper-layer protocols are out of scope of > this document, and I am uncomfortable making a recommendation on > including them in this document. I think that it would be possible > to say that, when available, these mechanisms can be used, > something like this: Actually, it makes sense to me to encourage stack builders to be smart about providing feedback from upper layers to lower layers in order to avoid the need for NUD _in those cases where it makes sense to from the NUD protocol perspective_. Not mentioning this, seems like not providing good guidance. 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 May 30 10:03:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UH3ErP003966; Thu, 30 May 2002 10:03:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UH3Exu003965; Thu, 30 May 2002 10:03: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.3+Sun/8.12.3) with ESMTP id g4UH3ArP003958 for ; Thu, 30 May 2002 10:03:10 -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 KAA11414 for ; Thu, 30 May 2002 10:03:11 -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 KAA07566 for ; Thu, 30 May 2002 10:03:11 -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 KAA10428 for ; Thu, 30 May 2002 10:03:11 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UH38g11395; Thu, 30 May 2002 10:03:08 -0700 X-mProtect: <200205301703> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxq6lHh; Thu, 30 May 2002 10:03:06 PDT Message-ID: <3CF65B4A.75C80F1C@iprg.nokia.com> Date: Thu, 30 May 2002 10:03:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Lassi Hippelainen (NET/Helsinki)" CC: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Lassi, lassi.hippelainen@nokia.com wrote: > Suppose the mobile end subscribes to local services using the CoA in stead of > the Home Address. The local service doesn't have to know about the home address > at all. While having your beer in the pub (for privacy reasons you actually > don't even *want* to use the HA route!) you can check the latest results of > Swamp Soccer World Championships (http://www.swampsoccer.net/) using the > optimal route. Multiplier 1. You are describing the well-known case where Mobile IP is not used at all. It does not necessarily relate to discussion about Mobile IP specifications. > But of course you'll lose the connection, if you happen to do a handover > out of the pub WLAN, so better sit down and order more beer. Or be prepared > to click 'reload' at the new address. I call this URP -- the "User-controlled Retransmission Protocol". The name is quite appropriate. > Now we're getting to percentages of traffic. How many services need to follow > you while moving? How many are used while being static for the duration of the > service session? Most of us don't browse the web while walking or driving! It is possible that a majority of the future Internet will be embedded devices. It is possible that voice applications will continue while people are moving. It is possible that video displays will be of interest to us even while we move. Don't get stuck in the mode of living with what's been forced on us by lack of functional network-wide mobility management in today's laptops and PDAs. > Thus far the Internet services have all been start-ups. IMHO, they still > will be for a long time. They are still looking for the best feel, which > leads back to my previous comment. And the kids are learning fast to > "reengineer human intuition" to what is available. The text messaging > tornado was driven by kids, not business users. None of this supports your contention related to the topic at hand. In fact, service providers across the Internet would be a lot happier if their clients did not have to URP all the time. > As a system architect I respect your arguments, but the wicked service > providers seem to have triumphed over them all... Nowhere in my text will you find the characterization that service providers are wicked. In fact, they tend to deploy the standardized protocols that help them make the most money. It's our job to get those standardized protocols available to them in a way that does not burn all of us in the future. > Making it a MUST wouldn't change anything. There is no Internet Police > that could enforce a MUST. Exactly. We can't make anyone implement IPv6. We can't make anyone implement Mobile IPv6. We can't make anyone implement these protocols, no matter which protocol features we MANDATE or RECOMMEND. But we can foster the expectation that we make good engineering judgements about what needs to be done, if vendors implement the protocols at all. Promulgating systems that are certain to break will not help us to foster this expectation. > We can't even claim that they will lose business, if they don't comply, > because there is no MIPv6 business to lose. So, how is it going to help us make the business if we promote false expectations about the need for various features? > Out of the three known tools of statesmanship, Threats and Blackmail > are powerless. The only one left is Bribing. Therefore I was asking, > if there is a business reason for the fixed, free-for-all, financed-by-ads > services to support MIP. What will they win, if they do it? Even in these dark days of worldwide loss of human lives, property, and civil liberties attributable to the intentional and/or misguided actions of certain of the world's leaders, I am not yet this cynical about the characterization of statesmanship. So I suggest that we continue along with the business of engineering useful protocols. Others in our company, and in other companies, will take up the task of creating systems using these protocols, and they may be able to continue trust in our results if we don't ourselves forget the purpose(s) of the work. I view good IETF work as enlarging the Internet pie, so that we can all get bigger slices. I reckon the service providers will make tons of money from IPv6. Why not? Why not help them, by enabling users to avoid URPing? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 10:13:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UHDtrP003997; Thu, 30 May 2002 10:13:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UHDtom003996; Thu, 30 May 2002 10:13: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.3+Sun/8.12.3) with ESMTP id g4UHDqrP003989 for ; Thu, 30 May 2002 10:13: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 KAA29684 for ; Thu, 30 May 2002 10:13:51 -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 KAA14261 for ; Thu, 30 May 2002 10:13:50 -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 KAA11413; Thu, 30 May 2002 10:13:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UHDnZ26633; Thu, 30 May 2002 10:13:49 -0700 X-mProtect: <200205301713> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVlyMXI; Thu, 30 May 2002 10:13:46 PDT Message-ID: <3CF65DCB.7939B84@iprg.nokia.com> Date: Thu, 30 May 2002 10:13:47 -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: keiichi@iij.ad.jp CC: charliep@iprg.nokia.com, kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> <20020530.171405.08368244.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keiichi SHIMA / $BEg7D0l(B wrote: > >From an implementor's point of view, manating RO will pose noticeable > extra work to all IPv6 implementors. It is not so easy to implement > RO (which means implementing the RR procedure and BCE management). from another implementor's point of view, this is nonsense. a lot of emphasis has been placed on the current MIPv6 internet draft to minimise the work the CN has to do. I can get you some code, if you think it is so difficult to implement. 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 Thu May 30 12:04:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UJ4rrP004683; Thu, 30 May 2002 12:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UJ4rXb004682; Thu, 30 May 2002 12:04: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.3+Sun/8.12.3) with ESMTP id g4UJ4orP004675 for ; Thu, 30 May 2002 12:04: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 MAA05321 for ; Thu, 30 May 2002 12:04:50 -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 NAA02550 for ; Thu, 30 May 2002 13:05:48 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g4UJ49N26520; Thu, 30 May 2002 22:04:09 +0300 Date: Thu, 30 May 2002 22:04:08 +0300 (EEST) From: Pekka Savola To: Vijay Devarapalli cc: keiichi@iij.ad.jp, , , Subject: Re: Mandating Route Optimization In-Reply-To: <3CF65DCB.7939B84@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 30 May 2002, Vijay Devarapalli wrote: > Keiichi SHIMA / $BEg7D0l(B wrote: > > > >From an implementor's point of view, manating RO will pose noticeable > > extra work to all IPv6 implementors. It is not so easy to implement > > RO (which means implementing the RR procedure and BCE management). > > from another implementor's point of view, this is nonsense. a lot > of emphasis has been placed on the current MIPv6 internet draft to > minimise the work the CN has to do. I can get you some code, if you > think it is so difficult to implement. Please show. Is it 50 lines, 100? -- 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 May 30 13:07:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UK7vrP004790; Thu, 30 May 2002 13:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UK7vrp004789; Thu, 30 May 2002 13:07: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.3+Sun/8.12.3) with ESMTP id g4UK7rrP004782 for ; Thu, 30 May 2002 13:07:54 -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 NAA06578 for ; Thu, 30 May 2002 13:07:54 -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 OAA05417 for ; Thu, 30 May 2002 14:08:52 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 320706A906; Thu, 30 May 2002 23:07:52 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 40D7E6A905; Thu, 30 May 2002 23:07:48 +0300 (EEST) Message-ID: <3CF686D8.4060605@kolumbus.fi> Date: Thu, 30 May 2002 23:08:56 +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: Margaret Wasserman Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: Cellular host issues References: <4.2.2.20020530081653.01f094b0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: >>>> Therefore, while the host must support Neighbor >>>> Solicitation and Advertisement messages, their use >>>> in address resolution and next-hop determination is >>>> not necessary and the host may choose to not initiate >>>> them. >>>> >>>I don't think that we should include the last sentence of >>>this paragraph. >>> >>Can you detail what your objection to the last sentence is? > > Saying that a host "may choose to not initiate" NUD messages is > the same thing as saying that a host may choose not to comply with > the NUD portions of RFC 2461, which clearly indicates that hosts send > NUD-related NA and NS messages in certain situations, such as when > an IPv6 packet is sent to/through a neighbor whose neighbor cache > entry is in the PROBE state. Ok, but this text fragment was not attempting to say anything about NUD, that's why it explicitly said "in address resolution and next-hop determination". But I can see that it can be interpreted the other way. How about the following: 2.4 RFC2461 - Neighbor Discovery for IPv6 Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6. 2.4.1 Neighbor Discovery in 3GPP Networks Hosts must support Neighbour Solicitation and Advertisement messages. In GPRS and UMTS networks, some Neighbor Discovery messaging can be unnecessary in certain cases. GPRS and UMTS links resemble a point-to-point link; hence, the host's only neighbor on the cellular link is the defaul router that is already known through Router Discovery. Therefore, while the host must support address resolution and next-hop determination, the host may choose to not initiate these tasks. So hopefully this covers part of the problem. We still have to deal with NUD. We already stated earlier that NUD is mandatory. My understanding is that the discussion relates to the kind of advice we can give to NUD for the suppression of the messages: 1) From the PDP context positive feedback all the way up to and including a working GGSN IP layer, even if this is strictly speaking lower layer from the point of view of the cellular host. 2) From the upper layers, without mentioning specifics. Basically exactly what RFC 2461 says. 3) From the upper layers, with some specific 3GPP guidance. For instance, SIP is heavily used over UDP. It might make sense to state that a SIP application should give the progress information it has to the UDP layer (which doesn't get any progress information) so that it can tell this information to IP. Margaret, I do see the problem you described in your e-mail about getting to the PROBE state, but as far as I can see, the current proposal was to use suppress NUD *only* if you got positive feedback. So, in your problem example the host would actually get positive feedback and the entry would be kept in the REACHABLE state. The remaining question is whether the source of the feedback can be 1, 2, or 3. Let me propose that we pick either 1 or 3. Assuming 1 is ok, the following text would appear to do the job: The host must support neighbour unreachability detection as specified in [RFC-2461]. In GPRS and UMTS networks, it is very desireable to conserve bandwidth. Therefore, hosts stacks used in these environments should include a mechanism in other layer protocols (such as TCP or PDP Context) to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, section 7.3.1). These confirmations will allow the suppression of most NUD-related messages. Assuming 3 is ok, the following text discusses a bit more into the details regarding the upper layers in typical 3GPP hosts: The host must support neighbour unreachability detection as specified in [RFC-2461]. In GPRS and UMTS networks, it is very desireable to conserve bandwidth. Therefore, hosts stacks used in these environments should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, section 7.3.1). These confirmations will allow the suppression of most NUD-related messages. Host TCP implementation should provide reachability confirmation. The use of UDP for many purposes in 3GPP networks poses a problem for providing this reachability confirmation. UDP itself is unable provide such confirmation. Instead, applications running over UDP should provide the confirmation where possible. In particular, when UDP is used for transporting RTP, the RTCP protocol feedback should be used as a basis for the reachability confirmation. When UDP is used for transporting SIP, responses to SIP requests should be used as the confirmation. 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 May 30 16:44:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UNiXrP005402; Thu, 30 May 2002 16:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UNiX4W005401; Thu, 30 May 2002 16:44: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.3+Sun/8.12.3) with ESMTP id g4UNiUrP005394 for ; Thu, 30 May 2002 16:44:30 -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 QAA10253 for ; Thu, 30 May 2002 16:44:30 -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 RAA25188 for ; Thu, 30 May 2002 17:44:30 -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 QAA03145; Thu, 30 May 2002 16:44:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UNiTU03409; Thu, 30 May 2002 16:44:29 -0700 X-mProtect: <200205302344> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpBIIG0; Thu, 30 May 2002 16:44:26 PDT Message-Id: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 May 2002 16:43:50 -0700 To: IPng List From: Bob Hinden Subject: Re: Mandating Route Optimization Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It was the original intent that all IPv6 nodes implement the correspondent node side of Mobile IPv6, even if they are not a mobile node. This was considered one of the benefits of IPv6 (i.e., improved Mobile IP). However as Itojun points out, all current (and soon to ship) product IPv6 implementations do not include route optimization now because the standardization of Mobile iPv6 has taken some time. [Please note this is not a criticism of Mobile IPv6, just observation of the current situation.] It doesn't seem right to make them non-compliant (i.e., make RO a MUST). Perhaps we can come up with some text for a very strong SHOULD, or make it a MUST for new IPv6 implementations. Independent of how this is resolved, I think the best place to define the route optimization implementation requirements for all IPv6 nodes is in the IPv6 Node Requirements document. I don't think it should be in the Mobile IPv6 specification because at a minimum implementers not planning to implement Mobile IPv6 might not see it. There is a design team effort underway to produce an IPv6 Node Requirements draft and I think they should have an -00 version out soon for w.g. review and comments. This discussion is important input into this document. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 17:27:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0RGrP005473; Thu, 30 May 2002 17:27:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V0RGKl005472; Thu, 30 May 2002 17:27: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.3+Sun/8.12.3) with ESMTP id g4V0RDrP005465 for ; Thu, 30 May 2002 17:27: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 RAA27904 for ; Thu, 30 May 2002 17:27:13 -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 RAA28970 for ; Thu, 30 May 2002 17:27:12 -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 RAA05163; Thu, 30 May 2002 17:27:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4V0RAB31645; Thu, 30 May 2002 17:27:10 -0700 X-mProtect: <200205310027> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlXQ6ZQ; Thu, 30 May 2002 17:15:24 PDT Message-ID: <3CF6C09A.7214595A@iprg.nokia.com> Date: Thu, 30 May 2002 17:15:22 -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: keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <01b001c206e5$87a721f0$396015ac@T23KEMPF> <3CF5037A.9B7B7890@iprg.nokia.com> <00f801c2078e$0e4f1750$b36015ac@T23KEMPF> <20020530.171405.08368244.keiichi@iij.ad.jp> <3CF65DCB.7939B84@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi Keiichi, sorry about the earlier mail. I realised it was rude and not called for. I will try to rephrase what I said. the CN implementation as it is described in draft-17 is quite simple (IMO). a lot of care was taken to make the CN as stateless as possible (at the cost of extra work by the MN). regards Vijay Vijay Devarapalli wrote: > > Keiichi SHIMA / $BEg7D0l(B wrote: > > > >From an implementor's point of view, manating RO will pose noticeable > > extra work to all IPv6 implementors. It is not so easy to implement > > RO (which means implementing the RR procedure and BCE management). > > from another implementor's point of view, this is nonsense. a lot > of emphasis has been placed on the current MIPv6 internet draft to > minimise the work the CN has to do. I can get you some code, if you > think it is so difficult to implement. > > Vijay > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 17:53:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0r4rP005720; Thu, 30 May 2002 17:53:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V0r4xc005719; Thu, 30 May 2002 17:53:04 -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.3+Sun/8.12.3) with ESMTP id g4V0qxrP005712 for ; Thu, 30 May 2002 17:53:00 -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 RAA06462 for ; Thu, 30 May 2002 17:52:59 -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 SAA19824 for ; Thu, 30 May 2002 18:52:58 -0600 (MDT) Received: from kenawang ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA01671; Thu, 30 May 2002 17:51:38 -0700 (PDT) Message-Id: <4.2.2.20020530205232.02d77dc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 30 May 2002 20:52:44 -0400 To: jari.arkko@piuha.net From: Margaret Wasserman Subject: Re: Cellular host issues Cc: Jari Arkko , john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten In-Reply-To: <3CF6A8DD.8010805@piuha.net> References: <4.2.2.20020530081653.01f094b0@mail.windriver.com> <3CF686D8.4060605@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, This looks good to me. Margaret At 06:34 PM 5/30/02 , Jari Arkko wrote: >Follow-up to my own e-mail, after some off-line discussions. >Here's an updated suggestion for the address resolution etc part: > > > 2.4 RFC2461 - Neighbor Discovery for IPv6 > > Neighbor Discovery is described in [RFC-2461]. This > specification is a mandatory part of IPv6. > > 2.4.1 Neighbor Discovery in 3GPP Networks > > Hosts must support Neighbour Solicitation and > Advertisement messages. > > In GPRS and UMTS networks, some Neighbor Discovery > messaging can be unnecessary in certain cases. > GPRS and UMTS links resemble a point-to-point link; > hence, the host's only neighbor on the cellular > link is the defaul router that is already known > through Router Discovery. There are no link layer > > addresses. Therefore, address resolution and next-hop > determination are not needed. > >Secondly, about alternative 1 for the advice to give for NUD. > >I've been asked to provide more details about the specific >protocol layers, whether the tunnel and the payload stacks >are the same etc. We'll send an e-mail about this tomorrow. > >Finally, for alternative 3 I have some updated text regarding >what kind of advice to give: > > > The host must support neighbour unreachability > detection as specified in [RFC-2461]. > > In GPRS and UMTS networks, it is very desireable to > conserve bandwidth. Therefore, hosts stacks used in > these environments should include a mechanism > in upper layer protocols to provide > reachability confirmation when two-way IP layer > reachability can be confirmed (see RFC-2461, > Section 7.3.1). These confirmations will allow the > suppression of most NUD-related messages. > > Host TCP implementation should provide > reachability confirmation in the manner > > explained in RFC 2461, Section 7.3.1. > > > The use of UDP for many purposes in 3GPP > networks poses a problem for providing this > reachability confirmation. UDP itself is > unable provide such confirmation. Instead, > applications running over UDP should provide > the confirmation where possible. In particular, > when UDP is used for transporting RTP, the RTCP > protocol feedback should be used as a basis for > the reachability confirmation. If an RTCP > > packet is received with a reception report block > indicating some packets have gone through, then packets > are reaching the peer. If they have reached the > peer, they have also reached the neighbour. > > When UDP is used for transporting SIP, responses to > > SIP requests should be used as the confirmation that > > packets sent to the peer are reaching it. > The receipt of new non-retransmitted requests within > a SIP dialog should be used as a confirmation that > previous responses have reached the peer. > >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 May 30 17:57:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0v6rP005766; Thu, 30 May 2002 17:57:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V0v5NP005765; Thu, 30 May 2002 17:57:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0uRrP005746 for ; Thu, 30 May 2002 17:56:27 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4V0uR6U349189; Thu, 30 May 2002 17:56:27 -0700 (PDT) Message-Id: <200205310056.g4V0uR6U349189@jurassic.eng.sun.com> Date: Thu, 30 May 2002 17:58:54 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: Mandating Route Optimization To: john.loughney@nokia.com, itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ixHoYm36eurxZDPH8dwttg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 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: john.loughney@nokia.com > X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 > content-class: urn:content-classes:message > > please be aware of already-deployed IPv6 codebase. WinXP is shipping, > > MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. > > even home address option (which is a MUST) is changing. > > i don't think it a good situation for implementers. > > I think that this will not be a significant problem - I assume that > there will be more IPv6 implementations coming than what what > exists already. Of course, the existing implementations may not > support Mobile IP and I think that will be something that we have > to live with. I agree with John completely. We don't have enough IPv6 deployment yet and it's good time to make the decision whether Route Optimization should be MUST in MobileIPv6. I think, it makes more sense to have Route Optimization a 'MUST' in MobileIPv6 draft now than in future, when we might have significant backward compatibility problems. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 18:02:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V121rP005843; Thu, 30 May 2002 18:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V121SO005842; Thu, 30 May 2002 18:02:01 -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.3+Sun/8.12.3) with ESMTP id g4V120rP005835 for ; Thu, 30 May 2002 18:02:00 -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 g4V11FaU002498 for ; Thu, 30 May 2002 18:01:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g4V11FSw002497 for ipng@sunroof.eng.sun.com; Thu, 30 May 2002 18:01:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UMX1rP005313 for ; Thu, 30 May 2002 15:33:01 -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 PAA01102 for ; Thu, 30 May 2002 15:33:01 -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 QAA22170 for ; Thu, 30 May 2002 16:33:59 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 6C5BB6A906; Fri, 31 May 2002 01:32:59 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8E7B66A905; Fri, 31 May 2002 01:32:57 +0300 (EEST) Message-ID: <3CF6A8DD.8010805@piuha.net> Date: Fri, 31 May 2002 01:34:05 +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: Jari Arkko Cc: Margaret Wasserman , john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: Cellular host issues References: <4.2.2.20020530081653.01f094b0@mail.windriver.com> <3CF686D8.4060605@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Follow-up to my own e-mail, after some off-line discussions. Here's an updated suggestion for the address resolution etc part: 2.4 RFC2461 - Neighbor Discovery for IPv6 Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6. 2.4.1 Neighbor Discovery in 3GPP Networks Hosts must support Neighbour Solicitation and Advertisement messages. In GPRS and UMTS networks, some Neighbor Discovery messaging can be unnecessary in certain cases. GPRS and UMTS links resemble a point-to-point link; hence, the host's only neighbor on the cellular link is the defaul router that is already known through Router Discovery. There are no link layer addresses. Therefore, address resolution and next-hop determination are not needed. Secondly, about alternative 1 for the advice to give for NUD. I've been asked to provide more details about the specific protocol layers, whether the tunnel and the payload stacks are the same etc. We'll send an e-mail about this tomorrow. Finally, for alternative 3 I have some updated text regarding what kind of advice to give: The host must support neighbour unreachability detection as specified in [RFC-2461]. In GPRS and UMTS networks, it is very desireable to conserve bandwidth. Therefore, hosts stacks used in these environments should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, Section 7.3.1). These confirmations will allow the suppression of most NUD-related messages. Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1. The use of UDP for many purposes in 3GPP networks poses a problem for providing this reachability confirmation. UDP itself is unable provide such confirmation. Instead, applications running over UDP should provide the confirmation where possible. In particular, when UDP is used for transporting RTP, the RTCP protocol feedback should be used as a basis for the reachability confirmation. If an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. If they have reached the peer, they have also reached the neighbour. When UDP is used for transporting SIP, responses to SIP requests should be used as the confirmation that packets sent to the peer are reaching it. The receipt of new non-retransmitted requests within a SIP dialog should be used as a confirmation that previous responses have reached the peer. 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 May 30 18:30:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V1UOrP005913; Thu, 30 May 2002 18:30:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V1UNIi005912; Thu, 30 May 2002 18:30:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V1UIrP005905 for ; Thu, 30 May 2002 18:30:20 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4V1UI6U355262; Thu, 30 May 2002 18:30:19 -0700 (PDT) Message-Id: <200205310130.g4V1UI6U355262@jurassic.eng.sun.com> Date: Thu, 30 May 2002 18:32:45 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: Mandating Route Optimization To: charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Cc: kempf@docomolabs-usa.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wg+Q9yaM9fUA63Vf7u6mTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here are some facts: > > A. A mobile device transmitting data to a correspondent node will > require forward and reverse tunneling through the home network > unless it can establish a binding cache entry at the correspondent > node. > > B. This can increase the total capacity requirement for the > communications by an arbitrary amount, depending on the > layout with respect to the home network. That could easily > mean a factor of "thousands". > > Opinion: > > A typical multiplier for (B) will be about 2. The actual > number depends on the relative placement of the nodes, and > the multiplier will be higher whenever a mobile device needs to > communicate with a local correspondent. > > Thus, the scenario where people would expect the most > responsive communications will offer counterintuitive > behavior. > > Solutions for this problem include: > - restricted mobility > - transient IP addresses > = subcase: EIDs to replace IP addresses as identifiers > - reengineering human intuition > - proxy agents > > These are good for more startups and full employment (like > NATs are), but most of them are bad for the Internet. > Those are all good points. A correspndent node as a Server: A correspondent node that serves a mobile node without route-optimization is no different than any other IPv6 server. So what is the advantage of using Mobile-IPv6 here other than using ipv6-addresses ? Should not this promote more usage of NATs using existing MobileIPv4 protocol with private addresses ? What would be the advantage of using MIPv6 rather than MIPV4 using co-located care-of-address with reverse tunnel ? One of the strong advantages of using MobileIPv6 is that route-optimization is in-built in the protocol, if MobileIPv6 does not specify "Route Optimization" as MUST behavior for CNs, we would be sending wrong messages to the IPv6 node implementors, as we expect that a large number of mobile devices will use MobileIPv6 in future. Depending on the location of the server and the home-agent and the mobile node the roundtrip time through the reverse tunnel could be much higher compared to the roundtrip time between MN-CN if route-optimization is used. Correspondent Node as MNs: In this case, imagine two MNs are visiting the same foreign network, but since one of them does not support RO (since it's not mandatory), they still communicate via their home-agent which is far away from the foreign network. This situation will create un-necessary traffic delay while mandatory route-optimization would have easily cut the RTT short to a great length. If we transfer large amount of data, imagine how compelling it would be to have the route-optimization feature in CN! I believe, for successful deployment of MobileIPv6 and IPv6, route-optimization should be MUST for all MIPv6 correspondent nodes and thus for all ipv6-nodes. Thanks, -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 18:35:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V1ZBrP005935; Thu, 30 May 2002 18:35:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V1ZBOR005934; Thu, 30 May 2002 18:35:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V1Z7rP005927 for ; Thu, 30 May 2002 18:35:07 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4V1Z66U355929; Thu, 30 May 2002 18:35:07 -0700 (PDT) Message-Id: <200205310135.g4V1Z66U355929@jurassic.eng.sun.com> Date: Thu, 30 May 2002 18:37:33 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: Mandating Route Optimization To: charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Cc: kempf@docomolabs-usa.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1spoIOc7/+QPCEjglgINaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here are some facts: > > A. A mobile device transmitting data to a correspondent node will > require forward and reverse tunneling through the home network > unless it can establish a binding cache entry at the correspondent > node. > > B. This can increase the total capacity requirement for the > communications by an arbitrary amount, depending on the > layout with respect to the home network. That could easily > mean a factor of "thousands". > > Opinion: > > A typical multiplier for (B) will be about 2. The actual > number depends on the relative placement of the nodes, and > the multiplier will be higher whenever a mobile device needs to > communicate with a local correspondent. > > Thus, the scenario where people would expect the most > responsive communications will offer counterintuitive > behavior. > > Solutions for this problem include: > - restricted mobility > - transient IP addresses > = subcase: EIDs to replace IP addresses as identifiers > - reengineering human intuition > - proxy agents > > These are good for more startups and full employment (like > NATs are), but most of them are bad for the Internet. > Those are all good points. A correspndent node as a Server: A correspondent node that serves a mobile node without route-optimization is no different than any other IPv6 server. So what is the advantage of using Mobile-IPv6 here other than using ipv6-addresses ? Should not this promote more usage of NATs using existing MobileIPv4 protocol with private addresses ? What would be the advantage of using MIPv6 rather than MIPV4 using co-located care-of-address with reverse tunnel ? One of the strong advantages of using MobileIPv6 is that route-optimization is in-built in the protocol, if MobileIPv6 does not specify "Route Optimization" as MUST behavior for CNs, we would be sending wrong messages to the IPv6 node implementors, as we expect that a large number of mobile devices will use MobileIPv6 in future. Depending on the location of the server and the home-agent and the mobile node the roundtrip time through the reverse tunnel could be much higher compared to the roundtrip time between MN-CN if route-optimization is used. Correspondent Node as MNs: In this case, imagine two MNs are visiting the same foreign network, but since one of them does not support RO (since it's not mandatory), they still communicate via their home-agent which is far away from the foreign network. This situation will create un-necessary traffic delay while mandatory route-optimization would have easily cut the RTT short to a great length. If we transfer large amount of data, imagine how compelling it would be to have the route-optimization feature in CN! I believe, for successful deployment of MobileIPv6 and IPv6, route-optimization should be MUST for all MIPv6 correspondent nodes and thus for all ipv6-nodes. Thanks, -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 30 18:54:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V1sGrP005962; Thu, 30 May 2002 18:54:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V1sGwR005961; Thu, 30 May 2002 18:54: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.3+Sun/8.12.3) with ESMTP id g4V1sDrP005954 for ; Thu, 30 May 2002 18:54:13 -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 SAA14183 for ; Thu, 30 May 2002 18:54:13 -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 SAA23973 for ; Thu, 30 May 2002 18:54:12 -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 KAA10594; Fri, 31 May 2002 10:54:11 +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 KAA03548; Fri, 31 May 2002 10:54:10 +0900 (JST) Date: Fri, 31 May 2002 10:53:41 +0900 (JST) Message-Id: <20020531.105341.82987001.keiichi@iij.ad.jp> To: vijayd@iprg.nokia.com Cc: pekkas@netcore.fi, charliep@iprg.nokia.com, kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: <3CF65DCB.7939B84@iprg.nokia.com> 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: Pekka Savola > > > >From an implementor's point of view, manating RO will pose noticeable > > > extra work to all IPv6 implementors. It is not so easy to implement > > > RO (which means implementing the RR procedure and BCE management). > > > > from another implementor's point of view, this is nonsense. a lot > > of emphasis has been placed on the current MIPv6 internet draft to > > minimise the work the CN has to do. I can get you some code, if you > > think it is so difficult to implement. > > Please show. Is it 50 lines, 100? I hope it easy. In my code (though I did not implemented any RR code yet), a binding cache management requires 250 lines or over. an extension header management requires 800 lines or over. plus some header files. I did not count any lines which was required to modify to support CN functions on the existing code (such as ip_input/output, nd_input/output, etc..). The final code will be greater than this. Again, I did not implemnted RR yet. I don't have a concrete idea how many lines do we need to implement RR. It may be trivial or... # of course, it depends on implementors if this number is big or small... 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 Fri May 31 03:34:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VAYZrP006556; Fri, 31 May 2002 03:34:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VAYZoY006555; Fri, 31 May 2002 03:34: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.3+Sun/8.12.3) with ESMTP id g4VAYWrP006548 for ; Fri, 31 May 2002 03:34:32 -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 DAA22464 for ; Fri, 31 May 2002 03:34:31 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23181 for ; Fri, 31 May 2002 04:34:29 -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 g4VAVuv02915; Fri, 31 May 2002 17:31:58 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bob Hinden cc: IPng List Subject: Re: Mandating Route Optimization In-Reply-To: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 17:31:56 +0700 Message-ID: <2913.1022841116@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 30 May 2002 16:43:50 -0700 From: Bob Hinden Message-ID: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> | It doesn't seem right to make them non-compliant (i.e., make RO a MUST). Bob, that's completely bogus as an argument. I don't know enough about the issues to comment on the substance, but if RO is something that the WG feels is important for all nodes to implement, then of course MUST is the right thing. Implementations that already exist can't possibly pretend to conform to a specification that doesn't yet exist, whatever is in that specification. When the new spec does appear, if older implementations decide that they want to be compliant with it, then they may need to issue software upgrades, or something, to get them there. There's nothing new in this, one day soon I'd hope that we want to make IPv6 a MUST implement for the Internet (one of the base required standards like IPb4 is today) - but if the argument is that we can't do that, or lots of stuff that shipped 20 years ago would become non-conformant, then we'd never get anywhere. When we're inventing something new, it is correct and reasonable to consider what effect that will have on the installed base which knows nothing about it - and I assume (and hope) that the RO stuff has been planned in a way such that the world won't break if some node or other happens not to have implemented it (even assuming it is a MUST). But we can not, now or ever, allow considerations of existing implementations conformance state affect the decisions about what new implementations should be required to implement. 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 May 31 03:42:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VAgCrP006578; Fri, 31 May 2002 03:42:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VAgCvU006577; Fri, 31 May 2002 03:42: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.3+Sun/8.12.3) with ESMTP id g4VAg9rP006570 for ; Fri, 31 May 2002 03:42: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 DAA09449 for ; Fri, 31 May 2002 03:42:08 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08589 for ; Fri, 31 May 2002 04:42:45 -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 g4VAbNv02929; Fri, 31 May 2002 17:37:46 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Jari Arkko cc: Margaret Wasserman , john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: Cellular host issues In-Reply-To: <3CF686D8.4060605@kolumbus.fi> References: <3CF686D8.4060605@kolumbus.fi> <4.2.2.20020530081653.01f094b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 17:37:23 +0700 Message-ID: <2927.1022841443@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 30 May 2002 23:08:56 +0300 From: Jari Arkko Message-ID: <3CF686D8.4060605@kolumbus.fi> | But I can see that it can be interpreted the other | way. How about the following: How about you include this ... | 2.4 RFC2461 - Neighbor Discovery for IPv6 | | Neighbor Discovery is described in [RFC-2461]. This | specification is a mandatory part of IPv6. | | 2.4.1 Neighbor Discovery in 3GPP Networks | | Hosts must support Neighbour Solicitation and | Advertisement messages. | | In GPRS and UMTS networks, some Neighbor Discovery | messaging can be unnecessary in certain cases. | GPRS and UMTS links resemble a point-to-point link; | hence, the host's only neighbor on the cellular | link is the defaul router that is already known | through Router Discovery. But stop there (and s/defaul/default/ of course). ND (for link address discovery) is only ever necessary when the link address isn't known - there's no real need to emphasize that point, and by so doing, perhaps lead people to infer things that are not really intended. It's also worth noting of course, that RA messages aren't required to carry the link level address (in general anyway, perhaps for 3GPP you are mandating that?) If the link level address isn't there, ND would be required to find it, wouldn't it? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 03:54:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VAsFrP006602; Fri, 31 May 2002 03:54:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VAsFAB006601; Fri, 31 May 2002 03:54: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.3+Sun/8.12.3) with ESMTP id g4VAsBrP006594 for ; Fri, 31 May 2002 03:54: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 DAA11131 for ; Fri, 31 May 2002 03:54:10 -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 EAA01634 for ; Fri, 31 May 2002 04:54:09 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E11054B23 for ; Fri, 31 May 2002 19:54:03 +0900 (JST) To: IPng List In-reply-to: kre's message of Fri, 31 May 2002 17:31:56 +0700. <2913.1022841116@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: Mandating Route Optimization From: itojun@iijlab.net Date: Fri, 31 May 2002 19:54:03 +0900 Message-ID: <24554.1022842443@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >But we can not, now or ever, allow considerations of existing implementations >conformance state affect the decisions about what new implementations >should be required to implement. then we will have two separate set of IPv6 nodes - without mobile-ipv6 and with mobile-ipv6, and they cannot even ping each other. do you feel it acceptable? i'm very unhappy about the delay of mobile-ipv6 spec. it should have defined home address option, set it in stone, and then work on other things. implementers cannot support (human resource-wise) drafts that drastically change content every time the new version appears. even if that technology is a good one, this way that won't deploy. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 05:14:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VCEbrP006752; Fri, 31 May 2002 05:14:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VCEb6J006751; Fri, 31 May 2002 05:14: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.3+Sun/8.12.3) with ESMTP id g4VCEXrP006744 for ; Fri, 31 May 2002 05:14: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 FAA09357 for ; Fri, 31 May 2002 05:14:33 -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 GAA03893 for ; Fri, 31 May 2002 06:14:31 -0600 (MDT) Received: from kenawang ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA22388; Fri, 31 May 2002 05:12:49 -0700 (PDT) Message-Id: <4.2.2.20020531081253.02d00aa0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 31 May 2002 08:13:39 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Cellular host issues Cc: Jari Arkko , john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten In-Reply-To: <2927.1022841443@munnari.OZ.AU> References: <3CF686D8.4060605@kolumbus.fi> <3CF686D8.4060605@kolumbus.fi> <4.2.2.20020530081653.01f094b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >It's also worth noting of course, that RA messages aren't required >to carry the link level address (in general anyway, perhaps for 3GPP >you are mandating that?) > >If the link level address isn't there, ND would be required to find >it, wouldn't it? There are not link-level addresses on the point-to-point link between the handset and the GGSN. So, no need to do anything to resolve them. Margaret >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 May 31 08:35:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VFZtrP006914; Fri, 31 May 2002 08:35:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VFZtBg006913; Fri, 31 May 2002 08:35:55 -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.3+Sun/8.12.3) with ESMTP id g4VFZqrP006906 for ; Fri, 31 May 2002 08:35:52 -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 IAA07989 for ; Fri, 31 May 2002 08:35:52 -0700 (PDT) Received: from smtp3.att.ne.jp (smtp3.att.ne.jp [165.76.15.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23795 for ; Fri, 31 May 2002 09:36:52 -0600 (MDT) Received: from localhost (poseidon.ccn.ne.jp [210.146.48.67]) by smtp3.att.ne.jp (Postfix) with ESMTP id 9380B154BB for ; Sat, 1 Jun 2002 00:35:49 +0900 (JST) Date: Sat, 01 Jun 2002 00:35:21 +0900 (JST) Message-Id: <20020601.003521.108735690.nov@tahi.org> To: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization From: OKABE Nobuo In-Reply-To: <24554.1022842443@itojun.org> References: <2913.1022841116@munnari.OZ.AU> <24554.1022842443@itojun.org> X-Mailer: Mew version 2.2 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: itojun@iijlab.net Subject: Re: Mandating Route Optimization Date: Fri, 31 May 2002 19:54:03 +0900 > >But we can not, now or ever, allow considerations of existing implementations > >conformance state affect the decisions about what new implementations > >should be required to implement. > > then we will have two separate set of IPv6 nodes - without mobile-ipv6 > and with mobile-ipv6, and they cannot even ping each other. > do you feel it acceptable? > > i'm very unhappy about the delay of mobile-ipv6 spec. it should have > defined home address option, set it in stone, and then work on other > things. implementers cannot support (human resource-wise) drafts > that drastically change content every time the new version appears. > even if that technology is a good one, this way that won't deploy. How should we apply the IETF motto, e.g. "rough consensus and running code", (especially latter words) in this case? ^^^^^^^^^^^^ If mip6 people shows experience and validity about route optimization based upon running code, we will be able to have more productive discussion. thanks, ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 08:46:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VFkErP006953; Fri, 31 May 2002 08:46:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VFkEwj006952; Fri, 31 May 2002 08:46: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.3+Sun/8.12.3) with ESMTP id g4VFkBrP006945 for ; Fri, 31 May 2002 08:46:11 -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 IAA27330 for ; Fri, 31 May 2002 08:46:11 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17289 for ; Fri, 31 May 2002 09:46:05 -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 g4VFhuv04453; Fri, 31 May 2002 22:43:57 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: IPng List Subject: Re: Mandating Route Optimization In-Reply-To: <24554.1022842443@itojun.org> References: <24554.1022842443@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 22:43:56 +0700 Message-ID: <4451.1022859836@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 31 May 2002 19:54:03 +0900 From: itojun@iijlab.net Message-ID: <24554.1022842443@itojun.org> | then we will have two separate set of IPv6 nodes - without mobile-ipv6 | and with mobile-ipv6, and they cannot even ping each other. | do you feel it acceptable? No, but that means that the way the technical work has been done is wrong, and it should be fixed so we don't have that problem. As I said I wasn't commenting on whether what is being offered technically is adequate or not, I haven't been paying attention to it at all. But whether that is correct or not, it certainly can't be the case that simply changing a MUST to a SHOULD in a doc will fix it. If there's a problem like that, it will take a more serious fix. 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 May 31 08:47:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VFlqrP006973; Fri, 31 May 2002 08:47:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VFlqa6006972; Fri, 31 May 2002 08:47: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.3+Sun/8.12.3) with ESMTP id g4VFlnrP006965 for ; Fri, 31 May 2002 08:47: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 IAA28022 for ; Fri, 31 May 2002 08:47:49 -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 JAA01302 for ; Fri, 31 May 2002 09:48:49 -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 g4VFlgPI025009; Fri, 31 May 2002 08:47:42 -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 ABT75636; Fri, 31 May 2002 08:44:43 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07292; Fri, 31 May 2002 08:47:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.39709.647687.595478@thomasm-u1.cisco.com> Date: Fri, 31 May 2002 08:47:41 -0700 (PDT) To: Samita Chakrabarti Cc: john.loughney@nokia.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: RE: Mandating Route Optimization In-Reply-To: <200205310056.g4V0uR6U349189@jurassic.eng.sun.com> References: <200205310056.g4V0uR6U349189@jurassic.eng.sun.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 I don't know if this has been mentioned, but regardless of whether implementation of RO for CN's is a MUST/SHOULD, there should be text in the draft that "RO MUST have a means to be administratively disabled on the CN." I hope it's obvious why. Mike Samita Chakrabarti writes: > > > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to > owner-ipng@sunroof.eng.sun.com using -f > > From: john.loughney@nokia.com > > X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 > > content-class: urn:content-classes:message > > > > please be aware of already-deployed IPv6 codebase. WinXP is shipping, > > > MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. > > > even home address option (which is a MUST) is changing. > > > i don't think it a good situation for implementers. > > > > I think that this will not be a significant problem - I assume that > > there will be more IPv6 implementations coming than what what > > exists already. Of course, the existing implementations may not > > support Mobile IP and I think that will be something that we have > > to live with. > > > I agree with John completely. We don't have enough IPv6 deployment > yet and it's good time to make the decision whether Route Optimization > should be MUST in MobileIPv6. I think, it makes more sense to have > Route Optimization a 'MUST' in MobileIPv6 draft now than in future, > when we might have significant backward compatibility problems. > > > -Samita > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 08:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VFnPrP006993; Fri, 31 May 2002 08:49:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VFnOW4006992; Fri, 31 May 2002 08:49: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.3+Sun/8.12.3) with ESMTP id g4VFnLrP006985 for ; Fri, 31 May 2002 08:49:22 -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 IAA28480 for ; Fri, 31 May 2002 08:49:22 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02153 for ; Fri, 31 May 2002 09:50:17 -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 g4VFknv04464; Fri, 31 May 2002 22:46:49 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: Jari Arkko , john.loughney@nokia.com, ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: Cellular host issues In-Reply-To: <4.2.2.20020531081253.02d00aa0@mail.windriver.com> References: <4.2.2.20020531081253.02d00aa0@mail.windriver.com> <3CF686D8.4060605@kolumbus.fi> <3CF686D8.4060605@kolumbus.fi> <4.2.2.20020530081653.01f094b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 22:46:49 +0700 Message-ID: <4462.1022860009@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 31 May 2002 08:13:39 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020531081253.02d00aa0@mail.windriver.com> | There are not link-level addresses on the point-to-point link between | the handset and the GGSN. So, no need to do anything to resolve | them. OK, in that case, I don't understand why there's any kind of issue at all - and I certainly wouldn't be explaining away the need for ND by reference to RA packets ("router discovery"). If there are no link level addresses, just say that, no need to mention ND at all, it will clearly be irrelevant. 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 May 31 09:32:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGWKrP007074; Fri, 31 May 2002 09:32:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGWJLO007073; Fri, 31 May 2002 09:32: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.3+Sun/8.12.3) with ESMTP id g4VGWFrP007066 for ; Fri, 31 May 2002 09:32:15 -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 JAA14052 for ; Fri, 31 May 2002 09:32:16 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17328 for ; Fri, 31 May 2002 09:32:15 -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 g4VGXla02535 for ; Fri, 31 May 2002 19:33:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 May 2002 19:32:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 19:32:21 +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: Mandating Route Optimization Date: Fri, 31 May 2002 19:32:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652DC@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcIIuoPQklc9JfteQsu25/XBpbzIpAABdx4g To: Cc: X-OriginalArrivalTime: 31 May 2002 16:32:21.0817 (UTC) FILETIME=[BD0B4290:01C208C0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VGWGrP007067 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michael, > I don't know if this has been mentioned, but > regardless of whether implementation of RO for > CN's is a MUST/SHOULD, there should be text in the > draft that "RO MUST have a means to be > administratively disabled on the CN." I agree with you. I do think that additional work will be needed to detail how RO is used, if there is a need for protocol negotiation, etc. I think that the important thing is to have a strong statement of support for implementing RO. How RO is used probably needs some real deployment experience, etc. I think that RO needs to be implemented, but its use is probably still open to local control, 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 Fri May 31 09:49:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGngrP007203; Fri, 31 May 2002 09:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGnft6007202; Fri, 31 May 2002 09:49:41 -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.3+Sun/8.12.3) with ESMTP id g4VGncrP007195 for ; Fri, 31 May 2002 09:49: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 JAA03100 for ; Fri, 31 May 2002 09:49:39 -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 JAA28389 for ; Fri, 31 May 2002 09:49:39 -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 JAA11240 for ; Fri, 31 May 2002 09:49:39 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VGnaZ31316; Fri, 31 May 2002 09:49:36 -0700 X-mProtect: <200205311649> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpfteOf; Fri, 31 May 2002 09:49:35 PDT Message-ID: <3CF7A99F.397DB16B@iprg.nokia.com> Date: Fri, 31 May 2002 09:49:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <0C1353ABB1DEB74DB067ADFF749C4EEFC652DC@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello John, john.loughney@nokia.com wrote: > I do think that additional work > will be needed to detail how RO is used, if there > is a need for protocol negotiation, etc. I think > that the important thing is to have a strong > statement of support for implementing RO. How > RO is used probably needs some real deployment > experience, etc. I think that RO needs to be > implemented, but its use is probably still open > to local control, etc. If there is any issue here, it is mainly a matter of allowing mobile nodes to hide their location. That's simple -- the node should simply do reverse tunneling, and not issue HoTI and CoTI. I can't imagine a reason why a correspondent node would prefer to have traffic going through the home network rather than directly to its mobile communications partner, but if there is a reason, then certainly the correspondent node can simply avoid sending HoT and CoT. Even with HoTI, CoTI, HoT, CoT, and BU mandated for implementation, the mobile nodes still have to correctly and courteously handle the cases where HoT and CoT and even Binding Error messages are never received. I hope these matters will be viewed as specified clearly. Anywhere they are not, we should fix. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 09:50:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGoMrP007220; Fri, 31 May 2002 09:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGoMpF007219; Fri, 31 May 2002 09:50: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.3+Sun/8.12.3) with ESMTP id g4VGoHrP007205; Fri, 31 May 2002 09:50:17 -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 JAA22178; Fri, 31 May 2002 09:50:18 -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 JAA00635; Fri, 31 May 2002 09:50:17 -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 g4VGoDmG002488; Fri, 31 May 2002 18:50:13 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 18:49:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053804593542@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins '" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Fri, 31 May 2002 18:49:46 +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 Hi Charlie, Sorry for the late reply. > => I think the HA must defend all addresses, including > the link-local one. This is related to RFC3041 and > Francis' discussion on the IPv6 list. A node implementing > RFC 3041 might form a global address that belongs to one of > the other MN's Home addresses. Hence, if the HA does not > defend all addresses, a MN might 'lose' one of its > home addresses to another node on the home link. I'd rather prohibit such behavior. I don't see the need for it. I am surprised that RFC 3041 would allow such behavior. Can you point out the offending part of the specification? What was the justification for enabling this? Aren't there "enough" random numbers in 2^64 to avoid clobbering addresses used byHi Charlie other nodes? sheesh... => RFC 2462 makes an optimisation (not a good one IMHO) that if a node does DAD on link-local addresses, it 'owns the interface id' for any other address with any scope. RFC3041 says that a node can generate a new iid and does DAD for _that_ address which uses the new iid. Since this is typically not a link local address, you could get a conflict if the HA does not defend all addresses. For more info, see Francis' thread on 'diid'. I won't be able to relpy quickly at least till monday. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 10:03:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VH3GrP007511; Fri, 31 May 2002 10:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VH3GXj007510; Fri, 31 May 2002 10:03: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.3+Sun/8.12.3) with ESMTP id g4VH32rP007493; Fri, 31 May 2002 10:03:02 -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 KAA28061; Fri, 31 May 2002 10:03:02 -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 KAA08299; Fri, 31 May 2002 10:03:02 -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 KAA11970; Fri, 31 May 2002 10:03:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VH30q18678; Fri, 31 May 2002 10:03:00 -0700 X-mProtect: <200205311703> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGN8SjO; Fri, 31 May 2002 10:02:58 PDT Message-ID: <3CF7ACC3.9272AFBF@iprg.nokia.com> Date: Fri, 31 May 2002 10:02:59 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <4DA6EA82906FD511BE2F00508BCF053804593542@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 Hello Hesham, "Hesham Soliman (ERA)" wrote: > => RFC 2462 makes an optimisation (not a good > one IMHO) that if a node does DAD on link-local > addresses, it 'owns the interface id' for any other > address with any scope. I think this is a good idea. > RFC3041 says that a node can generate a new iid > and does DAD for _that_ address which uses the > new iid. Since this is typically not a link local > address, you could get a conflict if the HA > does not defend all addresses. The problem is that RFC 3041 should require any such node to first acquire rights to the link-local address. I hope that is viewed as an omission, and one which can be quickly repaired. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 10:39:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHdTrP007959; Fri, 31 May 2002 10:39:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHdTiv007958; Fri, 31 May 2002 10:39: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.3+Sun/8.12.3) with ESMTP id g4VHdLrP007943; Fri, 31 May 2002 10:39:21 -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 KAA10418; Fri, 31 May 2002 10:39:20 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08772; Fri, 31 May 2002 11:39:20 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:39:19 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:39:19 -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.4905); Fri, 31 May 2002 10:39:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:39:18 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIxXukqoFBaEwtSHeIim8IDmf+IgABEPjQ From: "Richard Draves" To: "Charles E. Perkins" , "Hesham Soliman (ERA)" Cc: , "IPng Working Group " X-OriginalArrivalTime: 31 May 2002 17:39:19.0020 (UTC) FILETIME=[177BCAC0:01C208CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHdMrP007944 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I disagree. I think the problem is in the RFC 2462 optimization. The RFC 2462 optimization also can fail with manually-configured addresses - it's not just a problem with RFC 3041 temporary addresses. I'm curious about the implementation status. I know the Windows implementation does not implement the RFC 2462 optimization - it performs DAD on every address independently. What about other implementations? Rich > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:03 AM > To: Hesham Soliman (ERA) > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > Hello Hesham, > > "Hesham Soliman (ERA)" wrote: > > > => RFC 2462 makes an optimisation (not a good > > one IMHO) that if a node does DAD on link-local > > addresses, it 'owns the interface id' for any other > > address with any scope. > > I think this is a good idea. > > > RFC3041 says that a node can generate a new iid > > and does DAD for _that_ address which uses the > > new iid. Since this is typically not a link local > > address, you could get a conflict if the HA > > does not defend all addresses. > > The problem is that RFC 3041 should require any > such node to first acquire rights to the link-local > address. I hope that is viewed as an omission, and > one which can be quickly repaired. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 10:45:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHj5rP008066; Fri, 31 May 2002 10:45:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHj5ko008065; Fri, 31 May 2002 10:45: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.3+Sun/8.12.3) with ESMTP id g4VHiwrP008050; Fri, 31 May 2002 10:44:58 -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 KAA12161; Fri, 31 May 2002 10:44:57 -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 KAA01442; Fri, 31 May 2002 10:44:57 -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 KAA14756; Fri, 31 May 2002 10:44:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VHiub16415; Fri, 31 May 2002 10:44:56 -0700 X-mProtect: <200205311744> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXqtfMs; Fri, 31 May 2002 10:44:54 PDT Message-ID: <3CF7B696.C82EC0B9@iprg.nokia.com> Date: Fri, 31 May 2002 10:44:54 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Draves CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: RFC 2462 DAD optimization References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Richard, Even manually configured global addresses should be required to acquire rights to the corresponding link-local address. Why not? Regards, Charlie P. Richard Draves wrote: > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > 2462 optimization also can fail with manually-configured addresses - > it's not just a problem with RFC 3041 temporary addresses. > > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? > > Rich > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Friday, May 31, 2002 10:03 AM > > To: Hesham Soliman (ERA) > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > Hello Hesham, > > > > "Hesham Soliman (ERA)" wrote: > > > > > => RFC 2462 makes an optimisation (not a good > > > one IMHO) that if a node does DAD on link-local > > > addresses, it 'owns the interface id' for any other > > > address with any scope. > > > > I think this is a good idea. > > > > > RFC3041 says that a node can generate a new iid > > > and does DAD for _that_ address which uses the > > > new iid. Since this is typically not a link local > > > address, you could get a conflict if the HA > > > does not defend all addresses. > > > > The problem is that RFC 3041 should require any > > such node to first acquire rights to the link-local > > address. I hope that is viewed as an omission, and > > one which can be quickly repaired. > > > > Regards, > > Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 10:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHmkrP008199; Fri, 31 May 2002 10:48:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHmkCD008198; Fri, 31 May 2002 10:48: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.3+Sun/8.12.3) with ESMTP id g4VHmbrP008183; Fri, 31 May 2002 10:48:37 -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 KAA13276; Fri, 31 May 2002 10:48:37 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13104; Fri, 31 May 2002 11:48:31 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:48:31 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:48:31 -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); Fri, 31 May 2002 10:48:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:48:30 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIyuf4W9wSnnU1QNyUrroqfIceWwAAAY8g From: "Richard Draves" To: "Charles E. Perkins" Cc: , "IPng Working Group" X-OriginalArrivalTime: 31 May 2002 17:48:31.0196 (UTC) FILETIME=[609B29C0:01C208CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHmcrP008184 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You are basically arguing for DIID (duplicate interface-id detection) instead of DAD (duplicate address detection), by using DAD on the link-local address to perform DIID. It seems strange to me to perform DAD on a link-local address that is not actually being used. For better or worse, it's not the architecture that we have today and I'm not inclined to change it. Rich > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 > optimization. The > > RFC 2462 optimization also can fail with > manually-configured addresses > > - it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local addresses, it > > > > 'owns the interface id' for any other address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local address, you > > > > could get a conflict if the HA does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > address. I hope > > > that is viewed as an omission, and one which can be quickly > > > repaired. > > > > > > Regards, > > > Charlie P. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 10:59:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHx0rP008377; Fri, 31 May 2002 10:59:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHx0CE008376; Fri, 31 May 2002 10:59: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.3+Sun/8.12.3) with ESMTP id g4VHwqrP008361; Fri, 31 May 2002 10:58: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 KAA23704; Fri, 31 May 2002 10:58:52 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09859; Fri, 31 May 2002 10:58:51 -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); Fri, 31 May 2002 10:58:50 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:58:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:58:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:58:46 -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); Fri, 31 May 2002 10:58:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:58:44 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIy0gRI6qnTT2aQOOpG4ZWWiXDIwAAN4Cw From: "Dave Thaler" To: "Charles E. Perkins" , "Richard Draves" Cc: , "IPng Working Group" X-OriginalArrivalTime: 31 May 2002 17:58:46.0685 (UTC) FILETIME=[CF7754D0:01C208CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHwrrP008362 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As mentioned in email I sent a week or two back, this is related to the issue of whether a link-local address has to be unique across an entire subnet, not just a link. Today it's defined as a "link-local" not a "subnet-local" address. This means that it is not guaranteed to be unique across a subnet. Manually configured global addresses don't need to require rights to the corresponding link-local address since a) it's not necessary as they don't use the link-local address, b) it's not sufficient since they need to be unique across the subnet, not just the link. So unless you're proposing we redefine "link-local" addresses as "subnet-local" addresses (which would at least be a consistent argument, albeit a change to the architecture), then what you suggest does not seem to me to be the right solution. -Dave > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > > 2462 optimization also can fail with manually-configured addresses - > > it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local > > > > addresses, it 'owns the interface id' for any other > > > > address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local > > > > address, you could get a conflict if the HA > > > > does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > > > address. I hope that is viewed as an omission, and > > > one which can be quickly repaired. > > > > > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 11:50:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VIoKrP008746; Fri, 31 May 2002 11:50:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VIoKJj008745; Fri, 31 May 2002 11:50: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.3+Sun/8.12.3) with ESMTP id g4VIoHrP008738 for ; Fri, 31 May 2002 11:50:17 -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 LAA06774 for ; Fri, 31 May 2002 11:50:17 -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 MAA02279 for ; Fri, 31 May 2002 12:50:16 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 001106A906; Fri, 31 May 2002 21:50:09 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C06806A905; Fri, 31 May 2002 21:50:07 +0300 (EEST) Message-ID: <3CF7C625.9010708@kolumbus.fi> Date: Fri, 31 May 2002 21:51:17 +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: Robert Elz Cc: itojun@iijlab.net, IPng List Subject: Re: Mandating Route Optimization References: <24554.1022842443@itojun.org> <4451.1022859836@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Fri, 31 May 2002 19:54:03 +0900 > From: itojun@iijlab.net > Message-ID: <24554.1022842443@itojun.org> > > | then we will have two separate set of IPv6 nodes - without mobile-ipv6 > | and with mobile-ipv6, and they cannot even ping each other. > | do you feel it acceptable? > > No, but that means that the way the technical work has been done is > wrong, and it should be fixed so we don't have that problem. As I said > I wasn't commenting on whether what is being offered technically is > adequate or not, I haven't been paying attention to it at all. > > But whether that is correct or not, it certainly can't be the case that > simply changing a MUST to a SHOULD in a doc will fix it. If there's > a problem like that, it will take a more serious fix. Just for the record... the current MIPv6 drafts do not have this problem. A "new" IPv6 node can ping an "old" one and vice versa, even if the older node doesn't implement RO, HAO, or anything related to MIPv6. Sure, the communications would be smoother if both parties used RO and overall the Internet would have to carry less traffic, but nothing breaks horribly if they don't. This is a change from the old versions. Also, draft 16 was the first version that we can think of as being globally deployable for route optimization. This is because the requirement in the old versions about PKI or pre-configured security associations would have, in practice, severely limited the use of RO even if implemented in every node. In conclusion, we are free to a decision in this WG about what to mandate for all IPv6 nodes or for new nodes, as far as interoperability goes. The decision should be based on the technical benefits to the Internet and the nodes themselves and the meaning of keywords as specified in RFC 2119. And, perhaps I'm naive but I'm actually hoping good features sell themselves by being useful. I don't buy the argument that CNs do not care. A CN exists in the Internet because it wants to offer something, such as a news service. It should want to offer this in a manner that its clients get the best possible service, including minimal RTT. Jari P.S. John: I believe the current drafts do describe how to use RO. They even describe how to survive the situation that the peer does not implement RO. So in this respect I don't think we need anything new. See e.g. MN state machine 'WaitHC' state and the ICMP action. Please let us know if something additional is needed. At the moment I don't see it. P.S. Mike: Yes, we do need the administrative disable feature on this. The draft already talks about an automatic disable for situations where the node is under a DoS attack but a manual disable would be necessary as well. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 11:59:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VIx9rP008794; Fri, 31 May 2002 11:59:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VIx9PS008793; Fri, 31 May 2002 11:59: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.3+Sun/8.12.3) with ESMTP id g4VIx5rP008786 for ; Fri, 31 May 2002 11:59:05 -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 LAA21534 for ; Fri, 31 May 2002 11:59:05 -0700 (PDT) Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26026 for ; Fri, 31 May 2002 13:00:06 -0600 (MDT) Received: from us-ea-gtwy-8.ea.unisys.com (us-ea-gtwy-8.ea.unisys.com [192.61.145.108]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id SAA24775; Fri, 31 May 2002 18:57:06 GMT Received: by us-ea-gtwy-8.ea.unisys.com with Internet Mail Service (5.5.2655.55) id ; Fri, 31 May 2002 13:58:48 -0500 Message-ID: <236F133B43F4D211A4B00090273C79DC077BCF8E@us-rv-exch-2.rsvl.unisys.com> From: "Sellers, Julian P" To: "'Charles E. Perkins'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: RFC 2462 DAD optimization Date: Fri, 31 May 2002 13:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, See also the IPng archive from June, 2001. Search for ": DAD". I have not seen a resolution of the issue. Julian > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 12:45 PM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 > optimization. The RFC > > 2462 optimization also can fail with manually-configured addresses - > > it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local > > > > addresses, it 'owns the interface id' for any other > > > > address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local > > > > address, you could get a conflict if the HA > > > > does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > > > address. I hope that is viewed as an omission, and > > > one which can be quickly repaired. > > > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 13:31:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VKVXrP009024; Fri, 31 May 2002 13:31:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VKVXIl009023; Fri, 31 May 2002 13:31: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.3+Sun/8.12.3) with ESMTP id g4VKVTrP009016 for ; Fri, 31 May 2002 13:31: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 NAA04082 for ; Fri, 31 May 2002 13:31:30 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14324 for ; Fri, 31 May 2002 14:32:31 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GWZ00EQMT0F3Q@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 31 May 2002 14:31:29 -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 <0GWZ00E4NT0E20@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 31 May 2002 14:31:27 -0600 (MDT) Date: Fri, 31 May 2002 13:31:26 -0700 From: Alain Durand Subject: Re: Mandating Route Optimization In-reply-to: <2913.1022841116@munnari.OZ.AU> To: Robert Elz Cc: Bob Hinden , IPng List Message-id: <619B03B9-74D5-11D6-8B93-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.481) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, May 31, 2002, at 03:31 AM, Robert Elz wrote: > Date: Thu, 30 May 2002 16:43:50 -0700 > From: Bob Hinden > Message-ID: > <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> > > | It doesn't seem right to make them non-compliant (i.e., make RO a > MUST). > > Bob, that's completely bogus as an argument. I don't know enough about > the issues to comment on the substance, but if RO is something that the > WG feels is important for all nodes to implement, then of course MUST is > the right thing. When a new technology solves a critical problem for the operation of the Internet, it make sense to make it a MUST, regardless of the installed base. The issues here are to know if: a) RO solves a critical problem to the operation of the Internet b) RO is the right approach to the problem. If I can be convinced of a), b) is another story. Years ago, the Home Address option was defined and presented as _the_ thing that will solve _the_ problem. Then we discovered that there were security concerns, and a whole new approach, much more complex is now presented. How confident are we that this time, this is the right thing? Has it been tried in large scale environment? Are we sure it solves enough security concerns that another version of RO will not come next year to fix it? As some said early, there are a number of implementations out there today. It is not that it is not possible to change anything at this point, it is that there is a need for a certain level of confidence that RO, as defined today, is the right thing and will not change. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 13:50:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VKoVrP009059; Fri, 31 May 2002 13:50:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VKoVmf009058; Fri, 31 May 2002 13:50:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VKoRrP009051 for ; Fri, 31 May 2002 13:50:28 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23134; Fri, 31 May 2002 16:50:23 -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 g4VKoM33028444; Fri, 31 May 2002 16:50:22 -0400 (EDT) Message-Id: <200205312050.g4VKoM33028444@thunk.east.sun.com> From: Bill Sommerfeld To: Alain Durand cc: Robert Elz , Bob Hinden , IPng List Subject: Re: Mandating Route Optimization In-Reply-To: Your message of "Fri, 31 May 2002 13:31:26 PDT." <619B03B9-74D5-11D6-8B93-00039376A6AA@sun.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 31 May 2002 16:50:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's another reason why RO needs to be optional: Consider the traffic patterns surrounding a root name server. Properly functioning clients talk to it at most once every two days (the current TTL of root server NS records) per TLD used, and do a single packet exchange per TLD. There would be no point in it ever maintaining a binding cache. On the other hand, I don't see much harm in mandating that hosts be able to politely refuse a binding update request. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 14:05:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VL5LrP009143; Fri, 31 May 2002 14:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VL5LXk009142; Fri, 31 May 2002 14: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VL5IrP009135 for ; Fri, 31 May 2002 14:05:18 -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 OAA07338 for ; Fri, 31 May 2002 14:05:17 -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 PAA13208 for ; Fri, 31 May 2002 15:05:15 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA25443; Fri, 31 May 2002 14:05:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VL5DB26723; Fri, 31 May 2002 14:05:13 -0700 X-mProtect: <200205312105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfRX8uA; Fri, 31 May 2002 14:05:12 PDT Message-ID: <3CF7E588.F8602B84@iprg.nokia.com> Date: Fri, 31 May 2002 14:05:12 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Sommerfeld CC: IPng List Subject: Re: Mandating Route Optimization References: <200205312050.g4VKoM33028444@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Bill, There's a big difference between allowing refusal (which I agree should be possible) and requiring support in the implementation. I can make an analogy between your example and the IPsec mandate. Your example "works", because there aren't any communications that last for very many packets. What if I build a product that ONLY ever supports insecure applications? Should I be allowed to claim IPv6 conformance if my product platform does not have any IPsec implementation? Currently, the answer for IPv6 is "no". But, I reckon the number of nodes that only ever support insecure applications would be a lot more than the number of nodes that only ever support instantaneous, disconnected application streams. Plus, one could even devise semi-rational scenarios where the DNS server needs to support mobility, of course depending on the applications. For remote diagnosis, maybe some (secure!) streaming applications for processed or graphic data would be highly advantageous, and the diagnostician might be mobile at the time... In fact, this doesn't sound at all far fetched to me. Regards, Charlie P. Bill Sommerfeld wrote: > > Here's another reason why RO needs to be optional: > > Consider the traffic patterns surrounding a root name server. > > Properly functioning clients talk to it at most once every two days > (the current TTL of root server NS records) per TLD used, and do a > single packet exchange per TLD. > > There would be no point in it ever maintaining a binding cache. > > On the other hand, I don't see much harm in mandating that hosts be > able to politely refuse a binding update request. > > - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 15:17:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VMHgrP009628; Fri, 31 May 2002 15:17:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VMHg5E009627; Fri, 31 May 2002 15:17:42 -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.3+Sun/8.12.3) with ESMTP id g4VMHdrP009620 for ; Fri, 31 May 2002 15:17:39 -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 PAA06760 for ; Fri, 31 May 2002 15:17:39 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07298 for ; Fri, 31 May 2002 15:17:38 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4VM65Z24658; Fri, 31 May 2002 17:06:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 17:05:51 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03F70409@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Alain Durand Cc: Robert Elz , Bob Hinden , IPng List Subject: RE: Mandating Route Optimization Date: Fri, 31 May 2002 17:05:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C208EF.50053640" 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_01C208EF.50053640 Content-Type: text/plain; charset="iso-8859-1" Alain, Bob and Robert, You bring up some very good points in that it would be very good to detail the case for long-lived addresses where the proposed end to end route optimization provides the intended value. I see only three scenarios that make sense and I have reservations about the proposed end to end solution with each: 1> a person does not wish to disclose their true location to any level of granularity both to snooping parties and to communicating parties. reservation: It is very simple to dump the packets received at a communicating party and use a traceroute on the mobile's COA. The proposed solution gives up route optimization for this location privacy so the excuse for the feature is mute. If a person does not require location privacy then they can dynamically allocate an address from their initial point of attachment and anchored mobility can be used if they go off-domain. In this case the optimization is not that big of an issue. It does save bandwidth over skinny links back to the anchor, though. 2> a mobile router reservation: This just seems very odd to me to have communicating hosts be told the location of every single node attached to such a device especially since the police, defense and clandestine industry is a major customer of such devices. 3> IP VPN reservation: I'm not sure what admins are going to think about putting the security of their networks in the hands of the employee's hosts. There is currently little verbage in the draft about these scenarios. Also the case where there might be a skinny link is this VPN case. So the bandwidth saving argument for scenario 1 falls apart. 4> Every Single Node ever connected to IPv6 has a long lived address or at least a home prefix. reservation: This is a neat idea but due to Moore's law, devices get old and chunked every two years if not sooner. This doesn't seem like a good long term solution even with the expanded address space. Does anyone know of any other cases that make sense short of the PGP security model? I do think route optimization of some sort of standardized and ubiquitous would add significant value and not only in terms of mobility. I'm just not sure if a completely end to end is the answer. I certainly woudn't get bent out of shape if the current proposal was mandated though as I think the ubiquity of the function could be used for other useful purposes than just mobility. Glenn > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Friday, May 31, 2002 3:31 PM > To: Robert Elz > Cc: Bob Hinden; IPng List > Subject: Re: Mandating Route Optimization > > > > On Friday, May 31, 2002, at 03:31 AM, Robert Elz wrote: > > > Date: Thu, 30 May 2002 16:43:50 -0700 > > From: Bob Hinden > > Message-ID: > > <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> > > > > | It doesn't seem right to make them non-compliant (i.e., > make RO a > > MUST). > > > > Bob, that's completely bogus as an argument. I don't know > enough about > > the issues to comment on the substance, but if RO is > something that the > > WG feels is important for all nodes to implement, then of > course MUST is > > the right thing. > > When a new technology solves a critical problem for the operation > of the Internet, it make sense to make it a MUST, regardless of > the installed base. > > The issues here are to know if: > > a) RO solves a critical problem to the operation of the Internet > b) RO is the right approach to the problem. > > If I can be convinced of a), b) is another story. > Years ago, the Home Address option was defined and > presented as _the_ thing that will solve _the_ problem. > Then we discovered that there were security concerns, > and a whole new approach, much more complex is now > presented. > How confident are we that this time, this is the right thing? > Has it been tried in large scale environment? Are we > sure it solves enough security concerns that another > version of RO will not come next year to fix it? > > As some said early, there are a number of implementations > out there today. It is not that it is not possible to change anything > at this point, it is that there is a need for a certain level of > confidence > that RO, as defined today, is the right thing and will not change. > > - 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 > -------------------------------------------------------------------- > ------_=_NextPart_001_01C208EF.50053640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Mandating Route Optimization

Alain, Bob and Robert,

You bring up some very good points in that it would = be very good to detail the case for long-lived addresses where the = proposed end to end route optimization provides the intended value. =

I see only three scenarios that make sense and I have = reservations about the proposed end to end solution with each:

1> a person does not wish to disclose their true = location to any level of granularity both to snooping parties and to = communicating parties.

reservation:    It is very simple to = dump the packets received at a communicating party and use a traceroute = on the mobile's COA. The proposed solution gives up route optimization = for this location privacy so the excuse for the feature is mute. If a = person does not require location privacy then they can dynamically = allocate an address from their  initial point of attachment and = anchored mobility can be used if they go off-domain. In this case the = optimization is not that big of an issue. It does save bandwidth over = skinny links back to the anchor, though.

2> a mobile router

reservation:    This just seems very = odd to me to have communicating hosts be told the location of every = single node attached to such a device especially since the police, = defense and clandestine industry is a major customer of such = devices.

3> IP VPN       =

reservation:    I'm not sure what = admins are going to think about putting the security of their networks = in the hands of the employee's hosts. There is currently little verbage = in the draft about these scenarios. Also the case where there might be = a skinny link is this VPN case. So the bandwidth saving argument for = scenario 1 falls apart. 

4> Every Single Node ever connected to IPv6 has a = long lived address or at least a home prefix.

reservation:    This is a neat idea = but due to Moore's law, devices get old and chunked every two years if = not sooner. This doesn't seem like a good long term solution even with = the expanded address space.

Does anyone know of any other cases that make sense = short of the PGP security model?

I do think route optimization of some sort of = standardized and ubiquitous would add significant value and not only in = terms of mobility. I'm just not sure if a completely end to end is the = answer. I certainly woudn't get bent out of shape if the current = proposal was mandated though as I think the ubiquity of the function = could be used for other useful purposes than just mobility.

Glenn

> -----Original Message-----
> From: Alain Durand [mailto:Alain.Durand@Sun.COM]
> Sent: Friday, May 31, 2002 3:31 PM
> To: Robert Elz
> Cc: Bob Hinden; IPng List
> Subject: Re: Mandating Route = Optimization
>
>
>
> On Friday, May 31, 2002, at 03:31 AM, Robert = Elz wrote:
>
> >     = Date:        Thu, 30 May 2002 = 16:43:50 -0700
> >     = From:        Bob Hinden = <hinden@iprg.nokia.com>
> >     Message-ID:  =
> > = <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com>=
> >
> >   | It doesn't seem right to = make them non-compliant (i.e.,
> make RO a
> > MUST).
> >
> > Bob, that's completely bogus as an = argument.   I don't know
> enough about
> > the issues to comment on the substance, = but if RO is
> something that the
> > WG feels is important for all nodes to = implement, then of
> course MUST is
> > the right thing.
>
> When a new technology solves a critical problem = for the operation
> of the Internet, it make sense to make it a = MUST, regardless of
> the installed base.
>
> The issues here are to know if:
>
> a) RO solves a critical problem to the = operation of the Internet
> b) RO is the right approach to the = problem.
>
> If I can be convinced of a), b) is another = story.
> Years ago, the Home Address option was defined = and
> presented as _the_ thing that will solve _the_ = problem.
> Then we discovered that there were security = concerns,
> and a whole new approach, much more complex is = now
> presented.
> How confident are we that this time, this is = the right thing?
> Has it been tried in large scale environment? = Are we
> sure it solves enough security concerns that = another
> version of RO will not come next year to fix = it?
>
> As some said early, there are a number of = implementations
> out there today. It is not that it is not = possible to change anything
> at this point, it is that there is a need for a = certain level of
> confidence
> that RO, as defined today, is the right thing = and will not change.
>
>       - Alain.
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> ------------------------------------------------= --------------------
>

------_=_NextPart_001_01C208EF.50053640-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 15:49:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VMnRrP009701; Fri, 31 May 2002 15:49:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VMnRLT009700; Fri, 31 May 2002 15:49:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VMnNrP009693 for ; Fri, 31 May 2002 15:49:23 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4VMnN6U565617; Fri, 31 May 2002 15:49:23 -0700 (PDT) Message-Id: <200205312249.g4VMnN6U565617@jurassic.eng.sun.com> Date: Fri, 31 May 2002 15:51:50 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: Mandating Route Optimization To: mat@cisco.com Cc: john.loughney@nokia.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DgnYA4O4UP7P7GfOkK4t8A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't know if this has been mentioned, but > regardless of whether implementation of RO for > CN's is a MUST/SHOULD, there should be text in the > draft that "RO MUST have a means to be > administratively disabled on the CN." > I don't think there is any text in the MIPv6 draft which talks about the disabling and enabling RO functionality. It makes sense to have that text in the draft. As for existing IPv6 nodes that do not support MIPv6 at all and does not recognize "mobility Header", the draft should specify that they should respond with a ICMP PARAM problem. We have discussed that in the mobile-ip mailing list. Irrespective of RO being MUST/SHOULD, non-MIPv6 compliant IPv6 nodes should send ICMP error when it receives a binding update with MIPv6 protocol headers. If the mobile node sees an error from CN for processing BU, then it will continue communication through reverse tunnel path. So, I don't see much issues with incompatibility with existing IPv6 nodes-except they need to upgrade to mipv6-compliant IPv6 node sometime. So, it makes a lot of sense to have mandated and tunable route-optimization for MIPv6 for ipv6 nodes requirements. -Samita > Samita Chakrabarti writes: > > > > > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to > > owner-ipng@sunroof.eng.sun.com using -f > > > From: john.loughney@nokia.com > > > X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 > > > content-class: urn:content-classes:message > > > > > > please be aware of already-deployed IPv6 codebase. WinXP is shipping, > > > > MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. > > > > even home address option (which is a MUST) is changing. > > > > i don't think it a good situation for implementers. > > > > > > I think that this will not be a significant problem - I assume that > > > there will be more IPv6 implementations coming than what what > > > exists already. Of course, the existing implementations may not > > > support Mobile IP and I think that will be something that we have > > > to live with. > > > > > > I agree with John completely. We don't have enough IPv6 deployment > > yet and it's good time to make the decision whether Route Optimization > > should be MUST in MobileIPv6. I think, it makes more sense to have > > Route Optimization a 'MUST' in MobileIPv6 draft now than in future, > > when we might have significant backward compatibility problems. > > > > > > -Samita > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 31 16:06:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VN6YrP009816; Fri, 31 May 2002 16:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VN6Ybo009815; Fri, 31 May 2002 16:06:34 -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.3+Sun/8.12.3) with ESMTP id g4VN6VrP009808 for ; Fri, 31 May 2002 16:06:31 -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 QAA25436 for ; Fri, 31 May 2002 16:06:32 -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 RAA24946 for ; Fri, 31 May 2002 17:07:33 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E3BB76A906; Sat, 1 Jun 2002 02:06:24 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4667C6A905; Sat, 1 Jun 2002 02:06:23 +0300 (EEST) Message-ID: <3CF80234.4000603@kolumbus.fi> Date: Sat, 01 Jun 2002 02:07:32 +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: Samita Chakrabarti Cc: mat@cisco.com, john.loughney@nokia.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <200205312249.g4VMnN6U565617@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Samita Chakrabarti wrote: > As for existing IPv6 nodes that do not support MIPv6 at all > and does not recognize "mobility Header", the draft should > specify that they should respond with a ICMP PARAM problem. RFC 2463 takes care of this. Draft-17 of MIPv6 specifies how to deal with the reception of the resulting ICMP parameter problem in section 11.5.2. > Irrespective of RO being MUST/SHOULD, non-MIPv6 compliant IPv6 > nodes should send ICMP error when it receives a binding > update with MIPv6 protocol headers. > > If the mobile node sees an error from CN for processing BU, then > it will continue communication through reverse tunnel path. > > So, I don't see much issues with incompatibility with existing > IPv6 nodes-except they need to upgrade to mipv6-compliant IPv6 > node sometime. I 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 Fri May 31 20:59:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g513x8rP010417; Fri, 31 May 2002 20:59:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g513x80X010416; Fri, 31 May 2002 20:59: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.3+Sun/8.12.3) with ESMTP id g513x5rP010409 for ; Fri, 31 May 2002 20:59:05 -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 UAA04605 for ; Fri, 31 May 2002 20:59:06 -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 UAA01980 for ; Fri, 31 May 2002 20:59:05 -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 g513xTq19307 for ; Sat, 1 Jun 2002 06:59:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 1 Jun 2002 06:59:04 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 1 Jun 2002 06:59:04 +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: Mandating Route Optimization Date: Sat, 1 Jun 2002 06:59:03 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652E1@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcII1FTSinhjKDTSQAyLXNQDFH7lQgATEL8w To: , Cc: , X-OriginalArrivalTime: 01 Jun 2002 03:59:04.0639 (UTC) FILETIME=[ABD6F4F0:01C20920] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g513x5rP010410 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, > P.S. John: I believe the current drafts do describe how to use RO. > They even describe how to survive the situation that the peer does > not implement RO. So in this respect I don't think we need anything > new. See e.g. MN state machine 'WaitHC' state and the ICMP action. > Please let us know if something additional is needed. At the moment > I don't see it. Good. I have to catch-up on my reading. If that is in the document, I am satisfied. 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 --------------------------------------------------------------------