From owner-v6ops@ops.ietf.org Sat Mar 1 09:34:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05948 for ; Sat, 1 Mar 2003 09:34:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18p82J-0004cU-00 for v6ops-data@psg.com; Sat, 01 Mar 2003 06:32:23 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18p82D-0004cH-00 for v6ops@ops.ietf.org; Sat, 01 Mar 2003 06:32:17 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h21EW3E29628; Sat, 1 Mar 2003 16:32:04 +0200 Date: Sat, 1 Mar 2003 16:32:03 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, 17 Feb 2003, Margaret Wasserman wrote: > This is a WG Last Call for comments on sending the Unmanaged > Networks scenarios document to the IESG for consideration as > an Informational RFC: > > Title: Unmanaged Networks IPv6 Transition Scenarios > Filename: draft-ietf-v6ops-unman-scenarios-00.txt > Authors: C. Huitema, R. Austein, R. van der Pol > Date: January 10, 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt I've re-read the document. It seems good and I agree with the overall approach, but IMO a bit raw yet. As a scenario document, it seems to go a bit further than some might expect (see below) -- is this OK? The biggest (potential) issue: ==> the document goes beyond describing the current IPv4 deployments in several places, like 5.2.1 and 5.4.1; personally, these have typically been "rough solution scoping" -type approaches, and suggestions seem pretty good to me, at least. However, they may or may not be appropriate as is. Is this a sensible approach? Does someone see a process issue here? It's (on a higher level) fine by me, at least. (one approach might be tone down the language in these a bit e.g. in: Our analysis concludes that a tunnel service will be vastly preferable. change to: Our analysis concludes that tunnel service seems to be vastly preferable. =========== Substantial/semi-editorial issues: 2 Topology ==> this section somewhat defines the context of the unmanaged network: should there be an explicit definition of it for the purposes of this doc, and the solutions document (might not be easy)? A particular thing I note that multiple-subnet case seems to be out of scope, or that's the impression I get based on the first paragraph. Deploying servers usually requires providing the servers with a stable DNS name, and associating the global IPv4 address of the nat/firewall with that name. ==> associating with the address of _NAT/firewall_? If there is NAT, that's something that has to be done, yes. ==> So, if there is no NAT, this needs rewording. ==> s/requires/also requires/ (noticed the intent on second read, perhaps this is enough), else: this overlooks the required step that you must also somehow configure a mapping in the NAT/firewall box. 4.1 Requirements of local applications [...] The security of local applications is enhanced if these applications can be effectively isolated from the global Internet. ==> should this "enhancement" be strengthened to a (loose) requirement, or something? Sounds awfully weak to me.. If not, might have a problem with security considerations text. 4.2.1 Privacy requirement of client applications ==> this sub-section should be preceeded by a short paragraph describing why only "privacy" part of "security" was taken into consideration. ==> bigger issue: isn't this text applicable to all cases A-D? Could be placed somewhere else in the document, maybe? Randomization of the host identifier does however provide benefits. First, if some of the hosts in the unmanaged network are mobile, the randomization destroys any correlation between the addresses used at various locations: the addresses alone could not be used to determine whether a given connection originates from the same laptop moving from work to home, or used on the road. ==> this seems rather an issue for mobile computers, not specific for unmanaged networks. Second, the randomization removes any information that could be extracted from a hardwired host identifier; for example, it will prevent outsiders to correlate a serial number with a specific brand of expensive electronic equipment, and to use this information for planning marketing campaigns or possibly burglary attempts. ==> if this is the fear, there may be simpler fixes for the problem, e.g. resetting the MAC-address statically to one picked as locally unique. I think there is even a reserved "private use" range, but can't find it at the moment. 4.4 Requirements of server applications [...] The DNS entries for the server will have to be updated, preferably in real time, if the server's address changes. In practice, updating the DNS is slow, which implies that server applications will have a better chance of being deployed if the IPv6 addresses remain stable for a long period. [...] ==> please consider the context here. Personally, as one who has services on his home PC (acting also as a router), like SSH access, I don't feel absolute smoothness is a requirement. A nice thing to have, surely, but not a requirement. Unmanaged network is *NOT* the place to run critical services, especially if one has a NAT to traverse -- I'm sure we all agree on that. Perhaps this should be clarified slightly somehow. Server applications are also not a primary focus of Case A. Server applications require DNS support, which is difficult to engineer for clients located behind a NAT. ==> "DNS support" should IMO be clarified or elaborated. This is actually not the case, AFAICS. Of course, publishing a DNS update is a problem, but the root cause seems to be configuring the NAT to forward the requests, not the DNS support itself. We also observe that providing both IPv4 and IPv6 connectivity in an unmanaged network is not particularly difficult; indeed there is a well established experience of using IPv4 in these networks in parallel with other protocols such as for example IPX. ==> this seems a bit like comparing apples and oranges: I'm not aware that external IPX connectivity has been provided by the ISP: anything at all can be used locally, but that's not the point. Perhaps the example scenario needs to be worked out a bit? 5.2.2 Addresses and connectivity in Case B In Case B, the upgraded gateway will behave as an IPv6 router; it will continue providing the IPv4 connectivity of a non-upgraded NAT. Nodes in the local network will obtain: (same in 5.3.2) ==> the document assumes that in case B, the NAT is being used. That's not necessarily the case. ==> (editorial: "connectivity of a non-upgraded NAT" needs rewording in any case -- I can only try to guess what it means) 5.2.3 Naming services in Case B At this phase of IPv6 deployment, hosts in the unmanaged domain have access to DNS services through the gateway. As the gateway and the ISP both support IPv4 and IPv6, these services may be accessible by the IPv4 only hosts using IPv4, by the IPv6-only hosts using IPv6, and by the dual stack hosts using either. ==> the first sentence is (almost) always true -- note that IPv6-only host in Case B cannot use DNS services unless they're provided on IPv6 transport. However, you should really elaborate which "DNS services" you refer to. Perhaps in the first line, s/hosts/IPv6-only hosts ... domain also have .../ or the like. The response to a DNS request should not depend of the protocol with which the request is transported: dual-stack hosts may indifferently use IPv4 or IPv6 to contact the local resolver; the choice of IPv4 or IPv6 will be random; the value of the response should not depend of a random event. ==> s/will/may/ -- depends on several factors? There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels provided by the [6TO4] technology, or configured tunnels. Both technologies have advantages and limitations, which will be studied in a companion document. ==> much as I like e.g. 6to4, this should really be reworded slightly, not to advocate any solution. The simplest acceptable fix would be changing it to: There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels, e.g. provided by the [6TO4] technology, or configured tunnels. Both approaches have advantages and limitations, which will be studied in a companion document. .. or even strike the 6to4 part off completely. Any interaction between hosts in the unmanaged network and IPv4 hosts on the Internet will require the provision of some inter-protocol services by the ISP. ==> (and later, even more so) -- one should perhaps add an informative reference to the ISP scenarios document. In a way, unmanaged team gives a suggestion for the long-term ISP transition plan, and that should be more explicit in the text in some way. The loss of IPv4 connectivity has a direct impact on the provision of naming services. An obvious consequence is the gateway will have to be provisioned with the address of a DNS server and with other DNS parameters, and that this provisioning will have to use IPv6 mechanisms. ==> I fail to see why the gateway would *necessarily* have to be configured. Of course, in most cases, it makes a sense to run a caching resolver/forwarder there, but it's not necessary AFAICS. Loss of IPv4 connectivity means that (restricting to the scenario advocated in the document) that the gateway or a host opens an IPv4-in-IPv6 tunnel to the ISP. From there, the DNS services (over v4) could be used directly. 6 Security Considerations Security considerations are discussed as part of the applications' requirements. They include: - the guarantee that local applications are only used locally, - the protection of the privacy of clients - the requirement that peer-to-peer connections are only used by authorized peers. ==> I fear this is a bit on the weakish side for security considerations :-( ==> one particular point that wasn't discussed (much) on the draft or here is the connection between applications and possible firewall rules in IPv6 network at the gateway (consider e.g. p2p apps). But this is a difficult problem.. ==> in particular, one approach in a document like this could be to try to list some security features currently being used in IPv4 unmanaged networks, and try to identify the issues which will need to be tackled now (later). Solutions aren't necessary in this document, but recognizing the changes in assumptions etc. would be very good. This is *especially* important in unmanaged networks, I'm afraid -- as they seem to constitute about the greatest risk for abuse. 11 References [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks, work in progress. ==> References need to be split ;-) (and given in the proper format), but really: more references should be added, even if informative! ================== .. and then for more or less editorial issues .. ==> should you add an informational reference to the latest traditional NAT RFC? (I was triggered to this by section 3.4, before it was simple enough..) ==> section titles must be mainly in uppercase (e.g. Local applications --> Local Applications). ==> The text uses active forms like "We saw [...]" etc. Typically, the passive mode is used, but I guess this is also ok. ==> dual stack vs dual-stack (use one for consistancy), similar with IPv4 only vs IPv4-only and IPv6. ==> s/site local/site-local/g, s/link local/link-local/ (everywhere) Table of Contents: ==> ToC must be up in the beginning, after the abstract, according to the policy. Abstract In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. 1 Introduction In order to evaluate the suitability of transition mechanisms, we need to define the environment or scope in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. ==> Abstract is too terse; it should also include some text on the contents of the memo, not just the background. ==> Abstract/Introduction is out of sync ==> Introduction should (IMO) give some very brief overview of the layout of the draft ("why sections like this?") -- so that the red line does not disappear when reading it. (ISP)connection. Several hosts are connected to the subnet: ==> s/connection/ connection/ ==> s/are/may be/ static policies. There are however many cases in which the gateway ==> s/however/, however,/ of the unmanaged network. Typical examples are the sharing of file ==> s/file/files/ 3.2 Client applications [...] Local applications tend to work correctly in IPv4 unmanaged ==> s/Local/Client/ to-peer" that only involve hosts on the unmanaged network, and the "remote peer-to-peer" that involve both hosts on the unmanaged network and hosts outside the network. ==> s/hosts/host(s)/ -- not sure if this is strictly necessary, though, and whether it improves readibility.. We will only consider here the "remote peer-to-peer" applications ==> s/We will only consider here/Here, we will only consider/ applications are a subset of the "local applications." ==> s/."/"./ ? well identified peers outside the unmanaged network. These ==> s/well identified/well-identified/ ? networks. Examples of a peer-to-peer application would be a video- ==> s/a peer-to-peer application/peer-to-peer applications/ conference over IP, facilitated by a SIP server, or a distributed ==> the SIP abbreviation should probably spelled out here, as used for the first time. 3.4 Server applications Server applications involve running a server in the unmanaged network, for use by other parties outside the network. Examples would be running a web server or an e-mail server on one of the hosts inside the unmanaged network. ==> s/hosts/nodes/ ? (you should be able to run them also on the gateway box, right..?) nat/firewall with that name. Since updating DNS is a management ==> s/nat/NAT/ 4 Application requirements of an IPv6 unmanaged network ==> the intent should be clearer: "Requirements of Applications for IPv6 Unmanaged Networks" vs. "IPv6 Unmanaged Network Requirements for Applications"? I assume the former.. include the provision of IPv6 addresses and their quality: do host ==> s/do/does/ or /host/hosts/ ? Local applications require local connectivity. They must continue working even if the unmanaged network is isolated from the Internet. ==> s/continue working/continue to work/ (sounds much better that way, at least..)? -- the same later in a place or two. We may debate whether the IPv6 networking service should be ==> s/We may debate/It is debatable,/ ? manages a static IPv4 address; in both case, the IPv4 address or the ==> s/case/cases/ Randomization of the host identifier does however provide benefits. ==> s/however/, however,/ ? hardwired host identifier; for example, it will prevent outsiders to correlate a serial number with a specific brand of expensive ==> s/prevent ... to correlate/prevent ... from correlating/ ? all unmanaged network allow use of privacy addresses by those hosts who so choose. ==> s/who so choose/which choose to do so/ which will have to remain stable for the duration of the peer-to- peer between client and server. ==> s/peer-to-peer/peer-to-peer session/ "sip:user@example.com". A peer to peer session typically starts by ==> s/peer to peer/peer-to-peer/ -- for consistancy? (possibly including ISP CPE), the home gateway and the hosts ==> need to spell out CPE when used for the first time? an IPv6 based service; economic reality implies that the cost of ==> s/IPv6 based/IPv6-based/ ? Reverse lookup is hard to provide if the gateway is not upgraded. ==> s/hard/difficult/ well established experience of using IPv4 in these networks in ==> s/well established/well-established/ ? from network connectivity events and network based attacks; however, gateway advertises a site local prefix. This is as debatable: site ==> s/as debatable/debatable/ ? ==> s/network based/network-based/ managing non unique addresses can be problematic if some local hosts ==> s/non unique/non-unique/ To enable this scenario, the gateway need to use a mechanism obtain ==> s/need/needs/, s/obtain/to obtain/ discover the IPv4 address of the local DNS server using DHCP; there ==> s/DNS server/DNS resolver/g (a few times, also under case D) ? variations of domain name delegation. If we want to provide efficient reverse lookup functions, delegation of a fraction of the ip6.arpa tree is also required. ==> use e.g. "If efficient rev.. functions are to be provided, ..." In this case the gateway is IPv6 capable, dual stack, the ISP is not. The gateway has been upgraded and offers both IPv4 and IPv6 connectivity the hosts. ==> s/IPv6 capable/IPv6-capable/ ==> s/the ISP/but the ISP/ ==> s/offers/would be able to offer/ ? The network level protocol translation service appears to not be very desirable. ==> s/.../doesn't appear to be very desirable/ ? Once such addresses have been provided, the gateway effectively acquires dual- stack connectivity; for hosts inside the unmanaged network, this will be indistinguishable from the connectivity obtained in case B or C. ==> need to clarify "connectivity" in the text, because case B/C don't really deal with other than _IPv6_ connectivity: e.g. "IPv4 connectivity", right? of naming services. An obvious consequence is the gateway will have ==> s/is/is that/ -- for clarity through an IPv6 address documented in a AAAA record. However, the ==> s/a AAAA/an AAAA/ (could be used both ways if you pronounce quad-A, I guess) some misc editorial comments I misplaced: In this case the ISP is IPv6-only, so the gateway looses IPv4 connectivity ==> s/loose/lose/ (or change the word ...) At this phase of the transition, IPv6 hosts can perform all types of applications with other IPv6 hosts. IPv4 hosts in the unmanaged network will be able to perform local applications with IPv4 or dual stack local hosts. ==> replace the word "perform" with something else (I can only try to guess what it means..) There are three possible ways that an ISP can provide hosts in the unmanaged network with access to IPv4 application: by using a set of ==> s/application/applications/ ? We also observe that in an IPv6-only ISP the application relays would only be accessible over IPv6, ==> s/ISP/ISP,/ (helps readability even though not required) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Mar 3 08:01:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22568 for ; Mon, 3 Mar 2003 08:01:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ppYW-0004CU-00 for v6ops-data@psg.com; Mon, 03 Mar 2003 05:00:32 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18ppYT-0004C7-00 for v6ops@ops.ietf.org; Mon, 03 Mar 2003 05:00:30 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h23D0Es23708; Mon, 3 Mar 2003 14:00:14 +0100 (CET) Date: Mon, 3 Mar 2003 14:00:14 +0100 From: Ronald van der Pol To: "Bound, Jim" Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Message-ID: <20030303130014.GE22761@rvdp.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B034C07C8@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C07C8@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Feb 17, 2003 at 23:59:42 -0500, Bound, Jim wrote: > I believe this is ready for IESG review. Agreed. rvdp From owner-v6ops@ops.ietf.org Mon Mar 3 08:07:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22951 for ; Mon, 3 Mar 2003 08:07:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ppgd-0004Np-00 for v6ops-data@psg.com; Mon, 03 Mar 2003 05:08:55 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18ppgb-0004Na-00 for v6ops@ops.ietf.org; Mon, 03 Mar 2003 05:08:53 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h23D8mB23737 for v6ops@ops.ietf.org; Mon, 3 Mar 2003 14:08:48 +0100 (CET) Date: Mon, 3 Mar 2003 14:08:48 +0100 From: Ronald van der Pol To: v6ops@ops.ietf.org Subject: draft-huitema-v6ops-unmaneval-00.txt Message-ID: <20030303130848.GF22761@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.9 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk "Evaluation of Transition Mechanisms for Unmanaged Networks" is available now as: http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt Comments welcome. rvdp From owner-v6ops@ops.ietf.org Mon Mar 3 09:05:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26130 for ; Mon, 3 Mar 2003 09:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pqZh-0006V0-00 for v6ops-data@psg.com; Mon, 03 Mar 2003 06:05:49 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18pqZd-0006Un-00 for v6ops@ops.ietf.org; Mon, 03 Mar 2003 06:05:45 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h23E5aA24002; Mon, 3 Mar 2003 15:05:36 +0100 (CET) Date: Mon, 3 Mar 2003 15:05:36 +0100 From: Ronald van der Pol To: Pekka Savola Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <20030303140536.GG22761@rvdp.org> References: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Mar 01, 2003 at 16:32:03 +0200, Pekka Savola wrote: > The biggest (potential) issue: > > ==> the document goes beyond describing the current IPv4 deployments in > several places, like 5.2.1 and 5.4.1; personally, these have typically > been "rough solution scoping" -type approaches, and suggestions seem > pretty good to me, at least. > > However, they may or may not be appropriate as is. > > Is this a sensible approach? Does someone see a process issue here? > It's (on a higher level) fine by me, at least. I think you are right that ideally the scenario drafts should not do analyses. But I think making some choices to limit the analysis draft is not too bad. > (one approach might be tone down the language in these a bit e.g. in: > > Our analysis concludes that a tunnel service will be vastly preferable. > > change to: > > Our analysis concludes that tunnel service seems to be vastly preferable. I guess we could do that. > A particular thing I note that multiple-subnet case seems to be > out of scope, or that's the impression I get based on the first paragraph. We have been discussing multiple-subnet cases internally, especially an 802.11b router connected to a home LAN behind a SOHO router to the ISP. In the IPv4 case this usually is a NAT behind a NAT :-( > Deploying servers usually requires providing the servers with a > stable DNS name, and associating the global IPv4 address of the > nat/firewall with that name. > > ==> associating with the address of _NAT/firewall_? If there is NAT, > that's something that has to be done, yes. > > ==> So, if there is no NAT, this needs rewording. True. > 4.2.1 Privacy requirement of client applications > > ==> this sub-section should be preceeded by a short paragraph describing > why only "privacy" part of "security" was taken into consideration. It said security first, but than some in the design team noted that it was more about privacy than security :-) > ==> bigger issue: isn't this text applicable to all cases A-D? Could be > placed somewhere else in the document, maybe? It already is. Section 4 is not specific to one scenario, but to all. > Randomization of the host identifier does however provide benefits. > First, if some of the hosts in the unmanaged network are mobile, the > randomization destroys any correlation between the addresses used at > various locations: the addresses alone could not be used to > determine whether a given connection originates from the same laptop > moving from work to home, or used on the road. > > ==> this seems rather an issue for mobile computers, not specific for > unmanaged networks. True. > 4.4 Requirements of server applications > [...] > The DNS entries for the server will have to be updated, preferably > in real time, if the server's address changes. In practice, updating > the DNS is slow, which implies that server applications will have a > better chance of being deployed if the IPv6 addresses remain stable > for a long period. > [...] > > ==> please consider the context here. Personally, as one who has services > on his home PC (acting also as a router), like SSH access, I don't feel > absolute smoothness is a requirement. A nice thing to have, surely, but > not a requirement. Unmanaged network is *NOT* the place to run critical > services, especially if one has a NAT to traverse -- I'm sure we all agree > on that. I don't think it's about smoothness, but about stability. You want the server to have a stable (over a long time) IPv6 address. And I think services are important for unmanaged networks. Think about all kinds of IPv6 appliances in a home that one can reach from anywhere. > Server applications are also not a primary focus of Case A. Server > applications require DNS support, which is difficult to engineer for > clients located behind a NAT. > > ==> "DNS support" should IMO be clarified or elaborated. This is > actually not the case, AFAICS. Of course, publishing a DNS update is a > problem, but the root cause seems to be configuring the NAT to forward the > requests, not the DNS support itself. OK, I guess you can read it in different ways. But is says "is difficult to engineer" and I think that is the main point. > 5.2.2 Addresses and connectivity in Case B > > In Case B, the upgraded gateway will behave as an IPv6 router; it > will continue providing the IPv4 connectivity of a non-upgraded NAT. > Nodes in the local network will obtain: > > (same in 5.3.2) > > ==> the document assumes that in case B, the NAT is being used. That's > not necessarily the case. True, but in the scenario drafts we try to describe the most common cases. And unfortunatly, it seems NATs are very common. > ==> (editorial: "connectivity of a non-upgraded NAT" needs rewording in > any case -- I can only try to guess what it means) OK. > Any interaction between > hosts in the unmanaged network and IPv4 hosts on the Internet will > require the provision of some inter-protocol services by the ISP. > > ==> (and later, even more so) -- one should perhaps add an informative > reference to the ISP scenarios document. In a way, unmanaged team gives a > suggestion for the long-term ISP transition plan, and that should be more > explicit in the text in some way. OK. Thanks for your comments. rvdp From owner-v6ops@ops.ietf.org Tue Mar 4 06:21:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12738 for ; Tue, 4 Mar 2003 06:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qATa-000Fxb-00 for v6ops-data@psg.com; Tue, 04 Mar 2003 03:20:50 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18qATX-000FxP-00 for v6ops@ops.ietf.org; Tue, 04 Mar 2003 03:20:47 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h24BJZO28633; Tue, 4 Mar 2003 13:19:35 +0200 Date: Tue, 4 Mar 2003 13:19:34 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: Margaret Wasserman , Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <20030303140536.GG22761@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Commenting only to left-overs.. On Mon, 3 Mar 2003, Ronald van der Pol wrote: > > A particular thing I note that multiple-subnet case seems to be > > out of scope, or that's the impression I get based on the first paragraph. > > We have been discussing multiple-subnet cases internally, especially an > 802.11b router connected to a home LAN behind a SOHO router to the ISP. > In the IPv4 case this usually is a NAT behind a NAT :-( The best in this case might be to deploy the 801.11b router to act as a bridge. But in any case, the scenarios document should be clearer on what is considered "in scope" for the unmanaged networks. > > 4.2.1 Privacy requirement of client applications > > > > ==> this sub-section should be preceeded by a short paragraph describing > > why only "privacy" part of "security" was taken into consideration. > > It said security first, but than some in the design team noted that it > was more about privacy than security :-) Yes, I agree it's better to have a title corresponding to the text, but even better would be having multiple titles or justification why other parts of security weren't elaborated at that length. > > ==> bigger issue: isn't this text applicable to all cases A-D? Could be > > placed somewhere else in the document, maybe? > > It already is. Section 4 is not specific to one scenario, but to all. Oh ok, missed that. > > 4.4 Requirements of server applications > > [...] > > The DNS entries for the server will have to be updated, preferably > > in real time, if the server's address changes. In practice, updating > > the DNS is slow, which implies that server applications will have a > > better chance of being deployed if the IPv6 addresses remain stable > > for a long period. > > [...] > > > > ==> please consider the context here. Personally, as one who has services > > on his home PC (acting also as a router), like SSH access, I don't feel > > absolute smoothness is a requirement. A nice thing to have, surely, but > > not a requirement. Unmanaged network is *NOT* the place to run critical > > services, especially if one has a NAT to traverse -- I'm sure we all agree > > on that. > > I don't think it's about smoothness, but about stability. You want the > server to have a stable (over a long time) IPv6 address. And I think > services are important for unmanaged networks. Think about all kinds of > IPv6 appliances in a home that one can reach from anywhere. Yes, I very much like to see IPv6 appliances and connectivity in place. What I was trying to get at with the comment was that the so-called "connection survivability" or "DNS with zero TTL" should not be a problem in the unmanaged networks. It's nice to have a stable IPv6 address, but one can survive with a downtime of a few hours, even a day (e.g. a delay in updating the DNS, DNS record lifetimes) -- which might not be acceptable in e.g. enterprise networks. > > Server applications are also not a primary focus of Case A. Server > > applications require DNS support, which is difficult to engineer for > > clients located behind a NAT. > > > > ==> "DNS support" should IMO be clarified or elaborated. This is > > actually not the case, AFAICS. Of course, publishing a DNS update is a > > problem, but the root cause seems to be configuring the NAT to forward the > > requests, not the DNS support itself. > > OK, I guess you can read it in different ways. But is says "is difficult > to engineer" and I think that is the main point. To me "difficult to engineer" doesn't really tell much, because I want to see some answer to the "why is it difficult to engineer?" as the answer is not obvious (or different people have different opinions on why exactly it's difficult). > > 5.2.2 Addresses and connectivity in Case B > > > > In Case B, the upgraded gateway will behave as an IPv6 router; it > > will continue providing the IPv4 connectivity of a non-upgraded NAT. > > Nodes in the local network will obtain: > > > > (same in 5.3.2) > > > > ==> the document assumes that in case B, the NAT is being used. That's > > not necessarily the case. > > True, but in the scenario drafts we try to describe the most common cases. > And unfortunatly, it seems NATs are very common. In some places, they are; in some others, they might not be. Unless it's very painful, I'd try to cover both cases at least in some detail (so that folks who are *not* harmed by NAT's at that particular place don't throw the scenarios document out of the window as irrelevant). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 4 10:07:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25780 for ; Tue, 4 Mar 2003 10:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qDzi-000291-00 for v6ops-data@psg.com; Tue, 04 Mar 2003 07:06:14 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18qDzf-00028l-00 for v6ops@ops.ietf.org; Tue, 04 Mar 2003 07:06:12 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h24F69d30659 for ; Tue, 4 Mar 2003 17:06:09 +0200 Date: Tue, 4 Mar 2003 17:06:08 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: IPv6 firewalling draft updated (bonus: IPv6-specific DoS attack) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've updated my "IPv6 Firewalling Considerations" draft, and it will be available in the repositories before the meeting. In the mean time, it can be found at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling-01.txt As a sugar on top to encourage you folks to read it, I've added (in an appendix) an IPv6-specific DoS reflection attack (with amplification) involving multicast. I hope that's enough to make folks read & comment ;-) Abstract: There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 4 12:33:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02801 for ; Tue, 4 Mar 2003 12:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qGId-000CN0-00 for v6ops-data@psg.com; Tue, 04 Mar 2003 09:33:55 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 18qGIb-000CMo-00 for v6ops@ops.ietf.org; Tue, 04 Mar 2003 09:33:53 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 4 Mar 2003 09:33:52 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Mar 2003 09:33:51 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 4 Mar 2003 09:33:53 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 4 Mar 2003 09:33:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 4 Mar 2003 09:33:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Tue, 4 Mar 2003 09:33:48 -0800 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLiQqBbFTqD+hkGRumiNfoh0dliHwAMSnoQ From: "Christian Huitema" To: "Pekka Savola" , "Ronald van der Pol" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 04 Mar 2003 17:33:41.0106 (UTC) FILETIME=[327EF520:01C2E274] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02801 > On Mon, 3 Mar 2003, Ronald van der Pol wrote: > > > A particular thing I note that multiple-subnet case seems to be > > > out of scope, or that's the impression I get based on the first > paragraph. > > > > We have been discussing multiple-subnet cases internally, especially an > > 802.11b router connected to a home LAN behind a SOHO router to the ISP. > > In the IPv4 case this usually is a NAT behind a NAT :-( > > The best in this case might be to deploy the 801.11b router to act as a > bridge. > > But in any case, the scenarios document should be clearer on what is > considered "in scope" for the unmanaged networks. The issue was debated in the working group, in particular during the WG meeting in Atlanta. There was a very strong consensus to restrict the scope of our work to "single link subnets". I don't believe it is appropriate to revisit that decision right now. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Mar 5 04:23:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22532 for ; Wed, 5 Mar 2003 04:23:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qV7m-0000Ly-00 for v6ops-data@psg.com; Wed, 05 Mar 2003 01:23:42 -0800 Received: from tms002bb.han.telia.se ([131.115.230.133]) by psg.com with esmtp (Exim 3.36 #1) id 18qV7i-0000L0-00 for v6ops@ops.ietf.org; Wed, 05 Mar 2003 01:23:38 -0800 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Mar 2003 10:23:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: ISP team changes Date: Wed, 5 Mar 2003 10:23:35 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE837CF0E@TMS031MB.tcad.telia.se> Thread-Topic: ISP team changes Thread-Index: AcLi+OSw6lHvEtH/Rey9UiJxC2GUbg== From: To: X-OriginalArrivalTime: 05 Mar 2003 09:23:36.0083 (UTC) FILETIME=[E6264630:01C2E2F8] X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA22532 Hi all, As you might know there have been some changes in the ISP team recently. I, Mikael Lind, have taken over as editor and we have a new addition to the team, Jordi Palet. Thanks to Jordi we now also have a mailing list, isp@v6ops.euro6ix.net, with an archive that can be found together with other relevant information at http://www.v6ops.euro6ix.net/isp.php If there is some one who wants to contribute the ISP drafts please let us know, if not we are looking forward to your usual feedback. Regards, Mikael Lind From owner-v6ops@ops.ietf.org Wed Mar 5 11:11:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09543 for ; Wed, 5 Mar 2003 11:11:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbSd-000K1o-00 for v6ops-data@psg.com; Wed, 05 Mar 2003 08:09:39 -0800 Received: from proxy1.addr.com ([209.249.147.28]) by psg.com with esmtp (Exim 3.36 #1) id 18qbSX-000K1S-00 for v6ops@ops.ietf.org; Wed, 05 Mar 2003 08:09:33 -0800 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h25G9Ese069994; Wed, 5 Mar 2003 08:09:17 -0800 (PST) Message-Id: <5.2.0.9.0.20030305080441.024f57b8@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 08:09:12 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: draft agenda for v6ops San Francisco Cc: Margaret Wasserman , Jun-ichiro itojun Hagino , Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.7 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folk, The almost final agenda for v6ops is below. Please send me any corrections or suggestions for additions. Thanks, Bob === v6ops agenda status of v6ops projects - chairs, 10 mins 3G Analysis draft - Wiljakka, 20 mins UNMAN analysis draft - Huitema, 20 mins ISP Scenarios - Lind, 10 mins Enterprise Scenarios - Pouffary, 20 mins IPv4 Survey draft restructuring - Nesser or chairs, 10 mins Introduction Application area General area Operations & Management area Internet area Routing area Security area Sub-IP area Transport area Mech draft - Nordmark, 15 mins Translation Issues - van der Poel, 15 mins Translation Issues - Durand, 15 mins -end From owner-v6ops@ops.ietf.org Wed Mar 5 22:36:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11603 for ; Wed, 5 Mar 2003 22:36:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qmA4-0001ti-00 for v6ops-data@psg.com; Wed, 05 Mar 2003 19:35:12 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18qmA0-0001tV-00 for v6ops@ops.ietf.org; Wed, 05 Mar 2003 19:35:09 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA18710; Wed, 5 Mar 2003 19:35:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Mar 2003 22:33:55 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Document Review: Volunteers Needed Cc: Bob Fink , Itojun Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, The recent poor response to our document last calls (2 comments for one document, 4 comments for the other) is insufficient to justify advancing these documents to the IESG. Before we advance these document, or any documents, to the IESG, we want to be certain that they have been reviewed by a significant number of people representing a cross-section of areas of expertise. In an effort to fix this problem, Bob, Itojun and I are considering forming a semi-official v6ops document review team. This team would consist of people who are willing to spend a couple of hours reviewing and commenting on v6ops documents at each stage of the process -- WG acceptance, major intermediate revisions, WG last call(s), revisions to address IESG comments, etc. The review team would be chosen from a pool of volunteers to represent a broad range of knowledge and expertise, and members would be removed if they are too frequently non-responsive. All review comments would be sent to the list, and treated like any individual comments. Like most new processes, we don't know exactly how this would work, and there will probably be bugs to work out over time... But, we strongly feel that we have to do something to ensure that our documents are well reviewed before they are accepted by the WG and/or advanced to the IESG. We also hope that our efforts may serve as a useful model for improvements in this area throughout the IETF. What does the WG think about this idea? If you think that this is a good idea, how could we give credit to this team? Perhaps list them on the v6ops alternate web-site, and list them as "technical reviewers" in the acknowledgements section of our published documents? Who would be willing to volunteer for this type of role? Thanks, Margaret From owner-v6ops@ops.ietf.org Thu Mar 6 01:36:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14776 for ; Thu, 6 Mar 2003 01:36:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qozv-000NIe-00 for v6ops-data@psg.com; Wed, 05 Mar 2003 22:36:55 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18qozs-000NF2-00 for v6ops@ops.ietf.org; Wed, 05 Mar 2003 22:36:53 -0800 Received: from consulintel02 ([127.0.0.1]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 06 Mar 2003 07:38:57 +0100 Message-ID: <01a501c2e3ab$0ee77dc0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Subject: Re: Document Review: Volunteers Needed Date: Thu, 6 Mar 2003 07:38:54 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 127.0.0.1 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, it could work, and I will be happy to volunteer and participate. Regards, Jordi ----- Original Message ----- From: "Margaret Wasserman" To: Cc: "Bob Fink" ; "Itojun" Sent: Thursday, March 06, 2003 4:33 AM Subject: Document Review: Volunteers Needed > > Hi All, > > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. > > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by > a significant number of people representing a cross-section > of areas of expertise. > > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. > > This team would consist of people who are willing to spend a > couple of hours reviewing and commenting on v6ops documents at > each stage of the process -- WG acceptance, major intermediate > revisions, WG last call(s), revisions to address IESG comments, > etc. > > The review team would be chosen from a pool of volunteers to > represent a broad range of knowledge and expertise, and members > would be removed if they are too frequently non-responsive. All > review comments would be sent to the list, and treated like any > individual comments. > > Like most new processes, we don't know exactly how this > would work, and there will probably be bugs to work out > over time... But, we strongly feel that we have to do > something to ensure that our documents are well reviewed > before they are accepted by the WG and/or advanced to the > IESG. We also hope that our efforts may serve as a useful > model for improvements in this area throughout the IETF. > > What does the WG think about this idea? > > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? > > Who would be willing to volunteer for this type of role? > > Thanks, > Margaret > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Thu Mar 6 03:28:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28148 for ; Thu, 6 Mar 2003 03:28:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qqkU-0007me-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 00:29:06 -0800 Received: from [193.72.156.161] (helo=mercury.telscom.ch) by psg.com with esmtp (Exim 3.36 #1) id 18qqkQ-0007mG-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 00:29:03 -0800 Received: from ming (193.72.156.76) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-2621446) for ; Thu, 6 Mar 2003 09:26:05 +0100 From: "Marcin Michalak" Organization: Telscom To: Date: Thu, 06 Mar 2003 09:29:41 +0100 MIME-Version: 1.0 Subject: Re: Document Review: Volunteers Needed Message-ID: <3E671505.23399.C3E32@localhost> In-reply-to: <01a501c2e3ab$0ee77dc0$8700000a@consulintel.es> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Reply-To: marcin@telscom.ch X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 6 Mar 2003 at 7:38, JORDI PALET MARTINEZ wrote: > Yes, it could work, and I will be happy to volunteer and participate. > > Regards, > Jordi Me too :-) I've been working with some IPv6 projects already (NGN- LAB, 6NET, Eurov6, now Euro6IX) and would be happy to contribute. Marcin ---------------------------------------------------------- Marcin Michalak Research Engineer Mobile: +41 79 330 83 51 Telscom AG From owner-v6ops@ops.ietf.org Thu Mar 6 03:59:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28802 for ; Thu, 6 Mar 2003 03:59:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qrEo-0008h9-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 01:00:26 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18qrEm-0008gx-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 01:00:24 -0800 Received: from OLVERA01 ([10.0.0.67]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 06 Mar 2003 10:02:29 +0100 Message-ID: <007501c2e3bf$1d584ce0$4300000a@consulintel.es> Reply-To: =?iso-8859-1?Q?C=E9sar_Olvera_Morales?= From: =?iso-8859-1?Q?C=E9sar_Olvera_Morales?= To: References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Subject: Re: Document Review: Volunteers Needed Date: Thu, 6 Mar 2003 10:01:31 +0100 Organization: Consulintel, s.l. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 10.0.0.67 X-Return-Path: cesar.olvera@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I'm working with Jordi Palet, and I would like to participate in this effort. Regards, Csar Olvera Consulintel ----- Original Message ----- From: "Margaret Wasserman" To: Cc: "Bob Fink" ; "Itojun" Sent: Thursday, March 06, 2003 4:33 AM Subject: Document Review: Volunteers Needed > > Hi All, > > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. > > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by > a significant number of people representing a cross-section > of areas of expertise. > > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. > > This team would consist of people who are willing to spend a > couple of hours reviewing and commenting on v6ops documents at > each stage of the process -- WG acceptance, major intermediate > revisions, WG last call(s), revisions to address IESG comments, > etc. > > The review team would be chosen from a pool of volunteers to > represent a broad range of knowledge and expertise, and members > would be removed if they are too frequently non-responsive. All > review comments would be sent to the list, and treated like any > individual comments. > > Like most new processes, we don't know exactly how this > would work, and there will probably be bugs to work out > over time... But, we strongly feel that we have to do > something to ensure that our documents are well reviewed > before they are accepted by the WG and/or advanced to the > IESG. We also hope that our efforts may serve as a useful > model for improvements in this area throughout the IETF. > > What does the WG think about this idea? > > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? > > Who would be willing to volunteer for this type of role? > > Thanks, > Margaret > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Thu Mar 6 04:21:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29321 for ; Thu, 6 Mar 2003 04:21:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qrb7-0009OH-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 01:23:29 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 18qrb5-0009O5-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 01:23:27 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h269M5125926 for ; Thu, 6 Mar 2003 11:22:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 11:23:24 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 11:23:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 11:23:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Document Review: Volunteers Needed Date: Thu, 6 Mar 2003 11:23:23 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F01906F23@esebe005.ntc.nokia.com> Thread-Topic: Document Review: Volunteers Needed Thread-Index: AcLjk7ymoBEXeO3QRyWV4EeEkPFO6QALeZrA From: To: , Cc: , X-OriginalArrivalTime: 06 Mar 2003 09:23:23.0981 (UTC) FILETIME=[095967D0:01C2E3C2] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29321 Hello, I could also use a couple of hours my time for that. Cheers, -Juha W.- -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: 06 March, 2003 05:34 The review team would be chosen from a pool of volunteers to represent a broad range of knowledge and expertise, and members would be removed if they are too frequently non-responsive. All review comments would be sent to the list, and treated like any individual comments. Who would be willing to volunteer for this type of role? Thanks, Margaret From owner-v6ops@ops.ietf.org Thu Mar 6 05:24:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00951 for ; Thu, 6 Mar 2003 05:24:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qsYd-000BBH-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 02:24:59 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18qsYa-000BB4-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 02:24:57 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26AOnc15133; Thu, 6 Mar 2003 12:24:49 +0200 Date: Thu, 6 Mar 2003 12:24:49 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: v6ops@ops.ietf.org, Bob Fink , Itojun Subject: Re: Document Review: Volunteers Needed In-Reply-To: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk See a few comments below. On Wed, 5 Mar 2003, Margaret Wasserman wrote: > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. Good. > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by > a significant number of people representing a cross-section > of areas of expertise. This doesn't, I think, guarantee a representation of a cross-section of areas of expertise, unless you're very focused when gathering the team to see which kind of expertise they represent (more or less). Just gathering up folks is likely to equal "some" expertise, with purposely vague definition of "some". > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? Credit is the only "reward" (in addition to Getting Better Internet) to those folks who do work at the IETF based on its original values (and not because they're paid to do it, get bonuses for pushing through drafts, advocate their employer's ideas etc.), so I think it is a must in one way or another. Depending on the size of "review board", it could be listed on the web page and the drafts. The size of a board like this should be 5-10 (10 at most) persons. Remember, the point (at least to me, as I understood it) is to do expert review on drafts, not substituting "WG review" (by including everyone who occasionally reads the drafts). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Mar 6 06:29:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03543 for ; Thu, 6 Mar 2003 06:29:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qta1-000DI7-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 03:30:29 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qtZx-000DHn-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 03:30:25 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03174; Thu, 6 Mar 2003 06:28:20 -0500 (EST) Message-Id: <200303061128.GAA03174@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-02.txt Date: Thu, 06 Mar 2003 06:28:19 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-02.txt Pages : 20 Date : 2003-3-5 This document analyzes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-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-v6ops-3gpp-analysis-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-v6ops-3gpp-analysis-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: <2003-3-5141105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5141105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Mar 6 06:39:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04633 for ; Thu, 6 Mar 2003 06:39:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qtji-000De1-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 03:40:30 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18qtje-000Dd6-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 03:40:26 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26BhiF00318 for ; Thu, 6 Mar 2003 13:43:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Mar 2003 13:40:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:40:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-02.txt Date: Thu, 6 Mar 2003 13:40:24 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F01906F2C@esebe005.ntc.nokia.com> Thread-Topic: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-02.txt Thread-Index: AcLj1GQidsZ3ABhTS06v8rgElP347QAAGzaw From: To: X-OriginalArrivalTime: 06 Mar 2003 11:40:24.0182 (UTC) FILETIME=[2CF88960:01C2E3D5] X-Spam-Status: No, hits=3.9 required=5.0 tests=NO_REAL_NAME,SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04633 Hi all! A new revision with minor edits is now published. Comments are welcome (as always)! Cheers, -Juha W.- -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 06 March, 2003 13:28 Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-02.txt Pages : 20 Date : 2003-3-5 This document analyzes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-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-v6ops-3gpp-analysis-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-v6ops-3gpp-analysis-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. From owner-v6ops@ops.ietf.org Thu Mar 6 06:47:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05502 for ; Thu, 6 Mar 2003 06:47:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qtsO-000E3s-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 03:49:28 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 18qtsM-000E3g-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 03:49:26 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Bm5108984 for ; Thu, 6 Mar 2003 13:48:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Mar 2003 13:49:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:49:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Call for Papers: 2003 IEEE Workshop on IP Operations and Management Date: Thu, 6 Mar 2003 13:49:23 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC37F7@esebe005.ntc.nokia.com> Thread-Topic: Call for Papers: 2003 IEEE Workshop on IP Operations and Management Thread-Index: AcLj1m40BmdCz+wbR+e1Kuo5rov8Rw== X-Priority: 5 Importance: low From: To: X-OriginalArrivalTime: 06 Mar 2003 11:49:24.0017 (UTC) FILETIME=[6EBCD210:01C2E3D6] X-Spam-Status: No, hits=3.1 required=5.0 tests=NO_REAL_NAME,PRIORITY_NO_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05502 Hi all! Firstly, sorry for spamming if you have already received information on this workshop: http://CoNReL.sice.umkc.edu/ipom2003/index.html This workshop will include presentations based on original research in the area of Operations and Management of IP networks, spanning from current to future infrastructure. Several tutorials and panels will also be included as part of this workshop. The intent of the workshop is to bring together researchers and practitioners from academia and industry to address current and future issues that face operations and management of IP-oriented networks. Original papers are invited in the following areas (but not limited to): - Network Monitoring and Measurement of IP networks - Day-to-Day Operations of IP networks - Traffic Modeling, Analysis and Engineering for IP networks - Network Planning and Design - Intra-/Inter-Domain Routing Policy Issues and Management - SNMP - Interworking Operations and Management of IP over SONET/SDH or WDM networks - Security Management in IP Networks - Complexity Issues in Large-Scale IP Network Management - Wireless IP network deployment and Management Issues - Management Complexity of IPv4 and IPv6 interworking - IPv4-to-IPv6 transition/migration process - Managed Services on IP networks (e.g., IP-VPN, QoS, VoIP) - Enterprise IP network Management - Grid Management - Case Studies Paper Submission Deadline: March 31, 2003. Notification of Acceptance: June 15, 2003. Final Versions Due: July 15, 2003. Best Regards, -Juha W.- From owner-v6ops@ops.ietf.org Thu Mar 6 07:32:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08963 for ; Thu, 6 Mar 2003 07:32:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18quY9-000FbT-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 04:32:37 -0800 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 18quY6-000FbC-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 04:32:34 -0800 Received: (cpmta 16510 invoked from network); 6 Mar 2003 04:32:33 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 6 Mar 2003 04:32:33 -0800 X-Sent: 6 Mar 2003 12:32:33 GMT Message-ID: <01f201c2e3dc$a4d52ea0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: "Margaret Wasserman" , References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> <5.1.0.14.2.20030306071258.031d7990@mail.windriver.com> Subject: Re: Document Review: Volunteers Needed Date: Thu, 6 Mar 2003 14:33:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First, Sorry I missed sending this to everyone. >> is my comments > are Margret's responses ----- Original Message ----- From: "Margaret Wasserman" To: "EricLKlein" Sent: Thursday, March 06, 2003 2:21 PM Subject: Re: Document Review: Volunteers Needed > > Hi Eric, > > At 08:56 AM 3/6/2003 +0200, EricLKlein wrote: > >Although I think this idea is good, I think that they should still be > >published to the whole list so that others can still offer their input where > >appropriate. > > Absolutely! I think we have to keep several goals in mind: > > 1. Improve the quality and timeliness of review > that documents are getting. > 2. Don't reduce openness and/or the amount of > information sent to the list. That's why > I specified that all review comments (and > I should have said public document revisions) > will continue to be sent to the WG mailing > list. It is not our intention to create > a private sub-working group, just a group of > people who have agreed to be accountable for > doing good, timely reviews of our documents. > 3. Treat comments from all WG participants with > the same weight as comments from semi-official > reviewers. (although frequent non-official > reviewers may get arm-twisted to volunteer :-)). > > The whole point is to get more consistent, timely and credible > review of these documents -- not to do anything that will cut > down on WG openness, or the review feedback that we're already > getting. > > >So I would make it a two part review: > >Part 1 would be the review team and part 2 would be general comments. > > Yes, but I'd like to see both parts happen in parallel, not in > sequence. (I realize that you didn't imply a sequencing). > > Margaret With all taht Margaret sid in response to my comments, I agree and would be willing to review. Eric From owner-v6ops@ops.ietf.org Thu Mar 6 08:05:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11266 for ; Thu, 6 Mar 2003 08:05:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qv4V-000GuH-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 05:06:03 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18qv4S-000Gu4-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 05:06:00 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA18350; Thu, 6 Mar 2003 05:05:44 -0800 (PST) Message-Id: <5.1.0.14.2.20030306075438.02d60f88@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Mar 2003 07:59:08 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: Document Review: Volunteers Needed Cc: v6ops@ops.ietf.org, Bob Fink , Itojun In-Reply-To: References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > > Before we advance these document, or any documents, to the > > IESG, we want to be certain that they have been reviewed by > > a significant number of people representing a cross-section > > of areas of expertise. > >This doesn't, I think, guarantee a representation of a cross-section of >areas of expertise, unless you're very focused when gathering the team to >see which kind of expertise they represent (more or less). I agree. We will need to ask people what their areas of expertise actually are, and we may need to recruit for other areas. Of course, I'm not even sure what the "areas" are that we need covered... This will probably take some successive approximation over time. >Just gathering up folks is likely to equal "some" expertise, with >purposely vague definition of "some". True. Once we have a list of volunteers, have determine their areas of expertise, and have selected a subset (based on past review responsiveness, expertise, etc.), we will probably have to actively recruit for some uncovered areas. >Depending on the size of "review board", it could be listed on the web >page and the drafts. > >The size of a board like this should be 5-10 (10 at most) persons. > >Remember, the point (at least to me, as I understood it) is to do expert >review on drafts, not substituting "WG review" (by including everyone who >occasionally reads the drafts). I agree. The exact number may depend on what areas of expertise we determine we need, and how many folks it takes to cover them. I'd like to have a small enough group that it is easy for me, Bob and Itojun to keep track of who has/hasn't returned comments, but a large enough group to represent a solid, cross-functional review. Margaret From owner-v6ops@ops.ietf.org Thu Mar 6 18:42:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19531 for ; Thu, 6 Mar 2003 18:42:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18r4yB-000HMW-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 15:40:11 -0800 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18r4y9-000HLv-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 15:40:09 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 54CDB7AB6; Fri, 7 Mar 2003 00:40:02 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4EEBB77F4; Fri, 7 Mar 2003 00:39:53 +0100 (CET) From: "Jeroen Massar" To: , <6bone-admin@mailman.isi.edu>, Subject: [announce] GRH Distributed Looking Glass Date: Fri, 7 Mar 2003 00:40:36 +0100 Organization: Unfix Message-ID: <002c01c2e439$cbf90a80$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=0.6 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As the Ghost Route Hunter tool (*1) is already collecting BGP data we've added a Looking Glass (*2) allowing a direct view into all the participating AS's at one glance. This has the advantages of easy comparison and thus troubleshouting. The output of the different project participants is all the same even though they are currently using Juniper's, Cisco's and Zebra routers. New participants can signup (*3) for the GRH project, ofcourse the ultimate goal is a stable internet and having many views helps a lot. I hereby also want to thank the people and companies giving tips and the ones participating in the project. On another note we've also setup an IPv6 News site (*4) where one can submit IPv6 'news' stories. It's backed up by a forum so that a discussion about the topic is possible. Submissions to the site can be made using an email to info@sixxs.net or by posting in the relevant forum. If the topic is 'newsy' enough it will be marked as interresting and it will automatically pop up on the main pages. Ofcourse don't hesitate to mail when in doubt. Greets, Jeroen *1: http://www.sixxs.net/tools/grh/ *2: http://www.sixxs.net/tools/grh/lg/ *3: http://www.sixxs.net/tools/grh/signup/ *4: http://ipv6gate.sixxs.net/ From owner-v6ops@ops.ietf.org Thu Mar 6 18:50:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19830 for ; Thu, 6 Mar 2003 18:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18r59R-000Hyw-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 15:51:49 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18r59N-000Hyj-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 15:51:45 -0800 Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29372 for ; Thu, 6 Mar 2003 16:51:43 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBC009PBQ6E46@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 06 Mar 2003 16:49:27 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBC004NHQ6CKA@mail.sun.net> for v6ops@ops.ietf.org; Thu, 06 Mar 2003 16:49:26 -0700 (MST) Date: Thu, 06 Mar 2003 15:50:37 -0800 From: Alain Durand Subject: Re: Document Review: Volunteers Needed In-reply-to: <5.1.0.14.2.20030306075438.02d60f88@mail.windriver.com> To: Margaret Wasserman Cc: Pekka Savola , v6ops@ops.ietf.org, Bob Fink , Itojun Message-id: <6E4ADBD6-502E-11D7-BF7D-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Margaret, I share some of Pekka's concern. Having more people reviewing documents is good, but not enough. The wg need to make sure that the review process cover a broad enough base, with expertise coming from outside of the wg and probably also outside of the IETF. Note: this is not a new problem, we experiment the same lack of interest back in the NGtrans days That said, I'm willing to help. - Alain. From owner-v6ops@ops.ietf.org Thu Mar 6 23:47:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27687 for ; Thu, 6 Mar 2003 23:47:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18r9lT-0007rK-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 20:47:23 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18r9lQ-0007r0-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 20:47:20 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 303BD25A1; Thu, 6 Mar 2003 23:47:19 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Mar 2003 23:47:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Thu, 6 Mar 2003 23:47:18 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240FE5@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLiQqBbFTqD+hkGRumiNfoh0dliHwAMSnoQAHv0VcA= From: "Bound, Jim" To: "Christian Huitema" , "Pekka Savola" , "Ronald van der Pol" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 07 Mar 2003 04:47:19.0076 (UTC) FILETIME=[A24F3E40:01C2E464] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA27687 Folks, I don't agree with single link subnet. This is not cool and implies I use bridges in my house. In fact a colleague is now looking into UPnP to verify it is not stating this as we received rumor this was potential there too. People will run routers in their homes and SOHO's not only bridges with single subnet. That case will happen and we are not covering it. But the point is we did agree. So what do we do now? Is it ok to revisit? The reason for a last call is to catch things we may have missed. The case can be made. But then how is that resolved. Do we never revisit anything? This is quite a limitation for sure in uman IMO. I think it is not wise limitation. /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, March 04, 2003 12:34 PM > To: Pekka Savola; Ronald van der Pol > Cc: Margaret Wasserman; v6ops@ops.ietf.org > Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt > > > > On Mon, 3 Mar 2003, Ronald van der Pol wrote: > > > > A particular thing I note that multiple-subnet case seems to be > > > > out of scope, or that's the impression I get based on the first > > paragraph. > > > > > > We have been discussing multiple-subnet cases internally, > especially > an > > > 802.11b router connected to a home LAN behind a SOHO router to the > ISP. > > > In the IPv4 case this usually is a NAT behind a NAT :-( > > > > The best in this case might be to deploy the 801.11b router > to act as > a > > bridge. > > > > But in any case, the scenarios document should be clearer > on what is > > considered "in scope" for the unmanaged networks. > > The issue was debated in the working group, in particular > during the WG meeting in Atlanta. There was a very strong > consensus to restrict the scope of our work to "single link > subnets". I don't believe it is appropriate to revisit that > decision right now. > > -- Christian Huitema > > From owner-v6ops@ops.ietf.org Fri Mar 7 00:11:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28087 for ; Fri, 7 Mar 2003 00:11:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rAAb-0009RO-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 21:13:21 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rAAY-0009RB-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 21:13:19 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 424E471DE; Fri, 7 Mar 2003 00:13:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 00:13:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Document Review: Volunteers Needed Date: Fri, 7 Mar 2003 00:13:17 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA40@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Review: Volunteers Needed Thread-Index: AcLjkejr+0BByA6SQji5xJNECE3qjwA1hs/w From: "Bound, Jim" To: "Margaret Wasserman" , Cc: "Bob Fink" , "Itojun" X-OriginalArrivalTime: 07 Mar 2003 05:13:18.0154 (UTC) FILETIME=[4397AAA0:01C2E468] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA28087 I hate the idea and its too bad. But as Chairs you have no choice. THis is very unfortuneate. I support it as lesser of two evils. I suggest strongly to rotate these reviewers if you can find at the end of every IETF meeting. So we don't have the same reviewers all the time forever. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Wednesday, March 05, 2003 10:34 PM > To: v6ops@ops.ietf.org > Cc: Bob Fink; Itojun > Subject: Document Review: Volunteers Needed > > > > Hi All, > > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the IESG. > > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by a > significant number of people representing a cross-section of > areas of expertise. > > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. > > This team would consist of people who are willing to spend a > couple of hours reviewing and commenting on v6ops documents > at each stage of the process -- WG acceptance, major > intermediate revisions, WG last call(s), revisions to address > IESG comments, etc. > > The review team would be chosen from a pool of volunteers to > represent a broad range of knowledge and expertise, and > members would be removed if they are too frequently > non-responsive. All review comments would be sent to the > list, and treated like any individual comments. > > Like most new processes, we don't know exactly how this > would work, and there will probably be bugs to work out > over time... But, we strongly feel that we have to do > something to ensure that our documents are well reviewed > before they are accepted by the WG and/or advanced to the > IESG. We also hope that our efforts may serve as a useful > model for improvements in this area throughout the IETF. > > What does the WG think about this idea? > > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? > > Who would be willing to volunteer for this type of role? > > Thanks, > Margaret > > > > > From owner-v6ops@ops.ietf.org Fri Mar 7 00:12:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28104 for ; Fri, 7 Mar 2003 00:12:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rABZ-0009VM-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 21:14:21 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rABW-0009V9-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 21:14:18 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AB4D87053; Fri, 7 Mar 2003 00:14:17 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 00:14:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Document Review: Volunteers Needed Date: Fri, 7 Mar 2003 00:14:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA41@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Review: Volunteers Needed Thread-Index: AcLjvwq1vTi8tnHoRh6ZfglOhpcHKwAqUW2g From: "Bound, Jim" To: =?iso-8859-1?Q?C=E9sar_Olvera_Morales?= , X-OriginalArrivalTime: 07 Mar 2003 05:14:17.0559 (UTC) FILETIME=[67002670:01C2E468] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA28104 No comment to those all volunteeriung. But that's 3 right there. Almost as many that responded to last call :--) Amazing. /jim > -----Original Message----- > From: Csar Olvera Morales [mailto:cesar.olvera@consulintel.es] > Sent: Thursday, March 06, 2003 4:02 AM > To: v6ops@ops.ietf.org > Subject: Re: Document Review: Volunteers Needed > > > Hi, > > I'm working with Jordi Palet, and I would like to participate > in this effort. > > Regards, > > Csar Olvera > Consulintel > > ----- Original Message ----- > From: "Margaret Wasserman" > To: > Cc: "Bob Fink" ; "Itojun" > Sent: Thursday, March 06, 2003 4:33 AM > Subject: Document Review: Volunteers Needed > > > > > > Hi All, > > > > The recent poor response to our document last calls (2 comments for > > one document, 4 comments for the other) is insufficient to justify > > advancing these documents to the IESG. > > > > Before we advance these document, or any documents, to the IESG, we > > want to be certain that they have been reviewed by a significant > > number of people representing a cross-section of areas of expertise. > > > > In an effort to fix this problem, Bob, Itojun and I are considering > > forming a semi-official v6ops document review team. > > > > This team would consist of people who are willing to spend > a couple of > > hours reviewing and commenting on v6ops documents at each > stage of the > > process -- WG acceptance, major intermediate revisions, WG last > > call(s), revisions to address IESG comments, etc. > > > > The review team would be chosen from a pool of volunteers > to represent > > a broad range of knowledge and expertise, and members would > be removed > > if they are too frequently non-responsive. All review > comments would > > be sent to the list, and treated like any individual comments. > > > > Like most new processes, we don't know exactly how this > > would work, and there will probably be bugs to work out > > over time... But, we strongly feel that we have to do something to > > ensure that our documents are well reviewed before they are > accepted > > by the WG and/or advanced to the IESG. We also hope that > our efforts > > may serve as a useful model for improvements in this area > throughout > > the IETF. > > > > What does the WG think about this idea? > > > > If you think that this is a good idea, how could we give credit to > > this team? Perhaps list them on the v6ops alternate web-site, and > > list them as "technical reviewers" in the acknowledgements > section of > > our published documents? > > > > Who would be willing to volunteer for this type of role? > > > > Thanks, > > Margaret > > > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > > From owner-v6ops@ops.ietf.org Fri Mar 7 00:32:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00065 for ; Fri, 7 Mar 2003 00:32:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rAUL-000AkG-00 for v6ops-data@psg.com; Thu, 06 Mar 2003 21:33:45 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rAUJ-000Ak4-00 for v6ops@ops.ietf.org; Thu, 06 Mar 2003 21:33:43 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5484E72CC for ; Fri, 7 Mar 2003 00:33:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 00:33:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E46B.1D04EFE0" Subject: Last Call Reviewers Date: Fri, 7 Mar 2003 00:33:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA48@tayexc13.americas.cpqcorp.net> Thread-Topic: Last Call Reviewers Thread-Index: AcLkaxztzF0S3mX3QySwrWJ1gstT8g== From: "Bound, Jim" To: X-OriginalArrivalTime: 07 Mar 2003 05:33:42.0248 (UTC) FILETIME=[1D359680:01C2E46B] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E46B.1D04EFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Margaret, =20 Other suggestion. Don;'t use the reviewers in place of doing standard last call. In fact I suggest for process it is wise to not use them unless last call don 't work. That way there is not ethical question of creating good ole boy network of v6ops reviewers. The reviewers would be like special ops folks we call in for when the working group don't do their job. =20 Make Sense, =20 /jim. =20 =20 =20 ------_=_NextPart_001_01C2E46B.1D04EFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Margaret,
 
Other=20 suggestion.  Don;'t use the reviewers in place of doing standard = last=20 call.  In fact I suggest for process it is wise to not use them = unless last=20 call don 't work.  That way there is not ethical question of = creating good=20 ole boy network of v6ops reviewers.  The reviewers would be like = special=20 ops folks we call in for when the working group don't do their=20 job.
 
Make=20 Sense,
 
/jim.
 
 
 
=00 ------_=_NextPart_001_01C2E46B.1D04EFE0-- From owner-v6ops@ops.ietf.org Fri Mar 7 07:11:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23986 for ; Fri, 7 Mar 2003 07:11:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rGgy-0000mE-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 04:11:12 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rGgu-0000lL-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 04:11:08 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h27C9fS23912; Fri, 7 Mar 2003 13:09:41 +0100 (CET) Date: Fri, 7 Mar 2003 13:09:41 +0100 From: Ronald van der Pol To: "Bound, Jim" Cc: Christian Huitema , Pekka Savola , Ronald van der Pol , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <20030307120941.GF17261@rvdp.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B03240FE5@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240FE5@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Mar 06, 2003 at 23:47:18 -0500, Bound, Jim wrote: > Folks, > > I don't agree with single link subnet. This is not cool and implies I > use bridges in my house. In fact a colleague is now looking into UPnP > to verify it is not stating this as we received rumor this was potential > there too. People will run routers in their homes and SOHO's not only > bridges with single subnet. > That case will happen and we are not covering it. You seem to be quite confident about that. Could you explain why you think multiple subnets will arrive in SOHOs? I'm not saying I don't agree with you. I just would like to know the scenarios where multiple subnets are needed. And when they are needed. I think we have already spent too much time on the scenario/analysis drafts. We should not delay any longer when it is not absolutely necessary. Another question is whether v6ops should pick this up. Maybe zerouter (if that is going to be a WG) is a better place and we need to make sure they cover IPv6, unmanaged networks and SOHOs too. rvdp From owner-v6ops@ops.ietf.org Fri Mar 7 07:24:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25067 for ; Fri, 7 Mar 2003 07:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rGvL-0001At-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 04:26:03 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rGvJ-0001Ae-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 04:26:01 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h27CPrv24025; Fri, 7 Mar 2003 13:25:53 +0100 (CET) Date: Fri, 7 Mar 2003 13:25:53 +0100 From: Ronald van der Pol To: Margaret Wasserman Cc: v6ops@ops.ietf.org, Bob Fink , Itojun Subject: Re: Document Review: Volunteers Needed Message-ID: <20030307122553.GG17261@rvdp.org> References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Mar 05, 2003 at 22:33:55 -0500, Margaret Wasserman wrote: > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. I think we all agree. > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. That's a big step at once. Correct me if I am wrong, but I think the recent Last Call was the first that said: "Silence does NOT indicate consent during this phase." Apparently, that was not enough or people did not read it. Maybe you could first try to send reminders like: "People, we need more feedback on this draft otherwise we are not going to advance it". I know that would work for me :-) With formal review teams I am afraid we are going to spend more time on procedures than on actual work. rvdp From owner-v6ops@ops.ietf.org Fri Mar 7 07:27:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25445 for ; Fri, 7 Mar 2003 07:27:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rGyO-0001IV-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 04:29:12 -0800 Received: from mail1.telekom.de ([62.225.183.235]) by psg.com with esmtp (Exim 3.36 #1) id 18rGyM-0001I4-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 04:29:10 -0800 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 7 Mar 2003 13:29:07 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 13:29:07 +0100 Message-Id: From: "Bonness, Olaf" To: Ronald.vanderPol@rvdp.org, Jim.Bound@hp.com Cc: huitema@windows.microsoft.com, pekkas@netcore.fi, mrw@windriver.com, v6ops@ops.ietf.org Subject: AW: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Fri, 7 Mar 2003 13:29:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.8 required=5.0 tests=EMAIL_ATTRIBUTION,EXCHANGE_SERVER,MSG_ID_ADDED_BY_MTA_3, QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Ronald, from my point of view it's fairly obvious to have different subnets within my soho environment for instance one for every room I have or besides that when I want to use parts of my home (network) for professional reasons and want to separate this from my normal / private life. My 2cents Olaf -----Ursprungliche Nachricht----- Von: Ronald van der Pol [mailto:Ronald.vanderPol@rvdp.org] Gesendet: Freitag, 7. Marz 2003 13:10 An: Bound, Jim Cc: Christian Huitema; Pekka Savola; Ronald van der Pol; Margaret Wasserman; v6ops@ops.ietf.org Betreff: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt On Thu, Mar 06, 2003 at 23:47:18 -0500, Bound, Jim wrote: > Folks, > > I don't agree with single link subnet. This is not cool and implies I > use bridges in my house. In fact a colleague is now looking into UPnP > to verify it is not stating this as we received rumor this was potential > there too. People will run routers in their homes and SOHO's not only > bridges with single subnet. > That case will happen and we are not covering it. You seem to be quite confident about that. Could you explain why you think multiple subnets will arrive in SOHOs? I'm not saying I don't agree with you. I just would like to know the scenarios where multiple subnets are needed. And when they are needed. I think we have already spent too much time on the scenario/analysis drafts. We should not delay any longer when it is not absolutely necessary. Another question is whether v6ops should pick this up. Maybe zerouter (if that is going to be a WG) is a better place and we need to make sure they cover IPv6, unmanaged networks and SOHOs too. rvdp From owner-v6ops@ops.ietf.org Fri Mar 7 07:42:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27282 for ; Fri, 7 Mar 2003 07:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rHD6-0001qA-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 04:44:24 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rHD3-0001pm-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 04:44:21 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h27ChrM24174; Fri, 7 Mar 2003 13:43:53 +0100 (CET) Date: Fri, 7 Mar 2003 13:43:53 +0100 From: Ronald van der Pol To: "Bonness, Olaf" Cc: Ronald.vanderPol@rvdp.org, Jim.Bound@hp.com, huitema@windows.microsoft.com, pekkas@netcore.fi, mrw@windriver.com, v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <20030307124353.GH17261@rvdp.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, SUPERLONG_LINE,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Mar 07, 2003 at 13:29:05 +0100, Bonness, Olaf wrote: > Hi Ronald, > > from my point of view it's fairly obvious to have different subnets within my soho environment for instance one for every room I have or besides that when I want to use parts of my home (network) for professional reasons and want to separate this from my normal / private life. Yes, but I would like to know why it is fairly obvious. Is it because you want to use different ACLs on the different subnets? (ACLs and unmanaged networks don't fit well together :-) Is it because they use different technologies with different MTUs. Something else? rvdp From owner-v6ops@ops.ietf.org Fri Mar 7 10:16:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10151 for ; Fri, 7 Mar 2003 10:16:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rJad-0007KS-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 07:16:51 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18rJab-0007KG-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 07:16:49 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA14246; Fri, 7 Mar 2003 07:16:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030307101203.0335d340@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 10:15:15 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: Re: Last Call Reviewers Cc: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA48@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, The review team would not replace last call or any other step of the IETF document process. The reviewers would review the same publicly-available versions of documents as everyone else in the WG should be reviewing, and they would make their comments on the mailing list. Their comments would not be given special weight, beyond whatever weight they have due to their individual respect in the community. The idea is not to decrease visibility, but just to form a team of people who are willing to be held accountable for thorough and timely document review. Margaret At 12:33 AM 3/7/2003 -0500, Bound, Jim wrote: >Margaret, > >Other suggestion. Don;'t use the reviewers in place of doing standard >last call. In fact I suggest for process it is wise to not use them >unless last call don 't work. That way there is not ethical question of >creating good ole boy network of v6ops reviewers. The reviewers would be >like special ops folks we call in for when the working group don't do >their job. > >Make Sense, > >/jim. > > > From owner-v6ops@ops.ietf.org Fri Mar 7 10:44:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11524 for ; Fri, 7 Mar 2003 10:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rK24-0008R1-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 07:45:12 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rK21-0008QX-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 07:45:09 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C4901EAE; Fri, 7 Mar 2003 10:45:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 10:45:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Fri, 7 Mar 2003 10:45:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240FE8@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLkonVI4A+XYIgTRhm/EvjZ7TKVvgAHClpg From: "Bound, Jim" To: "Ronald van der Pol" Cc: "Christian Huitema" , "Pekka Savola" , "Margaret Wasserman" , X-OriginalArrivalTime: 07 Mar 2003 15:45:07.0521 (UTC) FILETIME=[87560310:01C2E4C0] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11524 > You seem to be quite confident about that. Could you explain > why you think multiple subnets will arrive in SOHOs? I'm not > saying I don't agree with you. I just would like to know the > scenarios where multiple subnets are needed. And when they > are needed. I think we have already spent too much time on > the scenario/analysis drafts. We should not delay any longer > when it is not absolutely necessary. First and foremost it is a "choice" we should permit. I personally think bridges were a bad idea for networks back in the late 80's, and I don't believe extended LANs are acceptable, being inherently evil wearing my network computer scientist hat. That being said, in a home you have one subnet in the basement, one in the 1st level, and then one in next level of the home. Each with its own applications for that subnet for personal and household appliances. If I want to access other floors one can, but over a router, and one does not want to see the traffic for many reasons on the other subnets. In SOHO this can be a clear division of work like the Dentist Office. The Dentist work is using machinery and robotics on one subnet, and the office admin is doing accounting on another subnet, and common applications are running in the closet of the office in a server accessible to both, and where ingress/egress end points are to the public Internet. Each of these networks do not want others on their subnet and it could be for security reasons too. Admin at front office hates patient that comes in and turns up the speed on the Dentist's drill when the patient begins treatment :---) As far as discussion. I asked the chairs the question. Until they tell us to stop discussion I intend to respond. Respectfully to that question. > > Another question is whether v6ops should pick this up. Maybe > zerouter (if that is going to be a WG) is a better place and > we need to make sure they cover IPv6, unmanaged networks and > SOHOs too. If that logic is true then the entire spec should move to zeroconf. I think that is not a good idea. Regards, /jim From owner-v6ops@ops.ietf.org Fri Mar 7 10:44:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11540 for ; Fri, 7 Mar 2003 10:44:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rK3H-0008Tr-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 07:46:27 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18rK3E-0008Te-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 07:46:24 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA28649; Fri, 7 Mar 2003 07:46:06 -0800 (PST) Message-Id: <5.1.0.14.2.20030307104041.00bc9060@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 10:45:04 -0500 To: Ronald van der Pol From: Margaret Wasserman Subject: Re: Document Review: Volunteers Needed Cc: v6ops@ops.ietf.org, Bob Fink , Itojun In-Reply-To: <20030307122553.GG17261@rvdp.org> References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 01:25 PM 3/7/2003 +0100, Ronald van der Pol wrote: >On Wed, Mar 05, 2003 at 22:33:55 -0500, Margaret Wasserman wrote: > > > The recent poor response to our document last calls (2 > > comments for one document, 4 comments for the other) is > > insufficient to justify advancing these documents to the > > IESG. > >I think we all agree. Good. > > In an effort to fix this problem, Bob, Itojun and I are > > considering forming a semi-official v6ops document review team. > >That's a big step at once. Correct me if I am wrong, but I think >the recent Last Call was the first that said: "Silence does NOT >indicate consent during this phase." Apparently, that was not >enough or people did not read it. Maybe you could first try >to send reminders like: "People, we need more feedback on this >draft otherwise we are not going to advance it". I know that >would work for me :-) With formal review teams I am afraid we >are going to spend more time on procedures than on actual work. I was hoping that we could do this in a way that is very light-weight regarding procedures. It would add a little overhead for me, Itojun and Bob, but not much to the whole WG. What, in particular, are you concerned about? Margaret From owner-v6ops@ops.ietf.org Fri Mar 7 10:48:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11670 for ; Fri, 7 Mar 2003 10:48:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rK6n-0008fi-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 07:50:05 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rK6k-0008fG-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 07:50:02 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 302D4ACAD; Fri, 7 Mar 2003 10:50:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 10:49:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Last Call Reviewers Date: Fri, 7 Mar 2003 10:49:59 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA5A@tayexc13.americas.cpqcorp.net> Thread-Topic: Last Call Reviewers Thread-Index: AcLkvJkr4Skt1yIZRj6HfVxj/7fF8wABHq1g From: "Bound, Jim" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 07 Mar 2003 15:49:59.0906 (UTC) FILETIME=[359C6C20:01C2E4C1] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11670 Margaret, > The reviewers would review the same publicly-available > versions of documents as everyone else in the WG should be > reviewing, and they would make their comments on the mailing > list. Their comments would not be given special weight, > beyond whatever weight they have due to their individual > respect in the community. That is fine but this should be clearly documented in some document. Thanks /jim From owner-v6ops@ops.ietf.org Fri Mar 7 11:07:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12673 for ; Fri, 7 Mar 2003 11:07:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rKOj-0009QL-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 08:08:37 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18rKOf-0009NN-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 08:08:33 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h27G7nu20161; Fri, 7 Mar 2003 11:07:49 -0500 (EST) Date: Fri, 07 Mar 2003 11:07:41 -0500 From: Marc Blanchet To: Margaret Wasserman , v6ops@ops.ietf.org cc: Bob Fink , Itojun Subject: Re: Document Review: Volunteers Needed Message-ID: <14040000.1047053261@classic.viagenie.qc.ca> In-Reply-To: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> X-Mailer: Mulberry/3.0.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- mercredi, mars 05, 2003 22:33:55 -0500 Margaret Wasserman wrote/a ecrit: > > Hi All, > > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. My guess on this: - informational documents, in general in IETF at least from my experience, usually have much less interest (exceptions exists but...) in reviewing from people, because they are informational (no protocol bits to take care of). - by no means, this is a judgement call on my part, just an observation. these scenarios documents are good to do, but we should be careful in having them laying around for a long period. We might end up having a focus/interest problem in the end. I would suggest the following: - during SFO ietf (maybe sunday), we (wg) or you (chairs) call a review meeting by inviting people to come all at the same time, same room and go through them, printing/reading on the screen and have the editors ready for discussion. The wg does not have to be all there, and in fact, would be counterproductive. But have few people that commit to come and then we all read it together. - then in 2 hours, we would have done: many reviewers, reviewed fast, etc... - speaking of myself, I would commit to a 2hour review session sunday 10h00-12h00am. A suggestion. Marc. > > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by > a significant number of people representing a cross-section > of areas of expertise. > > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. > > This team would consist of people who are willing to spend a > couple of hours reviewing and commenting on v6ops documents at > each stage of the process -- WG acceptance, major intermediate > revisions, WG last call(s), revisions to address IESG comments, > etc. > > The review team would be chosen from a pool of volunteers to > represent a broad range of knowledge and expertise, and members > would be removed if they are too frequently non-responsive. All > review comments would be sent to the list, and treated like any > individual comments. > > Like most new processes, we don't know exactly how this > would work, and there will probably be bugs to work out > over time... But, we strongly feel that we have to do > something to ensure that our documents are well reviewed > before they are accepted by the WG and/or advanced to the > IESG. We also hope that our efforts may serve as a useful > model for improvements in this area throughout the IETF. > > What does the WG think about this idea? > > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? > > Who would be willing to volunteer for this type of role? > > Thanks, > Margaret > > > From owner-v6ops@ops.ietf.org Fri Mar 7 11:12:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13226 for ; Fri, 7 Mar 2003 11:12:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rKUJ-0009dD-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 08:14:23 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18rKUG-0009cz-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 08:14:20 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 11EBC189B; Fri, 7 Mar 2003 11:14:20 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 11:14:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Document Review: Volunteers Needed Date: Fri, 7 Mar 2003 11:14:19 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCA5D@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Review: Volunteers Needed Thread-Index: AcLkxBSvWqQZXIRSQ8Sk76CsYqgABAAAE8Jw From: "Bound, Jim" To: "Marc Blanchet" , "Margaret Wasserman" , Cc: "Bob Fink" , "Itojun" X-OriginalArrivalTime: 07 Mar 2003 16:14:20.0068 (UTC) FILETIME=[9BEF7640:01C2E4C4] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13226 Marc's mail made me think of something else. The bar for an Info or BCP doc is different than standards track. Do we need this team for non standards track. I am suggesting we limit the authority and power of any review team as much as possible to not break our inherent processes. /jim > -----Original Message----- > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca] > Sent: Friday, March 07, 2003 11:08 AM > To: Margaret Wasserman; v6ops@ops.ietf.org > Cc: Bob Fink; Itojun > Subject: Re: Document Review: Volunteers Needed > > > > -- mercredi, mars 05, 2003 22:33:55 -0500 Margaret Wasserman > wrote/a ecrit: > > > > > Hi All, > > > > The recent poor response to our document last calls (2 comments for > > one document, 4 comments for the other) is insufficient to justify > > advancing these documents to the IESG. > > My guess on this: > - informational documents, in general in IETF at least from > my experience, usually have much less interest (exceptions > exists but...) in reviewing from people, because they are > informational (no protocol bits to take care of). > - by no means, this is a judgement call on my part, just an > observation. > > these scenarios documents are good to do, but we should be > careful in having them laying around for a long period. We > might end up having a focus/interest problem in the end. > > I would suggest the following: > - during SFO ietf (maybe sunday), we (wg) or you (chairs) > call a review meeting by inviting people to come all at the > same time, same room and go through them, printing/reading on > the screen and have the editors ready for discussion. The wg > does not have to be all there, and in fact, would be > counterproductive. But have few people that commit to come > and then we all read it together. > - then in 2 hours, we would have done: many reviewers, > reviewed fast, etc... > - speaking of myself, I would commit to a 2hour review > session sunday 10h00-12h00am. > > A suggestion. > > Marc. > > > > > > Before we advance these document, or any documents, to the IESG, we > > want to be certain that they have been reviewed by a significant > > number of people representing a cross-section of areas of expertise. > > > > In an effort to fix this problem, Bob, Itojun and I are considering > > forming a semi-official v6ops document review team. > > > > This team would consist of people who are willing to spend > a couple of > > hours reviewing and commenting on v6ops documents at each > stage of the > > process -- WG acceptance, major intermediate revisions, WG last > > call(s), revisions to address IESG comments, etc. > > > > The review team would be chosen from a pool of volunteers > to represent > > a broad range of knowledge and expertise, and members would > be removed > > if they are too frequently non-responsive. All review > comments would > > be sent to the list, and treated like any individual comments. > > > > Like most new processes, we don't know exactly how this > > would work, and there will probably be bugs to work out > > over time... But, we strongly feel that we have to do something to > > ensure that our documents are well reviewed before they are > accepted > > by the WG and/or advanced to the IESG. We also hope that > our efforts > > may serve as a useful model for improvements in this area > throughout > > the IETF. > > > > What does the WG think about this idea? > > > > If you think that this is a good idea, how could we give credit to > > this team? Perhaps list them on the v6ops alternate web-site, and > > list them as "technical reviewers" in the acknowledgements > section of > > our published documents? > > > > Who would be willing to volunteer for this type of role? > > > > Thanks, > > Margaret > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri Mar 7 12:00:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16624 for ; Fri, 7 Mar 2003 12:00:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rLDe-000BZR-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 09:01:14 -0800 Received: from mail4.microsoft.com ([131.107.3.122] helo=INET-IMC-04.redmond.corp.microsoft.com) by psg.com with esmtp (Exim 3.36 #1) id 18rLDb-000BYC-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 09:01:12 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by INET-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 7 Mar 2003 09:00:54 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Mar 2003 09:01:08 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 7 Mar 2003 09:01:10 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 7 Mar 2003 09:01:09 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Fri, 7 Mar 2003 09:01:02 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Fri, 7 Mar 2003 09:01:08 -0800 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLkonVI4A+XYIgTRhm/EvjZ7TKVvgAHClpgAALJaQA= From: "Christian Huitema" To: "Bound, Jim" , "Ronald van der Pol" Cc: "Pekka Savola" , "Margaret Wasserman" , X-OriginalArrivalTime: 07 Mar 2003 17:01:02.0590 (UTC) FILETIME=[225E61E0:01C2E4CB] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16624 > First and foremost it is a "choice" we should permit. I personally > think bridges were a bad idea for networks back in the late 80's, and I > don't believe extended LANs are acceptable, being inherently evil > > Another question is whether v6ops should pick this up. Maybe > > zerouter (if that is going to be a WG) is a better place and > > we need to make sure they cover IPv6, unmanaged networks and > > SOHOs too. > > If that logic is true then the entire spec should move to zeroconf. I > think that is not a good idea. Jim, There is no question that there may be a technical interest in having multiple subnets in a home network. However, there is also no question that we cannot provide "unmanaged multi-subnet networks" with today's technology. This is pretty much what settled the issue in the discussion group: multi-subnet networks, today, are managed. The UPNP architecture committee came pretty much to the same conclusion: structured networks in the home may be desirable, but are not practical today; bridges provide a reasonable alternative. Not that I like this state of affairs. In fact, Dave Thaler and I submitted a draft to the IPv6 WG that addresses the issue (draft-ietf-ipv6-multilink-subnets-00.txt). I believe we need something like that in practice, as we are finding practical deployment of "cascaded NATs" in some home networks today, and that really breaks a number of applications. But, well, this was the group's consensus. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri Mar 7 13:06:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20648 for ; Fri, 7 Mar 2003 13:06:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rMEr-000DHk-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 10:06:33 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18rMEo-000DHY-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 10:06:31 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C476D6F05; Fri, 7 Mar 2003 13:06:29 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Mar 2003 13:06:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Fri, 7 Mar 2003 13:06:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240FEE@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLkonVI4A+XYIgTRhm/EvjZ7TKVvgAHClpgAALJaQAAAn6GcA== From: "Bound, Jim" To: "Christian Huitema" , "Ronald van der Pol" Cc: "Pekka Savola" , "Margaret Wasserman" , X-OriginalArrivalTime: 07 Mar 2003 18:06:29.0697 (UTC) FILETIME=[471B5B10:01C2E4D4] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA20648 Christian, Excellent point. No way can we do unmanaged with multiple subnets. Kills it for me. Move the draft to IESG review Margaret is my input before someone else opens another can of worms or pandaora's box. We must learn to ship our work expediently and quickly around here. The uman team has done the work, we have discussed it, it is a well written draft, and if the IESG in their infinite wisdom makes this PS any warts can be fixed after PS. Thanks Christian I thought it was correct but in the discussion I missed the obvious and thanks for pointing that out to me indirectly. /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, March 07, 2003 12:01 PM > To: Bound, Jim; Ronald van der Pol > Cc: Pekka Savola; Margaret Wasserman; v6ops@ops.ietf.org > Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt > > > > First and foremost it is a "choice" we should permit. I personally > > think bridges were a bad idea for networks back in the late > 80's, and > I > > don't believe extended LANs are acceptable, being inherently evil > > > Another question is whether v6ops should pick this up. Maybe > > > zerouter (if that is going to be a WG) is a better place > and we need > > > to make sure they cover IPv6, unmanaged networks and SOHOs too. > > > > If that logic is true then the entire spec should move to > zeroconf. I > > think that is not a good idea. > > Jim, > > There is no question that there may be a technical interest > in having multiple subnets in a home network. However, there > is also no question that we cannot provide "unmanaged > multi-subnet networks" with today's technology. This is > pretty much what settled the issue in the discussion > group: multi-subnet networks, today, are managed. The UPNP > architecture committee came pretty much to the same > conclusion: structured networks in the home may be desirable, > but are not practical today; bridges provide a reasonable alternative. > > Not that I like this state of affairs. In fact, Dave Thaler > and I submitted a draft to the IPv6 WG that addresses the > issue (draft-ietf-ipv6-multilink-subnets-00.txt). I believe > we need something like that in practice, as we are finding > practical deployment of "cascaded NATs" in some home networks > today, and that really breaks a number of applications. > > But, well, this was the group's consensus. > > -- Christian Huitema > > From owner-v6ops@ops.ietf.org Fri Mar 7 15:49:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01416 for ; Fri, 7 Mar 2003 15:49:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rOka-000HCv-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 12:47:28 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rOkW-000HCh-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 12:47:25 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h27Kl5W26373; Fri, 7 Mar 2003 21:47:05 +0100 (CET) Date: Fri, 7 Mar 2003 21:47:05 +0100 From: Ronald van der Pol To: Margaret Wasserman Cc: Ronald van der Pol , v6ops@ops.ietf.org, Bob Fink , Itojun Subject: Re: Document Review: Volunteers Needed Message-ID: <20030307204705.GI17261@rvdp.org> References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> <5.1.0.14.2.20030307104041.00bc9060@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030307104041.00bc9060@mail.windriver.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Mar 07, 2003 at 10:45:04 -0500, Margaret Wasserman wrote: > I was hoping that we could do this in a way that is very > light-weight regarding procedures. It would add a little > overhead for me, Itojun and Bob, but not much to the whole > WG. That sounds good. > What, in particular, are you concerned about? Several procedural issues have already been raised. I just think a review team is an overkill at this moment. I think with a little pressure we can get enough Last Call replies. Jim made a important observation about the number of volunteers already for a review team. rvdp From owner-v6ops@ops.ietf.org Fri Mar 7 16:57:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07973 for ; Fri, 7 Mar 2003 16:57:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rPr3-000JPw-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 13:58:13 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18rPr0-000JPk-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 13:58:10 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA28209 for ; Fri, 7 Mar 2003 13:58:05 -0800 (PST) Message-Id: <5.1.0.14.2.20030307164529.03450d78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 16:57:00 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Send Review Comments NOW!!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.3 required=5.0 tests=PLING_PLING,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk The fact that we are discussing whether or not to form a more formal review team should not stop anyone from sending review comments (NOW!!) on the two documents that we currently have in WG last call: http://ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt and http://ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt Documents should be reviewed for: - Alignment with WG consensus - Correct scope (any omissions?) - Technical correctness - Usefulness - Clarity/editorial correctness - Alignment with the rest of the Internet architecture (for security, scalability, etc.) - Adherence to I-D Nits (found at: http://ietf.org/ID-nits.html) - Adherence to RFC editor policies (found at: http://www.rfc-editor.org/policy.html) Review team volunteers, please consider this your trial assignment! Enjoy! Margaret From owner-v6ops@ops.ietf.org Fri Mar 7 17:02:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08223 for ; Fri, 7 Mar 2003 17:02:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rPx8-000JcW-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 14:04:30 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18rPx6-000JcI-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 14:04:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h27M46o30542; Sat, 8 Mar 2003 00:04:06 +0200 Date: Sat, 8 Mar 2003 00:04:05 +0200 (EET) From: Pekka Savola To: "Bonness, Olaf" cc: Ronald.vanderPol@rvdp.org, , , , Subject: Re: AW: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 7 Mar 2003, Bonness, Olaf wrote: > from my point of view it's fairly obvious to have different subnets > within my soho environment for instance one for every room I have or > besides that when I want to use parts of my home (network) for > professional reasons and want to separate this from my normal / private > life. This in my book is clearly not _un_managed network. In my book, if you have to set different perimeters with different properties, hook up different segments to different router ports, etc. etc., it is IMO clearly not the majority *unmanaged* solution. YMMV. > -----Ursprungliche Nachricht----- > Von: Ronald van der Pol [mailto:Ronald.vanderPol@rvdp.org] > Gesendet: Freitag, 7. Marz 2003 13:10 > An: Bound, Jim > Cc: Christian Huitema; Pekka Savola; Ronald van der Pol; Margaret > Wasserman; v6ops@ops.ietf.org > Betreff: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt > > > On Thu, Mar 06, 2003 at 23:47:18 -0500, Bound, Jim wrote: > > > Folks, > > > > I don't agree with single link subnet. This is not cool and implies I > > use bridges in my house. In fact a colleague is now looking into UPnP > > to verify it is not stating this as we received rumor this was potential > > there too. People will run routers in their homes and SOHO's not only > > bridges with single subnet. > > That case will happen and we are not covering it. > > You seem to be quite confident about that. Could you explain why you > think multiple subnets will arrive in SOHOs? I'm not saying I don't > agree with you. I just would like to know the scenarios where multiple > subnets are needed. And when they are needed. I think we have already > spent too much time on the scenario/analysis drafts. We should not > delay any longer when it is not absolutely necessary. > > Another question is whether v6ops should pick this up. Maybe zerouter > (if that is going to be a WG) is a better place and we need to make > sure they cover IPv6, unmanaged networks and SOHOs too. > > rvdp > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Mar 7 17:29:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10188 for ; Fri, 7 Mar 2003 17:29:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rQN7-000KXc-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 14:31:21 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18rQN4-000KXD-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 14:31:19 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h27MV6130811; Sat, 8 Mar 2003 00:31:06 +0200 Date: Sat, 8 Mar 2003 00:31:05 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: Margaret Wasserman , , Bob Fink , Itojun Subject: Re: Document Review: Volunteers Needed In-Reply-To: <20030307204705.GI17261@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 7 Mar 2003, Ronald van der Pol wrote: [...] > Jim made a important > observation about the number of volunteers already for a review team. Note that not everyone necessarily "spammed" the list with their "yes, please" :-). For all we know, there might be a dozen or two volunteers already. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Mar 7 19:18:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17813 for ; Fri, 7 Mar 2003 19:18:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rS27-000O7t-00 for v6ops-data@psg.com; Fri, 07 Mar 2003 16:17:47 -0800 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18rS25-000O7V-00 for v6ops@ops.ietf.org; Fri, 07 Mar 2003 16:17:45 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18rS25-000L1o-00; Fri, 07 Mar 2003 16:17:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 7 Mar 2003 16:17:44 -0800 To: Margaret Wasserman Cc: v6ops@ops.ietf.org Subject: Re: Send Review Comments NOW!!! References: <5.1.0.14.2.20030307164529.03450d78@mail.windriver.com> Message-Id: X-Spam-Status: No, hits=1.0 required=5.0 tests=PLING_PLING,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The fact that we are discussing whether or not to form a > more formal review team should not stop anyone from sending > review comments (NOW!!) on the two documents that we currently > have in WG last call: and it would be particularly appropriate if those willing to spend a lot of email discussion what review processes should be would actually DO serious reviews. randy From owner-v6ops@ops.ietf.org Sat Mar 8 10:33:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05935 for ; Sat, 8 Mar 2003 10:33:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rgJI-0004gH-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 07:32:28 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rgJE-0004et-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 07:32:24 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h28FWJt01107; Sat, 8 Mar 2003 16:32:19 +0100 (CET) Date: Sat, 8 Mar 2003 16:32:19 +0100 From: Ronald van der Pol To: Alain Durand Cc: v6ops@ops.ietf.org, Sebastien Roy , jim.Paugh@Sun.COM Subject: Re: dual stack & IPv6 on by default Message-ID: <20030308153219.GA557@rvdp.org> References: <17B552A2-4AB1-11D7-A7BB-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17B552A2-4AB1-11D7-A7BB-00039376A6AA@sun.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Feb 27, 2003 at 16:10:49 -0800, Alain Durand wrote: > My colleagues (Sebastien Roy & Jim Paugh) from Sun & I wrote a draft > on dual stack implementations and turning IPv6 on by default on them. > > http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-00.txt > > We would like to offer it as a contribution to v6ops > and would like to receive feedback from the wg. Thanks. I think you raise some important issues. At this moment, I think IPv6 is not yet ready for the general public. There still are too many connectivity problems (early adoptors however _should_ use IPv6 to sort out these problems). 2. No IPv6 Router Neighbor Discovery's [1] conceptual sending algorithm dictates that when sending a packet to a destination, if a host's default router list is empty, then the host assumes that the destination is on-link. Hmm, that sounds reasonable in an IPv6-only environment, but not in a dual stack environment. A good example why this document is useful. 4. Poor IPv6 Network Performance Is this different from IPv4-only networks? In such networks there can also be different paths and the path with the lowest cost can have the highest packet loss. 4.1. Dealing with Poor IPv6 Network Performance Not much can be done in this case other than configure each node to prefer IPv4 destinations over IPv6. A lot can be done, the network should be fixed :-) I think you mean the end host can not do much. Preferring IPv4 over IPv6 could be one solution. Another could be disabling IPv6. That may be clearer to the end user. It basically says: don't enable IPv6 unless you are sure you have good IPv6 connectivity (or know what you are doing). rvdp From owner-v6ops@ops.ietf.org Sat Mar 8 10:33:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06020 for ; Sat, 8 Mar 2003 10:33:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rgMV-0004ol-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 07:35:47 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18rgMT-0004oY-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 07:35:45 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h28FZgG01116; Sat, 8 Mar 2003 16:35:42 +0100 (CET) Date: Sat, 8 Mar 2003 16:35:41 +0100 From: Ronald van der Pol To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: IPv6 firewalling draft updated (bonus: IPv6-specific DoS attack) Message-ID: <20030308153541.GB557@rvdp.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Mar 04, 2003 at 17:06:08 +0200, Pekka Savola wrote: > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling-01.txt > > As a sugar on top to encourage you folks to read it, I've added (in an > appendix) an IPv6-specific DoS reflection attack (with amplification) > involving multicast. I hope that's enough to make folks read & comment > ;-) That seems only fair after all the work you spend on other people's drafts. I have read it and find it useful. I have too little expertise on security to make specific comments. But I am sure there will be others who do have the expertise :-) rvdp From owner-v6ops@ops.ietf.org Sat Mar 8 12:17:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24792 for ; Sat, 8 Mar 2003 12:17:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rhx6-0008np-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 09:17:40 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18rhx2-0008nd-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 09:17:36 -0800 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01652; Sat, 8 Mar 2003 10:17:33 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28HHVuK007124; Sat, 8 Mar 2003 12:17:31 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h28HHP61011239; Sat, 8 Mar 2003 12:17:25 -0500 (EST) Message-Id: <200303081717.h28HHP61011239@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: Ronald van der Pol cc: Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from Ronald van der Pol of "Sat, 08 Mar 2003 16:32:19 +0100." <20030308153219.GA557@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Mar 2003 12:17:25 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Ronald, Thanks for reading the draft: Ronald.vanderPol@rvdp.org said: > 2. No IPv6 Router > > Neighbor Discovery's [1] conceptual sending algorithm dictates that > when sending a packet to a destination, if a host's default router > list is empty, then the host assumes that the destination is on-link. > > > Hmm, that sounds reasonable in an IPv6-only environment, but not in a > dual stack environment. A good example why this document is useful. I don't think I see how this would be reasonable even in an IPv6-only environment. Let's assume there are billions of IPv6 devices out there. If you have no route (and I do think that at the very least the ND spec should say route instead of default route in this case) to one of those billions of devices, what are the odds that it happens to reside on your link? This bit of ND is an optimization for a very rare case at the expense of very a common case (you actually can't reach the destination). Quickly notifying the application that there's no route to the destination so that the user can correctly configure routes (on-link or off) seems better than sitting there for minutes while TCP times out the larval connection. > > 4. Poor IPv6 Network Performance > > > Is this different from IPv4-only networks? In such networks there can > also be different paths and the path with the lowest cost can have the > highest packet loss. Right, it's no different from an IPv4 or IPv6 only scenario where the first destination picked for a connection is reachable but has poor connectivity. One general solution to this problem could be to actually connect to all destinations in parallel, somehow determine which one has the best connectivity, and close all of the other ones. I've been told that this kind of approach has been discussed in a few context at the IETF. > > > 4.1. Dealing with Poor IPv6 Network Performance > > Not much can be done in this case other than configure each node to > prefer IPv4 destinations over IPv6. > > > A lot can be done, the network should be fixed :-) I think you mean > the end host can not do much. Right, we should be more clear. > Preferring IPv4 over IPv6 could be one > solution. Another could be disabling IPv6. That may be clearer to the > end user. It basically says: don't enable IPv6 unless you are sure you > have good IPv6 connectivity (or know what you are doing). Thanks for your input, -Seb From owner-v6ops@ops.ietf.org Sat Mar 8 12:52:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01514 for ; Sat, 8 Mar 2003 12:52:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18riVr-000ACQ-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 09:53:35 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18riVo-000AC9-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 09:53:32 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28HrT805498 for ; Sat, 8 Mar 2003 19:53:29 +0200 Date: Sat, 8 Mar 2003 19:53:29 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Some Enterprise Scenarios comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've quickly read through entnet-scenarios-00. The approach seems generally OK (remember that ISP and enterprise scenarios are the most difficult ones, with large variety), but it's a bit early to tell. More specific comments below. Unfortunately, at this stage, it is difficult to provide good commentary yet. Substantial: ------------ ==> The approach in section 6 in M1-M6 seems, at places, a bit solution-specific. In many cases it says "enterprise policy is FOO". My point is that the document here is trying to grasp IPV4 enterprise systems as they are, describe them, and perhaps give some view on how to proceed with a solutions document. The point of subsequent work of v6ops is to give reasoning why a certain type of enterprise policy is adopted -- not (yet!) the other way around. The approach seems a bit solutions-centric, in particular with M2 and M3. Semi-editorial: --------------- Abstract IPv6 will be deployed in Enterprise networks. This scenario has requirements for the adoption of IPv6. ==> This should be reworded; "this scenario" is ambiguous and sounds bad, and the scope of the work here is not to set requirements for IPv6 adoption (rather, to describe the current IPv4 enterprise networks). This document will focus upon and define: a set of technology scenarios that shall exist for the enterprise network, the set of transition variables, transition methods, and tools required by different scenarios. [...] ==> "transition methods" and especially "and tools required by different scenarios" seem too vague. My first impression was that the document would be specifying which transition mechanisms (like 6to4, etc.etc.) would be required. Luckily, this was not the case, but may require some more verbose text. Terminology ==> several important wordsmithing fixes in editorial section, below. Critical issues for each: PMTUD : Support for discovery vs. traditional ICMP aversion ==> Is PMTUD really a critical approach? Without elaboration, it may be that some other word might be more appropriate, or this should be considered a bit.. Trust system between host & network management teams: Dual-stack vs. IPv6-only IPv6-only is a restricted capability subset Routing Architectural concept of tunneling over foo vs. native service ==> "Trust system ..." ??! I've no idea how these relate to trust, so more elaboration or rewording is definitely needed! Scenario #6 A new Enterprise providing location based services for over a wide geography enables mobile devices for their Account Teams to access network data and services. Set D. ==> compared to other scenarios, this strikes me as being perhaps a bit too specific ("account teams", etc.)? Editorial: ---------- V6ops Working Group Enterprise Network Scenarios Design Team INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt Yanick Pouffary (Chair) Jim Bound (Editor) Enterprise Networks Scenarios Design Team See Acknowledgements Section February 2003 ==> the header is quite unconventional: I'd just make it like: V6ops Working Group Yanick Pouffary (Chair) Internet Draft Jim Bound (Editor) Expiration Date: Aug 2003 Enterprise Networks Scenarios Design Team February 2003 1. Introduction IPv6 will be deployed in Enterprise networks. This scenario has requirements for the adoption of IPv6. This document will focus upon and define: a set of technology scenarios that shall exist for the enterprise network, the set of transition variables, transition methods, and tools required by different scenarios. The document using these definitions will define the points of transition for an Enterprise network. ==> same issues as with abstract The audience for this document is the enterprise network team ==> if you can find, I'd personally prefer another word to "audience". accomplishing the business goal, IPv6 provides strong motivations to move. ==> reword or expand "to move" (for a change?) Enterprise Network - An Enterprise Network is a network that has multiple links, a router conection to a Provider, and is activel managed by a network operations entity. ==> formatting: must not exceed 72 chars (also elsewhere in the document). ==> s/conection/connection/ Provider - A Provider is an entity that provides services and connectivity to the Internet or other private external networks for the Enterprise Network. ==> "Internet or _other_ private external networks" must be reworded; Internet is not a private external network :-) Edge - The Edge is the ingress and egress points connecting to the Internet, Extranet, or to another private external network. ==> is the assumption so that the egress point = always ingress point? The plurality of the sentence is ambiguous. Administrative Domain - An Administrative Domain are the ingress and egress points connecting nodes across the Enterprise Network, behind the Edges. ==> same consideration about points (in "are" applies here). It also strikes me that the defininion could be simpler (drop out egress/ingress points completely, Edges covers that already). Extranet - An Extranet is any Enterprise Network owned network components at the Edge, but not part of the Administrative Domain. ==> "any EN owned components" ? I'm having trouble parsing the sentence, minor rewording. Border Router - An Enterprise Network Border Router is a a router that is configured at the Edges. ==> I recommend using another word than "configured" -- typically it has some other connotations. Points of Transtion - An Enterprise Network Point of ==> s/Transtion/Transition/ Every node that can be addressed by another node must be in a registered name service, managing this name service is a ==> s/,/, and/ (multi-Party) require globally consistent addresses for peer-to- ==> s/P/p/ - Routers - Non Router Nodes ==> why just not say "Hosts" :-) solutions. A set of suggested solutions will be provided in a follow on document to this work. ==> s/follow on/follow-up/? V5: IPv6 software upgrades are not available for existing routers and nodes. ==> s/available/available or possible/ V6: Source code for applications have been lost or cannot be ==> s/have/has/ V7: New business function being defined and can exist without ==> s/being/is being/, s/can/it can/ This point on the graph will be an transtion strategy. After the ==> s/transtion/transition/ Mobility : Requirements for nodes ==> s/Requirements/Mobility requirements/ Scenario #6 (subset of all scenarios) ==> s/6/7/ ? The Enterprise network will have varying points of transition that will require different points of interoperability with IPv6 and IPv4. ==> reword "different points of interoperability" but an IPv4 Internal Router is between them. These nodes could also be Mobile nodes too and in a remote location. ==> s/ too and/, or/ 1. A Dual Stacked IPv4/IPv6 node wants to communicate to a legacy IPv4 service and is on a Native IPv6 link and Routing Domain. Enterpise ==> "Routing Domain" (upper case) is not defined, I think? 2. A Dual Stacked IPv4/IPv6 node wants to communicate to a legcy IPv4 ==> s/node /node / ==> s/legcy/legacy/ This Point of Transition exists for the following conditions: 1. A Dual Stacked IPv4/IPv6 node wants to communicate with a legacy IPv4 ==> kill the extra empty line security, applications, and remove some benefits from the IPv6 protocol. 1. The Design Team highly recommends that network not adopt the policy in reference "1" above. 2. IPv6 ONLY nodes should not be deployed in a network until they will not require access to any legacy IPv4. This means that applications and infrastructure has been ported or moved to IPv6. Until that time nodes for transition should be Dual Stacked IPv4/IPv6 nodes. This means networks that want to use IPv6 ONLY nodes will be required to move applications and infrastructure to IPv6 first. ==> the 1., 2., list starts out of empty air, so I'm assuming there should be some kind of text there. addresses to nodes. Though DHCPv6 can be used to administrate addresses that are assigned to nodes. ==> s/Though/However,/ (or some other wordsmithing, looks funny that way) When preforming stateless autoconfiguration, an EUI-64 is generated ==> s/pre/per/ bit IPV6 address. The EUI-64 is derived from the MAC address of the interface that being autoconfigured. This mechanism proves a large ==> s/IPV6/IPv6/ ==> s/that/that's/ ==> s/proves/provides/ token should be considered when establishing an address plan." ==> s/"// This section will identify the tools requirements for an EN transitioning to IPv6 so the configuration issues for the EN are ==> s/EN/Enterprise Network/ 12. Security Section ==> is this Security Section or Security Considerations? :-) Acknowledgments ==> this section is typically numbered, too. Design Team' Addresses Send email to ent-v6net@viagenie.qc.ca to contact the design team and send comments on the draft to v Authors contact info will be provided in a future draft. ==> s/Team'/Team's/ ==> overlong line ==> s/Authors/Authors'/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Mar 8 14:04:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15058 for ; Sat, 8 Mar 2003 14:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rjcl-000DBt-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 11:04:47 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18rjch-000DBY-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 11:04:44 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h28J5SwY022765; Sat, 8 Mar 2003 21:05:28 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h28J5P3W022754; Sat, 8 Mar 2003 21:05:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: dual stack & IPv6 on by default From: Mika Liljeberg To: Sebastien Roy Cc: Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com In-Reply-To: <200303081717.h28HHP61011239@strat.East.Sun.COM> References: <200303081717.h28HHP61011239@strat.East.Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047150324.2473.97.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 21:05:24 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-03-08 at 19:17, Sebastien Roy wrote: > > 2. No IPv6 Router > > > > Neighbor Discovery's [1] conceptual sending algorithm dictates that > > when sending a packet to a destination, if a host's default router > > list is empty, then the host assumes that the destination is on-link. > > > > > > Hmm, that sounds reasonable in an IPv6-only environment, but not in a > > dual stack environment. A good example why this document is useful. > > I don't think I see how this would be reasonable even in an IPv6-only > environment. Let's assume there are billions of IPv6 devices out there. > If you have no route (and I do think that at the very least the ND spec > should say route instead of default route in this case) to one of those > billions of devices, what are the odds that it happens to reside on your > link? This bit of ND is an optimization for a very rare case at the > expense of very a common case (you actually can't reach the > destination). The common case is that the host has a default router, in which case this rule isn't invoked at all. > Quickly notifying the application that there's no route > to the destination so that the user can correctly configure routes > (on-link or off) seems better than sitting there for minutes while TCP > times out the larval connection. A TCP connection in SYN-SENT or SYN-RECEIVED states should abort immediately when ND determines that the destination is unreachable, so TCP does not incur any additional delay here. However, this rule *is* somewhat problematic with multihomed hosts as well as in cases where network interfaces are set up on-demand. In the former case, the packets apparently have to be replicated to all links that have no default routers. In the latter case, an application might trigger an on-demand network interface setup. However, the packets from the application would still be directed on-link, since it takes a little while to receive and process a router advertisement. An implementation that caches the routing decision will have problems with this. MikaL From owner-v6ops@ops.ietf.org Sat Mar 8 15:00:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25815 for ; Sat, 8 Mar 2003 15:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rkWR-000FYJ-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 12:02:19 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18rkWP-000FY7-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 12:02:17 -0800 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05544; Sat, 8 Mar 2003 13:02:13 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28K2BuK022805; Sat, 8 Mar 2003 15:02:11 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h28K2561011668; Sat, 8 Mar 2003 15:02:05 -0500 (EST) Message-Id: <200303082002.h28K2561011668@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: Mika Liljeberg cc: Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from Mika Liljeberg of "08 Mar 2003 21:05:24 +0200." <1047150324.2473.97.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Mar 2003 15:02:05 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk mika.liljeberg@welho.com said: > > > > I don't think I see how this would be reasonable even in an IPv6-only > > environment. Let's assume there are billions of IPv6 devices out there. > > If you have no route (and I do think that at the very least the ND spec > > should say route instead of default route in this case) to one of those > > billions of devices, what are the odds that it happens to reside on your > > link? This bit of ND is an optimization for a very rare case at the > > expense of very a common case (you actually can't reach the > > destination). > > The common case is that the host has a default router, in which case > this rule isn't invoked at all. Ok, I agree that this would be the common case in an IPv6 only network. If a random dual stack box that has IPv6 enabled is placed in a random network out there, the common case today is that it has no IPv6 default router, and this ND rule would be problematic for it. That's what we were trying to get across in this section of the draft. I suppose we need to more explicitly specify in the draft what types of networks we're concerned with. > > Quickly notifying the application that there's no route > > to the destination so that the user can correctly configure routes > > (on-link or off) seems better than sitting there for minutes while TCP > > times out the larval connection. > > A TCP connection in SYN-SENT or SYN-RECEIVED states should abort > immediately when ND determines that the destination is unreachable, so > TCP does not incur any additional delay here. Is that stated somewhere (it should be)? Should it be explicitly stated in the nodes requirements? In practice, I don't think many TCP implementations do this correctly (or as you've described), and they should be fixed. Even if TCP is fixed to abort connections, there is still a 3 second delay in IP while NUD is being performed, which may or may not be acceptable depending on how many IPv6 destinations the application will try before trying IPv4. I can't see this as being acceptable when a destination resolves to a few dozen IPv6 addresses, for example. An immediate ICMP destination unreachable/network unreachable from IP would be generated if it didn't assume destinations were on-link. > > However, this rule *is* somewhat problematic with multihomed hosts as > well as in cases where network interfaces are set up on-demand. In the > former case, the packets apparently have to be replicated to all links > that have no default routers. In the latter case, an application might > trigger an on-demand network interface setup. However, the packets from > the application would still be directed on-link, since it takes a little > while to receive and process a router advertisement. An implementation > that caches the routing decision will have problems with this. Indeed, all good points. Thank you, -Seb From owner-v6ops@ops.ietf.org Sat Mar 8 15:57:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07246 for ; Sat, 8 Mar 2003 15:57:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rlOm-000IAv-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 12:58:28 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18rlOj-000IAj-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 12:58:25 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA12018 for ; Sat, 8 Mar 2003 20:58:23 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA27866 for ; Sat, 8 Mar 2003 20:58:23 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h28KwNU03454 for v6ops@ops.ietf.org; Sat, 8 Mar 2003 20:58:23 GMT Date: Sat, 8 Mar 2003 20:58:23 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: AW: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <20030308205823.GC3344@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk So are we addressing unmanaged networks or home networks? Just need to choose and name the work accordingly, given that not all home networks will be unmanaged. Sections 1 and 2 need to be tightened up either way. If the home network receives a /48 from the ISP (not unreasonable - if we assume a /64 then we're ignoring the RIR /48 site recommendations) then *something* has to be managed to deliver the /64 subnet(s) internally? Or are we saying all home networks will be "unmanaged" and receive /64's? Tim On Sat, Mar 08, 2003 at 12:04:05AM +0200, Pekka Savola wrote: > On Fri, 7 Mar 2003, Bonness, Olaf wrote: > > from my point of view it's fairly obvious to have different subnets > > within my soho environment for instance one for every room I have or > > besides that when I want to use parts of my home (network) for > > professional reasons and want to separate this from my normal / private > > life. > > This in my book is clearly not _un_managed network. > > In my book, if you have to set different perimeters with different > properties, hook up different segments to different router ports, etc. > etc., it is IMO clearly not the majority *unmanaged* solution. > > YMMV. > > > -----Ursprungliche Nachricht----- > > Von: Ronald van der Pol [mailto:Ronald.vanderPol@rvdp.org] > > Gesendet: Freitag, 7. Marz 2003 13:10 > > An: Bound, Jim > > Cc: Christian Huitema; Pekka Savola; Ronald van der Pol; Margaret > > Wasserman; v6ops@ops.ietf.org > > Betreff: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt > > > > > > On Thu, Mar 06, 2003 at 23:47:18 -0500, Bound, Jim wrote: > > > > > Folks, > > > > > > I don't agree with single link subnet. This is not cool and implies I > > > use bridges in my house. In fact a colleague is now looking into UPnP > > > to verify it is not stating this as we received rumor this was potential > > > there too. People will run routers in their homes and SOHO's not only > > > bridges with single subnet. > > > That case will happen and we are not covering it. > > > > You seem to be quite confident about that. Could you explain why you > > think multiple subnets will arrive in SOHOs? I'm not saying I don't > > agree with you. I just would like to know the scenarios where multiple > > subnets are needed. And when they are needed. I think we have already > > spent too much time on the scenario/analysis drafts. We should not > > delay any longer when it is not absolutely necessary. > > > > Another question is whether v6ops should pick this up. Maybe zerouter > > (if that is going to be a WG) is a better place and we need to make > > sure they cover IPv6, unmanaged networks and SOHOs too. > > > > rvdp > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Sat Mar 8 16:04:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08524 for ; Sat, 8 Mar 2003 16:04:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rlWM-000IYJ-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 13:06:18 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18rlWI-000IY7-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 13:06:15 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h28L71wY023223; Sat, 8 Mar 2003 23:07:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h28L70DZ023217; Sat, 8 Mar 2003 23:07:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: dual stack & IPv6 on by default From: Mika Liljeberg To: Sebastien Roy Cc: Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com In-Reply-To: <200303082002.h28K2561011668@strat.East.Sun.COM> References: <200303082002.h28K2561011668@strat.East.Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047157619.2473.155.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 23:06:59 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-03-08 at 22:02, Sebastien Roy wrote: > > The common case is that the host has a default router, in which case > > this rule isn't invoked at all. > > Ok, I agree that this would be the common case in an IPv6 only network. > If a random dual stack box that has IPv6 enabled is placed in a random > network out there, the common case today is that it has no IPv6 default > router, and this ND rule would be problematic for it. That's what we > were trying to get across in this section of the draft. I suppose we > need to more explicitly specify in the draft what types of networks > we're concerned with. No, I wasn't paying enough attention to the scenario - sorry. I think the text in the draft says this clearly enough. > > A TCP connection in SYN-SENT or SYN-RECEIVED states should abort > > immediately when ND determines that the destination is unreachable, so > > TCP does not incur any additional delay here. > > Is that stated somewhere (it should be)? This is a practise adopted by some current implementations because there is a sigificant usability impact, e.g., in web browsing. I don't recall that this is documented in any RFC, though. For IPv4, RFC1122 defines the ICMP errors that are to be treated as soft errors, but does not state any special conditions for the connect phase. It does say the following: An attempt to open a TCP connection could fail with excessive retransmissions of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachable. SYN retransmissions MUST be handled in the general way just described for data retransmissions, including notification of the application layer. However, port unreachable is classified as a hard error. Treating the other unreachable errors as hard errors during connect bends the rules a little bit (in a nice way IMO). > Should it be explicitly stated in the nodes requirements? Probably yes. RFC1122 still has a lot of good stuff for an implementor even though it is partially out-of-date. Certainly a lot of deployment experience has been gained since it was written. It would be good to write some of those things down in an updated document. > In practice, I don't think many TCP > implementations do this correctly (or as you've described), and they > should be fixed. I'm not able to test other boxes right now, but at least Linux seems to do it this way. > Even if TCP is fixed to abort connections, there is > still a 3 second delay in IP while NUD is being performed, which may or > may not be acceptable depending on how many IPv6 destinations the > application will try before trying IPv4. I can't see this as being > acceptable when a destination resolves to a few dozen IPv6 addresses, > for example. An immediate ICMP destination unreachable/network > unreachable from IP would be generated if it didn't assume destinations > were on-link. Agreed. RFC3484 helps, of course, but the "assume on-link" rule is still likely to cause trouble. MikaL From owner-v6ops@ops.ietf.org Sat Mar 8 16:34:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13827 for ; Sat, 8 Mar 2003 16:34:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rlyw-000K01-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 13:35:50 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18rlyu-000Jzn-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 13:35:48 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.17]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA19710; Sat, 8 Mar 2003 13:35:23 -0800 (PST) Message-Id: <5.1.0.14.2.20030308163302.0346fd90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Mar 2003 16:34:03 -0500 To: archana_p@huawei.com From: Margaret Wasserman Subject: Re: which prefix is to be used ? Cc: v6ops@ops.ietf.org In-Reply-To: <000201c2e3c7$65515020$db04120a@in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Archana, You're question is probably better answered by the IPv6 Operations (v6ops) WG, cc:ed above... Margaret [Re-send of message originally sent to ipng] At 03:31 PM 3/6/2003 +0530, Archana wrote: >Hi > >Can there be a situation like this - > >-> where a V6 cloud is connected by NAT-PT router (say R1) to a V4 cloud >(V4-1) > >-> the same V6 cloud is connected by another NAT-PT router ( say R2 ) to >another V4 cloud (V4-2) > >Assuming there is a network like that when a V6 node has to communicate >with a V4 node in V4-1 > >how will the V6 node know which prefix to use (the one sent by R1 or R2) ? > >Please clarify > >Regards > >Archana > > > > From owner-v6ops@ops.ietf.org Sat Mar 8 16:58:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18511 for ; Sat, 8 Mar 2003 16:58:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rmLH-000LG5-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 13:58:55 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18rmLD-000LFr-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 13:58:52 -0800 Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05742 for ; Sat, 8 Mar 2003 14:58:51 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBG00IN0AE2AT@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sat, 08 Mar 2003 14:58:51 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBG00G1LAE1X4@mail.sun.net> for v6ops@ops.ietf.org; Sat, 08 Mar 2003 14:58:50 -0700 (MST) Date: Sat, 08 Mar 2003 14:00:03 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default In-reply-to: <1047157619.2473.155.camel@devil> To: Mika Liljeberg Cc: Sebastien Roy , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM Message-id: <5082AC3E-51B1-11D7-9EE8-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Saturday, March 8, 2003, at 01:06 PM, Mika Liljeberg wrote: > For IPv4, RFC1122 defines the ICMP errors that are to be treated as > soft > errors, but does not state any special conditions for the connect > phase. > It does say the following: > > An attempt to open a TCP connection could fail with > excessive retransmissions of the SYN segment or by receipt > of a RST segment or an ICMP Port Unreachable. SYN > retransmissions MUST be handled in the general way just > described for data retransmissions, including notification > of the application layer. > > However, port unreachable is classified as a hard error. Treating the > other unreachable errors as hard errors during connect bends the rules > a > little bit (in a nice way IMO). RFC1122, section 4.2.3.5 says more just bellow what you quote: However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. The application can close the connection (i.e., give up on the open attempt) sooner, of course. DISCUSSION: Some Internet paths have significant setup times, and the number of such paths is likely to increase in the future. ==> I understand from that section that a TCP implementation should wait 3 minutes on a SYN-sent before timing out. Do I miss something? Is this recommendation widely ignored? - Alain. From owner-v6ops@ops.ietf.org Sat Mar 8 17:31:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23983 for ; Sat, 8 Mar 2003 17:31:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rmrf-000MtR-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 14:32:23 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18rmrc-000Mss-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 14:32:20 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h28MX6wY023631; Sun, 9 Mar 2003 00:33:07 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h28MX5xh023624; Sun, 9 Mar 2003 00:33:05 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: dual stack & IPv6 on by default From: Mika Liljeberg To: Alain Durand Cc: Sebastien Roy , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM In-Reply-To: <5082AC3E-51B1-11D7-9EE8-00039376A6AA@sun.com> References: <5082AC3E-51B1-11D7-9EE8-00039376A6AA@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047162785.2473.196.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2003 00:33:05 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-03-09 at 00:00, Alain Durand wrote: > RFC1122, section 4.2.3.5 says more just bellow what you quote: > > However, the values of R1 and R2 may be different for SYN > and data segments. In particular, R2 for a SYN segment MUST > be set large enough to provide retransmission of the segment > for at least 3 minutes. The application can close the > connection (i.e., give up on the open attempt) sooner, of > course. > > DISCUSSION: > Some Internet paths have significant setup times, and > the number of such paths is likely to increase in the > future. > > ==> I understand from that section that a TCP implementation should > wait 3 minutes on a SYN-sent before timing out. This bit applies to the case when there is no feedback (no RST or ICMP error received by the sender). > Do I miss something? Is this recommendation widely ignored? I don't think it's ignored but, as I said, some implementations take a bit more liberal view to which ICMP errors can abort the connect phase. There is some variation to the initial retransmit timeouts and retry counts in different implementations, though. Linux defaults to 5 SYN retransmissions, which comes pretty close to 3 minutes with the standard 3 second initial RTO. I recall some versions of Solaris starting with a 1 second RTO and timing out roughly after one minute. MikaL From owner-v6ops@ops.ietf.org Sat Mar 8 17:42:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26234 for ; Sat, 8 Mar 2003 17:42:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rn33-000NDA-00 for v6ops-data@psg.com; Sat, 08 Mar 2003 14:44:09 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18rn31-000NCy-00 for v6ops@ops.ietf.org; Sat, 08 Mar 2003 14:44:07 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20919 for ; Sat, 8 Mar 2003 15:44:06 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBG009IBCHHO4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sat, 08 Mar 2003 15:44:06 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBG004BQCHGKA@mail.sun.net> for v6ops@ops.ietf.org; Sat, 08 Mar 2003 15:44:05 -0700 (MST) Date: Sat, 08 Mar 2003 14:45:18 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default In-reply-to: <1047162785.2473.196.camel@devil> To: Mika Liljeberg Cc: Sebastien Roy , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Saturday, March 8, 2003, at 02:33 PM, Mika Liljeberg wrote: >> ==> I understand from that section that a TCP implementation should >> wait 3 minutes on a SYN-sent before timing out. > > This bit applies to the case when there is no feedback (no RST or ICMP > error received by the sender). Thanks for the explanation, that was not clear to me by reading 1122. This 3 mins timeout is relevant to a variation of case 'no Ipv6 routers' where we actually have a route but v6 packets are black holed somewhere in the network. This case is not theoretical, it happens to me at home on my dual stack network when I connect to SUN via our v4 only VPN. - Alain. From owner-v6ops@ops.ietf.org Sun Mar 9 09:53:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28028 for ; Sun, 9 Mar 2003 09:52:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s29E-0001DF-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 06:51:32 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18s29A-0001D3-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 06:51:29 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h29EpO921216; Sun, 9 Mar 2003 15:51:24 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h29Eoxof016824; Sun, 9 Mar 2003 15:50:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303091450.h29Eoxof016824@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt In-reply-to: Your message of Mon, 17 Feb 2003 12:04:56 EST. <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Date: Sun, 09 Mar 2003 15:50:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A short & late review of draft-ietf-v6ops-3gpp-cases-02.txt: I have no concern, only a comment and some editorial remarks. The comment: IMHO the PDP PPP context finishing at the ISP NAS will be the more common GPRS scenario because regulatory bodies won't accept the mobile operator and the ISP will be the same entity, i.e., customers should get the choice. This scenario is explicitely put out of the scope of the document in 4.1. Typos & co: 3.1 GPRS architecture basics It also serves as the default router for the UE. => It can also serve as the default router for the UE. 3.2 - I-CSCF (Interrogating-CSCF) is the contact point within an operators network for all connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operators service area. => ' characters were replaced by (AE is latin 15). 4.1 Figure 3 +-------------+ | | | UE | +------+ => +-------------+ | | | UE | +------+ 4.2 Figure 9 +------+ +------+ +-----+ +-----+ | | | | | | | | | UE |-...-| |-----| IMS |--------| | | | | GGSN | | |+------+| IMS | | IPv6 | | | | || IPv4 || | +------+ +------+ +-----++------++-----+ Figure 9: Two IMS islands connected over IPv4 => +------+ +------+ +-----+ +-----+ | | | | | | | | | UE |-...-| |-----| IMS |----------| | | | | GGSN | | | +------+ | IMS | | IPv6 | | | | | | IPv4 | | | +------+ +------+ +-----+ +------+ +-----+ Figure 9: Two IMS islands connected over IPv4 Acknowledgements The authors would like to thank Basavaraj Patil, Tuomo Sipil, Fred ^ not an ASCII character Informative references Partnership Project (3GPP) Standards", September 2002, RFC3314. => Partnership Project (3GPP) Standards", RFC3314, September 2002. Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Mar 9 11:04:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11309 for ; Sun, 9 Mar 2003 11:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s3I5-0002PY-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 08:04:45 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18s3I3-0002PM-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 08:04:43 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h29G4d921719; Sun, 9 Mar 2003 17:04:39 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h29G4Dof017017; Sun, 9 Mar 2003 17:04:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303091604.h29G4Dof017017@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-reply-to: Your message of Mon, 17 Feb 2003 12:11:16 EST. <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Date: Sun, 09 Mar 2003 17:04:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Here is my review of draft-ietf-v6ops-unman-scenarios-00.txt, I have no concern but some comments and editorial remarks. Comments I have no concern about the limitation to a single subnet as soon as it is clear from the beginning (and it is the case). A very common scenario (the one I use personally) is a VPN (with IPsec or SSH or both) which injects the home network into a virtual home site. I don't know if this should be explicitly considered but at least it should be put out of the scope of the document by a statement in the introduction. A DNS server can be recursive (i.e., be a "DNS proxy") or not. As almost all resolvers don't support recursion them selves, this is an important detail when the DNS crosses IP version domains. Typos & co: 2 Topology (ISP)connection. Several hosts are connected to the subnet: => (ISP) connection. Several hosts are connected to the subnet: 3 Applications types of applications: local, client, servers and peer-to-peers. => types of applications: local, client, server and peer-to-peer. 3.1 Local applications of the unmanaged network. Typical examples are the sharing of file => of the unmanaged network. Typical examples are the sharing of files 3.2 Client applications Local applications tend to work correctly in IPv4 unmanaged => Client applications tend to work correctly in IPv4 unmanaged 4.2 Requirements of client applications servers. In an IPv6 network, the client must be able to locate a DNS server. => perhaps this is the good place to introduce recursive DNS servers? Note: in BIND the recursion part is in the server itself, i.e., even a caching only server adds recursion support to the resolver but the scenarios are about *unmanaged* networks, i.e., IMHO without any BIND server by default. 4.2.1 Privacy requirement of client applications => I agree with the conclusion. 4.4 Requirements of server applications => insert a page break between 4.3 and 4.4 sections. 5.1.2 Addresses and connectivity in Case A to deploy, and light weight; it will have to involve tunneling over UDP, as this is the practical way to traverse a NAT. If servers are => s/UDP/& or TCP/ (SSH is a good example of TCP tunneling which works through NATs) 5.2.1 Application support in Case B all, and to just continue fielding IPv6-only devices. The remaining => please replace "fielding" by a more common term. 5.2.2 Addresses and connectivity in Case B be assessed in a companion memo [EVAL]. => as soon as there is a reference to [EVAL], there should be others. 5.2.3 Naming services in Case B compared in the evaluation draft. => add [EVAL]. 5.4.1 Application support in Case D by providing IPv4-over-IPv6 tunnels. Our analysis concludes that a tunnel service will be vastly preferable. and The proper alternative to application relays and network address translation is the provision of an IPv4-over-IPv6 service. => I agree (:-)!!! 5.4.3 Naming services in Case D The gateway should be able to act as a "DNS proxy" for the remaining IPv4 only hosts. => this "DNS proxy" is in fact a recursive DNS server running on a dual stack node. 11 References => should be split into two sections, etc. [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks, work in progress. => please add the name of the last version of the draft. => there is a [6TO4] in 5.3.2. Table of Contents: => move to front. Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Mar 9 11:21:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14401 for ; Sun, 9 Mar 2003 11:21:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s3Zt-0002ky-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 08:23:09 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18s3Zo-0002kd-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 08:23:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h29GN2n19322 for ; Sun, 9 Mar 2003 18:23:02 +0200 Date: Sun, 9 Mar 2003 18:23:01 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Some ISP Scenarios Comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=LINES_OF_YELLING,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I quickly re-read the ISP scenarios document, the previous version, -04. I think most comments are probably applicable, as changes happened mainly to the ISP section. In my opinion, the document is about ready to be accepted as a w.g. item. There is a big editorial choice ahead, IMO, which is whether some "Access Networks" specific stuff (about everything except under core/backbone and IXP sections) should be "aggregated" somewhere. That is, there seems to be no use repeating the same thing 5 times (e.g. about user authentication, access routers, hosting gear, web caching infrastructure etc.etc.), and only report the connectivity-specific stuff under the appropriate sections. Comments below. Substantial: ------------ Status of this Memo This document is an Internet-Draft and is subject to all Provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also ==> Here and elsewhere: the editorial quality and conformance to typical format must improve. For example, in a lot of places, paragraphs should be separated by empty lines, etc. Doing that makes reading the doc *a lot* easier. ==> I will make some direct contributions, if no one else comes first, when the situation has improved. ___|___ ___|__ ___|___ | | | | | | | CPE1 | | CPE2 | | CPE(n)| |_______| |______| |_______| ==> These should be named "Customer1", .. (n). Also in this section, issues about CPE's etc. should really be split off: such should be dealt under the appropriate access network scenarios section. ==> I'm not certain how to best handle the generic "layer" between all the access methods: there are certainly a lot of common elements, does everything have to be repeated N times? That's something which one may have to consider (e.g. whether to create "Access Networks" abstraction layer explaining the generic stuff) 4.1 Topology ==> This, and some scenarios above, are too "core/edge" -separation centric. There are a lot of networks which only include bigger and smaller edge devices, some of which are more geared to "core-like" operation while others are not. One such "all edge" network, for example, is GEANT (http://www.geant.net/geant/about-geant.html). 4.3.2 EGP Generally BGP4 is the Edge gateway protocol of choice. The EGP routing table consists of networks, which are received via customer advertisements, statically configured for customers who are not running a dynamic routing protocol or networks that are nailed up as part of the ISP infrastructure. ==> It is also common practise to redistribute static routes, through safety checks of a route map. This is particularly enticing if the customer routes are part of larger aggregates, that is, even if the customer link flaps, no BGP updates/withdrawals are propagated to the Internet, only to the internal topology of the ISP. 4.3.4 Multicast PIM-SM is the generally accepted solution for deploying multicast. ==> a lot of stuff should be added here in the future, on PIM, MBGP, MSDP, RP's, BSR, whether customers use your RP, etc.etc. I could contribute something even. 4.5. Security ==> protecting routers (e.g. access lists that prevent telnet/ssh access, other methods, account management, etc.) should be described. 4.5.1 Intrusion Detection Intrusion detection mechanisms and systems are used to protect infrastructure and host gear. Generally these intrusion detection systems are placed at various points within the network to search for vulnerabilities within the infrastructure as well as monitor activity that may be considered suspicious. ==> what infrastructure you're talking about? Certainly, I think it's quite rare to see IDS systems deployed to protect routers. They're more of protecting the management systems which are used to control the network, if anything. 4.5.2 Ingress Filtering Ingress filtering on CORE networks comes in multiple flavors. For providers that do filter, the first level is EGP filtering. When a peering session is setup, ISPs require a peer to register their routes in an IRR and that data is used to create an EGP filter on the peering session to only accept registered advertised routes. ==> there are also manually configured access lists, e.g. lists that disallow any more specifics from your aggregates (inbound or outbound). Of course, with todays errant multihoming practises, this may not be possible for some ISP's. ==> speaking of which, one should probably spend some time describing mechanisms which are used for multihoming the backbone network (trivial) and multihoming the customers (more related to access networks). Customer Premises NAP NSP <-------------------------> <---------------> <--------------------> +-----+ +-------+ +-----+ +--------+ +-----------+ |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP +-----+ +-------+ |Modem| +--------+ | Edge +==> Network +-----+ | Router | +-----------+ <----------------------------> ATM Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ | +-----+ +-------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP | +-----+ +-------+ +--------+ +----------+ | Edge +=>Core | Router | +-----------+ <--------------------------> PPP ==> some DSL figures include DSL model while others don't. Sync that up. (Note: I've mentioned this before, too, I'm getting tired of repeating myself.) 7.2. Hardware The hardware involved in dialup service provider connections include the CPE device that is usually a 56K modem, the Terminal server/modem bank and an authentication server. ==> also in some other places, I believe "narrowband" also applies to ISDN connections. +----------+ +-------+ | IP | | IP | +----------+ +-----------+ +-------+ | Wireless | | Bridging | | | | | LAN | +-----------+ | X | Y | | | |WLAN | X | | | | +----------+ +-----+-----+ +---+---+ ==> the model of WLAN section seems to build on the fact that AP acts as a bridge. This is not necessarily the case. AP can also be a router (when AP and router are co-located). 8.4 Security ==> Note that even 801.11x with extensions does not give protection; there is always the issue of a host and AP being certain that they are in fact talking to each other (a man-in-the-middle attack). Not sure if this needs to said in the draft (and this is why why some e.g. force the use of VPNs usings IPsec in WLAN's, even though this is not typical in hotspot-like activities) An IX is based on a layer 2 infrastructure that can be, either local to given building, or distributed over a large are by the way multiple interconnected point of presence. This layer 2 ==> note that there are also Layer-3 exchanges (the same applies to IPv4 -- there is zero differences there) ==> another issue to describe is how, in a L2 model, connections are established: ie, one big L2 mesh, or e.g. point-to-point L2 (e.g. through peer-to-peer VLAN's or ATM PVC's). ==> an issue to note is that in some L2 systems, multicast and/or IPv6 are separated in different VLAN's and PVC's. (This has some advantageous consequences.) 10.1.1 Hardware Basically, a regular IX is based on a layer 2 switch, or set of layer 2 switches that may either local to a building, or distributed over larger area. It provides also room space and power supply to enable long haul providers to install their own routers and to exchange routes to each other according to a peering agreement. ==> the last sentence is not correct: IX's are in no way forced to provide any room space or supply for routers. In many cases, they don't. Providers connect to the IX using a circuit, which is hooked up to the L2 fabric. Semi/Editorial: --------------- The local border routers are route reflector clients of the core. ==> add "often" or "sometimes" here, this is by far not always the case In some cases CPE equipment is provided by the CORE ISP. ==> irrelevant in the context of core/backbone networks. Customer routes are pinned up on core routers. ==> I'm not sure what you're trying to say; please use a bit more formal language, same under Aggregation and elsewhere. 5.3.2 CMTS Layer-2 Bridge IPv6 is then deployed on the ISP router infrastructure natively or using an automatic tunneling scheme like 6to4[RFC3056]. ==> move this kind of text to the solutions document. In an ideal world every IPv4 NAT router would be upgraded to additionally become a native IPv6 router using 6to4 automatic tunneling. In general 6to4 residential gateway devices must be made as self-configuring as existing IPv4 NAT routers. ==> likewise. If the CMTS is a native IPv6 router then it will likely need to participate in ISPs the IGP of choice. If the CMTS is a bridge, the infrastructure router(s) that it connects to will need to speak an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP sink (and forward) traffic to the anycast 6to4 relay router address [RFC3068]. ==> such as above, talk more of _IPv4_ scenarios! Existing IPv4 filter software will not block IPv6 communication. If IPv6 is tunneled over an IPv4 infrastructure filters may need to examine the contents of encapsulated packets. ==> likewise. 5.8 Host Gear Dual stack DNS server is necessary if you want to support IPv6-only CPE equipment. DDNS is pretty much mandatory if you want to give CPE devices DNS names. This is because only the IPv6 host knows what its full IPv6 address is (esp when privacy addresses are used). Transition functionality.. which? where? v4/v6 translation between devices in the home is done where? If RFC1918 addresses are in use (perhaps behind the NAT), then there isn't much choice but to do it inside the CPE box. Transparent proxy caches aren't going to cache IPv6 web traffic. ==> talk about v4, not about v6. Almost all of this should go to the solutions doc. Customer Premises | Network Access Provider | Network Service Provider CP NAP NSP +-----+ +-----+ +-----+ |Hosts|--| DSL +-------+DSLAM| +-----+ |Modem| | +----+ +-----+ +-----+ | | +-----+ +------+ | +-----+ +-------+ |Hosts|--|Router| +--+ BAS +----+ ISP | ISP +-----+ +--+---+ +--+ | | Edge +===> Network | | +-----+ | Router| +--+--+ | +-------+ | DSL +---+ | |Modem| | | +-----+ | | | +-----+ | +-----+ +------+ +---+DSLAM+----+ |Hosts|--|Router| +---+ | +-----+ +--+---+ | +-----+ | | +--+--+ | | DSL +---+ |Modem| +-----+ ==> I'd replace the last one with the scenario where a host is directly attached to the DSLAM, through a DSL PCI/ISA card. This changes certain assumptions slightly. (Broadband Access Server = DSLAM aggregator), which is in charge of directing them to the POP (Point Of Presence = the ISP Edge ==> I'd rather see that the term "POP" (here and later) would not be used in this context. We're mixing layers here. PoP is a layer 1 term (physical location and place of the connection, where the eqipment is), not layer 2 or 3. Figure 6.2.2.2 ==> this figure is identical to 6.2.2.1, we can very well live with just one of them, thanks -- same in other a few other figures :-) addresses today. Customers are usually disconnected every day ==> "often" or "sometimes" rather than "usually" IRR routing policy is generally registered by the ISP or NSP but in some cases the dialup provider may register policy. ==> it's not probably obvious to all readers what you mean so that should be expanded a bit. 9.3 Routing IGP The interior routing for Ethernet access doesn't differ to any other routing used with in one particular ISP. The routing protocols normally used are IS-IS or OSPF. EGP BGP is used for exchanging external routes. Exterior routing is not used towards the end customers since the customer networks are seen as being directly connected to the edge router and not having a CPE router in between. This means that the customer network is routed directly to an interface on the edge router and not to a customer router. ==> under broadband ethernet, a shorter explanation why IGP/EGP does not apply would probably be just as good. An IPv6 IX, unlike current NAPs, may assign independent long-haul provider addresses, according to [RFC2374]. An organization subscribing such addresses will be able to change long-haul provider without having to renumber. ==> solutions category (note that this text is mostly outdated anyway, as 2374 is getting historic) According to [RFC2374] aggreatable addresses are organized into a three level hierarchy. IXs, together with long haul providers, belong the higher one called "Public Topology". IXs will allocate IPv6 addresses to its directly connected subscribers, providing them addressing independence from long haul providers. IX will then have to include layer 3 functions, e.g. by the means of a router, in order to exchange routes with long haul provider, for gaining global connectivity to its subscribers. The figure below, describes such a new type of IX introducing layer 3 functions, and that topology differs from regular IPv4 IX. ==> ditto (some bits could maybe be left here) ==> figure 10.1b can probably also go. In the case of an IX providing independent addresses to its directly connected subscribers, the needed layer 3 function will be based on a regular IPv6 router. ==> same here. REFERENCES [01] TR-025 Core Network Architecture for Access to Legacy Data Networks over ADSL, TR-025 - ADSL Forum, September 1999 [02] RFC 1661 The Point-to-Point Protocol (PPP) ==> split the references and add them in the proper format. Editorial: ---------- This section describes the general topologies of and characteristics of today's CORE networks. Although there are ==> s/topologies of/topologies/ aggregation of long haul circuits to remote sites. The ==> s/haul /haul / Loopback interfaces and point-to-point links are what make up routes within the IGP. ==> s/are what make up routes/make up the routes/ peers. In the case of customer connections, there are peer groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES or DEFAULT-ROUTES to a particular set of customers. To perform ==> any particular reason to put these in uppercase? routed connection. Cacheing infrastructure is deployed in CORE ==> s/Cacheing/Caching/ router. It is usually connected between the cable modem and all other CPE equipment allows multiple devices to share a single ==> s/allows/allowing/ configuration overhead. The NAT/DHCP router is a directional IPv4-only device in the communication path between the CMTS and the CPE. ==> "directional" ? I can only try to guess what you mean, reword. CPE NAT boxes are rectifying routers. This can be viewed as an implementation of an "outgoing only" security policy. ==> likewise with "rectifying". ToD [RFC0868] for initial time synchronization. ==> "ToD" is an unknown abbreviation for me, don't use it. Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI ==> same for "RF". 6. Broadband DSL Networks This section describes the infrastructure that exists in todays High Speed DSL Networks. ==> s/todays/today's/ The hosts are connected to the DSL network either directly through a modem, either through a router and a modem. ==> reword at least the second line, I'm having trouble parsing it. opened to each NSP, but several PVCs are sometimes used when the NSP offers differentiated services (QoS...). ==> reword the last line to better integrate QoS if a referral to it is necessary. results in a decrease of the MSS of TCP that applications should ==> MSS needs to be spelled out. 6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL ==> all the headings need to be in a proper format, in this case: L2TP Access Aggregation (LAA) Model presence, via a L2TP tunnel. When a CPE initiates a session with ==> is it "an L2TP" or "a L2TP"? Typically if you pronounce that, you'd say "an el-two-tee-pee", but I guess putting "a" as for the written form would also be ok. and are given a new address each time they reconnect. Most of the times, ==> s/times/time/ majority of internet users use today to get online. The scenarios will include solutions where the dial infrastructure is controlled by one entity as well as solutions where ISPs lease modems from a wholesale modem providers. ==> s/a wholesale/wholesale/, or some other rewording. made the user credentials are sent to the Authentication server. ==> s/A/a/ (IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps (IEEE 802.11a). ==> a lot of other stds also give (theoretical) 54 Mbps as you know -- perhaps change: s/IEEE 801.11a/IEEE 801.11a and others/. mechanisms are presented in 3.x.5 in detail. Once the host is authenticated, AP acts as a bridge in order to relay host's information to ISP or vice versa. Various access network technologies can be used between AP and ISP. Lease line, xDSL ==> 3.x.5 ?? ==> s/Lease/Leased/ ISPs supply not static addresses by default but dynamic addresses by DHCP. ==> reword this completely. they reconnect. Most of the times, customers use private ==> s/times/time/ ISPs may need to configure traffic filtering or provisioning on demand of their customers. ==> reword Like ethernet, IEEE 802.11 standard dose not define authentication and security mechanisms. ==> s/eth/Eth/ ==> s/dose/does/ Moreover, WLAN is basically a broadcast network and each host can listen information of another host within the same AP service area. ==> reword the last two lines, especially "listen information of another host".. This mechanism supports host that does not support IEEE 802.1x. ==> s/host that does/hosts that do/ Therefore, very complicated data privacy mechanism must be provided in order not to be revealed by other hosts except intended host. ==> reword from "releveled..." 9.1. Topology Physical The layouts of Ethernet based accesses to the home are all almost identical. They usually consist in a star topology terminated in ==> different formatting with subtitles, please. ==> s/consist in/consist of/ some cases used. It can consist of web login or PPPoE. Web login can be done in two ways, one time login where the device's MAC- address is registered and kept or session login where login is ==> s/one time/as one time/ ==> s/session login/as session login/ local to given building, or distributed over a large are by the way multiple interconnected point of presence. This layer 2 infrastructure enables players (e.g. long haul providers) ==> s/are by the way/area in/ ==> s/presence/precences/ ==> use a more formal&better term than "player". :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 9 13:57:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13215 for ; Sun, 9 Mar 2003 13:57:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s5yh-0006bD-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 10:56:55 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18s5yf-0006b1-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 10:56:53 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA22291; Sun, 9 Mar 2003 10:56:46 -0800 (PST) Message-Id: <5.1.0.14.2.20030309135047.0667d098@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 13:52:40 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Final agenda for v6ops in San Francisco Cc: Bob Fink , Itojun Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_50_70,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folk, Below is the final agenda for v6ops. WEDNESDAY, March 19, 2003 0900-1130 Morning Sessions Imperial A OPS v6ops IPv6 Operations WG Thanks, Margaret, Itojun & Bob === v6ops agenda IETF-56 San Francisco status of v6ops projects - Wasserman, 10 mins 3GPP Analysis draft - Wiljakka, 20 mins UNMAN analysis draft - Huitema, 20 mins ISP Scenarios - Lind, 10 mins Enterprise Scenarios - Pouffary, 20 mins IPv4 Survey draft restructuring - Nesser or chairs, 10 mins Introduction Application area General area Operations & Management area Internet area Routing area Security area Sub-IP area Transport area Mech draft - Nordmark, 15 mins Translation Issues - van der Poel, 15 mins Translation Issues - Durand, 15 mins Discussion of what to do with NAT-PT - Wasserman, 10 mins Operational experience with turning IPv6 on by default - Durand, 10 mins From owner-v6ops@ops.ietf.org Sun Mar 9 14:52:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23190 for ; Sun, 9 Mar 2003 14:52:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s6s6-0008Pk-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 11:54:10 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18s6s3-0008PX-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 11:54:07 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA04449 for ; Sun, 9 Mar 2003 11:54:00 -0800 (PST) Message-Id: <5.1.0.14.2.20030309145048.066a2d18@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 14:52:56 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_00_01,SUBJ_MISSING version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In addition to our agenda details, you may also be interested to know that at the OPS area meeting in SF (Thursday, March 20 at 1300-1700) there will be a 30 min presentation on v6ops. It is expected to cover our scenarios work, coexistence strategies and architecture, and security issues. Margaret From owner-v6ops@ops.ietf.org Sun Mar 9 16:27:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09253 for ; Sun, 9 Mar 2003 16:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s8KD-000BTK-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 13:27:17 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18s8KA-000BT3-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 13:27:14 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA28030 for ; Sun, 9 Mar 2003 21:27:13 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA21499 for ; Sun, 9 Mar 2003 21:27:13 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h29LRCN20204 for v6ops@ops.ietf.org; Sun, 9 Mar 2003 21:27:12 GMT Date: Sun, 9 Mar 2003 21:27:12 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Document Review: Volunteers Needed Message-ID: <20030309212712.GB20122@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Margaret, So long as comments are sent to the list, I think this is fine. Any carrot to get more comments has to be a good thing. I would have reservations if discussions were held off-list though, even if it meant improved quality, because openness is also important :) Tim On Wed, Mar 05, 2003 at 10:33:55PM -0500, Margaret Wasserman wrote: > > Hi All, > > The recent poor response to our document last calls (2 > comments for one document, 4 comments for the other) is > insufficient to justify advancing these documents to the > IESG. > > Before we advance these document, or any documents, to the > IESG, we want to be certain that they have been reviewed by > a significant number of people representing a cross-section > of areas of expertise. > > In an effort to fix this problem, Bob, Itojun and I are > considering forming a semi-official v6ops document review team. > > This team would consist of people who are willing to spend a > couple of hours reviewing and commenting on v6ops documents at > each stage of the process -- WG acceptance, major intermediate > revisions, WG last call(s), revisions to address IESG comments, > etc. > > The review team would be chosen from a pool of volunteers to > represent a broad range of knowledge and expertise, and members > would be removed if they are too frequently non-responsive. All > review comments would be sent to the list, and treated like any > individual comments. > > Like most new processes, we don't know exactly how this > would work, and there will probably be bugs to work out > over time... But, we strongly feel that we have to do > something to ensure that our documents are well reviewed > before they are accepted by the WG and/or advanced to the > IESG. We also hope that our efforts may serve as a useful > model for improvements in this area throughout the IETF. > > What does the WG think about this idea? > > If you think that this is a good idea, how could we give > credit to this team? Perhaps list them on the v6ops > alternate web-site, and list them as "technical reviewers" > in the acknowledgements section of our published > documents? > > Who would be willing to volunteer for this type of role? > > Thanks, > Margaret > > > From owner-v6ops@ops.ietf.org Sun Mar 9 16:36:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10769 for ; Sun, 9 Mar 2003 16:36:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s8UZ-000Bsw-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 13:37:59 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18s8UV-000Bsh-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 13:37:55 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.14]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA28216; Sun, 9 Mar 2003 13:37:15 -0800 (PST) Message-Id: <5.1.0.14.2.20030309163548.03459920@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 16:36:11 -0500 To: Tim Chown From: Margaret Wasserman Subject: Re: Document Review: Volunteers Needed Cc: v6ops@ops.ietf.org In-Reply-To: <20030309212712.GB20122@login.ecs.soton.ac.uk> References: <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> <5.1.0.14.2.20030305223135.0345c138@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tim, >So long as comments are sent to the list, I think this is fine. Any carrot >to get more comments has to be a good thing. I would have reservations >if discussions were held off-list though, even if it meant improved quality, >because openness is also important :) I definitely agree. Margaret From owner-v6ops@ops.ietf.org Sun Mar 9 20:59:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28029 for ; Sun, 9 Mar 2003 20:59:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sCZh-000Lr3-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 17:59:33 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sCZc-000Lqr-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 17:59:29 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 814BA7E99; Sun, 9 Mar 2003 20:59:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 20:59:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Sun, 9 Mar 2003 20:59:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAC@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLllvWpiI0qbD4tQdSqmZTpEGFaQwBEWL7A From: "Bound, Jim" To: "Sebastien Roy" , "Ronald van der Pol" Cc: "Alain Durand" , , X-OriginalArrivalTime: 10 Mar 2003 01:59:27.0497 (UTC) FILETIME=[AE6B7F90:01C2E6A8] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA28029 Sebastien, The default route would always be known and PPA to send to simply from RAs, if nothing else were known by the end node. Are you suggesting a change to ND or to configuration of the network as potential outcome. /jim >-----Original Message----- >From: Sebastien Roy [mailto:Sebastien.Roy@sun.com] >Sent: Saturday, March 08, 2003 12:17 PM >To: Ronald van der Pol >Cc: Alain Durand; v6ops@ops.ietf.org; jim.Paugh@sun.com >Subject: Re: dual stack & IPv6 on by default > > >Ronald, > >Thanks for reading the draft: > >Ronald.vanderPol@rvdp.org said: >> 2. No IPv6 Router >> >> Neighbor Discovery's [1] conceptual sending algorithm >dictates that >> when sending a packet to a destination, if a host's default router >> list is empty, then the host assumes that the destination is >> on-link. >> >> Hmm, that sounds reasonable in an IPv6-only environment, but >not in a >> dual stack environment. A good example why this document is useful. > >I don't think I see how this would be reasonable even in an >IPv6-only environment. Let's assume there are billions of >IPv6 devices out there. If you have no route (and I do think >that at the very least the ND spec should say route instead of >default route in this case) to one of those billions of >devices, what are the odds that it happens to reside on your >link? This bit of ND is an optimization for a very rare case >at the expense of very a common case (you actually can't reach >the destination). Quickly notifying the application that >there's no route to the destination so that the user can >correctly configure routes (on-link or off) seems better than >sitting there for minutes while TCP times out the larval connection. > >> >> 4. Poor IPv6 Network Performance >> >> >> Is this different from IPv4-only networks? In such networks >there can >> also be different paths and the path with the lowest cost >can have the >> highest packet loss. > >Right, it's no different from an IPv4 or IPv6 only scenario >where the first destination picked for a connection is >reachable but has poor connectivity. One general solution to >this problem could be to actually connect to all destinations >in parallel, somehow determine which one has the best >connectivity, and close all of the other ones. I've been told >that this kind of approach has been discussed in a few context >at the IETF. > >> >> >> 4.1. Dealing with Poor IPv6 Network Performance >> >> Not much can be done in this case other than configure each node to >> prefer IPv4 destinations over IPv6. >> >> A lot can be done, the network should be fixed :-) I think you mean >> the end host can not do much. > >Right, we should be more clear. > >> Preferring IPv4 over IPv6 could be one >> solution. Another could be disabling IPv6. That may be >clearer to the >> end user. It basically says: don't enable IPv6 unless you >are sure you >> have good IPv6 connectivity (or know what you are doing). > >Thanks for your input, >-Seb > > > From owner-v6ops@ops.ietf.org Sun Mar 9 21:04:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28829 for ; Sun, 9 Mar 2003 21:04:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sCfY-000M0A-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 18:05:36 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18sCfV-000Lzx-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 18:05:33 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5030B7345; Sun, 9 Mar 2003 21:05:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 21:04:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Sun, 9 Mar 2003 21:04:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAD@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLlpgday/ut38MuRfi2WPe9JcoHnQBAswbA From: "Bound, Jim" To: "Mika Liljeberg" , "Sebastien Roy" Cc: "Ronald van der Pol" , "Alain Durand" , , X-OriginalArrivalTime: 10 Mar 2003 02:04:43.0029 (UTC) FILETIME=[6A7DDC50:01C2E6A9] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28829 >However, this rule *is* somewhat problematic with multihomed >hosts as well as in cases where network interfaces are set up >on-demand. In the former case, the packets apparently have to >be replicated to all links that have no default routers. In >the latter case, an application might trigger an on-demand >network interface setup. However, the packets from the >application would still be directed on-link, since it takes a >little while to receive and process a router advertisement. An >implementation that caches the routing decision will have >problems with this. Good point. But isn't it up to the implementation for links that had to deal with on-demand. As long as I have route for a link then I should apply it? The problem would be if the link information was not applied before the on-demand was accessed in a multi-home manner. But then I would assume destination unreachable would be the response to the application, though it should say link not known IMO. So isn't the multi-home scenario a two step problem. 1) the on-demand NIC has to see the link before used by the app, and 2) the implementation must be able to propogate attributes for multiple interfaces? /jim From owner-v6ops@ops.ietf.org Sun Mar 9 21:18:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01390 for ; Sun, 9 Mar 2003 21:18:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sCtC-000MK0-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 18:19:42 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18sCt9-000MJn-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 18:19:39 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0830F1569; Sun, 9 Mar 2003 21:19:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 21:19:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Sun, 9 Mar 2003 21:19:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240FF7@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLlrdAPnmS5oTydShS3BNMjlwwrngA+62ow From: "Bound, Jim" To: "Sebastien Roy" , "Mika Liljeberg" Cc: "Ronald van der Pol" , "Alain Durand" , , X-OriginalArrivalTime: 10 Mar 2003 02:19:37.0196 (UTC) FILETIME=[7F74EAC0:01C2E6AB] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01390 >Ok, I agree that this would be the common case in an IPv6 only >network. If a random dual stack box that has IPv6 enabled is >placed in a random network out there, the common case today is >that it has no IPv6 default router, and this ND rule would be >problematic for it. That's what we were trying to get across >in this section of the draft. I suppose we need to more >explicitly specify in the draft what types of networks we're >concerned with. The worst case scenario would be 1 node coming up on IPv4 network with IPv6. But then it would have to use transition mechanism to speak IPv6. Selecting the best method based on the policy of the network administrator I will assume here. Is this a fairly good synopsis of your general concern within this draft? > >> > Quickly notifying the application that there's no route to the >> > destination so that the user can correctly configure >routes (on-link >> > or off) seems better than sitting there for minutes while >TCP times >> > out the larval connection. >> >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort >> immediately when ND determines that the destination is >unreachable, so >> TCP does not incur any additional delay here. > >Is that stated somewhere (it should be)? Should it be >explicitly stated in the nodes requirements? In practice, I >don't think many TCP implementations do this correctly (or as >you've described), and they should be fixed. I believe from my knowledge most TCP implementations do this correctly. The above rule is very well known by TCP implementers it has nothing to do with ND or IPv6. With all the specs and all the work why must we continue to put in specs what is already a defined process that is well defined. > Even if TCP is >fixed to abort connections, there is still a 3 second delay in >IP while NUD is being performed, which may or may not be That depends on how NUD cache was built. Your making an implementation judgement not a standards judgement. Also how one builds the NUD in the ND spec is a "conceptual" model not a required model just that the state changes are in fact supported. For all any of us know most have figured this out to avoid a 3 second delay and its down to 300 nanoseconds. If you want an optimization you should suggest one so we can discuss. >acceptable depending on how many IPv6 destinations the >application will try before trying IPv4. And some applications will never try IPv4 because they are not using IPv4 anymore for this application. We cannot assume in the logic premises for this discussion that ALL applications can just use IPv4 that is an invalid assumption I believe. And an incorrect way to solve IPv6 node "perceived" problems. >I can't see this as >being acceptable when a destination resolves to a few dozen >IPv6 addresses, for example. Your speaking of the route above? Or because of multiple DNS entries? > An immediate ICMP destination >unreachable/network unreachable from IP would be generated if >it didn't assume destinations were on-link. So you can't send to nodes not on the same link using host routes? This is very possible? Thanks /jim From owner-v6ops@ops.ietf.org Sun Mar 9 22:22:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13129 for ; Sun, 9 Mar 2003 22:22:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sDrz-000NlZ-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 19:22:31 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18sDrv-000NlN-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 19:22:27 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7DBE7AF8F; Sun, 9 Mar 2003 22:22:26 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 22:22:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Some Enterprise Scenarios comments Date: Sun, 9 Mar 2003 22:22:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240FFA@tayexc13.americas.cpqcorp.net> Thread-Topic: Some Enterprise Scenarios comments Thread-Index: AcLlm+LS/Jd3j3OvTQaU1FAryPMqXQBFhqcg From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 10 Mar 2003 03:22:26.0450 (UTC) FILETIME=[461B6F20:01C2E6B4] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA13129 Pekka, Thanks for the carful review. >Substantial: >------------ > >==> The approach in section 6 in M1-M6 seems, at places, a bit >solution-specific. In many cases it says "enterprise policy >is FOO". My point is that the document here is trying to >grasp IPV4 enterprise systems as they are, describe them, and >perhaps give some view on how to proceed with a solutions >document. The point of subsequent work of v6ops is to >give reasoning why a certain type of enterprise policy is >adopted -- not >(yet!) the other way around. The approach seems a bit >solutions-centric, >in particular with M2 and M3. So what your saying is to state the Enterprise need for IPv6? Each enterprise will adopt different reasons for IPv6. I don't think that is the job of this spec. The job of this spec is to identify scenarios how the enterprise will approach the problem. The M variable defines how that can be accomplished and the Enterprises are looking at the M variables before they move to IPv6, and this is only part of the specifications equation. Listing them is important for the context of how the enterprise arrives at their choice, is our thinking model. M2 and M3 are no different than the other M values. These are simply choices in strategy and if anything we are missing some values. > >Semi-editorial: >--------------- > >Abstract > > IPv6 will be deployed in Enterprise networks. This scenario has > requirements for the adoption of IPv6. > >==> This should be reworded; "this scenario" is ambiguous and >sounds bad, and the scope of the work here is not to set >requirements for IPv6 >adoption (rather, to describe the current IPv4 enterprise networks). This wording has changed 4 times on the team. But this is a good point. We on the team have never believed the mission here is to describe IPv4 enterprise networks. So we may not agree on a very basic premise. The job is to describe how IPv4 Enterprises will approach moving to IPv6. > > This document will focus upon > and define: a set of technology scenarios that shall exist for the > enterprise network, the set of transition variables, transition > methods, and tools required by different scenarios. [...] > >==> "transition methods" and especially "and tools required by >different >scenarios" seem too vague. My first impression was that the document >would be specifying which transition mechanisms (like 6to4, etc.etc.) >would be required. Luckily, this was not the case, but may >require some >more verbose text. I for one agree. Not going to respond to other comments till I feel we agree on the scope of the work. I am sure you can understand that because it affects all other responses. Regards, /jim From owner-v6ops@ops.ietf.org Mon Mar 10 01:50:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20877 for ; Mon, 10 Mar 2003 01:50:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sH85-0003tT-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 22:51:21 -0800 Received: from proxy1.addr.com ([209.249.147.28]) by psg.com with esmtp (Exim 3.36 #1) id 18sH7z-0003t6-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 22:51:15 -0800 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h2A6oqUM082662; Sun, 9 Mar 2003 22:50:53 -0800 (PST) Message-Id: <5.2.0.9.0.20030309193021.02811b28@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Mar 2003 22:50:49 -0800 To: Pekka Savola , v6ops@ops.ietf.org From: Bob Fink Subject: Re: Some ISP Scenarios Comments Cc: Margaret Wasserman , Jun-ichiro itojun Hagino , Mikael Lind In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=BALANCE_FOR_LONG_20K,IN_REP_TO,MSG_ID_ADDED_BY_MTA_3, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, At 06:23 PM 3/9/2003 +0200, Pekka Savola wrote: >Hi, > >I quickly re-read the ISP scenarios document, the previous version, -04. >I think most comments are probably applicable, as changes happened mainly >to the ISP section. > >In my opinion, the document is about ready to be accepted as a w.g. item. I have not yet read the -05 version, but the -04 version just outlines the IPv4 architecture of various ISP environments without giving any ipv6 transition scenarioz that are to be attempted/analyzed, i.e., no IPv6 context was given in the -04 version. Margaret, Itojun and I are not willing to have this considered as a wg draft until this is corrected. The -05 version may have added some of this, but I haven't reviewed it yet. Meanwhile the new lead/editor, Mikael Lind, is aware of our view of this and is generating a plan soon to bring the draft to the level we need it. Thanks for your efforts, Bob >There is a big editorial choice ahead, IMO, which is whether some "Access >Networks" specific stuff (about everything except under core/backbone and >IXP sections) should be "aggregated" somewhere. That is, there seems to >be no use repeating the same thing 5 times (e.g. about user >authentication, access routers, hosting gear, web caching infrastructure >etc.etc.), and only report the connectivity-specific stuff under the >appropriate sections. > >Comments below. > >Substantial: >------------ >Status of this Memo > This document is an Internet-Draft and is subject to all > Provisions of Section 10 of RFC2026. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its > areas, and its working groups. Note that other groups may also > >==> Here and elsewhere: the editorial quality and conformance to typical >format must improve. For example, in a lot of places, paragraphs should >be separated by empty lines, etc. Doing that makes reading the doc *a >lot* easier. > >==> I will make some direct contributions, if no one else comes first, >when the situation has improved. > > ___|___ ___|__ ___|___ >| | | | | | >| CPE1 | | CPE2 | | CPE(n)| >|_______| |______| |_______| > > >==> These should be named "Customer1", .. (n). Also in this section, >issues about CPE's etc. should really be split off: such should be dealt >under the appropriate access network scenarios section. > >==> I'm not certain how to best handle the generic "layer" between all the >access methods: there are certainly a lot of common elements, does >everything have to be repeated N times? That's something which one may >have to consider (e.g. whether to create "Access Networks" abstraction >layer explaining the generic stuff) > >4.1 Topology > >==> This, and some scenarios above, are too "core/edge" -separation >centric. There are a lot of networks which only include bigger and >smaller edge devices, some of which are more geared to "core-like" >operation while others are not. One such "all edge" network, for example, >is GEANT (http://www.geant.net/geant/about-geant.html). > >4.3.2 EGP > Generally BGP4 is the Edge gateway protocol of choice. The EGP > routing table consists of networks, which are received via > customer advertisements, statically configured for customers who > are not running a dynamic routing protocol or networks that are > nailed up as part of the ISP infrastructure. > >==> It is also common practise to redistribute static routes, through >safety checks of a route map. This is particularly enticing if the >customer routes are part of larger aggregates, that is, even if the >customer link flaps, no BGP updates/withdrawals are propagated to the >Internet, only to the internal topology of the ISP. > >4.3.4 Multicast > PIM-SM is the generally accepted solution for deploying multicast. > >==> a lot of stuff should be added here in the future, on PIM, MBGP, MSDP, >RP's, BSR, whether customers use your RP, etc.etc. I could contribute >something even. > >4.5. Security > >==> protecting routers (e.g. access lists that prevent telnet/ssh access, >other methods, account management, etc.) should be described. > >4.5.1 Intrusion Detection > Intrusion detection mechanisms and systems are used to protect > infrastructure and host gear. Generally these intrusion > detection systems are placed at various points within the network > to search for vulnerabilities within the infrastructure as well > as monitor activity that may be considered suspicious. > >==> what infrastructure you're talking about? Certainly, I think it's >quite rare to see IDS systems deployed to protect routers. They're more >of protecting the management systems which are used to control the >network, if anything. > >4.5.2 Ingress Filtering > Ingress filtering on CORE networks comes in multiple flavors. > For providers that do filter, the first level is EGP filtering. > When a peering session is setup, ISPs require a peer to register > their routes in an IRR and that data is used to create an EGP > filter on the peering session to only accept registered > advertised routes. > >==> there are also manually configured access lists, e.g. lists that >disallow any more specifics from your aggregates (inbound or outbound). >Of course, with todays errant multihoming practises, this may not be >possible for some ISP's. > >==> speaking of which, one should probably spend some time describing >mechanisms which are used for multihoming the backbone network (trivial) >and multihoming the customers (more related to access networks). > > > Customer Premises NAP NSP ><-------------------------> <---------------> <--------------------> > >+-----+ +-------+ +-----+ +--------+ +-----------+ >|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP >+-----+ +-------+ |Modem| +--------+ | Edge +==> Network > +-----+ | Router | > +-----------+ > <----------------------------> > ATM > > Customer Premises NAP NSP ><--------------------> <----------------------> <-----------------> > > +-----------+ > | AAA | > +-------+ Radius | > | | TACACS | > | +-----------+ > | >+-----+ +-------+ +--------+ +----+-----+ +-----------+ >|Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP | >+-----+ +-------+ +--------+ +----------+ | Edge +=>Core > | Router | > +-----------+ > <--------------------------> > PPP > >==> some DSL figures include DSL model while others don't. Sync that up. >(Note: I've mentioned this before, too, I'm getting tired of repeating >myself.) > >7.2. Hardware > The hardware involved in dialup service provider connections > include the CPE device that is usually a 56K modem, the Terminal > server/modem bank and an authentication server. > >==> also in some other places, I believe "narrowband" also applies to ISDN >connections. > >+----------+ +-------+ >| IP | | IP | >+----------+ +-----------+ +-------+ >| Wireless | | Bridging | | | | >| LAN | +-----------+ | X | Y | >| | |WLAN | X | | | | >+----------+ +-----+-----+ +---+---+ > >==> the model of WLAN section seems to build on the fact that AP acts as a >bridge. This is not necessarily the case. AP can also be a router (when >AP and router are co-located). > >8.4 Security > >==> Note that even 801.11x with extensions does not give protection; there >is always the issue of a host and AP being certain that they are in fact >talking to each other (a man-in-the-middle attack). Not sure if this >needs to said in the draft (and this is why why some e.g. force the use of >VPNs usings IPsec in WLAN's, even though this is not typical in >hotspot-like activities) > > An IX is based on a layer 2 infrastructure that can be, either > local to given building, or distributed over a large are by the > way multiple interconnected point of presence. This layer 2 > >==> note that there are also Layer-3 exchanges (the same applies to IPv4 >-- there is zero differences there) > >==> another issue to describe is how, in a L2 model, connections are >established: ie, one big L2 mesh, or e.g. point-to-point L2 (e.g. through >peer-to-peer VLAN's or ATM PVC's). > >==> an issue to note is that in some L2 systems, multicast and/or IPv6 are >separated in different VLAN's and PVC's. (This has some advantageous >consequences.) > >10.1.1 Hardware > > Basically, a regular IX is based on a layer 2 switch, or set of > layer 2 switches that may either local to a building, or > distributed over larger area. It provides also room space and > power supply to enable long haul providers to install their own > routers and to exchange routes to each other according to a > peering agreement. > >==> the last sentence is not correct: IX's are in no way forced to provide >any room space or supply for routers. In many cases, they don't. >Providers connect to the IX using a circuit, which is hooked up to the L2 >fabric. > >Semi/Editorial: >--------------- > >The local border routers are > route reflector clients of the core. > >==> add "often" or "sometimes" here, this is by far not always the case > >In some cases CPE equipment is provided by the > CORE ISP. > >==> irrelevant in the context of core/backbone networks. > > Customer routes are pinned up on core routers. > >==> I'm not sure what you're trying to say; please use a bit more formal >language, same under Aggregation and elsewhere. > >5.3.2 CMTS Layer-2 Bridge > > IPv6 is then deployed on the ISP router infrastructure natively > or using an automatic tunneling scheme like 6to4[RFC3056]. > >==> move this kind of text to the solutions document. > > In an ideal world every IPv4 NAT router would be upgraded to > additionally become a native IPv6 router using 6to4 automatic > tunneling. > In general 6to4 residential gateway devices must be made as > self-configuring as existing IPv4 NAT routers. > >==> likewise. > > If the CMTS is a > native IPv6 router then it will likely need to participate in > ISPs the IGP of choice. If the CMTS is a bridge, the > infrastructure router(s) that it connects to will need to speak > an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP > sink (and forward) traffic to the anycast 6to4 relay router address > [RFC3068]. > >==> such as above, talk more of _IPv4_ scenarios! > > Existing IPv4 filter > software will not block IPv6 communication. If IPv6 is tunneled > over an IPv4 infrastructure filters may need to examine the > contents of encapsulated packets. > >==> likewise. > >5.8 Host Gear > > Dual stack DNS server is necessary if you want to support > IPv6-only CPE equipment. > DDNS is pretty much mandatory if you want to give CPE devices DNS > names. This is because only the IPv6 host knows what its full > IPv6 address is (esp when privacy addresses are used). > Transition functionality.. which? where? > v4/v6 translation between devices in the home is done where? If > RFC1918 addresses are in use (perhaps behind the NAT), then there > isn't much choice but to do it inside the CPE box. > Transparent proxy caches aren't going to cache IPv6 web traffic. > >==> talk about v4, not about v6. Almost all of this should go to the >solutions doc. > >Customer Premises | Network Access Provider | Network Service Provider > CP NAP NSP > >+-----+ +-----+ +-----+ >|Hosts|--| DSL +-------+DSLAM| >+-----+ |Modem| | +----+ > +-----+ +-----+ | > | >+-----+ +------+ | +-----+ +-------+ >|Hosts|--|Router| +--+ BAS +----+ ISP | ISP >+-----+ +--+---+ +--+ | | Edge +===> Network > | | +-----+ | Router| > +--+--+ | +-------+ > | DSL +---+ | > |Modem| | | > +-----+ | | > | +-----+ | >+-----+ +------+ +---+DSLAM+----+ >|Hosts|--|Router| +---+ | >+-----+ +--+---+ | +-----+ > | | > +--+--+ | > | DSL +---+ > |Modem| > +-----+ > > >==> I'd replace the last one with the scenario where a host is directly >attached to the DSLAM, through a DSL PCI/ISA card. This changes certain >assumptions slightly. > > (Broadband Access Server = DSLAM aggregator), which is in charge > of directing them to the POP (Point Of Presence = the ISP Edge > >==> I'd rather see that the term "POP" (here and later) would not be used >in this context. We're mixing layers here. PoP is a layer 1 term >(physical location and place of the connection, where the eqipment is), >not layer 2 or 3. > > Figure 6.2.2.2 > >==> this figure is identical to 6.2.2.1, we can very well live with just >one of them, thanks -- same in other a few other figures :-) > > addresses today. Customers are usually disconnected every day > >==> "often" or "sometimes" rather than "usually" > > IRR > routing policy is generally registered by the ISP or NSP but in > some cases the dialup provider may register policy. > >==> it's not probably obvious to all readers what you mean so that should >be expanded a bit. > >9.3 Routing > IGP > The interior routing for Ethernet access doesn't differ to any > other routing used with in one particular ISP. > The routing protocols normally used are IS-IS or OSPF. > > EGP > BGP is used for exchanging external routes. > Exterior routing is not used towards the end customers since the > customer networks are seen as being directly connected to the > edge router and not having a CPE router in between. This means > that the customer network is routed directly to an interface on > the edge router and not to a customer router. > >==> under broadband ethernet, a shorter explanation why IGP/EGP does not >apply would probably be just as good. > > An IPv6 IX, unlike current NAPs, may assign independent long-haul > provider addresses, according to [RFC2374]. An organization > subscribing such addresses will be able to change long-haul > provider without having to renumber. > >==> solutions category (note that this text is mostly outdated anyway, as >2374 is getting historic) > > According to [RFC2374] aggreatable addresses are organized into a > three level hierarchy. IXs, together with long haul providers, > belong the higher one called "Public Topology". IXs will allocate > IPv6 addresses to its directly connected subscribers, providing > them addressing independence from long haul providers. IX will > then have to include layer 3 functions, e.g. by the means of a > router, in order to exchange routes with long haul provider, for > gaining global connectivity to its subscribers. The figure below, > describes such a new type of IX introducing layer 3 functions, > and that topology differs from regular IPv4 IX. > >==> ditto (some bits could maybe be left here) >==> figure 10.1b can probably also go. > > In the case of an IX providing independent addresses to its > directly connected subscribers, the needed layer 3 function will > be based on a regular IPv6 router. > >==> same here. > >REFERENCES > [01] TR-025 Core Network Architecture for Access to Legacy Data > Networks over ADSL, TR-025 - ADSL Forum, September 1999 > > [02] RFC 1661 The Point-to-Point Protocol (PPP) > >==> split the references and add them in the proper format. > > >Editorial: >---------- > > This section describes the general topologies of and > characteristics of today's CORE networks. Although there are > >==> s/topologies of/topologies/ > > aggregation of long haul circuits to remote sites. The > >==> s/haul /haul / > > Loopback interfaces and point-to-point links are what make up > routes within the IGP. > >==> s/are what make up routes/make up the routes/ > > peers. In the case of customer connections, there are peer > groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES > or DEFAULT-ROUTES to a particular set of customers. To perform > >==> any particular reason to put these in uppercase? > > routed connection. Cacheing infrastructure is deployed in CORE > >==> s/Cacheing/Caching/ > > router. It is usually connected between the cable modem and all > other CPE equipment allows multiple devices to share a single > >==> s/allows/allowing/ > > configuration overhead. The NAT/DHCP router is a directional > IPv4-only device in the communication path between the CMTS and > the CPE. > >==> "directional" ? I can only try to guess what you mean, reword. > > CPE NAT boxes are rectifying routers. This can be viewed as an > implementation of an "outgoing only" security policy. > >==> likewise with "rectifying". > > ToD [RFC0868] for initial time synchronization. > >==> "ToD" is an unknown abbreviation for me, don't use it. > > Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI > >==> same for "RF". > >6. Broadband DSL Networks > > This section describes the infrastructure that exists in todays > High Speed DSL Networks. > >==> s/todays/today's/ > > The hosts are connected to the DSL network either directly > through a modem, either through a router and a modem. > >==> reword at least the second line, I'm having trouble parsing it. > > opened to each NSP, but several PVCs are sometimes used when the > NSP offers differentiated services (QoS...). > >==> reword the last line to better integrate QoS if a referral to it is >necessary. > > results in a decrease of the MSS of TCP that applications should > >==> MSS needs to be spelled out. > >6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL > >==> all the headings need to be in a proper format, in this case: > > L2TP Access Aggregation (LAA) Model > > presence, via a L2TP tunnel. When a CPE initiates a session with > >==> is it "an L2TP" or "a L2TP"? Typically if you pronounce that, you'd >say "an el-two-tee-pee", but I guess putting "a" as for the written form >would also be ok. > > and are given a new address each time they reconnect. Most of > the times, > >==> s/times/time/ > > majority of internet users use today to get online. The > scenarios will include solutions where the dial infrastructure is > controlled by one entity as well as solutions where ISPs lease > modems from a wholesale modem providers. > >==> s/a wholesale/wholesale/, or some other rewording. > > made the user credentials are sent to the Authentication server. > >==> s/A/a/ > > (IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps > (IEEE 802.11a). > >==> a lot of other stds also give (theoretical) 54 Mbps as you know -- >perhaps change: s/IEEE 801.11a/IEEE 801.11a and others/. > > mechanisms are presented in 3.x.5 in detail. Once the host is > authenticated, AP acts as a bridge in order to relay host's > information to ISP or vice versa. Various access network > technologies can be used between AP and ISP. Lease line, xDSL > >==> 3.x.5 ?? >==> s/Lease/Leased/ > >ISPs supply not static addresses by default but > dynamic addresses by DHCP. > >==> reword this completely. > > they reconnect. Most of the times, customers use private > >==> s/times/time/ > > ISPs may need to configure traffic filtering or provisioning on > demand of their customers. > >==> reword > > Like ethernet, IEEE 802.11 standard dose not define > authentication and security mechanisms. > >==> s/eth/Eth/ >==> s/dose/does/ > > Moreover, WLAN is > basically a broadcast network and each host can listen > information of another host within the same AP service area. > >==> reword the last two lines, especially "listen information of another >host".. > > This mechanism supports host that does not support IEEE 802.1x. > >==> s/host that does/hosts that do/ > >Therefore, very complicated data privacy mechanism must > be provided in order not to be revealed by other hosts except > intended host. > >==> reword from "releveled..." > >9.1. Topology > Physical > The layouts of Ethernet based accesses to the home are all almost > identical. They usually consist in a star topology terminated in > >==> different formatting with subtitles, please. >==> s/consist in/consist of/ > > some cases used. It can consist of web login or PPPoE. Web login > can be done in two ways, one time login where the device's MAC- > address is registered and kept or session login where login is > >==> s/one time/as one time/ >==> s/session login/as session login/ > > local to given building, or distributed over a large are by the > way multiple interconnected point of presence. This layer 2 > infrastructure enables players (e.g. long haul providers) > >==> s/are by the way/area in/ >==> s/presence/precences/ >==> use a more formal&better term than "player". :-) > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Mar 10 02:01:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24534 for ; Mon, 10 Mar 2003 02:01:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sHJq-0004Iy-00 for v6ops-data@psg.com; Sun, 09 Mar 2003 23:03:30 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18sHJn-0004Ij-00 for v6ops@ops.ietf.org; Sun, 09 Mar 2003 23:03:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2A73Lj23932; Mon, 10 Mar 2003 09:03:21 +0200 Date: Mon, 10 Mar 2003 09:03:21 +0200 (EET) From: Pekka Savola To: Bob Fink cc: v6ops@ops.ietf.org, Margaret Wasserman , Jun-ichiro itojun Hagino , Mikael Lind Subject: Scenarios documents: IPv4 vs IPv6 material? [Re: Some ISP Scenarios Comments] In-Reply-To: <5.2.0.9.0.20030309193021.02811b28@mail.addr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Sun, 9 Mar 2003, Bob Fink wrote: > At 06:23 PM 3/9/2003 +0200, Pekka Savola wrote: > >Hi, > > > >I quickly re-read the ISP scenarios document, the previous version, -04. > >I think most comments are probably applicable, as changes happened mainly > >to the ISP section. > > > >In my opinion, the document is about ready to be accepted as a w.g. item. > > I have not yet read the -05 version, but the -04 version just outlines the > IPv4 architecture of various ISP environments without giving any ipv6 > transition scenarioz that are to be attempted/analyzed, i.e., no IPv6 > context was given in the -04 version. There seems to be some confusion (see my comments on Enterprise Scenarios and Jim's reply) about what exactly the contents of "Enterprise scenarios" should be. At least on my part.. I was thinking that an "ideal" scenarios document would describe the scenarios with _IPv4_ (or with a protocol-agnostic way) with as much detail as possible, which would enable the _Solutions_ document to expand from there painlessly, to IPv6 situations, mechanisms and solutions. Of course, some text on IPv6 to scope the work better (non-solutions centric) might also be OK, but not too much. (3gpp-cases is a good example here, but may be difficult to compare against as it's quite restricted.) Perhaps this is something that is is needed to reach common understanding on? It should make writing the drafts easier too :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Mar 10 04:50:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05130 for ; Mon, 10 Mar 2003 04:50:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sJw7-0008om-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 01:51:11 -0800 Received: from tms001bb.han.telia.se ([131.115.230.132]) by psg.com with esmtp (Exim 3.36 #1) id 18sJw2-0008oY-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 01:51:06 -0800 Received: from tms031mb.han.telia.se ([131.115.230.163]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 10:51:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Some ISP Scenarios Comments Date: Mon, 10 Mar 2003 10:50:34 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE80123A6DB@TMS031MB.tcad.telia.se> Thread-Topic: Some ISP Scenarios Comments Thread-Index: AcLmWjQ50fWAJym7RkuUG7mJ4DIGRwAkAfZA From: To: , X-OriginalArrivalTime: 10 Mar 2003 09:51:03.0096 (UTC) FILETIME=[8FE94380:01C2E6EA] X-Spam-Status: No, hits=0.3 required=5.0 tests=BALANCE_FOR_LONG_20K,NO_REAL_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA05130 Hi, A complete revision of the document is underway. Since the current version doesn't cover IPv6 in any extent we have considered a completely new structure that will put more emphasis on different scenarios for IPv6 introduction instead of on the existing network structure. Although a new document is underway your comment will be useful, thank you for your extensive review. /Mikael Lind > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: den 9 mars 2003 17:23 > To: v6ops@ops.ietf.org > Subject: Some ISP Scenarios Comments > > Hi, > > I quickly re-read the ISP scenarios document, the previous version, -04. > I think most comments are probably applicable, as changes happened mainly > to the ISP section. > > In my opinion, the document is about ready to be accepted as a w.g. item. > > There is a big editorial choice ahead, IMO, which is whether some "Access > Networks" specific stuff (about everything except under core/backbone and > IXP sections) should be "aggregated" somewhere. That is, there seems to > be no use repeating the same thing 5 times (e.g. about user > authentication, access routers, hosting gear, web caching infrastructure > etc.etc.), and only report the connectivity-specific stuff under the > appropriate sections. > > Comments below. > > Substantial: > ------------ > Status of this Memo > This document is an Internet-Draft and is subject to all > Provisions of Section 10 of RFC2026. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its > areas, and its working groups. Note that other groups may also > > ==> Here and elsewhere: the editorial quality and conformance to typical > format must improve. For example, in a lot of places, paragraphs should > be separated by empty lines, etc. Doing that makes reading the doc *a > lot* easier. > > ==> I will make some direct contributions, if no one else comes first, > when the situation has improved. > > ___|___ ___|__ ___|___ > | | | | | | > | CPE1 | | CPE2 | | CPE(n)| > |_______| |______| |_______| > > > ==> These should be named "Customer1", .. (n). Also in this section, > issues about CPE's etc. should really be split off: such should be dealt > under the appropriate access network scenarios section. > > ==> I'm not certain how to best handle the generic "layer" between all the > access methods: there are certainly a lot of common elements, does > everything have to be repeated N times? That's something which one may > have to consider (e.g. whether to create "Access Networks" abstraction > layer explaining the generic stuff) > > 4.1 Topology > > ==> This, and some scenarios above, are too "core/edge" -separation > centric. There are a lot of networks which only include bigger and > smaller edge devices, some of which are more geared to "core-like" > operation while others are not. One such "all edge" network, for example, > is GEANT (http://www.geant.net/geant/about-geant.html). > > 4.3.2 EGP > Generally BGP4 is the Edge gateway protocol of choice. The EGP > routing table consists of networks, which are received via > customer advertisements, statically configured for customers who > are not running a dynamic routing protocol or networks that are > nailed up as part of the ISP infrastructure. > > ==> It is also common practise to redistribute static routes, through > safety checks of a route map. This is particularly enticing if the > customer routes are part of larger aggregates, that is, even if the > customer link flaps, no BGP updates/withdrawals are propagated to the > Internet, only to the internal topology of the ISP. > > 4.3.4 Multicast > PIM-SM is the generally accepted solution for deploying multicast. > > ==> a lot of stuff should be added here in the future, on PIM, MBGP, MSDP, > RP's, BSR, whether customers use your RP, etc.etc. I could contribute > something even. > > 4.5. Security > > ==> protecting routers (e.g. access lists that prevent telnet/ssh access, > other methods, account management, etc.) should be described. > > 4.5.1 Intrusion Detection > Intrusion detection mechanisms and systems are used to protect > infrastructure and host gear. Generally these intrusion > detection systems are placed at various points within the network > to search for vulnerabilities within the infrastructure as well > as monitor activity that may be considered suspicious. > > ==> what infrastructure you're talking about? Certainly, I think it's > quite rare to see IDS systems deployed to protect routers. They're more > of protecting the management systems which are used to control the > network, if anything. > > 4.5.2 Ingress Filtering > Ingress filtering on CORE networks comes in multiple flavors. > For providers that do filter, the first level is EGP filtering. > When a peering session is setup, ISPs require a peer to register > their routes in an IRR and that data is used to create an EGP > filter on the peering session to only accept registered > advertised routes. > > ==> there are also manually configured access lists, e.g. lists that > disallow any more specifics from your aggregates (inbound or outbound). > Of course, with todays errant multihoming practises, this may not be > possible for some ISP's. > > ==> speaking of which, one should probably spend some time describing > mechanisms which are used for multihoming the backbone network (trivial) > and multihoming the customers (more related to access networks). > > > Customer Premises NAP NSP > <-------------------------> <---------------> <--------------------> > > +-----+ +-------+ +-----+ +--------+ +-----------+ > |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP > +-----+ +-------+ |Modem| +--------+ | Edge +==> Network > +-----+ | Router | > +-----------+ > <----------------------------> > ATM > > Customer Premises NAP NSP > <--------------------> <----------------------> <-----------------> > > +-----------+ > | AAA | > +-------+ Radius | > | | TACACS | > | +-----------+ > | > +-----+ +-------+ +--------+ +----+-----+ +-----------+ > |Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP | > +-----+ +-------+ +--------+ +----------+ | Edge +=>Core > | Router | > +-----------+ > <--------------------------> > PPP > > ==> some DSL figures include DSL model while others don't. Sync that up. > (Note: I've mentioned this before, too, I'm getting tired of repeating > myself.) > > 7.2. Hardware > The hardware involved in dialup service provider connections > include the CPE device that is usually a 56K modem, the Terminal > server/modem bank and an authentication server. > > ==> also in some other places, I believe "narrowband" also applies to ISDN > connections. > > +----------+ +-------+ > | IP | | IP | > +----------+ +-----------+ +-------+ > | Wireless | | Bridging | | | | > | LAN | +-----------+ | X | Y | > | | |WLAN | X | | | | > +----------+ +-----+-----+ +---+---+ > > ==> the model of WLAN section seems to build on the fact that AP acts as a > bridge. This is not necessarily the case. AP can also be a router (when > AP and router are co-located). > > 8.4 Security > > ==> Note that even 801.11x with extensions does not give protection; there > is always the issue of a host and AP being certain that they are in fact > talking to each other (a man-in-the-middle attack). Not sure if this > needs to said in the draft (and this is why why some e.g. force the use of > VPNs usings IPsec in WLAN's, even though this is not typical in > hotspot-like activities) > > An IX is based on a layer 2 infrastructure that can be, either > local to given building, or distributed over a large are by the > way multiple interconnected point of presence. This layer 2 > > ==> note that there are also Layer-3 exchanges (the same applies to IPv4 > -- there is zero differences there) > > ==> another issue to describe is how, in a L2 model, connections are > established: ie, one big L2 mesh, or e.g. point-to-point L2 (e.g. through > peer-to-peer VLAN's or ATM PVC's). > > ==> an issue to note is that in some L2 systems, multicast and/or IPv6 are > separated in different VLAN's and PVC's. (This has some advantageous > consequences.) > > 10.1.1 Hardware > > Basically, a regular IX is based on a layer 2 switch, or set of > layer 2 switches that may either local to a building, or > distributed over larger area. It provides also room space and > power supply to enable long haul providers to install their own > routers and to exchange routes to each other according to a > peering agreement. > > ==> the last sentence is not correct: IX's are in no way forced to provide > any room space or supply for routers. In many cases, they don't. > Providers connect to the IX using a circuit, which is hooked up to the L2 > fabric. > > Semi/Editorial: > --------------- > > The local border routers are > route reflector clients of the core. > > ==> add "often" or "sometimes" here, this is by far not always the case > > In some cases CPE equipment is provided by the > CORE ISP. > > ==> irrelevant in the context of core/backbone networks. > > Customer routes are pinned up on core routers. > > ==> I'm not sure what you're trying to say; please use a bit more formal > language, same under Aggregation and elsewhere. > > 5.3.2 CMTS Layer-2 Bridge > > IPv6 is then deployed on the ISP router infrastructure natively > or using an automatic tunneling scheme like 6to4[RFC3056]. > > ==> move this kind of text to the solutions document. > > In an ideal world every IPv4 NAT router would be upgraded to > additionally become a native IPv6 router using 6to4 automatic > tunneling. > In general 6to4 residential gateway devices must be made as > self-configuring as existing IPv4 NAT routers. > > ==> likewise. > > If the CMTS is a > native IPv6 router then it will likely need to participate in > ISPs the IGP of choice. If the CMTS is a bridge, the > infrastructure router(s) that it connects to will need to speak > an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP > sink (and forward) traffic to the anycast 6to4 relay router address > [RFC3068]. > > ==> such as above, talk more of _IPv4_ scenarios! > > Existing IPv4 filter > software will not block IPv6 communication. If IPv6 is tunneled > over an IPv4 infrastructure filters may need to examine the > contents of encapsulated packets. > > ==> likewise. > > 5.8 Host Gear > > Dual stack DNS server is necessary if you want to support > IPv6-only CPE equipment. > DDNS is pretty much mandatory if you want to give CPE devices DNS > names. This is because only the IPv6 host knows what its full > IPv6 address is (esp when privacy addresses are used). > Transition functionality.. which? where? > v4/v6 translation between devices in the home is done where? If > RFC1918 addresses are in use (perhaps behind the NAT), then there > isn't much choice but to do it inside the CPE box. > Transparent proxy caches aren't going to cache IPv6 web traffic. > > ==> talk about v4, not about v6. Almost all of this should go to the > solutions doc. > > Customer Premises | Network Access Provider | Network Service Provider > CP NAP NSP > > +-----+ +-----+ +-----+ > |Hosts|--| DSL +-------+DSLAM| > +-----+ |Modem| | +----+ > +-----+ +-----+ | > | > +-----+ +------+ | +-----+ +-------+ > |Hosts|--|Router| +--+ BAS +----+ ISP | ISP > +-----+ +--+---+ +--+ | | Edge +===> Network > | | +-----+ | Router| > +--+--+ | +-------+ > | DSL +---+ | > |Modem| | | > +-----+ | | > | +-----+ | > +-----+ +------+ +---+DSLAM+----+ > |Hosts|--|Router| +---+ | > +-----+ +--+---+ | +-----+ > | | > +--+--+ | > | DSL +---+ > |Modem| > +-----+ > > > ==> I'd replace the last one with the scenario where a host is directly > attached to the DSLAM, through a DSL PCI/ISA card. This changes certain > assumptions slightly. > > (Broadband Access Server = DSLAM aggregator), which is in charge > of directing them to the POP (Point Of Presence = the ISP Edge > > ==> I'd rather see that the term "POP" (here and later) would not be used > in this context. We're mixing layers here. PoP is a layer 1 term > (physical location and place of the connection, where the eqipment is), > not layer 2 or 3. > > Figure 6.2.2.2 > > ==> this figure is identical to 6.2.2.1, we can very well live with just > one of them, thanks -- same in other a few other figures :-) > > addresses today. Customers are usually disconnected every day > > ==> "often" or "sometimes" rather than "usually" > > IRR > routing policy is generally registered by the ISP or NSP but in > some cases the dialup provider may register policy. > > ==> it's not probably obvious to all readers what you mean so that should > be expanded a bit. > > 9.3 Routing > IGP > The interior routing for Ethernet access doesn't differ to any > other routing used with in one particular ISP. > The routing protocols normally used are IS-IS or OSPF. > > EGP > BGP is used for exchanging external routes. > Exterior routing is not used towards the end customers since the > customer networks are seen as being directly connected to the > edge router and not having a CPE router in between. This means > that the customer network is routed directly to an interface on > the edge router and not to a customer router. > > ==> under broadband ethernet, a shorter explanation why IGP/EGP does not > apply would probably be just as good. > > An IPv6 IX, unlike current NAPs, may assign independent long-haul > provider addresses, according to [RFC2374]. An organization > subscribing such addresses will be able to change long-haul > provider without having to renumber. > > ==> solutions category (note that this text is mostly outdated anyway, as > 2374 is getting historic) > > According to [RFC2374] aggreatable addresses are organized into a > three level hierarchy. IXs, together with long haul providers, > belong the higher one called "Public Topology". IXs will allocate > IPv6 addresses to its directly connected subscribers, providing > them addressing independence from long haul providers. IX will > then have to include layer 3 functions, e.g. by the means of a > router, in order to exchange routes with long haul provider, for > gaining global connectivity to its subscribers. The figure below, > describes such a new type of IX introducing layer 3 functions, > and that topology differs from regular IPv4 IX. > > ==> ditto (some bits could maybe be left here) > ==> figure 10.1b can probably also go. > > In the case of an IX providing independent addresses to its > directly connected subscribers, the needed layer 3 function will > be based on a regular IPv6 router. > > ==> same here. > > REFERENCES > [01] TR-025 Core Network Architecture for Access to Legacy Data > Networks over ADSL, TR-025 - ADSL Forum, September 1999 > > [02] RFC 1661 The Point-to-Point Protocol (PPP) > > ==> split the references and add them in the proper format. > > > Editorial: > ---------- > > This section describes the general topologies of and > characteristics of today's CORE networks. Although there are > > ==> s/topologies of/topologies/ > > aggregation of long haul circuits to remote sites. The > > ==> s/haul /haul / > > Loopback interfaces and point-to-point links are what make up > routes within the IGP. > > ==> s/are what make up routes/make up the routes/ > > peers. In the case of customer connections, there are peer > groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES > or DEFAULT-ROUTES to a particular set of customers. To perform > > ==> any particular reason to put these in uppercase? > > routed connection. Cacheing infrastructure is deployed in CORE > > ==> s/Cacheing/Caching/ > > router. It is usually connected between the cable modem and all > other CPE equipment allows multiple devices to share a single > > ==> s/allows/allowing/ > > configuration overhead. The NAT/DHCP router is a directional > IPv4-only device in the communication path between the CMTS and > the CPE. > > ==> "directional" ? I can only try to guess what you mean, reword. > > CPE NAT boxes are rectifying routers. This can be viewed as an > implementation of an "outgoing only" security policy. > > ==> likewise with "rectifying". > > ToD [RFC0868] for initial time synchronization. > > ==> "ToD" is an unknown abbreviation for me, don't use it. > > Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI > > ==> same for "RF". > > 6. Broadband DSL Networks > > This section describes the infrastructure that exists in todays > High Speed DSL Networks. > > ==> s/todays/today's/ > > The hosts are connected to the DSL network either directly > through a modem, either through a router and a modem. > > ==> reword at least the second line, I'm having trouble parsing it. > > opened to each NSP, but several PVCs are sometimes used when the > NSP offers differentiated services (QoS...). > > ==> reword the last line to better integrate QoS if a referral to it is > necessary. > > results in a decrease of the MSS of TCP that applications should > > ==> MSS needs to be spelled out. > > 6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL > > ==> all the headings need to be in a proper format, in this case: > > L2TP Access Aggregation (LAA) Model > > presence, via a L2TP tunnel. When a CPE initiates a session with > > ==> is it "an L2TP" or "a L2TP"? Typically if you pronounce that, you'd > say "an el-two-tee-pee", but I guess putting "a" as for the written form > would also be ok. > > and are given a new address each time they reconnect. Most of > the times, > > ==> s/times/time/ > > majority of internet users use today to get online. The > scenarios will include solutions where the dial infrastructure is > controlled by one entity as well as solutions where ISPs lease > modems from a wholesale modem providers. > > ==> s/a wholesale/wholesale/, or some other rewording. > > made the user credentials are sent to the Authentication server. > > ==> s/A/a/ > > (IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps > (IEEE 802.11a). > > ==> a lot of other stds also give (theoretical) 54 Mbps as you know -- > perhaps change: s/IEEE 801.11a/IEEE 801.11a and others/. > > mechanisms are presented in 3.x.5 in detail. Once the host is > authenticated, AP acts as a bridge in order to relay host's > information to ISP or vice versa. Various access network > technologies can be used between AP and ISP. Lease line, xDSL > > ==> 3.x.5 ?? > ==> s/Lease/Leased/ > > ISPs supply not static addresses by default but > dynamic addresses by DHCP. > > ==> reword this completely. > > they reconnect. Most of the times, customers use private > > ==> s/times/time/ > > ISPs may need to configure traffic filtering or provisioning on > demand of their customers. > > ==> reword > > Like ethernet, IEEE 802.11 standard dose not define > authentication and security mechanisms. > > ==> s/eth/Eth/ > ==> s/dose/does/ > > Moreover, WLAN is > basically a broadcast network and each host can listen > information of another host within the same AP service area. > > ==> reword the last two lines, especially "listen information of another > host".. > > This mechanism supports host that does not support IEEE 802.1x. > > ==> s/host that does/hosts that do/ > > Therefore, very complicated data privacy mechanism must > be provided in order not to be revealed by other hosts except > intended host. > > ==> reword from "releveled..." > > 9.1. Topology > Physical > The layouts of Ethernet based accesses to the home are all almost > identical. They usually consist in a star topology terminated in > > ==> different formatting with subtitles, please. > ==> s/consist in/consist of/ > > some cases used. It can consist of web login or PPPoE. Web login > can be done in two ways, one time login where the device's MAC- > address is registered and kept or session login where login is > > ==> s/one time/as one time/ > ==> s/session login/as session login/ > > local to given building, or distributed over a large are by the > way multiple interconnected point of presence. This layer 2 > infrastructure enables players (e.g. long haul providers) > > ==> s/are by the way/area in/ > ==> s/presence/precences/ > ==> use a more formal&better term than "player". :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Mon Mar 10 07:53:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08914 for ; Mon, 10 Mar 2003 07:53:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sMmi-000DPh-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 04:53:40 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18sMme-000DPU-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 04:53:36 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 42999819D; Mon, 10 Mar 2003 07:53:33 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 07:53:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Scenarios documents: IPv4 vs IPv6 material? [Re: Some ISP Scenarios Comments] Date: Mon, 10 Mar 2003 07:53:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAC4@tayexc13.americas.cpqcorp.net> Thread-Topic: Scenarios documents: IPv4 vs IPv6 material? [Re: Some ISP Scenarios Comments] Thread-Index: AcLm14V9rCONkLKvTvWQX7FvIGobnQALDE7w From: "Bound, Jim" To: "Pekka Savola" , "Bob Fink" Cc: , "Margaret Wasserman" , "Jun-ichiro itojun Hagino" , "Mikael Lind" X-OriginalArrivalTime: 10 Mar 2003 12:53:33.0047 (UTC) FILETIME=[0E973070:01C2E704] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA08914 I agree with Pekka. Can we be sure we are all in synch. In the Ent Scenarios the M value variables were not to depict solutions but present a set of means that would be open to the users building Ent networks. Most members of the Ent team are working on Enterprise transitions now and the M variables are definitely part of the considersations. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, March 10, 2003 2:03 AM > To: Bob Fink > Cc: v6ops@ops.ietf.org; Margaret Wasserman; Jun-ichiro itojun > Hagino; Mikael Lind > Subject: Scenarios documents: IPv4 vs IPv6 material? [Re: > Some ISP Scenarios Comments] > > > Hi, > > On Sun, 9 Mar 2003, Bob Fink wrote: > > At 06:23 PM 3/9/2003 +0200, Pekka Savola wrote: > > >Hi, > > > > > >I quickly re-read the ISP scenarios document, the previous > version, > > >-04. I think most comments are probably applicable, as changes > > >happened mainly to the ISP section. > > > > > >In my opinion, the document is about ready to be accepted > as a w.g. > > >item. > > > > I have not yet read the -05 version, but the -04 version > just outlines > > the > > IPv4 architecture of various ISP environments without > giving any ipv6 > > transition scenarioz that are to be attempted/analyzed, > i.e., no IPv6 > > context was given in the -04 version. > > There seems to be some confusion (see my comments on > Enterprise Scenarios > and Jim's reply) about what exactly the contents of > "Enterprise scenarios" > should be. At least on my part.. > > I was thinking that an "ideal" scenarios document would > describe the scenarios with _IPv4_ (or with a > protocol-agnostic way) with as much detail as possible, which > would enable the _Solutions_ document to expand from there > painlessly, to IPv6 situations, mechanisms and solutions. > > Of course, some text on IPv6 to scope the work better (non-solutions > centric) might also be OK, but not too much. (3gpp-cases is a > good example here, but may be difficult to compare against as > it's quite restricted.) > > Perhaps this is something that is is needed to reach common > understanding on? It should make writing the drafts easier too :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > From owner-v6ops@ops.ietf.org Mon Mar 10 08:14:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12521 for ; Mon, 10 Mar 2003 08:14:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sN8S-000E6n-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 05:16:08 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 18sN8P-000E6b-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 05:16:05 -0800 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2ADG3B3018110; Mon, 10 Mar 2003 14:16:03 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Mar 2003 14:16:03 +0100 Message-ID: <8DE93563AC71D311B30400508B5D5D8B049B0793@eselint201.li.sw.ericsson.se> From: "Anders Eriksson C (EAB)" To: Ronald van der Pol Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Mon, 10 Mar 2003 14:15:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > You seem to be quite confident about that. Could you explain > > why you think multiple subnets will arrive in SOHOs? I'm not > > saying I don't agree with you. I just would like to know the > > scenarios where multiple subnets are needed. And when they > > are needed. I think we have already spent too much time on > > the scenario/analysis drafts. We should not delay any longer > > when it is not absolutely necessary. > I'm already forced to run multiple subnets at home. Some gadgets only support 10 Mbps and the way to make the PC cluster 100 Mbps (using the non-dual 10/100 hubs I had available) was to create a separate 100 Mbps LAN and have one box as a router. I see no reason why i should have to change this configration when using IPv6. /Anders From owner-v6ops@ops.ietf.org Mon Mar 10 09:30:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25994 for ; Mon, 10 Mar 2003 09:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sOIw-000GVJ-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 06:31:02 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18sOIs-000GUx-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 06:30:59 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2AEUeK26737; Mon, 10 Mar 2003 16:30:40 +0200 Date: Mon, 10 Mar 2003 16:30:40 +0200 (EET) From: Pekka Savola To: "Anders Eriksson C (EAB)" cc: Ronald van der Pol , Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <8DE93563AC71D311B30400508B5D5D8B049B0793@eselint201.li.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 10 Mar 2003, Anders Eriksson C (EAB) wrote: > > > You seem to be quite confident about that. Could you explain > > > why you think multiple subnets will arrive in SOHOs? I'm not > > > saying I don't agree with you. I just would like to know the > > > scenarios where multiple subnets are needed. And when they > > > are needed. I think we have already spent too much time on > > > the scenario/analysis drafts. We should not delay any longer > > > when it is not absolutely necessary. > > > > I'm already forced to run multiple subnets at home. Some gadgets only > support 10 Mbps and the way to make the PC cluster 100 Mbps (using the > non-dual 10/100 hubs I had available) was to create a separate 100 Mbps > LAN and have one box as a router. I see no reason why i should have to > change this configration when using IPv6. Again, do you consider this case an _unmanaged_ network? Adding a box to act as a router is something you and I would maybe do, but I'm not sure if this fits in the charter of "unmanaged"? Note: the definition is not "home" or "SoHo" network. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Mar 10 09:39:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26310 for ; Mon, 10 Mar 2003 09:39:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sOSp-000Gub-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 06:41:15 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18sOSl-000Gu9-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 06:41:12 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h2AEf7906396; Mon, 10 Mar 2003 15:41:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2AEf7of020466; Mon, 10 Mar 2003 15:41:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303101441.h2AEf7of020466@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: "Anders Eriksson C (EAB)" , Ronald van der Pol , v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-reply-to: Your message of Mon, 10 Mar 2003 16:30:40 +0200. Date: Mon, 10 Mar 2003 15:41:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Note: the definition is not "home" or "SoHo" network. => I agree: if the restriction to one subnet is a problem, the solution is to create a new document for lightly managed networks. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Mon Mar 10 09:50:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26894 for ; Mon, 10 Mar 2003 09:50:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sOdN-000HIU-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 06:52:09 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 18sOdI-000HIH-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 06:52:04 -0800 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AEq2B3020494; Mon, 10 Mar 2003 15:52:02 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Mar 2003 15:52:02 +0100 Message-ID: <8DE93563AC71D311B30400508B5D5D8B049B0799@eselint201.li.sw.ericsson.se> From: "Anders Eriksson C (EAB)" To: "'Pekka Savola'" Cc: Ronald van der Pol , v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Mon, 10 Mar 2003 15:51:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Note: the definition is not "home" or "SoHo" network. Well, the abstract of unman-scenarios-00 suggests that home and SoHo has been taken into account. Granted that the rest of the text only covers one subnet. Perhaps a slight rewording in that area is in place? /Anders From owner-v6ops@ops.ietf.org Mon Mar 10 10:02:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27356 for ; Mon, 10 Mar 2003 10:02:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sOoC-000Hk2-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 07:03:20 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18sOo9-000Hjo-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 07:03:17 -0800 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06089; Mon, 10 Mar 2003 07:03:08 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AF369P027123; Mon, 10 Mar 2003 10:03:06 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h2AF3061019459; Mon, 10 Mar 2003 10:03:00 -0500 (EST) Message-Id: <200303101503.h2AF3061019459@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: "Bound, Jim" cc: "Ronald van der Pol" , "Alain Durand" , v6ops@ops.ietf.org, jim.Paugh@sun.com, ipng@sunroof.eng.Sun.COM From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from "Bound, Jim" of "Sun, 09 Mar 2003 20:59:26 EST." <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAC@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Mar 2003 10:03:00 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim.Bound@hp.com said: > The default route would always be known and PPA to send to simply from > RAs, if nothing else were known by the end node. Jim, I'm sorry, I don't understand what you're saying. Can you rephrase it? > > Are you suggesting a change to ND or to configuration of the network as > potential outcome. That's a really good question. I'm not sure what would be the best way to address this. What we're saying in this draft is that operational experience has shown that this part of ND could be problematic in some circumstances. Does ND need to be changed as a result? Probably not. There are no MUST's surrounding that bit of ND. As implementors, we're free to interpret the spec in a sane mannor. With this draft, we're pointing out reasons why implementors may want to be careful with that part of ND. There is informational value in this alone without having to muck with the ND spec itself. -Seb From owner-v6ops@ops.ietf.org Mon Mar 10 10:49:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00037 for ; Mon, 10 Mar 2003 10:49:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sPWh-000Jvb-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 07:49:19 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18sPWe-000JvM-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 07:49:16 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2AFofVg001557 for ; Mon, 10 Mar 2003 16:50:42 +0100 (CET) Date: Mon, 10 Mar 2003 08:00:49 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Comments on draft-ietf-v6ops-unman-scenarios-00.txt From: Kurt Erik Lindqvist To: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0632F1DE-52C6-11D7-9822-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=1.7 required=5.0 tests=DATE_IN_PAST_06_12,RCVD_IN_RFCI,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess this is in the eleventh hour, but anyway... I think this is a good draft. Some editorial comments, I would suggest to have the table of contents in the beginning, and there are references missing in the reference section. Only one minor comment, in 5.1.3 it's said that reverse service is hard to provide. I would say that it is hard to provide for the hosts on the SOHO network, just to be clear. - kurtis - From owner-v6ops@ops.ietf.org Mon Mar 10 11:18:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01185 for ; Mon, 10 Mar 2003 11:18:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sPzX-000LEf-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 08:19:07 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sPzU-000LEL-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 08:19:04 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6FF321732; Mon, 10 Mar 2003 11:19:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 11:19:01 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Some Enterprise Scenarios comments X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 10 Mar 2003 11:19:00 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCACC@tayexc13.americas.cpqcorp.net> Thread-Topic: Some Enterprise Scenarios comments Thread-Index: AcLlm+LS/Jd3j3OvTQaU1FAryPMqXQBdzbIg From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 10 Mar 2003 16:19:01.0388 (UTC) FILETIME=[C2DABCC0:01C2E720] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01185 Hi Pekka, We will fix all edits below. Thank you for this extensive review of our spec. All your input below is valid. Thank You, /jim > > > Terminology > > ==> several important wordsmithing fixes in editorial section, below. > > Critical issues for each: > > PMTUD : Support for discovery vs. traditional > ICMP aversion > > ==> Is PMTUD really a critical approach? Without > elaboration, it may be > that some other word might be more appropriate, or this should be > considered a bit.. The operational issue the user has to consider for IPv6 packets in their network is they are now only fragmented e2e, if at all, and this can affect an enterprise like a discrete engineering operation that sends MBs of data modeling across the network or a financial institution bulk wire transfer updates, etc etc. PMTUD is important to be used. I think PMTUD is the correct word and later needs more discussion in the follow on text. What other word would be better, to point out this in a listing of bullets? > > Trust system between host & network management teams: > > Dual-stack vs. IPv6-only > IPv6-only is a restricted capability subset > Routing > Architectural concept of tunneling over foo vs. native service > > ==> "Trust system ..." ??! I've no idea how these relate to > trust, so more > elaboration or rewording is definitely needed! Agreed. WHen I keyed this in as editor I knew someone would ding us on this one for sure. The idea is to get some crisp bullets of where the core trust beliefs can be shattered in the minds of the users defining how to adopt IPv6. Some of the ones I hear, as a note, are fallacy and not reality, and some are completely missing. But yes this needs major wordsmithing. > > Scenario #6 > > A new Enterprise providing location based services for over a wide > geography enables mobile devices for their Account Teams to access > network data and services. Set D. > > ==> compared to other scenarios, this strikes me as being > perhaps a bit > too specific ("account teams", etc.)? We can fix that yes. > > > Editorial: > ---------- > > V6ops Working Group Enterprise Network Scenarios Design Team > > INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt > OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt > > Yanick > Pouffary (Chair) > Jim Bound (Editor) > Enterprise Networks Scenarios > Design Team > See > Acknowledgements Section > > > February 2003 > > ==> the header is quite unconventional: I'd just make it like: > > V6ops Working Group Yanick > Pouffary (Chair) > Internet Draft Jim > Bound (Editor) > Expiration Date: Aug 2003 Enterprise Networks Scenarios > Design Team I will look at this as editor. I followed templates/current-wisdom the IETF points me to as a note though. > > > February 2003 > > 1. Introduction > > IPv6 will be deployed in Enterprise networks. This scenario has > requirements for the adoption of IPv6. This document will > focus upon > and define: a set of technology scenarios that shall exist for the > enterprise network, the set of transition variables, transition > methods, and tools required by different scenarios. The document > using these definitions will define the points of transition for an > Enterprise network. > > ==> same issues as with abstract We hear you. > > The audience for this document is the enterprise network team > > ==> if you can find, I'd personally prefer another word to "audience". We will review ok. > > accomplishing the business goal, IPv6 provides strong > motivations to > move. > > > ==> reword or expand "to move" (for a change?) We will review ok. > > Enterprise Network - An Enterprise Network is a network > that has multiple links, a router > conection to a Provider, > and is activel > managed by a network > operations entity. > > ==> formatting: must not exceed 72 chars (also elsewhere in > the document). Hmmmm. NROFF did it correct it got munged by peoples mailers on the team. Will fix. > > ==> s/conection/connection/ Thanks. > > Provider - A Provider is an entity > that provides > services and > connectivity to the Internet > or other private > external networks for > the Enterprise Network. > > ==> "Internet or _other_ private external networks" must be reworded; > Internet is not a private external network :-) ACK. > > Edge - The Edge is the ingress > and egress points > connecting to the > Internet, Extranet, or > to another private > external network. > > ==> is the assumption so that the egress point = always > ingress point? > The plurality of the sentence is ambiguous. Not necessarily esp. multi-site enterprise. Will reword. > > Administrative Domain - An Administrative Domain are the > ingress and egress > points connecting > nodes across the Enterprise > Network, behind the Edges. > > ==> same consideration about points (in "are" applies here). It also > strikes me that the defininion could be simpler (drop out > egress/ingress > points completely, Edges covers that already). That fixes the issue above too. Thanks. > > Extranet - An Extranet is any > Enterprise Network > owned network components > at the Edge, but > not part of the > Administrative Domain. > > ==> "any EN owned components" ? I'm having trouble parsing > the sentence, > minor rewording. ACK. > > Border Router - An Enterprise Network > Border Router is a > a router that is > configured at the Edges. > > ==> I recommend using another word than "configured" -- > typically it has some other connotations. ACK. > > Points of Transtion - An Enterprise Network Point of > > ==> s/Transtion/Transition/ > > Every node that can be addressed by another node must be in a > registered name service, managing this name service is a > > ==> s/,/, and/ Thanks. > > (multi-Party) require globally consistent addresses for peer-to- > > ==> s/P/p/ Thanks > > - Routers > - Non Router Nodes > > ==> why just not say "Hosts" :-) I agree. I think we were practicing valuing differences :--) > > solutions. A set of suggested solutions will be provided > in a follow > on document to this work. > > ==> s/follow on/follow-up/? Thanks > > V5: IPv6 software upgrades are not available for existing > routers and nodes. > > ==> s/available/available or possible/ Thanks > > V6: Source code for applications have been lost or cannot be > > > ==> s/have/has/ Thanks > > V7: New business function being defined and can exist without > > ==> s/being/is being/, s/can/it can/ Thanks > > This point on the graph will be an transtion strategy. After the > > ==> s/transtion/transition/ Thanks > > Mobility : Requirements for nodes > > ==> s/Requirements/Mobility requirements/ Thanks > > Scenario #6 (subset of all scenarios) > > ==> s/6/7/ ? Thanks > > The Enterprise network will have varying points of transition that > will require different points of interoperability with > IPv6 and IPv4. > > ==> reword "different points of interoperability" ACK. > > but an IPv4 Internal Router is between them. These > nodes could also > be Mobile nodes too and in a remote location. > > ==> s/ too and/, or/ THanks > > 1. A Dual Stacked IPv4/IPv6 node wants to communicate > to a legacy IPv4 > service and is on a Native IPv6 link and Routing > Domain. Enterpise > > ==> "Routing Domain" (upper case) is not defined, I think? > > 2. A Dual Stacked IPv4/IPv6 node wants to communicate > to a legcy IPv4 > > ==> s/node /node / > ==> s/legcy/legacy/ > > > This Point of Transition exists for the following conditions: > > > 1. A Dual Stacked IPv4/IPv6 node wants to communicate > with a legacy IPv4 > > ==> kill the extra empty line > > security, applications, and remove some benefits from the IPv6 > protocol. > > 1. The Design Team highly recommends that network not adopt the > policy > in reference "1" above. > 2. IPv6 ONLY nodes should not be deployed in a network > until they > will > not require access to any legacy IPv4. This means that > applications > and infrastructure has been ported or moved to IPv6. > Until that > time nodes for transition should be Dual Stacked > IPv4/IPv6 nodes. > This means networks that want to use IPv6 ONLY nodes will be > required > to move applications and infrastructure to IPv6 first. > > ==> the 1., 2., list starts out of empty air, so I'm assuming > there should > be some kind of text there. > > addresses to nodes. Though DHCPv6 can be used to administrate > addresses that are assigned to nodes. > > ==> s/Though/However,/ (or some other wordsmithing, looks > funny that way) > > When preforming stateless autoconfiguration, an EUI-64 is generated > > ==> s/pre/per/ > > bit IPV6 address. The EUI-64 is derived from the MAC > address of the > interface that being autoconfigured. This mechanism proves a large > > ==> s/IPV6/IPv6/ > ==> s/that/that's/ > ==> s/proves/provides/ > > token should be considered when establishing an address plan." > > ==> s/"// > > This section will identify the tools requirements for an EN > transitioning to IPv6 so the configuration issues for the EN are > > ==> s/EN/Enterprise Network/ > > 12. Security Section > > ==> is this Security Section or Security Considerations? :-) > > Acknowledgments > > ==> this section is typically numbered, too. > > Design Team' Addresses > > Send email to ent-v6net@viagenie.qc.ca to contact the design > team and send > comments on the draft to v > > Authors contact info will be provided in a future draft. > > ==> s/Team'/Team's/ > ==> overlong line > ==> s/Authors/Authors'/ > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Mon Mar 10 11:29:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01820 for ; Mon, 10 Mar 2003 11:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sQBP-000LiB-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 08:31:23 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18sQBN-000Lhw-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 08:31:21 -0800 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04423; Mon, 10 Mar 2003 09:31:15 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AGVD9P019175; Mon, 10 Mar 2003 11:31:14 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h2AGV761019763; Mon, 10 Mar 2003 11:31:07 -0500 (EST) Message-Id: <200303101631.h2AGV761019763@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: "Bound, Jim" cc: "Mika Liljeberg" , "Ronald van der Pol" , "Alain Durand" , v6ops@ops.ietf.org, jim.Paugh@sun.com, ipng@sunroof.eng.Sun.COM From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from "Bound, Jim" of "Sun, 09 Mar 2003 21:19:36 EST." <9C422444DE99BC46B3AD3C6EAFC9711B03240FF7@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Mar 2003 11:31:07 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim.Bound@hp.com said: > >Ok, I agree that this would be the common case in an IPv6 only > >network. If a random dual stack box that has IPv6 enabled is > >placed in a random network out there, the common case today is > >that it has no IPv6 default router, and this ND rule would be > >problematic for it. That's what we were trying to get across > >in this section of the draft. I suppose we need to more > >explicitly specify in the draft what types of networks we're > >concerned with. > > The worst case scenario would be 1 node coming up on IPv4 network with > IPv6. But then it would have to use transition mechanism to speak IPv6. > Selecting the best method based on the policy of the network > administrator I will assume here. > > Is this a fairly good synopsis of your general concern within this > draft? I'm not sure if I parsed what you wrote above correctly, so I can't say for sure. Just to make sure we're on the same page; The general concern being addressed by this draft is that enabling IPv6 on a dual-stack node in an IPv4 network that may or may not have IPv6 routing support might result in side-effects that the user of that node didn't anticipate or welcome. Some of those are protocol related (ND, ICMPv6, TCP, etc...), and others are administrative. > >> > >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort > >> immediately when ND determines that the destination is > >unreachable, so > >> TCP does not incur any additional delay here. > > > >Is that stated somewhere (it should be)? Should it be > >explicitly stated in the nodes requirements? In practice, I > >don't think many TCP implementations do this correctly (or as > >you've described), and they should be fixed. > > I believe from my knowledge most TCP implementations do this correctly. > The above rule is very well known by TCP implementers it has nothing to > do with ND or IPv6. With all the specs and all the work why must we > continue to put in specs what is already a defined process that is well > defined. It could very well be that the behavior is well defined to a number of people, and implemented as such in many TCP implementations. How it became well defined is a mystery to me, because RFC 1122 actually suggests (in section 4.2.3.9) to do the opposite of what makes sense in this situation. It says that if TCP receives an ICMP destination unreachable code 0 (no route to destination) or 1 (host unreachable), that it MUST NOT abort the connection. That's in direct conflict with what we're all agreeing is the right thing to do here (to abort the connection if it's in SYN-SENT or SYN-RECEIVED state). > > Even if TCP is > >fixed to abort connections, there is still a 3 second delay in > >IP while NUD is being performed, which may or may not be > > That depends on how NUD cache was built. Your making an implementation > judgement not a standards judgement. Also how one builds the NUD in the > ND spec is a "conceptual" model not a required model just that the state > changes are in fact supported. For all any of us know most have figured > this out to avoid a 3 second delay and its down to 300 nanoseconds. I agree that it's a conceptual model. > > If you want an optimization you should suggest one so we can discuss. My suggested optimization is that you don't assume a destination is on-link just because you don't have a default route. > > >acceptable depending on how many IPv6 destinations the > >application will try before trying IPv4. > > And some applications will never try IPv4 because they are not using > IPv4 anymore for this application. We cannot assume in the logic > premises for this discussion that ALL applications can just use IPv4 > that is an invalid assumption I believe. And an incorrect way to solve > IPv6 node "perceived" problems. True, IPv6-only applications won't have these problems. > > >I can't see this as > >being acceptable when a destination resolves to a few dozen > >IPv6 addresses, for example. > > Your speaking of the route above? Or because of multiple DNS entries? I'm trying to say that if you're assuming that all destinations are on-link because you don't have a default route, as a name resolves to more IPv6 addresses, the delays associated with failed NUD on each address are compounded. > > > An immediate ICMP destination > >unreachable/network unreachable from IP would be generated if > >it didn't assume destinations were on-link. > > So you can't send to nodes not on the same link using host routes? This > is very possible? Absolutely, and that's exacly my point. If you have a host route (or any other route that covers the destination), use it. If you don't have a route, then the destination is unreachable. If you don't have a route to the destination, why try to reach it on-link just in case the destination might happen to be on-link? Is there a situation where this would be useful? -Seb From owner-v6ops@ops.ietf.org Mon Mar 10 14:15:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08910 for ; Mon, 10 Mar 2003 14:15:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sSkG-0002Ip-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 11:15:32 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18sSk7-0002IK-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 11:15:24 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2AJFwwY011586; Mon, 10 Mar 2003 21:15:59 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2AJFsAn011584; Mon, 10 Mar 2003 21:15:54 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dual stack & IPv6 on by default From: Mika Liljeberg To: "Bound, Jim" Cc: Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAD@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAD@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047323752.2473.914.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2003 21:15:54 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-03-10 at 04:04, Bound, Jim wrote: > Good point. But isn't it up to the implementation for links that had to > deal with on-demand. As long as I have route for a link then I should > apply it? The problem would be if the link information was not applied > before the on-demand was accessed in a multi-home manner. But then I > would assume destination unreachable would be the response to the > application, though it should say link not known IMO. So isn't the > multi-home scenario a two step problem. 1) the on-demand NIC has to see > the link before used by the app, and 2) the implementation must be able > to propogate attributes for multiple interfaces? The question also is: what triggers the on-demand link setup? Two potential cases: a) there is an on-link default route to the on-demand interface -> first packet routed to the interface starts link setup b) on-demand link setup starts on no-route, according to preset policy Suppose we have a wireless terminal with two interfaces: a dialup one (e.g. cellular circuit switched data) for Internet connectivity [DOWN], and 802.11 for ad-hoc or cheap Internet access via an access point [UP]. If one takes the ND spec strictly, case a) might or might not trigger dialup, depending on which default route we hit first. Case b) would never trigger the dialup [although an implementation might choose to do so after NUD]. On the other hand, as soon as the host receives the first RA from the dialup interface and configures a default router, the other interface stops working for ad-hoc. All this just goes to show that the default on-link route implied by the ND specification perhaps isn't fully thought out, at least with multihoming. Besides, such a route could always be configured explicitly if the user wants to use a particular interface for ad-hoc. [I'm not sure if this actually has any additional implications to the dual stack issue raised by the original poster.] MikaL From owner-v6ops@ops.ietf.org Mon Mar 10 14:30:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09524 for ; Mon, 10 Mar 2003 14:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sT0c-00031n-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 11:32:26 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18sT0Y-00031I-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 11:32:22 -0800 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AJWK825984 for ; Mon, 10 Mar 2003 14:32:20 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <1H3RVJS4>; Mon, 10 Mar 2003 13:32:20 -0600 Message-ID: From: "Fischer, Christine A (Chris)" To: Margaret Wasserman , v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Mon, 10 Mar 2003 13:32:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Comments from Chris Fischer on Transition Scenarios for 3GPP Networks Section 2, last paragraph: It might be useful to include a reference to 3GPP TS 23.221, "Architectural requirements", which shows the transition scenarios for 3GPP. Section 3.1, third paragraph: change "comprised of" to "comprising" Section 3.2, under I-CSCF: typo on "operator's" same section: change "an 3GPP" to "a 3GPP" Section 4.1, item 1), last paragraph: You may want to add a comment that this may require the use of NAT on external interfaces, when appropriate. Also, a comment that the placement and handling of DNS servers for IPv4 / IPv6 communication has not been included in these scenarios. Section 4.1, item 4): Please define intent of the boxes marked by "x". Are these IPv4 networks or transition gateways? Page 10, under Acknowledgements: There is an unknown character after Sipil. -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Monday, February 17, 2003 11:05 AM To: v6ops@ops.ietf.org Subject: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Hi All, This is a WG Last Call for comments on sending the 3GPP scenarios document to the IESG for consideration as an Informational RFC: Title: Transition Scenarios for 3GPP Networks Filename: draft-ietf-v6ops-3gpp-cases-02.txt Editor: J. Soininen Date: January 2003 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt Abstract This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. Since this is the first WG last call that we have had in the v6ops WG, we would like to remind you of the process that we discussed for WG last calls when we started this WG. The WG Last Call is a final check that the WG has rough consensus to advance the document to the IESG. Advancing a document to the IESG indicates that the WG believes that this document is both technically sound and useful. It also indicates that we believe that the document meets all of the requirements for publication as an RFC. To pass WG last call, this document must be reviewed and actively supported by a significant number of people, including experts in all applicable areas, or it will not be sent to the IESG. Silence does NOT indicate consent during this phase. So, please review this document carefully, and send your feedback to the list, indicating whether or not you believe that this document is ready to go to the IESG. Unless sufficient support is demonstrated on the list, the document will not be send to the IESG. Thanks, Margaret, Itojun and Bob v6ops WG Chairs From owner-v6ops@ops.ietf.org Mon Mar 10 14:35:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09781 for ; Mon, 10 Mar 2003 14:35:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sT4n-0003Dc-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 11:36:45 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18sT4l-0003DO-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 11:36:43 -0800 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AJaf828630 for ; Mon, 10 Mar 2003 14:36:41 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <1H3RVKDY>; Mon, 10 Mar 2003 13:36:40 -0600 Message-ID: From: "Fischer, Christine A (Chris)" To: Margaret Wasserman , v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Mon, 10 Mar 2003 13:35:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Comments from Chris Fischer on Unmanaged Networks IPv6 Transition Scenarios The majority of these are minor editing comments to make content clearer. Section 3: change "status vary" to "status varies" Section 3.1: change "sharing of file or printers" to "sharing of files or printers" Sections 3.1 and 3.2: change "performs NAT or firewall function" to "performs NAT or a firewall function" Section 4.1, second paragraph: change "an example of standard system" to "an example of a standard system" (same comment page 6) Section 4.2.1, third paragraph: change "prevent outsiders to correlate" to "prevent outsiders from being able to correlate" same section, fourth paragraph: "is not a sufficient reason to enable additional tracking through IPv6 addresses" Did you mean additional tracking here or additional privacy? Section 4.2.1, last sentence in section: change "unmanaged network allow" to "unmanaged networks allow" Top of Page 10, section 5.2.1: The text refers to the problems with DNS requests when translation is implemented. It might help to include a reference to a draft that discusses these problems, for example, Alain Durand "Issues with NAT-PT DNS ALG in RFC2766"; there are others as well. Page 10, section 5.2.2 and 5.3.2: "natted", shouldn't acronyms be upper case? Section 5.2.2: change "This is as debatable" to "This is debatable" Section 5.2.2: change "to site local application" to "to site local applications" Section 5.2.2: change "the gateway need to use a mechanism obtain" to "the gateway needs to use a mechanism to obtain" Section 5.2.3, page 11: change "depend of the protocol" to "depend on the protocol" -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Monday, February 17, 2003 11:11 AM To: v6ops@ops.ietf.org Subject: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Hi All, This is a WG Last Call for comments on sending the Unmanaged Networks scenarios document to the IESG for consideration as an Informational RFC: Title: Unmanaged Networks IPv6 Transition Scenarios Filename: draft-ietf-v6ops-unman-scenarios-00.txt Authors: C. Huitema, R. Austein, R. van der Pol Date: January 10, 2003 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt Abstract In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. Please review this document carefully, and send your feedback to the list, indicating whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the document will not be send to the IESG. Thanks, Margaret, Itojun and Bob v6ops WG Chairs From owner-v6ops@ops.ietf.org Mon Mar 10 14:53:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10459 for ; Mon, 10 Mar 2003 14:53:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sTMg-00044o-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 11:55:14 -0800 Received: from proxy1.addr.com ([209.249.147.28]) by psg.com with esmtp (Exim 3.36 #1) id 18sTMc-00044a-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 11:55:10 -0800 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h2AJt8YZ022589 for ; Mon, 10 Mar 2003 11:55:09 -0800 (PST) Message-Id: <5.2.0.9.0.20030310114052.01c70878@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 11:54:59 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: revised v6ops agenda (10Mar03 version) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.0 required=5.0 tests=HTML_50_70,MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Revised agenda for v6ops. Christian's operational experience talk added at end, ENTERPRISE report now to be covered in Margaret's project status report. Bob === v6ops agenda (version of 10Mar03) IETF-56 San Francisco status of v6ops projects - Wasserman, 20 mins 3GPP Analysis draft - Wiljakka, 20 mins UNMAN analysis draft - Huitema, 20 mins ISP Scenarios - Lind, 10 mins IPv4 Survey draft restructuring - Nesser or chairs, 10 mins Introduction Application area General area Operations & Management area Internet area Routing area Security area Sub-IP area Transport area Mech draft - Nordmark, 15 mins Translation Issues - van der Poel, 15 mins Translation Issues - Durand, 15 mins Discussion of what to do with NAT-PT - Wasserman, 10 mins Operational experience with turning IPv6 on by default - Durand, 10 mins Operational experience with Microsoft IPv6 based P2P application ("threedegrees") - Huitema, 10 mins -end From owner-v6ops@ops.ietf.org Mon Mar 10 17:46:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18051 for ; Mon, 10 Mar 2003 17:46:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sW27-000Czb-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 14:46:11 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #1) id 18sW24-000CzF-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 14:46:08 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AMk5812240 for ; Mon, 10 Mar 2003 16:46:06 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 16:46:04 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:45:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Mon, 10 Mar 2003 14:45:28 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDC44@mvebe001.americas.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLmTHTMl39GJmLTQDad9yaa1eGInQBBprLw From: To: , Cc: X-OriginalArrivalTime: 10 Mar 2003 22:45:29.0702 (UTC) FILETIME=[C02AA860:01C2E756] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18051 Francis, > -----Original Message----- > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, March 09, 2003 6:51 AM > To: Margaret Wasserman > Cc: v6ops@ops.ietf.org > Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt > > > A short & late review of draft-ietf-v6ops-3gpp-cases-02.txt: > I have no concern, only a comment and some editorial remarks. > > The comment: > IMHO the PDP PPP context finishing at the ISP NAS will be the > more common GPRS scenario because regulatory bodies won't accept > the mobile operator and the ISP will be the same entity, i.e., > customers should get the choice. This scenario is explicitely > put out of the scope of the document in 4.1. I do not completely agree with your statement - especially, as having a different ISP than the mobile operator doesn't have anything to do with PDP Type PPP. It can be achieved with PDP Type IP as well. Anyways, I wonder if this has to be discussed here. Back a question: We deliberately put the case where there is PPP connection directly from the mobile to the ISP as an out of scope case as we would tendo to believe that it is part of a more general case (i.e. the ISP cases). Are you happy with this decision, or are you objecting to that? (You seemed to be happy about it as we discussed it the last time.) > > Typos & co: > > 3.1 GPRS architecture basics > > It also serves as the default router for the UE. > > => It can also serve as the default router for the UE. > > 3.2 > > - I-CSCF (Interrogating-CSCF) is the contact point within an > operators network for all connections destined to a > subscriber > of that network operator, or a roaming subscriber currently > located within that network operators service area. > > => ' characters were replaced by (AE is latin 15). Shoot! I thought I got all of those out, but it seems that the MS Word -> text conversion does put some strange characters in the text file. Thanx. > > 4.1 Figure 3 > > +-------------+ > | | > | UE | +------+ > > => > > +-------------+ > | | > | UE | +------+ > Cheers. > 4.2 Figure 9 > > +------+ +------+ +-----+ +-----+ > | | | | | | | | > | UE |-...-| |-----| IMS |--------| | > | | | GGSN | | |+------+| IMS | > | IPv6 | | | | || IPv4 || | > +------+ +------+ +-----++------++-----+ > Figure 9: Two IMS islands connected over IPv4 > > => > > +------+ +------+ +-----+ +-----+ > | | | | | | | | > | UE |-...-| |-----| IMS |----------| | > | | | GGSN | | | +------+ | IMS | > | IPv6 | | | | | | IPv4 | | | > +------+ +------+ +-----+ +------+ +-----+ > Figure 9: Two IMS islands connected over IPv4 Francis, I only found that you changed the picture where there is the IPv4 "cloud" (=block). Was this for estetical reasons, or do the lines get wrapped in your screen? > > Acknowledgements > > The authors would like to thank Basavaraj Patil, Tuomo > Sipil", Fred > ^ > not an ASCII character > Cheers. > Informative references > > Partnership Project (3GPP) Standards", September 2002, RFC3314. > > => > > Partnership Project (3GPP) Standards", RFC3314, September 2002. Yep. > > Thanks > > Francis.Dupont@enst-bretagne.fr Thank you, Jonne. From owner-v6ops@ops.ietf.org Mon Mar 10 17:56:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18375 for ; Mon, 10 Mar 2003 17:56:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sWDK-000Dcp-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 14:57:46 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18sWDA-000Dcc-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 14:57:36 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 22848170F; Mon, 10 Mar 2003 17:57:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 17:57:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 17:57:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAFE@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnGt7HGtoieuhoTIq2O3vmq0D6AwAPWd2A From: "Bound, Jim" To: "Sebastien Roy" Cc: "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 10 Mar 2003 22:57:36.0026 (UTC) FILETIME=[7116E7A0:01C2E758] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18375 Hi Sebastien, >> The default route would always be known and PPA to send to >simply from >> RAs, if nothing else were known by the end node. > >Jim, I'm sorry, I don't understand what you're saying. Can >you rephrase it? When the node hears RAs it can note the router that sent them as implementation feature :--) > >> >> Are you suggesting a change to ND or to configuration of the network >> as potential outcome. > >That's a really good question. I'm not sure what would be the >best way to address this. What we're saying in this draft is >that operational experience has shown that this part of ND >could be problematic in some circumstances. Does ND need to >be changed as a result? Probably not. There are no MUST's >surrounding that bit of ND. As implementors, we're free to >interpret the spec in a sane mannor. With this draft, we're >pointing out reasons why implementors may want to be careful >with that part of ND. There is informational value in this >alone without having to muck with the ND spec itself. I agree. Thanks /jim > >-Seb > > From owner-v6ops@ops.ietf.org Mon Mar 10 18:02:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18676 for ; Mon, 10 Mar 2003 18:02:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sWJT-000DyA-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 15:04:07 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18sWJQ-000Dxn-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 15:04:04 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 62D717A0F; Mon, 10 Mar 2003 18:04:03 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 18:04:03 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 18:04:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnInuh7XyF/rHCQFWstbkrDvv1XQANhGCw From: "Bound, Jim" To: "Sebastien Roy" Cc: "Mika Liljeberg" , "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 10 Mar 2003 23:04:03.0304 (UTC) FILETIME=[57ECD680:01C2E759] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18676 >> The worst case scenario would be 1 node coming up on IPv4 >network with >> IPv6. But then it would have to use transition mechanism to speak >> IPv6. Selecting the best method based on the policy of the network >> administrator I will assume here. >> >> Is this a fairly good synopsis of your general concern within this >> draft? > >I'm not sure if I parsed what you wrote above correctly, so I >can't say for sure. For edification. I have a node on a work LAN that knows nothing of IPv6. I download software and configure my node to be capable of IPv6. I manually configure my interface to support IPv6. I now ftp to an IPv6 address. This is not going to work. But I was stupid to think it would? Is this the kind of basic mistake your also worried about? > Just to make sure we're on the same page; >The general concern being addressed by this draft is that >enabling IPv6 on a dual-stack node in an IPv4 network that may >or may not have IPv6 routing support might result in >side-effects that the user of that node didn't anticipate or >welcome. Some of those are protocol related (ND, ICMPv6, TCP, >etc...), and others are administrative. But there also could be no problem is my point. I think the draft should state when there is no problem at all. Showing both sides in the draft is important. /jim > >> >> >> >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort >> >> immediately when ND determines that the destination is >> >unreachable, so >> >> TCP does not incur any additional delay here. >> > >> >Is that stated somewhere (it should be)? Should it be >> >explicitly stated in the nodes requirements? In practice, I >> >don't think many TCP implementations do this correctly (or as >> >you've described), and they should be fixed. >> >> I believe from my knowledge most TCP implementations do this >> correctly. The above rule is very well known by TCP implementers it >> has nothing to do with ND or IPv6. With all the specs and all the >> work why must we continue to put in specs what is already a defined >> process that is well defined. > >It could very well be that the behavior is well defined to a >number of people, and implemented as such in many TCP >implementations. How it became well defined is a mystery to >me, because RFC 1122 actually suggests (in section 4.2.3.9) to >do the opposite of what makes sense in this situation. It >says that if TCP receives an ICMP destination unreachable code >0 (no route to destination) or 1 (host unreachable), that it >MUST NOT abort the connection. That's in direct conflict with >what we're all agreeing is the right thing to do here (to >abort the connection if it's in SYN-SENT or SYN-RECEIVED state). > >> > Even if TCP is >> >fixed to abort connections, there is still a 3 second delay in >> >IP while NUD is being performed, which may or may not be >> >> That depends on how NUD cache was built. Your making an >> implementation judgement not a standards judgement. Also how one >> builds the NUD in the ND spec is a "conceptual" model not a required >> model just that the state changes are in fact supported. >For all any >> of us know most have figured this out to avoid a 3 second delay and >> its down to 300 nanoseconds. > >I agree that it's a conceptual model. > >> >> If you want an optimization you should suggest one so we can discuss. > >My suggested optimization is that you don't assume a >destination is on-link just because you don't have a default route. > >> >> >acceptable depending on how many IPv6 destinations the >> >application will try before trying IPv4. >> >> And some applications will never try IPv4 because they are not using >> IPv4 anymore for this application. We cannot assume in the logic >> premises for this discussion that ALL applications can just use IPv4 >> that is an invalid assumption I believe. And an incorrect way to >> solve IPv6 node "perceived" problems. > >True, IPv6-only applications won't have these problems. > >> >> >I can't see this as >> >being acceptable when a destination resolves to a few dozen >> >IPv6 addresses, for example. >> >> Your speaking of the route above? Or because of multiple >DNS entries? > >I'm trying to say that if you're assuming that all >destinations are on-link because you don't have a default >route, as a name resolves to more IPv6 addresses, the delays >associated with failed NUD on each address are compounded. > >> >> > An immediate ICMP destination >> >unreachable/network unreachable from IP would be generated if >> >it didn't assume destinations were on-link. >> >> So you can't send to nodes not on the same link using host routes? >> This is very possible? > >Absolutely, and that's exacly my point. If you have a host >route (or any other route that covers the destination), use >it. If you don't have a route, then the destination is unreachable. > >If you don't have a route to the destination, why try to reach >it on-link just in case the destination might happen to be >on-link? Is there a situation where this would be useful? > >-Seb > > From owner-v6ops@ops.ietf.org Mon Mar 10 18:11:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19852 for ; Mon, 10 Mar 2003 18:11:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sWSQ-000EXU-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 15:13:22 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18sWSM-000EXH-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 15:13:18 -0800 Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22728 for ; Mon, 10 Mar 2003 16:13:18 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBK00KZZ365P3@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:13:18 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBK004OJ364K3@mail.sun.net> for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:13:17 -0700 (MST) Date: Mon, 10 Mar 2003 15:13:16 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default To: "Bound, Jim" Cc: Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-id: <3E6D1C0C.80003@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Bound, Jim wrote: >For edification. I have a node on a work LAN that knows nothing of IPv6. I >download software and configure my node to be capable of IPv6. I manually >configure my interface to support IPv6. I now ftp to an IPv6 address. This >is not going to work. But I was stupid to think it would? Is this the kind >of basic mistake your also worried about? > Alternate scenario: We ship our system so they configure IPv6 ON by default on all interface. User install this machine on his v4-only network and now experiment larger than usual delays to connect to his favorite servers. User call customer support. This is what I worried about. - Alain. From owner-v6ops@ops.ietf.org Mon Mar 10 18:28:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20640 for ; Mon, 10 Mar 2003 18:28:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sWiB-000FQ5-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 15:29:39 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sWi9-000FPs-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 15:29:37 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F10408100; Mon, 10 Mar 2003 18:29:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 18:29:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 18:29:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241001@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnWqjl+t9x6sKdSkOgJOV6jebUgwAAYUFg From: "Bound, Jim" To: "Alain Durand" Cc: "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 10 Mar 2003 23:29:36.0911 (UTC) FILETIME=[EA06B1F0:01C2E75C] X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20640 Hi Alain, > >>For edification. I have a node on a work LAN that knows nothing of >>IPv6. I download software and configure my node to be >capable of IPv6. >>I manually configure my interface to support IPv6. I now ftp to an >>IPv6 address. This is not going to work. But I was stupid >to think it >>would? Is this the kind of basic mistake your also worried about? >> >Alternate scenario: >We ship our system so they configure IPv6 ON by default on all >interface. User install this machine on his v4-only network >and now experiment larger than usual delays to connect to his >favorite servers. User call customer support. This is what I >worried about. Yep. I know of large user that may require all new systems very soon must be capable of supporting both IPv4 and IPv6. They specifically will require IPv6 not be enabled automaitcally. The reason is that they have gone far beyond Sebastien's draft of potential problems and know not to have it enabled automatically. It is good to document these use issues in the IETF but we need to be responsible to make sure all sides of the coin are depicted. I think it's a thin line where the IETF should work on operational conditions and where they should not. We all say we are so busy and we have the entire problem statement area BOF in San Francisco next week. Part of our problem is we are doing more than what we were mean't to do in the IETF. A lot of these issues are documented in the market but they are not going to publicize it so some of us have to watch it get redone here. Regards, /jim From owner-v6ops@ops.ietf.org Mon Mar 10 19:07:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21658 for ; Mon, 10 Mar 2003 19:07:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sXJo-000HYs-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 16:08:32 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18sXJm-000HYg-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:08:30 -0800 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 QAA18985; Mon, 10 Mar 2003 16:08:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2B08Se17499; Mon, 10 Mar 2003 16:08:28 -0800 X-mProtect: <200303110008> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.99, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAdtQse; Mon, 10 Mar 2003 16:08:25 PST Message-ID: <3E6D28F6.10003@iprg.nokia.com> Date: Mon, 10 Mar 2003 16:08:22 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Erik Nordmark Subject: Path MTU for draft-ietf-v6ops-mech-v2-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.5 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I notice that in the latest draft version, you are no longer requiring an MRU of 4420 bytes in decapsulators and seem to be taking a less aggressive approach in the dynamic MTU discovery in the encapsulator. Can you say more as to the reasons for the change? Thanks, Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon Mar 10 19:15:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21810 for ; Mon, 10 Mar 2003 19:15:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sXSf-000I5g-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 16:17:41 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sXSc-000I5S-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:17:38 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E78A98144; Mon, 10 Mar 2003 19:17:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 19:17:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 19:17:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241002@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnPUtJRskpv/TaQlmhaiuphWImVgAJEExw From: "Bound, Jim" To: "Mika Liljeberg" Cc: "Sebastien Roy" , "Ronald van der Pol" , "Alain Durand" , , X-OriginalArrivalTime: 11 Mar 2003 00:17:36.0901 (UTC) FILETIME=[9EA24B50:01C2E763] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA21810 Hi Mika, >The question also is: what triggers the on-demand link setup? >Two potential cases: > >a) there is an on-link default route to the on-demand >interface -> first packet routed to the interface starts link setup > >b) on-demand link setup starts on no-route, according to preset policy OK. > >Suppose we have a wireless terminal with two interfaces: a >dialup one (e.g. cellular circuit switched data) for Internet >connectivity [DOWN], and 802.11 for ad-hoc or cheap Internet >access via an access point [UP]. OK. > >If one takes the ND spec strictly, case a) might or might not >trigger dialup, depending on which default route we hit first. >Case b) would never trigger the dialup [although an >implementation might choose to do so after NUD]. OK. But NUD would mean it tells some function to configure the interface in this case of dial up? Right? Even dialers do this now. But ND is working above you do not say it does not from what I can see as question? > >On the other hand, as soon as the host receives the first RA >from the dialup interface and configures a default router, the >other interface stops working for ad-hoc. Why? From your example it sounds like two separate links and that is a non-issue as I interpret ND. But, lets assume it's the same air link interface (cellular cyberspace) nothing in ND precludes the use of multiple interfaces, just duplicate EUIs. > >All this just goes to show that the default on-link route >implied by the ND specification perhaps isn't fully thought >out, at least with multihoming. The default route is for a link. And multiple routers are permitted to announce routes. So two routers can be supported on a link, with one being the default. Multipe interfaces can exist on one link. So in that sense ND is transparent to multihome node. Now if your speaking about two different links then ND is non issue specifically because it only addresses link attributes today. Or are you discussing the self-healing needs for routes when two links merge or that coordination is required for two links of close proximity for multihome case for two or more links a node may be attached to. A default route in any implementation I know is implied to mean only for a specific link not for multiple links. The default route would be determined by the tuple interface, address, and route entry. IPv6 scoping would need to be part of this once that is supported too. >Besides, such a route could >always be configured explicitly if the user wants to use a >particular interface for ad-hoc. Yes but it will still only apply to a link. Now if a link fails an implementation could permit sending traffic to another link over that links default route. Now I suppose there could be a global default route for all links but that has nothing to do with ND and out of scope for ND today. Hmmm. I suppose an ND extension could advertize such a parameter but the interoperability problems could be horrific. I may have missed your point in my parser? Thanks /jim From owner-v6ops@ops.ietf.org Mon Mar 10 19:41:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22358 for ; Mon, 10 Mar 2003 19:41:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sXqb-000JXi-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 16:42:25 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18sXqX-000JXQ-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:42:22 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C57C570EA for ; Mon, 10 Mar 2003 19:42:20 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 19:42:20 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: draft-durand-v6ops-dualstack-vs-natpt-00 Date: Mon, 10 Mar 2003 19:42:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241003@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-durand-v6ops-dualstack-vs-natpt-00 Thread-Index: AcLnZxNWnCxGxKL/SE+EkntdNArEsw== From: "Bound, Jim" To: X-OriginalArrivalTime: 11 Mar 2003 00:42:20.0740 (UTC) FILETIME=[13122840:01C2E767] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA22358 I think this draft is important for the working group to work on and deal with the issues in this work. -------------------------------------------- Abstract Outside of the IETF community, lot of people think that IPv4 to IPv6 transition consist merely at solving the problem of how does a v4 box communicate with a v6 box and vice versa. Within the IETF, the dual stack approach has long been defined. There is an ongoing discussion to understand if translation with tools like [NAT-PT] is absolutly needed to enable IPv6 nodes to communicate with an IPv4 node or if we can/should mandate IPv6 nodes to also deploy an IPv4 stack if/when they needs to communicate with IPv4 nodes. This draft is aimed at clarifying the discussion without taking side by studying in 3 cases the implications of mandating a dual-stack versus the implications of deploying a translation device ---------------------------------- I don't like the idea of mandating anything that's a bad word above in the last sentence. But this is an area that should be documented so operators understand the ramification of NAT with IPv6 and the trade-offs. Most of my input are edits I will send offline and still thinking if this is enough cases, but I think so. It is stated all understand the dual stack concept but I do not believe entirely. For example IPv6 don't run over IPv4 as one error I have heard regarding implementation. Also most implementations are really dual IP layers not dual stacks. They are more of what is called a "hyrid IPv4/IPv6 stack". But this work should be pursued. /jim From owner-v6ops@ops.ietf.org Mon Mar 10 19:56:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22711 for ; Mon, 10 Mar 2003 19:56:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sY5w-000KQg-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 16:58:16 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18sY5u-000KQN-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 16:58:14 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8FDEC1465 for ; Mon, 10 Mar 2003 19:58:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 19:58:10 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E769.48D96AF6" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Note on Scenarios for IPv6 Date: Mon, 10 Mar 2003 19:58:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241004@tayexc13.americas.cpqcorp.net> Thread-Topic: Note on Scenarios for IPv6 Thread-Index: AcLnaUlWMLg2qwElRZy6bJxn9PY6cw== From: "Bound, Jim" To: X-OriginalArrivalTime: 11 Mar 2003 00:58:10.0386 (UTC) FILETIME=[491AA320:01C2E769] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E769.48D96AF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just as note. Users are now working on their own scenarios and other forums (not the IPv6 Forum, they have good work who does what with the IETF). If we don't do this quickly no one will care. But if they are just template for us to build tools they are still useful.=20 =20 Also realize folks are designing networks using the methods from Teredo, ISATAP, and DSTM. Just as a note. Products exist for each too or about to be released. =20 The market is not waiting for v6ops. But this is true in other IETF areas not just here. =20 Picking on our Ent work as example. We have had pretty much the same intro and scope we believed was important since the v6ops interim meeting and in Yokohamma. Today we now learn there is a scope issue. Yokohamma was 9 months or so ago. We need to fix this folks. It is not all the teams fault or the working group. Its some kind of process we are stuck in. We need to break it. =20 /jim =20 =20 =20 ------_=_NextPart_001_01C2E769.48D96AF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Just = as note. =20 Users are now working on their own scenarios and other forums (not the = IPv6=20 Forum, they have good work who does what with the IETF).   If = we don't=20 do this quickly no one will care.  But if they are just template = for us to=20 build tools they are still useful.
 
Also = realize folks=20 are designing networks using the methods from Teredo, ISATAP, and=20 DSTM.
Just = as a=20 note.  Products exist for each too or about to be=20 released.
 
The = market is not=20 waiting for v6ops. But this is true in other IETF areas not just=20 here.
 
Picking on our Ent=20 work as example.  We have had pretty much the same intro and scope = we=20 believed was important since the v6ops interim meeting and in = Yokohamma. =20 Today we now learn there is a scope issue.  Yokohamma was 9 months = or so=20 ago.  We need to fix this folks.  It is not all the teams = fault or the=20 working group.  Its some kind of process we are stuck in.  We = need to=20 break it.
 
/jim
 
 
 
=00 ------_=_NextPart_001_01C2E769.48D96AF6-- From owner-v6ops@ops.ietf.org Mon Mar 10 20:52:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23886 for ; Mon, 10 Mar 2003 20:52:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sYwR-000NKU-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 17:52:31 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18sYwK-000NKH-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 17:52:24 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.10]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA04439; Mon, 10 Mar 2003 17:52:10 -0800 (PST) Message-Id: <5.1.0.14.2.20030310203703.00bd6480@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Mar 2003 20:47:49 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: Re: Note on Scenarios for IPv6 Cc: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241004@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, >Picking on our Ent work as example. We have had pretty much the same >intro and scope we believed was important since the v6ops interim meeting >and in Yokohamma. Today we now learn there is a scope issue. Yokohamma >was 9 months or so ago. We need to fix this folks. It is not all the >teams fault or the working group. Its some kind of process we are stuck >in. We need to break it. Why do you believe that there is a scope issue for this document? I have just read it, again, and I do not believe that there is anything wrong with the scope of this document. Obviously, there are still many incomplete sections that need to be completed, and there is some further editing needed, but I believe that the scope and structure are fine. The important thing is that we write a set of documents that help us to understand how enterprise networks will move to IPv6, where/when/how/if they will need to run both IPv4 and IPv6, and what coexistence mechanisms will be needed to make this work. We broke the task into two pieces, scenarios and analysis, because we wanted to understand the problem space before we started working on the applicability of each coexistence mechanism to the problem space. I think that this document does a good job of defining the problem space for our later analysis work. Margaret From owner-v6ops@ops.ietf.org Mon Mar 10 21:06:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24178 for ; Mon, 10 Mar 2003 21:06:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sZBb-000OIe-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 18:08:11 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sZBZ-000OIS-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 18:08:09 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0075F7B6C; Mon, 10 Mar 2003 21:08:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 21:08:07 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Note on Scenarios for IPv6 Date: Mon, 10 Mar 2003 21:08:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241005@tayexc13.americas.cpqcorp.net> Thread-Topic: Note on Scenarios for IPv6 Thread-Index: AcLncN6FJRkGhXemQi64cDDf8O7tzAAAT9mg From: "Bound, Jim" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 11 Mar 2003 02:08:07.0906 (UTC) FILETIME=[0F055C20:01C2E773] X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA24178 Hi Margaret, I won't inline comment (not because I am lazy) because I am in tune with your mail and agree. I am fully on board with the v6ops charter to see if it works. I stated my input on that but can move on if that is what the team wants to do, except for very rare cases (e.g. Stateful being a SHOULD in node reqs and will fight the to the IESG most likely). What I was referencing (not picking on Pekka) was Pekka's mail to our Ent draft and short discussion Pekka had with Bob Fink regarding defining the IPv4 Enterprise in scenarios not IPv6. Granted it was a short mail exchange, and I could be reading to much into it. But, I have seen this type of mail in our culture cause raging debate over the assumptions and goals, and we end up back at the starting gate. So given many years here I am a bit nervous on the amount of energy I put into it. But I thought we were ok till today too. Just checking. I also believe doing the scearios will make steps move very quickly for TTM for our specs and output from this WG. At least in theory. Thanks /jim >-----Original Message----- >From: Margaret Wasserman [mailto:mrw@windriver.com] >Sent: Monday, March 10, 2003 8:48 PM >To: Bound, Jim >Cc: v6ops@ops.ietf.org >Subject: Re: Note on Scenarios for IPv6 > > > >Hi Jim, > >>Picking on our Ent work as example. We have had pretty much the same >>intro and scope we believed was important since the v6ops >interim meeting >>and in Yokohamma. Today we now learn there is a scope issue. > Yokohamma >>was 9 months or so ago. We need to fix this folks. It is >not all the >>teams fault or the working group. Its some kind of process >we are stuck >>in. We need to break it. > >Why do you believe that there is a scope issue for this >document? I have just read it, again, and I do not believe >that there is anything wrong with the scope of this document. > >Obviously, there are still many incomplete sections that >need to be completed, and there is some further editing >needed, but I believe that the scope and structure are >fine. > >The important thing is that we write a set of documents >that help us to understand how enterprise networks will move >to IPv6, where/when/how/if they will need to run both IPv4 >and IPv6, and what coexistence mechanisms will be needed >to make this work. > >We broke the task into two pieces, scenarios and analysis, >because we wanted to understand the problem space before we >started working on the applicability of each coexistence >mechanism to the problem space. I think that this document >does a good job of defining the problem space for our later >analysis work. > >Margaret > > > > > > From owner-v6ops@ops.ietf.org Mon Mar 10 22:47:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26003 for ; Mon, 10 Mar 2003 22:47:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sajy-0003x5-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 19:47:46 -0800 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18sajw-0003wp-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 19:47:44 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 97B0C4BC9; Tue, 11 Mar 2003 12:47:40 +0900 (JST) To: Alain Durand Cc: "Bound, Jim" , Sebastien Roy , Mika Liljeberg , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Mon, 10 Mar 2003 15:13:16 PST. <3E6D1C0C.80003@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: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Tue, 11 Mar 2003 12:47:40 +0900 Message-Id: <20030311034740.97B0C4BC9@coconut.itojun.org> X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>For edification. I have a node on a work LAN that knows nothing of IPv6. I >>download software and configure my node to be capable of IPv6. I manually >>configure my interface to support IPv6. I now ftp to an IPv6 address. This >>is not going to work. But I was stupid to think it would? Is this the kind >>of basic mistake your also worried about? >> >Alternate scenario: >We ship our system so they configure IPv6 ON by default on all interface. >User install this machine on his v4-only network and now experiment >larger than usual delays to connect to his favorite servers. >User call customer support. >This is what I worried about. your worry has very little to do with IPv6 itself. this is because of the way we operate IPv6 today (especially in the States) where long-haul tunnels and excessive/nonconsiderate transit is common. another thing is that users would call customer support regardless from the protocol type they're using. IPv4 or IPv6. there's no difference. itojun From owner-v6ops@ops.ietf.org Tue Mar 11 01:08:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28668 for ; Tue, 11 Mar 2003 01:08:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18scwF-000D9S-00 for v6ops-data@psg.com; Mon, 10 Mar 2003 22:08:35 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18scwD-000D9C-00 for v6ops@ops.ietf.org; Mon, 10 Mar 2003 22:08:33 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2B68Lf00412; Tue, 11 Mar 2003 08:08:21 +0200 Date: Tue, 11 Mar 2003 08:08:21 +0200 (EET) From: Pekka Savola To: Alain Durand cc: "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , , , Subject: Re: dual stack & IPv6 on by default In-Reply-To: <3E6D1C0C.80003@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 10 Mar 2003, Alain Durand wrote: > >For edification. I have a node on a work LAN that knows nothing of IPv6. I > >download software and configure my node to be capable of IPv6. I manually > >configure my interface to support IPv6. I now ftp to an IPv6 address. This > >is not going to work. But I was stupid to think it would? Is this the kind > >of basic mistake your also worried about? > > > Alternate scenario: > We ship our system so they configure IPv6 ON by default on all interface. > User install this machine on his v4-only network and now experiment > larger than usual delays to connect to his favorite servers. > User call customer support. > This is what I worried about. How do the delays get longer, I wonder? Different flavors of BSD have shipped v6-enabled by default since, about 2000 or 2001, I don't remember anymore, and I've never seen anyone complain about increased delays. I don't think there should be any significant potential drawback *until* the system is configured with a non-link-local address. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 11 03:27:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13035 for ; Tue, 11 Mar 2003 03:27:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sf7S-000M2j-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 00:28:18 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18sf7P-000M2X-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 00:28:15 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00564; Tue, 11 Mar 2003 01:28:13 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2B8S8P24010; Tue, 11 Mar 2003 09:28:09 +0100 (MET) Date: Tue, 11 Mar 2003 09:24:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: v6ops@ops.ietf.org, Erik Nordmark In-Reply-To: "Your message with ID" <3E6D28F6.10003@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I notice that in the latest draft version, you are no longer requiring an > MRU of 4420 bytes in decapsulators and seem to be taking a less > aggressive approach in the dynamic MTU discovery in the encapsulator. > Can you say more as to the reasons for the change? This change (the non-need for the 4420 limit) was presented in Atlanta even though it was not in the previous version of the draft. The basic results (which I think were on the slides, or perhaps only in the discussion in Atlanta) is that the decapsulator needs to support reassembly of up to the max (of its interface MTUs) and 1280+20. (There is a note in the spec about it really being its neighbors MTU that matter when the MTU != MRU). Then the encapsulator can choose between the static approach of a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic tunnel MTU detection using IPv4 path MTU discovery. The latter will never result in IPv4 packets at the decapsulator larger than the max of the decapsualtor's interface MTUs. Finally the spec allows for manual configuration to override the 1280 number in the static/fixed MTU case, but only if the receiver can handle reassembly of the larger IPv4 packets. Thus it requires manual coordination between the encapsulator and decapsulator to do this manual override. Erik From owner-v6ops@ops.ietf.org Tue Mar 11 04:17:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13877 for ; Tue, 11 Mar 2003 04:17:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sfto-000NTs-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 01:18:16 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18sftU-000NSr-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 01:17:56 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h2B9Hq921890; Tue, 11 Mar 2003 10:17:52 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2B9Hkof023661; Tue, 11 Mar 2003 10:17:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303110917.h2B9Hkof023661@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jonne.Soininen@nokia.com cc: mrw@windriver.com, v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt In-reply-to: Your message of Mon, 10 Mar 2003 14:45:28 PST. <4D7B558499107545BB45044C63822DDEEBDC44@mvebe001.americas.nokia.com> Date: Tue, 11 Mar 2003 10:17:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > The comment: > IMHO the PDP PPP context finishing at the ISP NAS will be the > more common GPRS scenario because regulatory bodies won't accept > the mobile operator and the ISP will be the same entity, i.e., > customers should get the choice. This scenario is explicitely > put out of the scope of the document in 4.1. I do not completely agree with your statement - especially, as having a different ISP than the mobile operator doesn't have anything to do with PDP Type PPP. It can be achieved with PDP Type IP as well. Anyways, I wonder if this has to be discussed here. => there are not many other solutions (GGSN as a mobile IP foreign agent, etc) and the only widely deployed solution in a similar context, ADSL, is to switch PPP in the box which has the role equivalent to the GGSN. Back a question: We deliberately put the case where there is PPP connection directly from the mobile to the ISP as an out of scope case as we would tendo to believe that it is part of a more general case (i.e. the ISP cases). Are you happy with this decision, or are you objecting to that? (You seemed to be happy about it as we discussed it the last time.) => I have no objection as soon as it is clear that it is out of the scope of the document. IMHO the scenario documents should not try to cover too many cases each, the only real constraint is the whole set doesn't neglect some important cases. the MS Word -> text conversion => argh! Was this for estetical reasons => it was. Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Tue Mar 11 05:34:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15142 for ; Tue, 11 Mar 2003 05:34:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sh5t-000PZy-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 02:34:49 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18sh5p-000PZl-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 02:34:46 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2BAYfOI044038; Tue, 11 Mar 2003 11:34:41 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2BAYebn202498; Tue, 11 Mar 2003 11:34:41 +0100 Received: from dhcp222-59.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58356 from ; Tue, 11 Mar 2003 11:34:39 +0100 Message-Id: <3E6DBB84.BB761962@hursley.ibm.com> Date: Tue, 11 Mar 2003 11:33:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Note on Scenarios for IPv6 References: <9C422444DE99BC46B3AD3C6EAFC9711B03241005@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I made the comment a few weeks ago that the enterprise document should include some customer-scenario use cases, to validate the technical scenarios as being relevant - and Jim acknowledged this as a useful thing to add. But I don't think that means there is a basic scope problem with the document. Brian "Bound, Jim" wrote: > > Hi Margaret, > > I won't inline comment (not because I am lazy) because I am in tune with > your mail and agree. I am fully on board with the v6ops charter to see > if it works. I stated my input on that but can move on if that is what > the team wants to do, except for very rare cases (e.g. Stateful being a > SHOULD in node reqs and will fight the to the IESG most likely). > > What I was referencing (not picking on Pekka) was Pekka's mail to our > Ent draft and short discussion Pekka had with Bob Fink regarding > defining the IPv4 Enterprise in scenarios not IPv6. Granted it was a > short mail exchange, and I could be reading to much into it. But, I > have seen this type of mail in our culture cause raging debate over the > assumptions and goals, and we end up back at the starting gate. So given > many years here I am a bit nervous on the amount of energy I put into > it. > > But I thought we were ok till today too. Just checking. I also believe > doing the scearios will make steps move very quickly for TTM for our > specs and output from this WG. At least in theory. > > Thanks > /jim > > > > >-----Original Message----- > >From: Margaret Wasserman [mailto:mrw@windriver.com] > >Sent: Monday, March 10, 2003 8:48 PM > >To: Bound, Jim > >Cc: v6ops@ops.ietf.org > >Subject: Re: Note on Scenarios for IPv6 > > > > > > > >Hi Jim, > > > >>Picking on our Ent work as example. We have had pretty much the same > >>intro and scope we believed was important since the v6ops > >interim meeting > >>and in Yokohamma. Today we now learn there is a scope issue. > > Yokohamma > >>was 9 months or so ago. We need to fix this folks. It is > >not all the > >>teams fault or the working group. Its some kind of process > >we are stuck > >>in. We need to break it. > > > >Why do you believe that there is a scope issue for this > >document? I have just read it, again, and I do not believe > >that there is anything wrong with the scope of this document. > > > >Obviously, there are still many incomplete sections that > >need to be completed, and there is some further editing > >needed, but I believe that the scope and structure are > >fine. > > > >The important thing is that we write a set of documents > >that help us to understand how enterprise networks will move > >to IPv6, where/when/how/if they will need to run both IPv4 > >and IPv6, and what coexistence mechanisms will be needed > >to make this work. > > > >We broke the task into two pieces, scenarios and analysis, > >because we wanted to understand the problem space before we > >started working on the applicability of each coexistence > >mechanism to the problem space. I think that this document > >does a good job of defining the problem space for our later > >analysis work. > > > >Margaret From owner-v6ops@ops.ietf.org Tue Mar 11 07:24:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17189 for ; Tue, 11 Mar 2003 07:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sioK-0002aP-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 04:24:48 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18sioH-0002aD-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 04:24:45 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA29869; Tue, 11 Mar 2003 04:24:27 -0800 (PST) Message-Id: <5.1.0.14.2.20030311071233.0345cf38@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Mar 2003 07:15:40 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: Note on Scenarios for IPv6 Cc: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241005@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, >What I was referencing (not picking on Pekka) was Pekka's mail to our >Ent draft and short discussion Pekka had with Bob Fink regarding >defining the IPv4 Enterprise in scenarios not IPv6. I'll go back and check, but I think that the only scope issue we've been discussing with a v6ops scenario draft is the ISP draft, not the Enterprise draft. The ISP draft includes some execellent work that describes current IPv4 installations, but it doesn't (yet) explain how/when/where/if IPv6 will be introduced, so it doesn't set up scenarios that can be used to analyze the applicability of coexistence mechanisms. I believe that the ISP team is aware of the need to expand the scope of their draft, and that they are working on it. So, unless I've missed something important (if I have, Pekka, please tell me), there is no disagreement about the scope of the Enterprise draft. Margaret From owner-v6ops@ops.ietf.org Tue Mar 11 07:30:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17419 for ; Tue, 11 Mar 2003 07:30:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sivt-0002oo-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 04:32:37 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sivq-0002oc-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 04:32:34 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 319438232; Tue, 11 Mar 2003 07:32:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 07:32:31 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Note on Scenarios for IPv6 Date: Tue, 11 Mar 2003 07:32:31 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB25@tayexc13.americas.cpqcorp.net> Thread-Topic: Note on Scenarios for IPv6 Thread-Index: AcLnyHgC5njr/GMuTg63jY0iyvi/DgAAbXxQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 11 Mar 2003 12:32:31.0720 (UTC) FILETIME=[4931B680:01C2E7CA] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA17419 Brian, Assume the customers can remain anonymous? Thanks /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, March 11, 2003 5:34 AM > To: Bound, Jim > Cc: Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: Note on Scenarios for IPv6 > > > I made the comment a few weeks ago that the enterprise > document should include some customer-scenario use cases, to > validate the technical scenarios as being relevant - and Jim > acknowledged this as a useful thing to add. But I don't think > that means there is a basic scope problem with the document. > > Brian > > "Bound, Jim" wrote: > > > > Hi Margaret, > > > > I won't inline comment (not because I am lazy) because I am in tune > > with your mail and agree. I am fully on board with the > v6ops charter > > to see if it works. I stated my input on that but can move > on if that > > is what the team wants to do, except for very rare cases (e.g. > > Stateful being a SHOULD in node reqs and will fight the to the IESG > > most likely). > > > > What I was referencing (not picking on Pekka) was Pekka's > mail to our > > Ent draft and short discussion Pekka had with Bob Fink regarding > > defining the IPv4 Enterprise in scenarios not IPv6. > Granted it was a > > short mail exchange, and I could be reading to much into > it. But, I > > have seen this type of mail in our culture cause raging debate over > > the assumptions and goals, and we end up back at the > starting gate. So > > given many years here I am a bit nervous on the amount of > energy I put > > into it. > > > > But I thought we were ok till today too. Just checking. I also > > believe doing the scearios will make steps move very > quickly for TTM > > for our specs and output from this WG. At least in theory. > > > > Thanks > > /jim > > > > > > > > >-----Original Message----- > > >From: Margaret Wasserman [mailto:mrw@windriver.com] > > >Sent: Monday, March 10, 2003 8:48 PM > > >To: Bound, Jim > > >Cc: v6ops@ops.ietf.org > > >Subject: Re: Note on Scenarios for IPv6 > > > > > > > > > > > >Hi Jim, > > > > > >>Picking on our Ent work as example. We have had pretty much the > > >>same intro and scope we believed was important since the v6ops > > >interim meeting > > >>and in Yokohamma. Today we now learn there is a scope issue. > > > Yokohamma > > >>was 9 months or so ago. We need to fix this folks. It is > > >not all the > > >>teams fault or the working group. Its some kind of process > > >we are stuck > > >>in. We need to break it. > > > > > >Why do you believe that there is a scope issue for this > document? I > > >have just read it, again, and I do not believe that there > is anything > > >wrong with the scope of this document. > > > > > >Obviously, there are still many incomplete sections that > need to be > > >completed, and there is some further editing needed, but I believe > > >that the scope and structure are fine. > > > > > >The important thing is that we write a set of documents > > >that help us to understand how enterprise networks will > move to IPv6, > > >where/when/how/if they will need to run both IPv4 and > IPv6, and what > > >coexistence mechanisms will be needed to make this work. > > > > > >We broke the task into two pieces, scenarios and analysis, > because we > > >wanted to understand the problem space before we started > working on > > >the applicability of each coexistence mechanism to the > problem space. > > >I think that this document does a good job of defining the problem > > >space for our later analysis work. > > > > > >Margaret > From owner-v6ops@ops.ietf.org Tue Mar 11 07:42:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17575 for ; Tue, 11 Mar 2003 07:42:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sj6M-0003BK-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 04:43:26 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18sj6K-0003B7-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 04:43:24 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2BCh8F02968; Tue, 11 Mar 2003 14:43:08 +0200 Date: Tue, 11 Mar 2003 14:43:08 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Bound, Jim" , Subject: RE: Note on Scenarios for IPv6 In-Reply-To: <5.1.0.14.2.20030311071233.0345cf38@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Tue, 11 Mar 2003, Margaret Wasserman wrote: > >What I was referencing (not picking on Pekka) was Pekka's mail to our > >Ent draft and short discussion Pekka had with Bob Fink regarding > >defining the IPv4 Enterprise in scenarios not IPv6. > > I'll go back and check, but I think that the only scope > issue we've been discussing with a v6ops scenario draft > is the ISP draft, not the Enterprise draft. My concern here was where do you draw the line. > The ISP draft includes some execellent work that describes > current IPv4 installations, but it doesn't (yet) explain > how/when/where/if IPv6 will be introduced, so it doesn't > set up scenarios that can be used to analyze the applicability > of coexistence mechanisms. My first though on scenarios documents were: "OK. First we must understand the problem (IPv4 networks, typically) to be able to work on IPv6". This has been done rather well in the ISP doc. It doesn't discuss IPv6 all that much, but I'm a bit unsure what kind of scenarios it could actually use without going into _solutions_ (one could argue that even basic principles like dual-stack or tunneling are solutions but I guess the consensus is that such are OK to discuss them under scenarios) -- this makes some assumptions about how v6 is enabled. One could argue that describing "how/when/where/if IPv6 is introducted" is part of the solutions space. > I believe that the ISP team is aware of the need to expand > the scope of their draft, and that they are working on it. > > So, unless I've missed something important (if I have, Pekka, > please tell me), there is no disagreement about the scope > of the Enterprise draft. Enterprise has a more integrated approach to how basic IPv6 transition mechanisms are taken into consideration in the text than ISP, yes -- but the general questions still arise: What should the _scenario_ documents include? (And what not.) What should the _solutions_ documents include? (And what not.) This seems to be a critical thing to have a common understanding on. To me, at least, this seems a quite uncertain. If we don't know what we should be doing, it's no wonder we haven't been able to make as much progress as we might have hoped :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 11 07:49:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17758 for ; Tue, 11 Mar 2003 07:49:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sjEO-0003T5-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 04:51:44 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18sjEL-0003Sn-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 04:51:41 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA07342 for ; Tue, 11 Mar 2003 12:51:39 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA13868 for ; Tue, 11 Mar 2003 12:51:38 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BCpcG25949 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 12:51:38 GMT Date: Tue, 11 Mar 2003 12:51:38 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Note on Scenarios for IPv6 Message-ID: <20030311125138.GK8715@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B03241005@tayexc13.americas.cpqcorp.net> <5.1.0.14.2.20030311071233.0345cf38@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030311071233.0345cf38@mail.windriver.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Mar 11, 2003 at 07:15:40AM -0500, Margaret Wasserman wrote: > > > set up scenarios that can be used to analyze the applicability > of coexistence mechanisms. So this is the key observation? If we cannot analyse the applicability of transition/coexistence mechanisms from the scenarios document, then the document is not sufficient. Completeness of the scenario space is another issue (i.e. we can create scenarios that we can guess may lead to a certain solution, and probably scenarios that would lead to use of many currently unadopted solutions). Tim From owner-v6ops@ops.ietf.org Tue Mar 11 08:31:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18857 for ; Tue, 11 Mar 2003 08:31:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sjqb-0004ta-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 05:31:13 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18sjqX-0004sE-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 05:31:10 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA09938; Tue, 11 Mar 2003 13:31:05 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15832; Tue, 11 Mar 2003 13:31:04 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BDV4j28822; Tue, 11 Mar 2003 13:31:04 GMT Date: Tue, 11 Mar 2003 13:31:04 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.Sun.COM Subject: Re: dual stack & IPv6 on by default Message-ID: <20030311133104.GM8715@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.Sun.COM References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Mar 10, 2003 at 06:04:02PM -0500, Bound, Jim wrote: > > For edification. I have a node on a work LAN that knows nothing of > IPv6. I download software and configure my node to be capable of IPv6. > I manually configure my interface to support IPv6. I now ftp to an IPv6 > address. This is not going to work. But I was stupid to think it > would? Is this the kind of basic mistake your also worried about? Agreed if you're static in a network, then that's a mistake. But a common problem is taking an IPv6-enabled device from a "dual stack" network where it happily runs using either protocol into one where only IPv4 is supported. Then what happens varies with OS/browser. For example, in WinXP+MSIE6 any attempt to reach a site with an AAAA (and A) record will fail with an error after 20-60 seconds. With WinXP+Mozilla 1.3 a similar attempt will just get an immediate "connection refused". In neither case is there (the desirable) fallback to IPv4. So for people who want to go dual-stack in their workplace yet take devices to IPv4-only networks that's the problem they face. Of course you get what you deserve maybe for the application writer trusting presence of a DNS record as an indication of connectivity. There will be some user-land settings required for IPv6 connectivity. For example RFC3041 needs to be per application so you can rely on (as many people will want to) per-host IP-based authentication for ssh access, while taking advantage of RFC3041 while browsing the net from the same host. I can see that we can offer users a privacy/fixed IP toggle, and many could understand that as an advanced setting in their TCP/IP options, but it's something we want to shield "typical" users from. I don't believe a userland v4/v6 toggle would be useful for "typical" users. It be used by the v6-geeks in the current stage of deployment, but we need more robust methods for handling movement between dual-stack and IPv4-only networks where IPv6 is enabled on a device. We're paying for the choice of app developers to promote IPv6 by trying IPv6 ahead of IPv4, and then not falling back (quickly) when it fails. Tim From owner-v6ops@ops.ietf.org Tue Mar 11 09:00:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19626 for ; Tue, 11 Mar 2003 09:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18skKb-0006AW-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 06:02:13 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18skKT-000699-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 06:02:05 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA02910; Tue, 11 Mar 2003 06:01:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030311085338.047395e8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Mar 2003 08:59:47 -0500 To: Pekka Savola From: Margaret Wasserman Subject: RE: Note on Scenarios for IPv6 Cc: "Bound, Jim" , In-Reply-To: References: <5.1.0.14.2.20030311071233.0345cf38@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >What should the _scenario_ documents include? (And what not.) >What should the _solutions_ documents include? (And what not.) > >This seems to be a critical thing to have a common understanding on. Actually, I'm not so sure that this is critical... The division of this work in to two documents is somewhat artificial. The idea is to have a first document, scenarios, that describes the possible scenarios for introducing IPv6 into a particular environment, and a second document, analysis, that analyzes which coexistance mechanisms (existing or to be developed) are needed for each scenario. The enterprise, 3GPP and unmanaged docs all do include discussion of where IPv6 will be introduced/available in the scenarios document, and they break down the scenarios that way, so it would be best if the ISP document is consistent with them. However, the _critical_ goal is to get to an end-state where we understand which coexistence mechanisms are needed and how/when they should be used. Margaret From owner-v6ops@ops.ietf.org Tue Mar 11 09:19:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20217 for ; Tue, 11 Mar 2003 09:19:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18skdC-0006sC-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 06:21:26 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18skd6-0006rx-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 06:21:23 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2BEKEOI120198; Tue, 11 Mar 2003 15:20:14 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2BEKDHe124806; Tue, 11 Mar 2003 15:20:14 +0100 Received: from dhcp22-14.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32644 from ; Tue, 11 Mar 2003 15:20:08 +0100 Message-Id: <3E6DF05D.6B0186E5@hursley.ibm.com> Date: Tue, 11 Mar 2003 15:19:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Note on Scenarios for IPv6 References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB25@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sure. "A bank". "A large IT company".... Brian "Bound, Jim" wrote: > > Brian, > > Assume the customers can remain anonymous? > > Thanks > /jim > > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Tuesday, March 11, 2003 5:34 AM > > To: Bound, Jim > > Cc: Margaret Wasserman; v6ops@ops.ietf.org > > Subject: Re: Note on Scenarios for IPv6 > > > > > > I made the comment a few weeks ago that the enterprise > > document should include some customer-scenario use cases, to > > validate the technical scenarios as being relevant - and Jim > > acknowledged this as a useful thing to add. But I don't think > > that means there is a basic scope problem with the document. > > > > Brian > > > > "Bound, Jim" wrote: > > > > > > Hi Margaret, > > > > > > I won't inline comment (not because I am lazy) because I am in tune > > > with your mail and agree. I am fully on board with the > > v6ops charter > > > to see if it works. I stated my input on that but can move > > on if that > > > is what the team wants to do, except for very rare cases (e.g. > > > Stateful being a SHOULD in node reqs and will fight the to the IESG > > > most likely). > > > > > > What I was referencing (not picking on Pekka) was Pekka's > > mail to our > > > Ent draft and short discussion Pekka had with Bob Fink regarding > > > defining the IPv4 Enterprise in scenarios not IPv6. > > Granted it was a > > > short mail exchange, and I could be reading to much into > > it. But, I > > > have seen this type of mail in our culture cause raging debate over > > > the assumptions and goals, and we end up back at the > > starting gate. So > > > given many years here I am a bit nervous on the amount of > > energy I put > > > into it. > > > > > > But I thought we were ok till today too. Just checking. I also > > > believe doing the scearios will make steps move very > > quickly for TTM > > > for our specs and output from this WG. At least in theory. > > > > > > Thanks > > > /jim > > > > > > > > > > > > >-----Original Message----- > > > >From: Margaret Wasserman [mailto:mrw@windriver.com] > > > >Sent: Monday, March 10, 2003 8:48 PM > > > >To: Bound, Jim > > > >Cc: v6ops@ops.ietf.org > > > >Subject: Re: Note on Scenarios for IPv6 > > > > > > > > > > > > > > > >Hi Jim, > > > > > > > >>Picking on our Ent work as example. We have had pretty much the > > > >>same intro and scope we believed was important since the v6ops > > > >interim meeting > > > >>and in Yokohamma. Today we now learn there is a scope issue. > > > > Yokohamma > > > >>was 9 months or so ago. We need to fix this folks. It is > > > >not all the > > > >>teams fault or the working group. Its some kind of process > > > >we are stuck > > > >>in. We need to break it. > > > > > > > >Why do you believe that there is a scope issue for this > > document? I > > > >have just read it, again, and I do not believe that there > > is anything > > > >wrong with the scope of this document. > > > > > > > >Obviously, there are still many incomplete sections that > > need to be > > > >completed, and there is some further editing needed, but I believe > > > >that the scope and structure are fine. > > > > > > > >The important thing is that we write a set of documents > > > >that help us to understand how enterprise networks will > > move to IPv6, > > > >where/when/how/if they will need to run both IPv4 and > > IPv6, and what > > > >coexistence mechanisms will be needed to make this work. > > > > > > > >We broke the task into two pieces, scenarios and analysis, > > because we > > > >wanted to understand the problem space before we started > > working on > > > >the applicability of each coexistence mechanism to the > > problem space. > > > >I think that this document does a good job of defining the problem > > > >space for our later analysis work. > > > > > > > >Margaret > > From owner-v6ops@ops.ietf.org Tue Mar 11 09:46:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20978 for ; Tue, 11 Mar 2003 09:46:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sl1s-0007vH-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 06:46:56 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sl1p-0007v4-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 06:46:53 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 81123837E; Tue, 11 Mar 2003 09:46:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 09:46:52 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Note on Scenarios for IPv6 Date: Tue, 11 Mar 2003 09:46:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241008@tayexc13.americas.cpqcorp.net> Thread-Topic: Note on Scenarios for IPv6 Thread-Index: AcLny8/MyjGKdxPbT8qZbFyElhRATQAD6X+w From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 11 Mar 2003 14:46:52.0325 (UTC) FILETIME=[0DB06D50:01C2E7DD] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20978 As one of our Ent design team members stated Mr. Tony Hain the matrix or points on a graph for all the variant possibilities of how an enterprise will approach adoption of IPv6 are to large to document each case. The approach we have taken is to select the best case scenarios and methods to cover the widest possible cases. I think one thing we realized on the Ent team is that we believe the phrase IPv6 Adoption applies to the initial scenarios rather than IPv6 Transition. First the Enterprise will believe it is important to Adopt IPv6. Then the Enterprise will look at all the possibilities to reach that Adoption and develop their plan. The key here is the Enterprise will NOT just do what we say in specs for Adoption or Transition. They look for us to provide them INPUT not the PLAN. This is a key assumption by us on the Ent team and have discussed it in depth. Out of curiosity does anyone in v6ops not agree with this? It is an assumption about our role in the industry at large too. Another point I want to make that is important for folks to understand. Large Enterprises like Fortune 100 companies, Government, Military, etc. all hire very knowledgable computer scientists and folks just like on this list who are experts like us with as much senority as many of us in the industry. They have architects, engineers, operational expertise, etc. I tend to think vendors and standards bodies often don't get this point. We also can never develop a one-size-fits all set of specs or architecture for IPv6 operations, but only add to the tools the users can use to build IPv6 networks. Understanding what I say above (not that all agree) is important to realize about our assumptions as a team working together and how/why one of us may view our work and efforts differently. I personally believe from reading mail on this list and hearing views that a part of our team here do not get that the users are far more educated, have deployed far more IPv6 than we realize in their labs, and have far more experience with IPv6 operationally, architecturally, and theoretically than we realize. Also realize vendor have been pitching IPv6 to customers for 3 years now, the users may actually know more about what products exist, next product plans by vendors than this list too. Regards, /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, March 11, 2003 7:43 AM > To: Margaret Wasserman > Cc: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: Note on Scenarios for IPv6 > > > Hi, > > On Tue, 11 Mar 2003, Margaret Wasserman wrote: > > >What I was referencing (not picking on Pekka) was Pekka's > mail to our > > >Ent draft and short discussion Pekka had with Bob Fink regarding > > >defining the IPv4 Enterprise in scenarios not IPv6. > > > > I'll go back and check, but I think that the only scope > > issue we've been discussing with a v6ops scenario draft > > is the ISP draft, not the Enterprise draft. > > My concern here was where do you draw the line. > > > The ISP draft includes some execellent work that describes current > > IPv4 installations, but it doesn't (yet) explain how/when/where/if > > IPv6 will be introduced, so it doesn't set up scenarios that can be > > used to analyze the applicability of coexistence mechanisms. > > My first though on scenarios documents were: "OK. First we > must understand the problem (IPv4 networks, typically) to be > able to work on IPv6". This has been done rather well in the ISP doc. > > It doesn't discuss IPv6 all that much, but I'm a bit unsure > what kind of scenarios it could actually use without going > into _solutions_ (one could argue that even basic principles > like dual-stack or tunneling are solutions but I guess the > consensus is that such are OK to discuss them under > scenarios) -- this makes some assumptions about how v6 is enabled. > > One could argue that describing "how/when/where/if IPv6 is > introducted" is part of the solutions space. > > > I believe that the ISP team is aware of the need to expand > the scope > > of their draft, and that they are working on it. > > > > So, unless I've missed something important (if I have, > Pekka, please > > tell me), there is no disagreement about the scope of the > Enterprise > > draft. > > Enterprise has a more integrated approach to how basic IPv6 > transition mechanisms are taken into consideration in the > text than ISP, yes -- but the general questions still arise: > > What should the _scenario_ documents include? (And what not.) > What should the _solutions_ documents include? (And what not.) > > This seems to be a critical thing to have a common > understanding on. To me, at least, this seems a quite > uncertain. If we don't know what we should be doing, it's no > wonder we haven't been able to make as much progress as we > might have hoped :-). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Tue Mar 11 09:48:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20998 for ; Tue, 11 Mar 2003 09:48:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sl4r-00082j-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 06:50:01 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sl4k-000826-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 06:49:54 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 79E70163C; Tue, 11 Mar 2003 09:49:53 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 09:49:53 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Note on Scenarios for IPv6 Date: Tue, 11 Mar 2003 09:49:52 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB37@tayexc13.americas.cpqcorp.net> Thread-Topic: Note on Scenarios for IPv6 Thread-Index: AcLn2XAsvgSvcPsrRDisiHRv8UTMpAAA72VQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 11 Mar 2003 14:49:53.0341 (UTC) FILETIME=[799546D0:01C2E7DD] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20998 Thanks then we can add that to our Ent docs without saying names. For example then Government would cover Commerce, Military, Energy, but would differentiate research as different. These folks are moving NOW with IPv6 and ahead of this group with scenarios fyi in most geographies. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, March 11, 2003 9:19 AM > To: Bound, Jim > Cc: Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: Note on Scenarios for IPv6 > > > Sure. "A bank". "A large IT company".... > > Brian > > "Bound, Jim" wrote: > > > > Brian, > > > > Assume the customers can remain anonymous? > > > > Thanks > > /jim > > > > > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Tuesday, March 11, 2003 5:34 AM > > > To: Bound, Jim > > > Cc: Margaret Wasserman; v6ops@ops.ietf.org > > > Subject: Re: Note on Scenarios for IPv6 > > > > > > > > > I made the comment a few weeks ago that the enterprise document > > > should include some customer-scenario use cases, to validate the > > > technical scenarios as being relevant - and Jim > acknowledged this as > > > a useful thing to add. But I don't think that means there > is a basic > > > scope problem with the document. > > > > > > Brian > > > > > > "Bound, Jim" wrote: > > > > > > > > Hi Margaret, > > > > > > > > I won't inline comment (not because I am lazy) because I am in > > > > tune with your mail and agree. I am fully on board with the > > > v6ops charter > > > > to see if it works. I stated my input on that but can move > > > on if that > > > > is what the team wants to do, except for very rare cases (e.g. > > > > Stateful being a SHOULD in node reqs and will fight the to the > > > > IESG most likely). > > > > > > > > What I was referencing (not picking on Pekka) was Pekka's > > > mail to our > > > > Ent draft and short discussion Pekka had with Bob Fink > regarding > > > > defining the IPv4 Enterprise in scenarios not IPv6. > > > Granted it was a > > > > short mail exchange, and I could be reading to much into > > > it. But, I > > > > have seen this type of mail in our culture cause raging debate > > > > over the assumptions and goals, and we end up back at the > > > starting gate. So > > > > given many years here I am a bit nervous on the amount of > > > energy I put > > > > into it. > > > > > > > > But I thought we were ok till today too. Just > checking. I also > > > > believe doing the scearios will make steps move very > > > quickly for TTM > > > > for our specs and output from this WG. At least in theory. > > > > > > > > Thanks > > > > /jim > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Margaret Wasserman [mailto:mrw@windriver.com] > > > > >Sent: Monday, March 10, 2003 8:48 PM > > > > >To: Bound, Jim > > > > >Cc: v6ops@ops.ietf.org > > > > >Subject: Re: Note on Scenarios for IPv6 > > > > > > > > > > > > > > > > > > > >Hi Jim, > > > > > > > > > >>Picking on our Ent work as example. We have had > pretty much the > > > > >>same intro and scope we believed was important since the v6ops > > > > >interim meeting > > > > >>and in Yokohamma. Today we now learn there is a scope issue. > > > > > Yokohamma > > > > >>was 9 months or so ago. We need to fix this folks. It is > > > > >not all the > > > > >>teams fault or the working group. Its some kind of process > > > > >we are stuck > > > > >>in. We need to break it. > > > > > > > > > >Why do you believe that there is a scope issue for this > > > document? I > > > > >have just read it, again, and I do not believe that there > > > is anything > > > > >wrong with the scope of this document. > > > > > > > > > >Obviously, there are still many incomplete sections that > > > need to be > > > > >completed, and there is some further editing needed, but I > > > > >believe that the scope and structure are fine. > > > > > > > > > >The important thing is that we write a set of > documents that help > > > > >us to understand how enterprise networks will > > > move to IPv6, > > > > >where/when/how/if they will need to run both IPv4 and > > > IPv6, and what > > > > >coexistence mechanisms will be needed to make this work. > > > > > > > > > >We broke the task into two pieces, scenarios and analysis, > > > because we > > > > >wanted to understand the problem space before we started > > > working on > > > > >the applicability of each coexistence mechanism to the > > > problem space. > > > > >I think that this document does a good job of defining the > > > > >problem space for our later analysis work. > > > > > > > > > >Margaret > > > > From owner-v6ops@ops.ietf.org Tue Mar 11 09:54:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21133 for ; Tue, 11 Mar 2003 09:54:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sl9z-0008Hi-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 06:55:19 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18sl9w-0008HT-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 06:55:16 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D0D6F832A; Tue, 11 Mar 2003 09:55:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 09:55:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 09:55:04 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB38@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLn0vJI4aALWXQ0T1S+6ms8UGf9hgACqOww From: "Bound, Jim" To: "Tim Chown" , , X-OriginalArrivalTime: 11 Mar 2003 14:55:04.0700 (UTC) FILETIME=[332AE3C0:01C2E7DE] X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA21133 > > So for people who want to go dual-stack in their workplace > yet take devices > to IPv4-only networks that's the problem they face. Of > course you get what > you deserve maybe for the application writer trusting > presence of a DNS > record as an indication of connectivity. This is for me key. I believe in punishment, penalties, and accountability :--) So if you do stupid things you will learn from that. But also we cannot possibly correct every network problem like this in IPv4 or IPv6. Again it is not indicative of just IPv6 but IPv4 too. Also I want to restate. For some if IPv6 don't work then they are dead. Fall back to IPv4 is not an option. I know users who are going to adopt IPv6 with the intention of phasing out IPv4 as quickly as possible and immediately move to dominant IPv6 routing backbones on their Intranet as a strategy. This is also becoming more and more prevalent exponentially too. My guess is they see the cost and decide lets just go to IPv6 as quick as possible and get the pain over with. This view is now as predominant as any other for deployment and I feel many on this list don't "get it". This is not mean't to be negative or a challenge merely a statement. /jim From owner-v6ops@ops.ietf.org Tue Mar 11 11:10:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25063 for ; Tue, 11 Mar 2003 11:10:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18smKG-000Bmd-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 08:10:00 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18smKC-000BmO-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 08:09:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18smKB-0008iz-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 08:09:55 -0800 Message-ID: <20030311134318.GB24974@newton.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> <3E6D1C0C.80003@sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: <3E6D1C0C.80003@sun.com> Date: Tue, 11 Mar 2003 14:43:18 +0100 From: Ignatios Souvatzis To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default X-Spam-Status: No, hits=-4.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi, On Mon, Mar 10, 2003 at 03:13:16PM -0800, Alain Durand wrote: > Alternate scenario: > We ship our system so they configure IPv6 ON by default on all interface. > User install this machine on his v4-only network and now experiment > larger than usual delays to connect to his favorite servers. The user won't, because in this case the machine won't get any address prefix and routing information. The trouble comes when the customer's net has a long-delay IPv6 connection. Regards, -is --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPm3n8zCn4om+4LhpAQHTDwgAkMcktlXt9S/w4VoufD2JDQj1Ar0TZGek vuiXqA1G30RD29HdLsyVOUR2skL2T4ODg31ZCs4hfZt1d7sha1/LgvdGLYsmbVq7 VKdtQGRRy1w1ihYnLoie6QHSEvdNJsjepustqXKitPoGJ5x7zZjITM2tj0fymCdc D0Ee7KZhfsUKnff1l394j+MOkT8QTf1RP8lzauFnXKOpS7mwBvF8Ut0twrQ9/jHT C/hG6/43rpOGyDzVI+qSWNhUwBpE05MElGYpLJQow/A9j2864AUfd53JuKEPvvZE /+FZo2B8/MFiRMJWYMIawxQdSGXZDxTDplAVcArGI+5Ju5JdXw+9Cw== =Wjl+ -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-v6ops@ops.ietf.org Tue Mar 11 11:29:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26204 for ; Tue, 11 Mar 2003 11:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18smeW-000Cu2-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 08:30:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18smeT-000Ctp-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 08:30:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18smeR-0008kO-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 08:30:51 -0800 In-Reply-To: Your message of "Tue, 11 Mar 2003 08:08:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030311152345.C83AB7B6C@berkshire.research.att.com> From: "Steven M. Bellovin" To: Pekka Savola Cc: Alain Durand , "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 10:23:45 -0500 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] In message , Pekka Savola wr ites: >On Mon, 10 Mar 2003, Alain Durand wrote: >> >For edification. I have a node on a work LAN that knows nothing of IPv6. >I >> >download software and configure my node to be capable of IPv6. I manually >> >configure my interface to support IPv6. I now ftp to an IPv6 address. Thi >s >> >is not going to work. But I was stupid to think it would? Is this the kin >d >> >of basic mistake your also worried about? >> > >> Alternate scenario: >> We ship our system so they configure IPv6 ON by default on all interface. >> User install this machine on his v4-only network and now experiment >> larger than usual delays to connect to his favorite servers. >> User call customer support. >> This is what I worried about. > >How do the delays get longer, I wonder? > >Different flavors of BSD have shipped v6-enabled by default since, about >2000 or 2001, I don't remember anymore, and I've never seen anyone >complain about increased delays. > >I don't think there should be any significant potential drawback *until* >the system is configured with a non-link-local address. There have been reports of problems with some Web browsers trying to use only the v6 address. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From owner-v6ops@ops.ietf.org Tue Mar 11 11:41:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26690 for ; Tue, 11 Mar 2003 11:41:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18smpy-000DW7-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 08:42:46 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18smpt-000DVd-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 08:42:42 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2BGh3wY017388; Tue, 11 Mar 2003 18:43:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2BGgwRg017386; Tue, 11 Mar 2003 18:42:58 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dual stack & IPv6 on by default From: Mika Liljeberg To: "Bound, Jim" Cc: Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241002@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241002@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047400973.2469.1743.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2003 18:42:58 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-03-11 at 02:17, Bound, Jim wrote: > >If one takes the ND spec strictly, case a) might or might not > >trigger dialup, depending on which default route we hit first. > >Case b) would never trigger the dialup [although an > >implementation might choose to do so after NUD]. > > OK. But NUD would mean it tells some function to configure the interface > in this case of dial up? Right? Even dialers do this now. > But ND is working above you do not say it does not from what I can see > as question? So far so good. ND itself is fine, I'm just exploring the rule: "If the Default Router List is empty, the sender assumes that the destination is on-link." The above rule makes option a) unfeasible in multi-homed hosts, so implementors have to go for option b). Not necessarily a big problem but reduces the options available to the implementor. > >On the other hand, as soon as the host receives the first RA > >from the dialup interface and configures a default router, the > >other interface stops working for ad-hoc. > > Why? Because now the default router list (combined from all interfaces) is not empty, so we can no longer assume that all destinations are on-link. Applications rely on the default route to get them to the routed network, so it does not make sense to have a default router in one interface and an on-link default route in another. Applications can't cope with it. > From your example it sounds like two separate links and that is a > non-issue as I interpret ND. Yes, I'm talking about separate links, but I'm sure its a non-issue. > >All this just goes to show that the default on-link route > >implied by the ND specification perhaps isn't fully thought > >out, at least with multihoming. > > The default route is for a link. And multiple routers are permitted to > announce routes. So two routers can be supported on a link, with one > being the default. Multipe interfaces can exist on one link. So in > that sense ND is transparent to multihome node. I understand and agree with all this. The point is: applications can't cope with multiple default routes, unless those routes offer equivalent connectivity. Default routers and on-link default routes just don't mix. Normal applications can't be expected to choose which network interface they want to use. So what I'm trying to say is that the rule "If the Default Router List is empty, the sender assumes that the destination is on-link" doesn't seem to make sense in a multi-homed host. To my mind, it doesn't make much sense in a single-homed host either. The intent would seem to be to allow link-local communication using configured addresses in the absence of a router. What's the point? Why not just use link-local addresses? I suspect the answer to that is ideological rather than practical. If the idea is to allow ad-hoc communication using configured addresses, then logically a multi-homed host, which currently doesn't know any default routers, would have to try to do ND on *all* its interfaces (rather than just picking an arbitrary one), in order to resolve a given destination address. Unfortunately this is not normal routing anymore. > I may have missed your point in my parser? Maybe at least partially. I hope I was more lucid this time. MikaL From owner-v6ops@ops.ietf.org Tue Mar 11 15:46:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11471 for ; Tue, 11 Mar 2003 15:46:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sqd1-0000jK-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 12:45:39 -0800 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18sqcy-0000j6-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 12:45:37 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5ED694FA4; Wed, 12 Mar 2003 05:45:32 +0900 (JST) To: "Steven M. Bellovin" Cc: Pekka Savola , Alain Durand , "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: smb's message of Tue, 11 Mar 2003 10:23:45 EST. <20030311152345.C83AB7B6C@berkshire.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Wed, 12 Mar 2003 05:45:32 +0900 Message-Id: <20030311204532.5ED694FA4@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >There have been reports of problems with some Web browsers trying to >use only the v6 address. this is due to the way mozilla is written. mozilla did: hp = gethostbyname2(host, AF_INET6); if (!hp) hp = gethostbyname(host); so mozilla tries to connect to IPv6/v4 dual stack destination, it would try to connect to IPv6 only. it has to be fixed by using getaddrinfo(3). itojun From owner-v6ops@ops.ietf.org Tue Mar 11 16:06:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12280 for ; Tue, 11 Mar 2003 16:06:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sqyf-0001vD-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 13:08:01 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18sqyZ-0001uw-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 13:07:55 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0A837B31; Tue, 11 Mar 2003 16:07:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 16:07:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 16:07:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB71@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLoD51nIEUQhOCAQG2vFCBI8FHdgwAAjIUQ From: "Bound, Jim" To: , "Steven M. Bellovin" Cc: "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 11 Mar 2003 21:07:53.0992 (UTC) FILETIME=[484DF880:01C2E812] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA12280 Folks, Mozilla is going to fix this. Part of the problem was we took so long getting rfc 2553 updated to new RFC (its in the RFC editor queue now) they used Richard Stevens old program model. This will be updated to getaddrinfo and I agree with Itojun. Now as usual we await release updates :--) We also updated the API after this code base that is must specify AI_MAPPED to get both v4 and v6. Regards, /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, March 11, 2003 3:46 PM > To: Steven M. Bellovin > Cc: Pekka Savola; Alain Durand; Bound, Jim; Sebastien Roy; > Mika Liljeberg; Ronald van der Pol; v6ops@ops.ietf.org; > jim.Paugh@Sun.COM; ipng@sunroof.eng.sun.com > Subject: Re: dual stack & IPv6 on by default > > > >There have been reports of problems with some Web browsers trying to > >use only the v6 address. > > this is due to the way mozilla is written. > mozilla did: > hp = gethostbyname2(host, AF_INET6); > if (!hp) > hp = gethostbyname(host); > so mozilla tries to connect to IPv6/v4 dual stack > destination, it > would try to connect to IPv6 only. it has to be fixed by using > getaddrinfo(3). > > itojun > From owner-v6ops@ops.ietf.org Tue Mar 11 16:08:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12446 for ; Tue, 11 Mar 2003 16:08:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sr1K-00025X-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 13:10:46 -0800 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18sr1H-00025K-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 13:10:44 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5485C4FC1; Wed, 12 Mar 2003 06:10:42 +0900 (JST) To: "Bound, Jim" Cc: "Steven M. Bellovin" , "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: Jim.Bound's message of Tue, 11 Mar 2003 16:07:53 EST. <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB71@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: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Wed, 12 Mar 2003 06:10:42 +0900 Message-Id: <20030311211042.5485C4FC1@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Mozilla is going to fix this. Part of the problem was we took so long >getting rfc 2553 updated to new RFC (its in the RFC editor queue now) >they used Richard Stevens old program model. This will be updated to >getaddrinfo and I agree with Itojun. Now as usual we await release >updates :--) We also updated the API after this code base that is must >specify AI_MAPPED to get both v4 and v6. no need for that, you can use PF_UNSPEC in hints.ai_family to get both IPv4 address (as ai_family = AF_INET) and IPv6 address (as ai_family = AF_INET6) and socket(2) as appropriate. itojun From owner-v6ops@ops.ietf.org Tue Mar 11 22:24:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24697 for ; Tue, 11 Mar 2003 22:24:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18swr2-000LsC-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 19:24:32 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18swqz-000Lry-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 19:24:29 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 437703D9F; Tue, 11 Mar 2003 22:24:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 22:24:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 22:24:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB98@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLn7UVuTGT6XTHzRSGdRnlSM2En5wAPrzYg From: "Bound, Jim" To: "Mika Liljeberg" Cc: "Sebastien Roy" , "Ronald van der Pol" , "Alain Durand" , , X-OriginalArrivalTime: 12 Mar 2003 03:24:28.0104 (UTC) FILETIME=[E371DC80:01C2E846] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA24697 Hi Mika, > On Tue, 2003-03-11 at 02:17, Bound, Jim wrote: > > >If one takes the ND spec strictly, case a) might or might not > > >trigger dialup, depending on which default route we hit first. Case > > >b) would never trigger the dialup [although an implementation might > > >choose to do so after NUD]. > > > > OK. But NUD would mean it tells some function to configure the > > interface in this case of dial up? Right? Even dialers do > this now. > > But ND is working above you do not say it does not from > what I can see > > as question? > > So far so good. ND itself is fine, I'm just exploring the rule: > > "If the Default Router List is empty, the sender assumes that > the destination is on-link." > > The above rule makes option a) unfeasible in multi-homed > hosts, so implementors have to go for option b). Not > necessarily a big problem but reduces the options available > to the implementor. Hmmm. See below assumption on my part. > > > >On the other hand, as soon as the host receives the first RA from > > >the dialup interface and configures a default router, the other > > >interface stops working for ad-hoc. > > > > Why? > > Because now the default router list (combined from all > interfaces) is not empty, so we can no longer assume that all > destinations are on-link. Applications rely on the default > route to get them to the routed network, so it does not make > sense to have a default router in one interface and an > on-link default route in another. Applications can't cope with it. This is where I believe I disconnect. To me applications are transparent to defult routes totally. This is done by the transport in combination with the IP routing table lookups, to determine the interface the packet will leave on, and in that process use a route for that interface and link. Those are per link with per link default routes. Given that it is not a problem? > > > From your example it sounds like two separate links and that is a > > non-issue as I interpret ND. > > Yes, I'm talking about separate links, but I'm sure its a non-issue. I agree per my comment above. > > > >All this just goes to show that the default on-link route implied > > >by the ND specification perhaps isn't fully thought out, at least > > >with multihoming. > > > > The default route is for a link. And multiple routers are > permitted > > to announce routes. So two routers can be supported on a > link, with > > one being the default. Multipe interfaces can exist on one > link. So > > in that sense ND is transparent to multihome node. > > I understand and agree with all this. The point is: > applications can't cope with multiple default routes, unless > those routes offer equivalent connectivity. Default routers > and on-link default routes just don't mix. Normal > applications can't be expected to choose which network > interface they want to use. Agreed, but applications do not choose this normally or the link. For a multilink node the search cannot just be for first left most bits match but an exhaustive search for the route till no match is found. That is the key. I agree if that is not done there is a problem. So if link 1 is 3FFE:3::24 and link2 is 3FFE:4::25 a match on 3FFE is not enough for a multilink node. The search must look past 3FFE and to the next bit (assume bit position search). Then one of them will be successful. This will point to an interface and link. At that point a default route will be looked for if no ND cache entry, if route exists that will be used, else sent over the link. The packet goes over the correct link and the application should not be involved. Now I agree an implementation that is not as robust as I suggest above will have a problem if the search is only on 3FFE and then a default interface will be selected too. But that is not a flaw in ND which is what I am saying but in the robustness of an implementation. The standard does nothing to prevent multihome nodes using ND. > > So what I'm trying to say is that the rule "If the Default > Router List is empty, the sender assumes that the destination > is on-link" doesn't seem to make sense in a multi-homed host. If the node has received no prefix or address knowledge it is a means to still try to send the packet. But in that case as I said above it would have to be a default link too or I guess a round robin decision. But this is not a problem with ND. Other than in many places in general in the IETF we always try to send the packet. One of my favorites is sending to a Global Address if all you have is a link-local address. I find this silly but it is permitted :--) But that is not a flaw in ND either. Though in most cases source address selection will fix this but not all. > To my mind, it doesn't make much sense in a single-homed host > either. The intent would seem to be to allow link-local > communication using configured addresses in the absence of a > router. What's the point? Why not just use link-local > addresses? I suspect the answer to that is ideological rather > than practical. Errr. Yep. > > If the idea is to allow ad-hoc communication using configured > addresses, then logically a multi-homed host, which currently > doesn't know any default routers, would have to try to do ND > on *all* its interfaces (rather than just picking an > arbitrary one), in order to resolve a given destination > address. Unfortunately this is not normal routing anymore. True, it is the ND protocol and it is required for IPv6. > > > I may have missed your point in my parser? > > Maybe at least partially. I hope I was more lucid this time. Well I believe it's a worthwhile discussion but this has been the case for awhile and ND if used will populate the ND cache and Route List, which I believe makes the problem go away. With the correct search algorithm for sending packets. ND works fine. Now if someone doesn't run ND then they are not IPv6 compliant. /jim > > MikaL > > From owner-v6ops@ops.ietf.org Tue Mar 11 23:17:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25517 for ; Tue, 11 Mar 2003 23:17:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sxhg-000NGj-00 for v6ops-data@psg.com; Tue, 11 Mar 2003 20:18:56 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18sxhd-000NGX-00 for v6ops@ops.ietf.org; Tue, 11 Mar 2003 20:18:53 -0800 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 UAA16431; Tue, 11 Mar 2003 20:18:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2C4IqS27241; Tue, 11 Mar 2003 20:18:52 -0800 X-mProtect: <200303120418> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.111, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8blPQS; Tue, 11 Mar 2003 20:18:49 PST Message-ID: <3E6EB525.70304@iprg.nokia.com> Date: Tue, 11 Mar 2003 20:18:45 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>I notice that in the latest draft version, you are no longer requiring an >>MRU of 4420 bytes in decapsulators and seem to be taking a less >>aggressive approach in the dynamic MTU discovery in the encapsulator. >>Can you say more as to the reasons for the change? >> >> > >This change (the non-need for the 4420 limit) was presented in >Atlanta even though it was not in the previous version of the draft. > >The basic results (which I think were on the slides, or perhaps only >in the discussion in Atlanta) is that the decapsulator needs to >support reassembly of up to the max (of its interface MTUs) and 1280+20. >(There is a note in the spec about it really being its neighbors MTU >that matter when the MTU != MRU). > Makes sense; it seems the 4420 requirement may have been too big for some low-end devices anyway. >Then the encapsulator can choose between the static approach of >a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic >tunnel MTU detection using IPv4 path MTU discovery. The latter will never >result in IPv4 packets at the decapsulator larger than the max of the >decapsualtor's interface MTUs. > Sure. Setting the DF bit prevents packets that are too big from reaching the decapsulator. >Finally the spec allows for manual configuration to override the 1280 number >in the static/fixed MTU case, but only if the receiver can handle reassembly >of the larger IPv4 packets. Thus it requires manual coordination between >the encapsulator and decapsulator to do this manual override. > Are there any concerns for denial of service based on receive buffer overrun at the decapsulator in this case? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 12 04:24:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27042 for ; Wed, 12 Mar 2003 04:24:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t2Tc-0006cX-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 01:24:44 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18t2TZ-0006cL-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 01:24:42 -0800 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2C9S7F04708 for ; Wed, 12 Mar 2003 11:28:07 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 11:24:39 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 11:24:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Wed, 12 Mar 2003 11:24:38 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3813@esebe005.ntc.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLnPJ61jK2WuSyVQkeyQnLqZ4CrxgBNIg0Q From: To: Cc: , X-OriginalArrivalTime: 12 Mar 2003 09:24:39.0566 (UTC) FILETIME=[34E142E0:01C2E879] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA27042 Hello, Chris! I was glad to receive comments on our draft - many thanks! Some comments with 'JW' below. -----Original Message----- From: ext Fischer, Christine A (Chris) [mailto:cafischer@lucent.com] Sent: 10 March, 2003 21:32 Section 2, last paragraph: It might be useful to include a reference to 3GPP TS 23.221, "Architectural requirements", which shows the transition scenarios for 3GPP. JW: Yep, we can consider doing that. In 23.221, section 5.2 there is a short description on "Interoperability between IPv4 and IPv6 networks." However, we are describing the scenarios more precisely in this 3GPP v6ops document. Section 3.1, third paragraph: change "comprised of" to "comprising" JW: OK! Section 3.2, under I-CSCF: typo on "operator's" same section: change "an 3GPP" to "a 3GPP" JW: Yes to both. The first one seems to be a non-ASCII char. Section 4.1, item 1), last paragraph: You may want to add a comment that this may require the use of NAT on external interfaces, when appropriate. Also, a comment that the placement and handling of DNS servers for IPv4 / IPv6 communication has not been included in these scenarios. JW: That sounds like a good proposal. At least the NAT usage should be mentioned. Section 4.1, item 4): Please define intent of the boxes marked by "x". Are these IPv4 networks or transition gateways? JW: The boxes marked with "?" show that some functionality in the network would be needed to make this kind of communication possible. The needed functionality (e.g. an ALG or a protocol translator) is then described in the "3GPP analysis" document. However, it might be useful to write 1-2 sentences on the "?" box functionality also in this document... Page 10, under Acknowledgements: There is an unknown character after Sipil. JW: Yes, we shall make him Mr. Sipila. :-) Cheers, -Juha W.- From owner-v6ops@ops.ietf.org Wed Mar 12 05:23:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28046 for ; Wed, 12 Mar 2003 05:23:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t3Pj-0008Sx-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 02:24:47 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18t3Pe-0008Sd-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 02:24:42 -0800 Received: from OLVERA01 ([217.167.116.220]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Wed, 12 Mar 2003 11:26:53 +0100 Message-ID: <011901c2e881$e3ee36a0$dc74a7d9@consulintel.es> Reply-To: =?iso-8859-1?Q?C=E9sar_Olvera_Morales?= From: =?iso-8859-1?Q?C=E9sar_Olvera_Morales?= To: References: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Wed, 12 Mar 2003 11:26:32 +0100 Organization: Consulintel, s.l. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.167.116.220 X-Return-Path: cesar.olvera@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I've read the draft and the early comments, and I don't have any additional comment. I think it will be ready with the proposed corrections. Best regards, Csar Olvera Consulintel ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Monday, February 17, 2003 6:04 PM Subject: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt > > > Hi All, > > This is a WG Last Call for comments on sending the 3GPP scenarios > document to the IESG for consideration as an Informational RFC: > > Title: Transition Scenarios for 3GPP Networks > Filename: draft-ietf-v6ops-3gpp-cases-02.txt > Editor: J. Soininen > Date: January 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt > > Abstract > > This document describes different scenarios in Third Generation > Partnership Project (3GPP) defined packet network, i.e. General > Packet Radio Service (GPRS) that would need IP version 6 and IP > version 4 transition. The focus of this document is on the scenarios > where the User Equipment (UE) connects to nodes in other networks, > e.g. in the Internet. GPRS network internal transition scenarios, > i.e. between different GPRS elements in the network, are out of scope > of this document. > > The purpose of the document is to list the scenarios for further > discussion and study. > > Since this is the first WG last call that we have had in the v6ops > WG, we would like to remind you of the process that we discussed for > WG last calls when we started this WG. > > The WG Last Call is a final check that the WG has rough consensus > to advance the document to the IESG. Advancing a document to the > IESG indicates that the WG believes that this document is both > technically sound and useful. It also indicates that we believe > that the document meets all of the requirements for publication > as an RFC. > > To pass WG last call, this document must be reviewed and actively > supported by a significant number of people, including experts in > all applicable areas, or it will not be sent to the IESG. > > Silence does NOT indicate consent during this phase. > > So, please review this document carefully, and send your feedback > to the list, indicating whether or not you believe that this > document is ready to go to the IESG. Unless sufficient support > is demonstrated on the list, the document will not be send to > the IESG. > > Thanks, > Margaret, Itojun and Bob > v6ops WG Chairs > ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Mar 12 08:38:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03135 for ; Wed, 12 Mar 2003 08:38:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t6Px-000FyM-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 05:37:13 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18t6Pu-000FyA-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 05:37:10 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 171983C60; Wed, 12 Mar 2003 08:37:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Mar 2003 08:37:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Wed, 12 Mar 2003 08:37:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCBA2@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLoEt+uaTxhhfDDRI2L6Ra3gkFdFgAiY5Vg From: "Bound, Jim" To: Cc: "Steven M. Bellovin" , "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 12 Mar 2003 13:37:08.0854 (UTC) FILETIME=[7A8F2960:01C2E89C] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03135 Yes this is better approach. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, March 11, 2003 4:11 PM > To: Bound, Jim > Cc: Steven M. Bellovin; Pekka Savola; Alain Durand; Sebastien > Roy; Mika Liljeberg; Ronald van der Pol; v6ops@ops.ietf.org; > jim.Paugh@Sun.COM; ipng@sunroof.eng.sun.com > Subject: Re: dual stack & IPv6 on by default > > > >Mozilla is going to fix this. Part of the problem was we > took so long > >getting rfc 2553 updated to new RFC (its in the RFC editor queue now) > >they used Richard Stevens old program model. This will be > updated to > >getaddrinfo and I agree with Itojun. Now as usual we await release > >updates :--) We also updated the API after this code base > that is must > >specify AI_MAPPED to get both v4 and v6. > > no need for that, you can use PF_UNSPEC in > hints.ai_family to get both > IPv4 address (as ai_family = AF_INET) and IPv6 address > (as ai_family > = AF_INET6) and socket(2) as appropriate. > > itojun > > From owner-v6ops@ops.ietf.org Wed Mar 12 16:18:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23356 for ; Wed, 12 Mar 2003 16:18:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tDar-00070G-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 13:16:57 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18tDam-0006zq-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 13:16:54 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2CLHVwY024288; Wed, 12 Mar 2003 23:17:32 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2CLHSES024284; Wed, 12 Mar 2003 23:17:28 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dual stack & IPv6 on by default From: Mika Liljeberg To: "Bound, Jim" Cc: Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB98@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB98@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047503848.18625.82.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Mar 2003 23:17:28 +0200 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, On Wed, 2003-03-12 at 05:24, Bound, Jim wrote: > > So what I'm trying to say is that the rule "If the Default > > Router List is empty, the sender assumes that the destination > > is on-link" doesn't seem to make sense in a multi-homed host. > > If the node has received no prefix or address knowledge it is a means to > still try to send the packet. But in that case as I said above it would > have to be a default link too or I guess a round robin decision. This, I think, is the first time during this discussion that you're directly addressing the question I am trying to raise. Default link or round robin? Or try all routerless links at once? That's my question, and RFC2461 gives no answers at all. Let's face it, "default interface" is a trivial solution. It might work in a specific case but not as a general answer. "Round robin" won't work properly either, since the result is non-deterministic. "Try all routerless links at once" might work but, hey, that's pretty ugly. There being no good answer, our current implementationd doesn't try at all. That, at least, is deterministic. To take things back in the direction of dual stack hosts and transition, how does the above fit with the destination address selection algorithm in RFC3484 and the first rule: Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB. Is the name resolver implementation supposed to do a route search only, or is it supposed to try to apply the "no routers -> assume all destinations are on-link" rule as well? Of course, RFC3484 doesn't give much guidance either: Discussion: An implementation may know that a particular destination is unreachable in several ways. For example, the destination may be reached through a network interface that is currently unplugged. For example, the implementation may retain for some period of time information from Neighbor Unreachability Detection [14]. In any case, the determination of unreachability for the purposes of this rule is implementation-dependent. An implementation can't really know that a destination address is unreachable, unless it does a route search and, failing to find one, proceeds to try to ND all routerless links as well. Is that what we should do? MikaL From owner-v6ops@ops.ietf.org Wed Mar 12 17:45:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26702 for ; Wed, 12 Mar 2003 17:45:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tEyk-000AV2-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 14:45:42 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18tEyg-000AUh-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 14:45:38 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21437; Wed, 12 Mar 2003 15:45:37 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2CMjTP20415; Wed, 12 Mar 2003 23:45:29 +0100 (MET) Date: Wed, 12 Mar 2003 23:13:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E6EB525.70304@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >Finally the spec allows for manual configuration to override the 1280 number > >in the static/fixed MTU case, but only if the receiver can handle reassembly > >of the larger IPv4 packets. Thus it requires manual coordination between > >the encapsulator and decapsulator to do this manual override. > > Are there any concerns for denial of service based on receive buffer overrun > at the decapsulator in this case? Not any worse than a factor MTU/1460 than in the normal case. I.e. if the decapsulator has been configured to use e.g. 9kbyte buffers for a particular tunnel it might use 9k/1460 times more memory for buffers for that tunnel. Erik From owner-v6ops@ops.ietf.org Wed Mar 12 18:48:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00392 for ; Wed, 12 Mar 2003 18:48:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tFxi-000DBM-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 15:48:42 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18tFxd-000DAh-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 15:48:37 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24408 for ; Wed, 12 Mar 2003 15:48:36 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2CNmWP13878 for ; Thu, 13 Mar 2003 00:48:33 +0100 (MET) Date: Thu, 13 Mar 2003 00:44:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-v6ops-mech-v2-00.txt To: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk For those of you that didn't notice the draft announcement this is the intended replacement for RFC 2893 with edits since draft-ietf-ngtrans-mech-v2-nn.txt. There are no open issues in the document that I am aware of. If folks have issues please bring them up on the list so we can try to resolve them before or at the v6ops meeting next week. The recent changes (copied from the document): - Clarified that the dynamic path MTU mechanism in section 3.2 is OPTIONAL but if it is implemented it should follow the rules in section 3.2. - Stated that when the dynamic PMTU is not implemented the sender MUST NOT by default send IPv6 packets larger than 1280 into the tunnel. - Stated that implementations MAY have a knob by which the MTU can be set to larger values on a tunnel by tunnel basis, but that the default MUST be 1280 and that decapsulators need to be configured to match the encapsulaltor's MTU. - Restated the "currently underway" language about ToS to loosely point at [RFC2983] and [RFC3168]. - Stated that IPv4 source MAY also be administratively specified. (This is especially useful on multi-interface nodes and with configured tunneling) - Fixed reference to Assigned Numbers to be to online version (with proper pointer to "Assigned Numbers is obsolete" RFC) - Clarified text about ingress filtering e.g. that it applies to packet delivered to transport protocols on the decapsulating node as well as packets being forwarded by the decapsulator, and how the decapsulator's checks help when IPv4 and IPv6 ingress filtering is in place. Erik From owner-v6ops@ops.ietf.org Wed Mar 12 23:55:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08142 for ; Wed, 12 Mar 2003 23:55:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tKlL-000Nfs-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 20:56:15 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18tKlI-000Nfe-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 20:56:12 -0800 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 UAA07866; Wed, 12 Mar 2003 20:56:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2D4uBm11712; Wed, 12 Mar 2003 20:56:11 -0800 X-mProtect: <200303130456> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.193.228, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAmoJHh; Wed, 12 Mar 2003 20:56:08 PST Message-ID: <3E700F64.1050103@iprg.nokia.com> Date: Wed, 12 Mar 2003 20:56:04 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>>Finally the spec allows for manual configuration to override the 1280 number >>>in the static/fixed MTU case, but only if the receiver can handle reassembly >>>of the larger IPv4 packets. Thus it requires manual coordination between > >>> >>> >>the encapsulator and decapsulator to do this manual override. > >>Are there any concerns for denial of service based on receive buffer overrun >>at the decapsulator in this case? >> >> > >Not any worse than a factor MTU/1460 than in the normal case. >I.e. if the decapsulator has been configured to use e.g. 9kbyte buffers for a >particular tunnel it might use 9k/1460 times more memory for buffers >for that tunnel. > I understand what you are saying about the buffer reqt's. But, when IPv4 fragmentation is occurring in the path between the encapsulator and decapsulator, there is no way for the encapsulator to learn this and decrease its MTU estimate. As currently worded, the specification could result in harmful levels of fragmentation in the network when encapsulators implement only the base specification. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Mar 13 00:05:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08468 for ; Thu, 13 Mar 2003 00:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tKw9-000O3u-00 for v6ops-data@psg.com; Wed, 12 Mar 2003 21:07:25 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18tKw7-000O3g-00 for v6ops@ops.ietf.org; Wed, 12 Mar 2003 21:07:23 -0800 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 VAA08140; Wed, 12 Mar 2003 21:07:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2D57LC18511; Wed, 12 Mar 2003 21:07:21 -0800 X-mProtect: <200303130507> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.193.228, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbXff5b; Wed, 12 Mar 2003 21:07:18 PST Message-ID: <3E701202.6070003@iprg.nokia.com> Date: Wed, 12 Mar 2003 21:07:14 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Some comments appear in the text below: Fred Templin ftemplin@iprg.nokia.com Erik Nordmark wrote: >For those of you that didn't notice the draft announcement this >is the intended replacement for RFC 2893 with edits since >draft-ietf-ngtrans-mech-v2-nn.txt. > >There are no open issues in the document that I am aware of. >If folks have issues please bring them up on the list so we can >try to resolve them before or at the v6ops meeting next week. > >The recent changes (copied from the document): > - Clarified that the dynamic path MTU mechanism in section 3.2 is > OPTIONAL but if it is implemented it should follow the rules in > section 3.2. > This method is susceptible to black holes (see RFC 2923). > > - Stated that when the dynamic PMTU is not implemented the sender > MUST NOT by default send IPv6 packets larger than 1280 into the > tunnel. > > - Stated that implementations MAY have a knob by which the MTU can > be set to larger values on a tunnel by tunnel basis, but that > the default MUST be 1280 and that decapsulators need to be > configured to match the encapsulaltor's MTU. > This method should only be used when care is taken to avoid harmful levels of fragmentation in the network (please see my previous note on this subject). This needs to be clarified in the draft. > > - Restated the "currently underway" language about ToS to loosely > point at [RFC2983] and [RFC3168]. > > - Stated that IPv4 source MAY also be administratively specified. > (This is especially useful on multi-interface nodes and with > configured tunneling) > > - Fixed reference to Assigned Numbers to be to online version > (with proper pointer to "Assigned Numbers is obsolete" RFC) > > - Clarified text about ingress filtering e.g. that it applies to > packet delivered to transport protocols on the decapsulating > node as well as packets being forwarded by the decapsulator, and > how the decapsulator's checks help when IPv4 and IPv6 ingress > filtering is in place. > > Erik > > > > > From owner-v6ops@ops.ietf.org Thu Mar 13 10:33:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05651 for ; Thu, 13 Mar 2003 10:33:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tUiK-000KE4-00 for v6ops-data@psg.com; Thu, 13 Mar 2003 07:33:48 -0800 Received: from alc136.alcatel.be ([195.207.101.136] helo=bt0g2p.god.bel.alcatel.be) by psg.com with esmtp (Exim 3.36 #1) id 18tUiH-000KDq-00 for v6ops@ops.ietf.org; Thu, 13 Mar 2003 07:33:45 -0800 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 h2DFXgx11835; Thu, 13 Mar 2003 16:33:42 +0100 From: Robert.Peschi@alcatel.be Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: Erik Nordmark Cc: v6ops@ops.ietf.org Date: Thu, 13 Mar 2003 16:33:37 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/13/2003 16:33:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, Erik Nordmark wrote: > There are no open issues in the document that I am aware > of. If folks have issues please bring them up on the > list so we can try to resolve them before or at the > v6ops meeting next week. I have some wording confusing there below: > - Clarified that the dynamic path MTU mechanism in > section 3.2 is OPTIONAL (...) Assume an implementation not implementing dynamic PMTU. > If it is not implemented instead the node MUST instead > limit the size of the IPv6 packets it tunnels to 1280 > bytes i.e., treat the tunnel interface as having a > fixed interface MTU of 1280 bytes. "MUST NOT" send packet >1280 -> "MTU>1280" is "Absolute prohibition" > An implementation MAY have a configuration knob which > can be used to set a larger value of the tunnel MTU > than 1280 bytes, "MAY" -> "MTU>1280" is freely allowed This seems to be quite in contradiction ? Thanks, Robert From owner-v6ops@ops.ietf.org Thu Mar 13 11:44:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08269 for ; Thu, 13 Mar 2003 11:44:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tVoy-000NWE-00 for v6ops-data@psg.com; Thu, 13 Mar 2003 08:44:44 -0800 Received: from p-mail1.rd.francetelecom.com ([193.49.124.31]) by psg.com with smtp (Exim 3.36 #1) id 18tVow-000NVR-00 for v6ops@ops.ietf.org; Thu, 13 Mar 2003 08:44:42 -0800 Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Thu, 13 Mar 2003 17:45:01 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 17:44:39 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Thu, 13 Mar 2003 17:44:39 +0100 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLWqtLnM+t50MRiScKHkxGVtbVEhASzGDpg From: "BAUDOT Alain FTRD/DMI/CAE" To: X-OriginalArrivalTime: 13 Mar 2003 16:44:39.0710 (UTC) FILETIME=[D7014BE0:01C2E97F] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08269 I reveiwed the document draft-ietf-v6ops-3gpp-cases-02.txt and I only have a few comments : First paragraphe of section 2 : "The scope of this document is to describe the possible transition scenarios in the 3GPP defined GPRS network where a UE connects to, or is contacted from, the Internet or another UE. The document describes scenarios with and without the usage of the SIP based IP Multimedia Core Network Subsystem (IMS). " Since the abstract specifies that "The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet.", it is no clear to me wether the other UE may be connected to the same network than the UE initiating the connection, or not. I've been rather surprised by the last paragraphe of section 2 : "These scenarios may or may not be found feasible, or even likely in further study." One may be confused since one may understand scenarios have nothing to do with reallity. It maybe rephrased stating that the scenarios match real cases and that a subset of them are likely to be met in a given architecture. Last, second paragraph section 4.1 : "Transition scenarios of the GPRS internal interfaces are outside of the scope of this document." I guess this is because the UE has limited ressources and that running internal transition mechanism is likely to be avoided. I wonder in that case if it should explicitly specified. I hope this helps a bit. Regards, Alain. From owner-v6ops@ops.ietf.org Thu Mar 13 13:45:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12395 for ; Thu, 13 Mar 2003 13:45:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXj9-0003qF-00 for v6ops-data@psg.com; Thu, 13 Mar 2003 10:46:51 -0800 Received: from sj-core-1.cisco.com ([171.71.177.237]) by psg.com with esmtp (Exim 3.36 #1) id 18tXj6-0003q2-00 for v6ops@ops.ietf.org; Thu, 13 Mar 2003 10:46:48 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DIki0G016263; Thu, 13 Mar 2003 10:46:46 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEY19090; Thu, 13 Mar 2003 10:41:25 -0800 (PST) Date: Thu, 13 Mar 2003 10:46:42 -0800 (PST) From: Suresh K Satapati To: BAUDOT Alain FTRD/DMI/CAE cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Mar 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > I've been rather surprised by the last paragraphe of section 2 : > > "These scenarios may or may not be found feasible, or even likely in > further study." > > One may be confused since one may understand scenarios have nothing to > do with reallity. It maybe rephrased stating that the scenarios match > real cases and that a subset of them are likely to be met in a given > architecture. I share the same concern.. -Suresh From owner-v6ops@ops.ietf.org Thu Mar 13 16:00:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18907 for ; Thu, 13 Mar 2003 16:00:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tZok-000DAe-00 for v6ops-data@psg.com; Thu, 13 Mar 2003 13:00:46 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18tZoh-000DAK-00 for v6ops@ops.ietf.org; Thu, 13 Mar 2003 13:00:43 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00755 for ; Thu, 13 Mar 2003 14:00:42 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBP00JT0H16TZ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 13 Mar 2003 14:00:42 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBP00ELJH152A@mail.sun.net> for v6ops@ops.ietf.org; Thu, 13 Mar 2003 14:00:42 -0700 (MST) Date: Thu, 13 Mar 2003 13:02:52 -0800 From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt To: v6ops@ops.ietf.org Message-id: <3E70F1FC.3000405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I have a comment on draft-ietf-v6ops-unman-scenarios-00.txt. Scenario case A: A) Gateway does not provide IPv6 By reading just this document, it sounds perfectly ok. However, after reading the companion document, draft-huitema-v6ops-unmaneval-00.txt, section 2.1.3: The tunnel approach is more expensive to provide, because the tunnel server will have to carry a much larger amount of traffic. It is unclear that a tunnel service can be provided as an almost free "supporting infrastructure", except perhaps if the service was directly provided by the same ISP that already provides IPv4 connectivity to the unmanaged network. I came to the conclusion that this scenario A is actually combining 2 sub-scenarios: A1- Gateway does not provide IPv6, ISP is cooperating to offer some level of v6 service A2- Gateway does not provide IPv6, ISP is not cooperating IMHO, the scenario document should reflect this. This leads me to a larger issue, why should we rush publishing those scenario documents as info RFC? The above is a clear example that the scenarios may need to be revisited at the light of the analysis. - Alain. From owner-v6ops@ops.ietf.org Fri Mar 14 10:08:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27633 for ; Fri, 14 Mar 2003 10:08:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tqlE-000NMT-00 for v6ops-data@psg.com; Fri, 14 Mar 2003 07:06:16 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18tqlB-000NME-00 for v6ops@ops.ietf.org; Fri, 14 Mar 2003 07:06:13 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EF9hF19395 for ; Fri, 14 Mar 2003 17:09:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 17:06:13 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 17:06:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Fri, 14 Mar 2003 17:06:10 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC381F@esebe005.ntc.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLpkWfLMp2yYUqRS9G8R/6ZvtaYtAAqSWzA From: To: , Cc: X-OriginalArrivalTime: 14 Mar 2003 15:06:11.0419 (UTC) FILETIME=[3FCD62B0:01C2EA3B] X-Spam-Status: No, hits=-0.3 required=5.0 tests=EMAIL_ATTRIBUTION,NO_REAL_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27633 Hi, Alain and Suresh! Thanks for your comments! We will do some rewording for that text. We have noticed that not all scenarios are relevant (those are mainly commented in the '3GPP analysis' document). Cheers, -Juha W.- -----Original Message----- From: ext Suresh K Satapati [mailto:satapati@cisco.com] Sent: 13 March, 2003 20:47 To: BAUDOT Alain FTRD/DMI/CAE Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt On Thu, 13 Mar 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > I've been rather surprised by the last paragraphe of section 2 : > > "These scenarios may or may not be found feasible, or even likely in > further study." > > One may be confused since one may understand scenarios have nothing to > do with reallity. It maybe rephrased stating that the scenarios match > real cases and that a subset of them are likely to be met in a given > architecture. I share the same concern.. -Suresh From owner-v6ops@ops.ietf.org Sat Mar 15 11:58:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20559 for ; Sat, 15 Mar 2003 11:58:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uExy-000GMK-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 08:57:02 -0800 Received: from [12.36.112.226] (helo=soln-sro177.solutionip.com) by psg.com with esmtp (Exim 3.36 #1) id 18uExw-000GM7-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 08:57:00 -0800 Received: from [12.44.189.51] (helo=starfruit.itojun.org) by soln-sro177.solutionip.com with esmtp (Exim 3.34 #1) id 18uExv-0002Vj-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 08:56:59 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id CB43F791; Sun, 16 Mar 2003 01:56:21 +0900 (JST) To: v6ops@ops.ietf.org Subject: draft-mickles-v6ops-isp-cases-05.txt 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 From: Jun-ichiro itojun Hagino Date: Sun, 16 Mar 2003 01:56:21 +0900 Message-Id: <20030315165621.CB43F791@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >3.3.1 IGP (snip) > Case 2: Existing ISIS IPv4 network > > If the ISP chooses to build IPv6 capabilities using OSPFv3, then > considerations of existing hardware and memory constraints must be > made since OSPFv3 places additional load on network gear. This > IGP will operate in separate memory space and will need to be configured > separately from any existing ISIS implementation. > > If the ISP chooses to build IPv6 capabilities using ISIS, then the > amount of hardware resources are not as taxing since IPv6 is > integrated within ISIS. The protocol does not need to be configured > separately. Even if you chose to run IS-IS for both IPv4 and IPv6, you still need to maintain IPv6 routing table with IS-IS, which will have memory constraints to routers. We could share some information (like router adjacency) among IPv4 IS-IS and IPv6 IS-IS, but how significant it is to share such information compared to run IPv4 IS-IS + OSPFv3? The above text seems to me very IS-IS centric view. Is there any quantitative measurement on this topic? >3.3.4 Multicast > > PIM-SM is the generally accepted solution for deploying multicast. > > For IPv6, this is a hard problem. Even for IPv4, deployment of PIM-SM is a hard problem. This section does not talk about multicast routing across different ASes - what will we use for this? editorial: why some of the section names in section 5 are all uppercase? From owner-v6ops@ops.ietf.org Sat Mar 15 12:05:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20651 for ; Sat, 15 Mar 2003 12:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uF5W-000Gjs-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 09:04:50 -0800 Received: from [12.36.112.226] (helo=soln-sro177.solutionip.com) by psg.com with esmtp (Exim 3.36 #1) id 18uF5T-000Gjb-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 09:04:47 -0800 Received: from [12.44.189.51] (helo=starfruit.itojun.org) by soln-sro177.solutionip.com with esmtp (Exim 3.34 #1) id 18uF5T-00035z-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 09:04:47 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AB323791; Sun, 16 Mar 2003 02:04:09 +0900 (JST) To: v6ops@ops.ietf.org Subject: draft-savola-v6ops-firewalling-01.txt 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 From: Jun-ichiro itojun Hagino Date: Sun, 16 Mar 2003 02:04:09 +0900 Message-Id: <20030315170409.AB323791@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >2.2. Possible Solutions > > The correct behaviour must be made clear; the wording should be > clarified. Clarifications might be needed at least on: > > 1. whether intermediate nodes should be taken into account in the > text describing the header processing > > 2. intermediate nodes' behaviour when detecting unrecognized > headers do we have such document/consideration (packet processing at intermediate nodes, like firewalls) in base IPv4 specification? as far as I know, no. therefore, i guess we should try to "clarify" it outside of base IPv6 spec, if we are to do it. it is not IPv6 base spec's fault that it does not cover behavior of firewalls. itojun From owner-v6ops@ops.ietf.org Sat Mar 15 12:14:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20819 for ; Sat, 15 Mar 2003 12:14:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uFEW-000H86-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 09:14:08 -0800 Received: from [12.36.112.226] (helo=soln-sro177.solutionip.com) by psg.com with esmtp (Exim 3.36 #1) id 18uFES-000H7s-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 09:14:04 -0800 Received: from [12.44.189.51] (helo=starfruit.itojun.org) by soln-sro177.solutionip.com with esmtp (Exim 3.34 #1) id 18uFES-0003qs-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 09:14:04 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 95FCD791; Sun, 16 Mar 2003 02:13:26 +0900 (JST) To: v6ops@ops.ietf.org Subject: draft-huitema-v6ops-unmaneval-00.txt 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 From: Jun-ichiro itojun Hagino Date: Sun, 16 Mar 2003 02:13:26 +0900 Message-Id: <20030315171326.95FCD791@starfruit.itojun.org> X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >2.1 Evaluation of connectivity mechanisms > > In case A, IPv6 capable hosts seek IPv6 connectivity in order to > participate with applications in the global IPv6 Internet. The > connectivity requirement can be met in two ways: Teredo [TEREDO], or > UDP tunnels. there are many other ways to solve case A, including: - IPv6 PPP over TCP (can penetrate any NAT as it is TCP) - RFC2893 tunnelling with certain NAT/decapsulator configuration if you wish to limit solutions to teredo and UDP tunnels, you would need to describe why. >6 Provisional recommendations > - To meet case A requirements, we need to develop and standardize > the Teredo or similar technology. therefore, it is too early to conclude like this. itojun From owner-v6ops@ops.ietf.org Sat Mar 15 14:42:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23159 for ; Sat, 15 Mar 2003 14:42:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uHXl-000PFD-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 11:42:09 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 18uHXj-000PF1-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 11:42:07 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sat, 15 Mar 2003 11:42:10 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 15 Mar 2003 11:42:06 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sat, 15 Mar 2003 11:42:10 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 15 Mar 2003 11:42:05 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sat, 15 Mar 2003 11:42:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-huitema-v6ops-unmaneval-00.txt Date: Sat, 15 Mar 2003 11:42:03 -0800 Message-ID: Thread-Topic: draft-huitema-v6ops-unmaneval-00.txt Thread-Index: AcLrGYEZHYozzxITTZGhKJ5NxAYakwAEF2w3 From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 15 Mar 2003 19:42:05.0180 (UTC) FILETIME=[F5069BC0:01C2EB2A] X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA23159 Itojun, When it comes to traversing NAT, the issue is how to "come in", not how to "go out". AFAIK, teredo is the only solution that allows "self deploy" because it let UDP packets "come in". All the other solutions are variations on fixed tunnels, and thus require some form of contract between a user and a tunnel endpoint. You can clearly do PPP over TCP, but you can only do that if you initiate the connection from inside the NAT towards a fixed tunnel end-point; in that case, I believe that a UDP base tunnel will provide a lesser overhead, and will avoid the "head of line blocking" issues found in TCP. RFC 2893 tunneling only works with some NAT, and as such cannot be a generic solution. -- Christian Huitema ________________________________ From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] Sent: Sat 3/15/2003 9:13 AM To: v6ops@ops.ietf.org Subject: draft-huitema-v6ops-unmaneval-00.txt >2.1 Evaluation of connectivity mechanisms > > In case A, IPv6 capable hosts seek IPv6 connectivity in order to > participate with applications in the global IPv6 Internet. The > connectivity requirement can be met in two ways: Teredo [TEREDO], or > UDP tunnels. there are many other ways to solve case A, including: - IPv6 PPP over TCP (can penetrate any NAT as it is TCP) - RFC2893 tunnelling with certain NAT/decapsulator configuration if you wish to limit solutions to teredo and UDP tunnels, you would need to describe why. >6 Provisional recommendations > - To meet case A requirements, we need to develop and standardize > the Teredo or similar technology. therefore, it is too early to conclude like this. itojun From owner-v6ops@ops.ietf.org Sat Mar 15 23:25:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05140 for ; Sat, 15 Mar 2003 23:25:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uPiQ-000Fo6-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 20:25:42 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18uPiN-000Fnp-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 20:25:39 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA26097 for ; Sun, 16 Mar 2003 04:25:35 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA22406 for ; Sun, 16 Mar 2003 04:25:35 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2G4PZC13248 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 04:25:35 GMT Date: Sun, 16 Mar 2003 04:25:35 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-mickles-v6ops-isp-cases-05.txt Message-ID: <20030316042535.GA4715@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20030315165621.CB43F791@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030315165621.CB43F791@starfruit.itojun.org> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Mar 16, 2003 at 01:56:21AM +0900, Jun-ichiro itojun Hagino wrote: > > Even if you chose to run IS-IS for both IPv4 and IPv6, you still need > to maintain IPv6 routing table with IS-IS, which will have memory > constraints to routers. We could share some information (like router > adjacency) among IPv4 IS-IS and IPv6 IS-IS, but how significant it is > to share such information compared to run IPv4 IS-IS + OSPFv3? The > above text seems to me very IS-IS centric view. Is there any > quantitative measurement on this topic? There is a discussion of such issues in the 6NET report of NRENs who have migrated dual stack. See http://www.6net.org/publications/deliverables/D2.2.2.pdf Regarding PIM-SM, there is a lot of operational experience in m6bone and m6net, but this isn't really written up yet. Tim From owner-v6ops@ops.ietf.org Sat Mar 15 23:46:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05526 for ; Sat, 15 Mar 2003 23:46:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQ4L-000Hxg-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 20:48:21 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18uQ4J-000HxT-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 20:48:19 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F1F6A3B77; Sat, 15 Mar 2003 23:48:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 23:48:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-huitema-v6ops-unmaneval-00.txt Date: Sat, 15 Mar 2003 23:48:18 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB0@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-huitema-v6ops-unmaneval-00.txt Thread-Index: AcLrFrxYf4oyNEJoSpORGOPIfKB0JQAYHCvA From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 16 Mar 2003 04:48:18.0854 (UTC) FILETIME=[43A86460:01C2EB77] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05526 >>6 Provisional recommendations >> - To meet case A requirements, we need to develop and >standardize >> the Teredo or similar technology. > > therefore, it is too early to conclude like this. I agree. I also think Tunnel Broker is very useful additional tool for umanaged networks. /jim > > From owner-v6ops@ops.ietf.org Sat Mar 15 23:51:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05586 for ; Sat, 15 Mar 2003 23:51:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQ9W-000IWG-00 for v6ops-data@psg.com; Sat, 15 Mar 2003 20:53:42 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18uQ9U-000IW4-00 for v6ops@ops.ietf.org; Sat, 15 Mar 2003 20:53:40 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A278F3395; Sat, 15 Mar 2003 23:53:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 23:53:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Sat, 15 Mar 2003 23:53:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLo3Li7EU7rhk4XTj6kquM0vOlQNQCmtbfg From: "Bound, Jim" To: "Mika Liljeberg" Cc: "Sebastien Roy" , "Ronald van der Pol" , "Alain Durand" , , X-OriginalArrivalTime: 16 Mar 2003 04:53:39.0544 (UTC) FILETIME=[02CDCD80:01C2EB78] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05586 Hi Mika, >An implementation can't really know that a destination address >is unreachable, unless it does a route search and, failing to >find one, proceeds to try to ND all routerless links as well. >Is that what we should do? I think today this is the bottom line only answer. But your mail thread makes me wonder if we need to do more and I think so. But it would have to be in the context of ND. ND is a requirement to use IPv6. Feels like an edge that could be "do this if ND don't work"? Thanks /jim From owner-v6ops@ops.ietf.org Sun Mar 16 05:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21234 for ; Sun, 16 Mar 2003 05:07:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uV33-000NSC-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 02:07:21 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18uV2w-000NS0-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 02:07:14 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2GA80wY019417; Sun, 16 Mar 2003 12:08:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2GA7vXe019413; Sun, 16 Mar 2003 12:07:57 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dual stack & IPv6 on by default From: Mika Liljeberg To: "Bound, Jim" Cc: Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047809277.13138.88.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Mar 2003 12:07:57 +0200 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, [The following quote concerns RFC3484 and destination address selection] > >An implementation can't really know that a destination address > >is unreachable, unless it does a route search and, failing to > >find one, proceeds to try to ND all routerless links as well. > >Is that what we should do? > > I think today this is the bottom line only answer. That's too bad, because it means that the DNS resolver would have do this for the whole candidate destination address list. That takes time. I would much prefer do a route search only. > But your mail thread makes me wonder if we need to do more and I think > so. RFC1122 clarified and corrected several small details in the IPv4 specifications. I think the node requirements spec could do the same for any fuzzy bits in the IPv6 specificatons. > But it would have to be in the context of ND. ND is a requirement to > use IPv6. I agree. This is just a detail that needs to be clarified somehow. > Feels like an edge that could be "do this if ND don't work"? No. It's a very specific case of "how to implement the following bit of next-hop determination" in a host with multiple network interfaces and how it relates to RFC3484 and destination address selection: If the Default Router List is empty, the sender assumes that the destination is on-link. Until there is a clear understanding, we are sticking with: If the route search fails, the sender assumes the destination is unreachable. I haven't seen comments from any other implementors. It would be very interesting to hear if you have solved this and how you implemented it. Thanks, MikaL From owner-v6ops@ops.ietf.org Sun Mar 16 05:15:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21506 for ; Sun, 16 Mar 2003 05:15:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uVCn-000OPf-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 02:17:25 -0800 Received: from h024.c001.snv.cp.net ([209.228.32.139] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 18uVCd-000OPF-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 02:17:15 -0800 Received: (cpmta 28622 invoked from network); 16 Mar 2003 02:17:13 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 16 Mar 2003 02:17:13 -0800 X-Sent: 16 Mar 2003 10:17:13 GMT Message-ID: <00c601c2eba5$685be7e0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: , , Subject: Question about IPv6 Management Date: Sun, 16 Mar 2003 12:18:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C2EBB6.293B1BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.6 required=5.0 tests=BIG_FONT,SPAM_PHRASE_03_05,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C2EBB6.293B1BB0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I appologize, this is being possted to multiple WG's as it seems to = cross areas. Is there any information about the requirment changes in the Network = Management Systems (NMS) or Operations Support Systems (OSS) necesary to = support IPv6? I have looked at the various MIB RFC's and such, but can not find = anything more than you need bigger address support and some SNMPv2 = compliance. This seems too simple to me. Eric ------=_NextPart_000_00C3_01C2EBB6.293B1BB0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
I appologize, this is being possted to = multiple=20 WG's as it seems to cross areas.
 
Is there any information about the = requirment=20 changes in the Network Management Systems (NMS) or Operations=20 Support Systems (OSS) necesary to support IPv6?
 
I have looked at the various MIB RFC's and = such, but=20 can not find anything more than you need bigger address support and some = SNMPv2=20 compliance.
 
This seems too simple to me.
 
 Eric
------=_NextPart_000_00C3_01C2EBB6.293B1BB0-- From owner-v6ops@ops.ietf.org Sun Mar 16 06:45:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22953 for ; Sun, 16 Mar 2003 06:44:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWZh-0007bk-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 03:45:09 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uWZe-0007bY-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 03:45:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GBisB22142; Sun, 16 Mar 2003 13:44:56 +0200 Date: Sun, 16 Mar 2003 13:44:54 +0200 (EET) From: Pekka Savola To: yasuhiro@nttv6.jp cc: v6ops@ops.ietf.org Subject: comments on shirasaki-dualstack-service-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,SUBJ_HAS_UNIQ_ID, USER_AGENT_PINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (It's amazing how many drafts you can read on a 12h flight.. :-) Thanks for documenting the NTT DSL access service. I think this is very useful. A few comments, mostly editorial in nature, below. non-editorial: -------------- 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. ==> I'd remove this section completely and switch to lower case must, should, etc. because this isn't exactly a document with interop interest :-) When CPE receives packets which are destined for the delegated prefix, CPE MUST NOT forward the packets to a PE. CPE SHOULD return ICMPv6 Destination Unreachable message to a source address or silently discard the packets. ==> would it be worthwhile to describe how this is accomplished? Null0 route is at least trivial, but it won't return an unreachable message except by explicit config in some implementations. But maybe this is outside of scope.. editorial: ---------- INTERNET-DRAFT Yasuhiro Shirasaki Expires: August, 2003 Shin Miyakawa Toshiyuki Yamasaki Ayako Takenouchi ==> initial of the first name only service should have mechanism to configure IPv6 specific parameters ==> s/service/services/ Here are some antecedents of the architecture. The architecture mainly targets at a leased line ADSL service for home users. It ==> s/mainly targets/is mainly targeted/ assumes that there is a PPP logical link between CPE and Provider ==> spell out PPP follows. o IPv6 and IPv4 connectivity are provided over a single PPP logical link. ==> bullets are one character left of the normal intendation, shit a few chars right? o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and IPCP works independently over a single PPP logical link. ==> s/works/work/ The automatic configuration function aims at simplication of user ==> s/cation/fication/ setup. Usually, users have to configure at least two IPv6 specific parameters, prefix(es) and IPv6 DNS servers addresses. The function ==> s/servers/servers'/ (if this was the intent) In this section, details of the user network interface specification are described. Only PPPoE and its upper layer are mentioned. The ==> spell out PPPoE other layers such as ethernet and lowers are out of scope. IPv4 ==> s/eth/Eth/ The service uses PPP connection and CHAP authentication to identify ==> spell out CHAP. without any side-effect for each other. It is intended that users can choose three services, IPv4 only, IPv6 only and IPv4/IPv6 dual stack. ==> s/choose/choose between/ ? CPE MUST reply with LCP Echo-Reply when it is in the LCP Opened state and receives LCP Echo-Request as described in [RFC1661] ==> s/]/]./ 3.3. Prefix Delegation PE delegates prefixes to CPE by DHCPv6 [DHCPv6] with prefix delegation options [PD]. The model of sequence for prefix delegation is as follows: ==> perhaps could use like "a DHCPv6 Solicit", "an IA_PD options" etc. more in this section (rather than without a/an/the) o A CPE requests prefixes to a PE by sending DHCPv6 Solicit message ==> s/to/from/ o The PE chooses prefix(es) which is notified by AAA server or choosen from PE's local pool and returns Advertise message which contains IA_PD and IA_PD Prefix option. The prefix-length in the IA_PD Prefix option is 48. ==> reword" which is notified by AAA server" ==> s/choosen/chosen/ ==> s/contains ... option/contain ... options/ Once IPV6CP is terminated or restarted by any reason, CPE MUST initiate a Rebind/Reply message exchange as described in [PD]. ==> s/Once/If/ ? 3.4. Address Assignment The CPE assigns global-scope prefixes subnetted from the delegated prefix to its downstream interfaces with its length /64. Because ==> s|prefixes .. with its length /64|/64 prefixes .../ 3.6. Obtaining Addresses of DNS Servers The service provides IPv6 DNS cache servers in the ISP site as same as IPv4 case. PE notifies the global unicast addresses of these ==> reword "as same as IPv4 case" 3.7. Miscellaneous Information PE may notify other IPv6 enabled server addresses such as Network Time Protocol servers [OPT-NTP], SIP servers [OPT-SIP], etc in Advertise/Reply message on the prefix delegation message exchange if it is available. ==> s/it is/those are/ packet when it receives ICMPv6 Echo Request packet. The health check packets are destined for subnet-rouer anycast address for the delegated prefix. ==> s/for/to/, s/rouer/router [RFC2472] D. Haskin and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. ==> author's surname should be listed first, same in some other refs. Author's Address ==> s/Author's Address/Authors' Addresses/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 06:47:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22977 for ; Sun, 16 Mar 2003 06:47:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWeK-00086H-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 03:49:56 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uWeF-000865-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 03:49:51 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GBnnm22162 for ; Sun, 16 Mar 2003 13:49:49 +0200 Date: Sun, 16 Mar 2003 13:49:48 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6only operation comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A few comments on roy-v6ops-v6onbydefault-00. In general, I think it's very useful to explore the issues, but it seems to me that there are some underlying assumptions which may have led to some questionable conclusions. Some comments have probably already been mentioned before, but here goes anyway... For an IPv6 enabled host deployed on a network that has no IPv6 routers, the result is that link-layer address resolution must be performed on all IPv6 destinations to which the host sends packets. ==> prior to that, default address selection is performed; if the source is link-local and destination is global, the packet is never sent off the node. This should prevent issues when the node has only link-local addresses. The Default Address Selection for IPv6 [2] destination address selection mechanism, if used by applications, would minimize the problem by placing IPv6 addresses at the end of the list of addresses returned by name lookups. The host has only generated a link-local address, so the scope of IPv6 destinations won't match any possible IPv6 source. ==> source address selection works too :-) An example of such a network is an enterprise network that has both IPv4 and IPv6 routing within the enterprise and has a firewall configured to allow some IPv4 communication, but no IPv6 communication. ==> wrong deployment, sorry :-( ==> in this case, the router(s) should either be configured with a null default route variant which would send unreachable is no network is found, or alternatively, have no default routes at all (avoids the problem) To allow applications to correctly fall back to IPv4 when IPv6 packets are destined beyond their allowed scope, the devices enforcing the scope boundary should send ICMP Destination Unreachable messages back to senders of such packets. ==> would transport protocols heed these soft errors? better than discard, surely, of course! This has the negative side-effect that these nodes will almost never use IPv6 unless the only address published in the DNS for a given name is IPv6., presumably because of this phenomenon. ==> s/.,/,/ ==> this is something to consider in a bigger scale, in deployments. People would populate IPv6-only zones if this approach would be a common practise. collocated with a firewall, but more difficult if internal nodes do their own IPv6 tunneling. ==> s/col/co-/ returned from a name lookup when attempting connections works in most cases for most applications, but there are still cases where that's not enough. Applications also need to be aware that the fact that a dual stack destination's IPv6 address is published in the DNS does not imply that all services on that destination function over IPv6. ==> s/imply/necessarily imply/! ==> I consider models where someone publishes www.foo.com with A+AAAA but doesn't support HTTP over v6 a User Error. Of course, one _should_ be able to recover from that, but some service degradation is acceptable. Applications should not assume that because a service is reachable at an IPv6 address, that other services at that destination are also reachable via that IPv6 address. ==> getaddrinfo loop ends at the wrong place, it should try connect first, I guess? 7. References ==> split refs [1] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] R. Draves, "Default Address Selection for IPv6", draft-ietf-ipv6-default-addr-select-09.txt, August 2002. ==> wrong format for refs, authors surname first -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 07:00:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23236 for ; Sun, 16 Mar 2003 07:00:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWqX-0009Ru-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 04:02:33 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uWqU-0009QL-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 04:02:30 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GC2SF22290 for ; Sun, 16 Mar 2003 14:02:28 +0200 Date: Sun, 16 Mar 2003 14:02:28 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: durand-v6ops-dualstack-vs-natpt-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I think it's useful to try to describe some scenarios from the dual-stack vs nat-pt perspective. I didn't bother to check editorial issues, here are a few comments that struck me while reading the draft. A first usage case is for new networks that would like to deploy IPv6 only. Today, we may not have all the pieces to do so, but it is reasonable to think that in the not so distant future, it would be possible. One immediate goal is be to make sure that things works at least as well as if that network had deployed private IPv4 address space instead, so this network wants to enable connections initiated from the inside to the "legacy" Internet. IPv4 connections initiated by the outside won't work, but it would also be the case if the network had used private IPv4 addresses. However, IPv6 connections initiated by either the inside or the outside would work, and this is considered a plus significant enough to justify deploying IPv6. ... Note that, except from the DNS-ALG part which is currently defined in RFC2766, IPv4 to IPv4 NAT and IPv6 to IPv4 NAT share essentially the same properties, so doing private v4 to global v4 translation does not have any significant advantage over doing global v6 to global v4 translation. ==> if v6 deployments are desirable, with really high usage rate of v6, it would appear to be most desirable to deploy private IP addresses with one or a few public v4 addresses they map to at the border: the v4 traffic should be minimum anyway! In other cases, e.g. TCP relay could be performed for specific legacy apps. 2. Case 2: heterogeneous multi-party application NAT communications initiated from the v4 side is a much more difficult problem to solve than NAT communications initiated from the v6 side as in the precedent case. The issue is to allocate a temporary v4 address for the v6 peer and return it via the DNS to the v4 peer. If this allocation is performed in the DNS server of the v6 peer, it opens the door to denial of service attacks, so it is a non starter. The alternative is to do the allocation in the recursive DNS server used by the v4 peer. It basically requires cooperation from the v4 peer's ISP to introduce a DNS-ALG. If DNSsec is deployed, it also requires the v4 node to delegate all signature verification to the recursive DNS server. ... The 'use the dual stack' approach requires: - All peers must use the same IP version. If unmodified IPv4 nodes are to be present in the call, it means that everybody must speak IPv4. An "interesting" case is what happen if all hosts in the call are IPv6 and a new IPv4-only host wants to join. - All peers must have global addresses. The "translate IPv4 to IPv6" option requires: - availability of v6 to v4 translation service, with cooperation of the IPv6 network - availability of v4 to v6 translation service, with cooperation of the IPv4 network infrastructure (DNS-ALG). - change of the trust model of DNS-sec where the v4 nodes will have to delegate the signature verifications to the recursive DNS server. ==> when deploying multi-party apps, translation is not useful, due to reasons given. The only real possibilities are v4 or v6-only, as you point out/imply. 3. Case 3: end game scenario A third case is an end game scenario, where some legacy IPv4 only hosts or applications can not be upgraded to support IPv6 and the rest of the infrastructure is mainly IPv6. As shown in the previous case study, using NAT requires a DNS-ALG running with the help of the local IPv4 network. The idea behind it is that, if the host (or the application) cannot be modified, maybe the surrounding network infrastructure can be modified at a minimal cost to perform the DNS-ALG functionality. The 'use the dual stack' approach requires: - a global IPv4 address on all v6 servers that want to be reached by the un-upgradable hosts. The "translate IPv4 to IPv6" option requires: - cooperation from the local IPv4 infrastructure to support the DNS-ALG/NAT part - change of the trust model of DNS-sec where the v4 nodes will have to delegate the signature verifications to the recursive DNS server. ==> TCP relay seems to be a better alternative in this case (== no problem with DNS ALG), to enable access to few apps and nodes to understand if translation with tools like [NAT-PT] is absolutly ==> no refs in the abstract -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 07:10:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23345 for ; Sun, 16 Mar 2003 07:10:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWzQ-000AWd-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 04:11:44 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uWzN-000AWP-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 04:11:42 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GCBd922386 for ; Sun, 16 Mar 2003 14:11:39 +0200 Date: Sun, 16 Mar 2003 14:11:39 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: durand-v6ops-natpt-dns-alg-issues-00 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A few comments. There seems to be some bashing of DNSALG, but there is a draft on how to fix those issues too -- and AFAIR, it fixes adequately most of the issues. Instead bashing DNS-ALG and advocating NAT-PT++ perhaps a more comprehensive look at the subject would be useful. One robustness comment below, the rest are editorials. 5.2 Robustness of NAT-PT with DNS-ALG The DNS-ALG needs to actively monitor the NAT-PT boxes, to detect the potential failure of one of them and remove it from the list of valid translators. In practice, this means that the prefix associated to that translator will not be used anymore by the DNS-ALG to respond to DNS queries. For this to work, the DNS-ALG must set the TTL of the DNS answer to zero and user applications are expected to respect that TTL, i.e. not cache the name to address mapping, even for a short ... ==> same routing the prefix-approach applies with DNS-ALG too. editorials ---------- Status of this memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. ==> boilerplate is missing newlines etc. 1. Introduction: non DNS ALG solution Note: This section does not provide a complete description of a non DNS ALG solution for NAT-PT, but provide a quick overview of such a ==> s/provide/provides/ solution to understand better the discussions of the next sections. ==> s/understand better/better understand/ The way this is envision to work is that an IPv6 application running ==> s/envision/envisioned/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 08:03:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24423 for ; Sun, 16 Mar 2003 08:03:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uXoa-000GvI-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 05:04:36 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uXoW-000Gr4-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 05:04:32 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GD4O422666; Sun, 16 Mar 2003 15:04:25 +0200 Date: Sun, 16 Mar 2003 15:04:23 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: draft-savola-v6ops-firewalling-01.txt In-Reply-To: <20030315170409.AB323791@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for comments. On Sun, 16 Mar 2003, Jun-ichiro itojun Hagino wrote: > >2.2. Possible Solutions > > > > The correct behaviour must be made clear; the wording should be > > clarified. Clarifications might be needed at least on: > > > > 1. whether intermediate nodes should be taken into account in the > > text describing the header processing > > > > 2. intermediate nodes' behaviour when detecting unrecognized > > headers > > do we have such document/consideration (packet processing at > intermediate nodes, like firewalls) in base IPv4 specification? > as far as I know, no. Well, depends on what you want. For example, in RFC791 there is no text that *forbids* it and in IP options there is: ===== The copied flag indicates that this option is copied into all fragments on fragmentation. 0 = not copied 1 = copied ===== .. which would heavily imply that a router (=intermediate node) is supposed to in fact process the packet, modify it, etc. The situation in IPv6 is slightly different wrt. intermediate nodes as RFC1812 states: 4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 A router MUST ignore IP options which it does not recognize. A corollary of this requirement is that a router MUST implement the End of Option List option and the No Operation option, since neither contains an explicit length. but host reqs RFC1122 says: The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others. .. so the behaviour seems to be unspecified as there are no fields like these which would trigger a response from hosts but not routers. > therefore, i guess we should try to "clarify" > it outside of base IPv6 spec, if we are to do it. it is not IPv6 > base spec's fault that it does not cover behavior of firewalls. This case is probably applicable to most middleboxes etc. too, but I tend to agree that changing RFC2460 in the spec is not an option. A clearer case of true ambiguity is the use of option starting wiht "11" (ie. send back ICMP) with _hop-by-hop_ option, which are to be processed by every node on the path. At least for this particular option, the intent is that routers/etc. will send ICMP's out if something unrecognized is noticed, but that's not crystal clear.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 08:05:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24453 for ; Sun, 16 Mar 2003 08:05:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uXrj-000HGh-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 05:07:51 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uXrg-000HGU-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 05:07:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GD7fi22676; Sun, 16 Mar 2003 15:07:41 +0200 Date: Sun, 16 Mar 2003 15:07:41 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Jun-ichiro itojun Hagino , Subject: RE: draft-huitema-v6ops-unmaneval-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 15 Mar 2003, Christian Huitema wrote: > When it comes to traversing NAT, the issue is how to "come in", not how > to "go out". AFAIK, teredo is the only solution that allows "self > deploy" because it let UDP packets "come in". All the other solutions > are variations on fixed tunnels, and thus require some form of contract > between a user and a tunnel endpoint. By "coming in" you probably refer to "coming in without an explicit tunnel". Not being to just "come in" could be considered a feature, too. Especially if "coming in" doesn't work on any properly implemented (=secure) NAT boxes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 10:04:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26025 for ; Sun, 16 Mar 2003 10:04:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uZg7-0004Fb-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 07:03:59 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uZfu-0004FB-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 07:03:47 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GF3fM23412 for ; Sun, 16 Mar 2003 17:03:41 +0200 Date: Sun, 16 Mar 2003 17:03:40 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: huitema-v6ops-unmaneval-00 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Here's my 2 cents worth of comments for the unmanaged evaluation. non-editorial: -------------- 2 Meeting case A requirements In case A, IPv6 capable hosts located behind a NAT need to acquire IPv6 connectivity. In this section, we first evaluate how mechanisms already defined or being worked on in the IETF meet this requirement. We then consider the "remaining holes" and recommend specific developments. ==> In case A, it may be that you don't have NAT at all. In fact, I believe this is quite typical for e.g. dialup/ISDN, even some cable/DSL users. ==> I've been trying to push this in the scenarios doc but with little success as of yet.. To gauge the difference, we consider the case of a host engaging in Voice over IP: it will maintain its address reachable all the time, and it will send a large amount of traffic whenever it is engaged in a conversation. According to classic figures collected by AT&T, the average duration of a conversation is around 100 seconds, and a business telephone is likely to be engaged in a conversation about 10% of the time, which implies starting a conversation on average every 1000 seconds. The average load sent by a tunnel client to the tunnel server will be 10% of the average data rate of the client; assuming a 16kbps codec and 50 packets per second, the data rate of the client sums up to about 51 kbps, hence an average load on the tunnel server of 5 kbps. The load sent by the tunnel client to the tunnel server will be about one exchange of bubble per minute, to defend the address, plus one bubble exchange at the beginning of each session with a new peer; adding all headers, the bubble size is about 144 bytes, which results in about 20 bps of traffic on the server. In short, the amount of traffic seen by the Teredo server is 250 times less that the traffic seen by a Teredo client. ==> a reality check here would be useful: do you really expect business telephones to emerge *at large* behind unmanaged NAT's, and engage in conversation with other Teredo clients (and not the other IPv6 infrastructure) -- in the latter case, they'll have to pass through the relay anyway, generating the same amount of traffic. The tunnel approach is more expensive to provide, because the tunnel server will have to carry a much larger amount of traffic. It is unclear that a tunnel service can be provided as an almost free "supporting infrastructure", except perhaps if the service was directly provided by the same ISP that already provides IPv4 connectivity to the unmanaged network. ==> how about the traffic at the teredo relay boxes? :-) The two approaches have much in common: both need to parameterize a client with the name of a server and with sufficient credentials; the encapsulation is similar; both use the same encapsulation mechanism; and both will use router solicitations to obtain an address prefix. The main difference is the handling of bubbles in Teredo, which are used to defend the address and to initiate sessions with peers. This is obviously more complex than sending the packet without any processing, but the complexity is only marginally higher than the discovery of link layer addresses using neighbor discovery. In short, Teredo is more complex, but the complexity is not overwhelming. ==> instead of one peer and a standard set of solutions we have N peers and relay architecture Manual configuration of stable addresses is not satisfactory in an unmanaged IPv6 network: the prefix allocated to the gateway may or may not be stable, and in any case copying long binary addresses through a manual procedure is error prone. ==> these justifications are about equally applicable to IPv4 as IPv6 in case _B_ (in case A, it might be a different story if NAT mappings are more change-prone) -- binary addresses is not a big problem, if it comes down to that, it'd be just a matter of cut'n'paste. ==> I'd say "manual configuration ... should be avoided if possible". 3.3.3 Resolving local IPv6 addresses There are two possible ways of resolving local IPv6 addresses: one may either publish the IPv6 addresses in a local server, or one may use a peer-to-peer address resolution protocol such as link local multicast name resolution [LLMNR]. ==> please tell me again why these local addresses (I'm assuming this is an edito from earlier versions) cannot be published in the global DNS? Assuming that they aren't site-locals, that is. ==> Of course if you want them to work properly even when the net connectivity is down, it's understandable to have some mechanism -- but you should really say that too (and consider whether some other elements might also stop working in the sporadically connected case). The case B solutions provide global IPv6 connectivity to the local hosts. Removing the limit to connectivity imposed by NAT is both a feature and a risk. Implementations should carefully limit global IPv6 connectivity to only those applications that are specifically designed to operate on the global Internet. ==> should one provide more analysis or recommendations on issues like this (think of bellovin's access-prefix or brian zill's similar work, for instance) editorial: ---------- NLnet Labs ==> Initial only, Ronald :-) In a companion paper we defined the "unmanaged networks" scope, which typically correspond to home networks or small office ==> s/correspond/corresponds/ (the same in introduction) networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group. ==> move the table of contents here ==> typically the ISOC copyright statement is also here dual stack. This issue is discussed in detail in a companion paper ==> s/paper/memo/ The issues involved are described in the next sections. This analysis outlines two types of requirement: connectivity ==> s/requirement/requirements/ 2.1.1 TEREDO TEREDO is a mechanism designed to provide IPv6 connectivity to hosts ==> s/TEREDO/Teredo/ 2.2 Security considerations in case A ==> upper case first chars in (most) words 3.2 Communication between IPv4-only and IPv6-only hosts ==> s/hosts/nodes/g (many places in this and following sections) 6to4 routers and relay them to the "regular" IPv6 Internet. These relays all listen to the same IPv4 anycast address [RFC3056], which ==> that address is in 3068 :-) 11 References [UNMANREQ] Unmanaged Networks Transition Scope. Work in progress. [NATPTBISSUES] Issues when translating between IPv4 and IPv6. Work in progress. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. ==> refs need to be split ==> reference format is not right, Surname, initial. first -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 16 13:10:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01124 for ; Sun, 16 Mar 2003 13:10:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ucaU-000MpX-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 10:10:22 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18ucaR-000MpJ-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 10:10:19 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22268; Sun, 16 Mar 2003 10:10:18 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIAFP05638; Sun, 16 Mar 2003 19:10:15 +0100 (MET) Date: Sun, 16 Mar 2003 19:06:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > As currently worded, the specification could result in harmful levels of > fragmentation in > the network when encapsulators implement only the base specification. My understanding from the previous discussion on the draft the WG did not want to mandate the dynamic MTU discovery from encapsulator to decapsulator. Hence it is optional in the new draft. But limiting the size of the packets sent into the tunnel to 1280+20 doesn't cause any more fragmentation than the dynamic scheme. Essentially the mandatory part of the specification means that the tunnel over IPv4 will provide the link specific fragmentation (for the link that is IPv4) that the IPv6 base specification requires for links that can not support 1280 bytes of IPv6 packets. Having the encapsulator discover the IPv4 MTU doesn't allow us to reduce the amount of ressembly that the decapsulator needs to perform. And I don't think the level of fragmentation is harmful - especially given that most Internet paths support an MTU of 1500 bytes. Erik From owner-v6ops@ops.ietf.org Sun Mar 16 13:10:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01140 for ; Sun, 16 Mar 2003 13:10:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ucbM-000Mqx-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 10:11:16 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18ucbJ-000Mqb-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 10:11:13 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04028; Sun, 16 Mar 2003 11:11:11 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIB9P05708; Sun, 16 Mar 2003 19:11:09 +0100 (MET) Date: Sun, 16 Mar 2003 19:07:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >The recent changes (copied from the document): > > - Clarified that the dynamic path MTU mechanism in section 3.2 is > > OPTIONAL but if it is implemented it should follow the rules in > > section 3.2. > > > > This method is susceptible to black holes (see RFC 2923). Yes, if ICMPv4 "too big" packets are blocked by firewalls between the encapsulator and decapsulator. It definitely makes sure additing warnings about this in the spec. > > - Stated that implementations MAY have a knob by which the MTU can > > be set to larger values on a tunnel by tunnel basis, but that > > the default MUST be 1280 and that decapsulators need to be > > configured to match the encapsulaltor's MTU. > > > > This method should only be used when care is taken to avoid harmful > levels of > fragmentation in the network (please see my previous note on this > subject). This > needs to be clarified in the draft. I can add warnings about this in the draft. Erik From owner-v6ops@ops.ietf.org Sun Mar 16 13:11:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01160 for ; Sun, 16 Mar 2003 13:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uccA-000MsU-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 10:12:06 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18ucc8-000MsI-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 10:12:04 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28347; Sun, 16 Mar 2003 10:11:59 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIBuP05931; Sun, 16 Mar 2003 19:11:56 +0100 (MET) Date: Sun, 16 Mar 2003 19:07:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: Robert.Peschi@alcatel.be Cc: Erik Nordmark , v6ops@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > If it is not implemented instead the node MUST instead > > limit the size of the IPv6 packets it tunnels to 1280 > > bytes i.e., treat the tunnel interface as having a > > fixed interface MTU of 1280 bytes. > > "MUST NOT" send packet >1280 > -> "MTU>1280" is "Absolute prohibition" > > > An implementation MAY have a configuration knob which > > can be used to set a larger value of the tunnel MTU > > than 1280 bytes, > > "MAY" -> "MTU>1280" is freely allowed > > This seems to be quite in contradiction ? Perhaps poor phrasing. The intent is something along the lines of: If the encapsulator does not implement dynamic tunnel MTU it will use a fixed MTU for the tunnel. The fixed MTU MUST default to 1280. It MAY be configurable but in that case the default MUST be 1280. Is that more clear? Erik From owner-v6ops@ops.ietf.org Sun Mar 16 13:40:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02105 for ; Sun, 16 Mar 2003 13:40:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ud5L-000O1H-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 10:42:15 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18ud5J-000O0z-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 10:42:13 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28286; Sun, 16 Mar 2003 11:42:11 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIg6P07492; Sun, 16 Mar 2003 19:42:06 +0100 (MET) Date: Sun, 16 Mar 2003 19:38:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Sebastien Roy Cc: "Bound, Jim" , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > That's a really good question. I'm not sure what would be the best way > to address this. What we're saying in this draft is that operational > experience has shown that this part of ND could be problematic in some > circumstances. Does ND need to be changed as a result? Probably not. > There are no MUST's surrounding that bit of ND. As implementors, we're > free to interpret the spec in a sane mannor. With this draft, we're > pointing out reasons why implementors may want to be careful with that > part of ND. There is informational value in this alone without having > to muck with the ND spec itself. A possible way to approach this problem would be to make the choice between A and AAAA be a function of whether there is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). That way you don't have to tweak ND. But you do end up with some having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() needs to already do some checks in order to implement the default address selection document. > If you don't have a route to the destination, why try to reach it > on-link just in case the destination might happen to be on-link? Is > there a situation where this would be useful? If you have two nodes communicating on a link and the router dies for long enough time it seems useful to be able to continue to communicate. Of course, the communication will fail once the addresses become invalid but that might take a long time. Erik From owner-v6ops@ops.ietf.org Sun Mar 16 13:40:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02121 for ; Sun, 16 Mar 2003 13:40:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ud5E-000O0q-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 10:42:08 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18ud58-000O0T-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 10:42:02 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07493; Sun, 16 Mar 2003 10:42:00 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIftP07472; Sun, 16 Mar 2003 19:41:56 +0100 (MET) Date: Sun, 16 Mar 2003 19:37:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Sebastien Roy Cc: "Bound, Jim" , Mika Liljeberg , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > If you don't have a route to the destination, why try to reach it > on-link just in case the destination might happen to be on-link? Is > there a situation where this would be useful? > Back when the ND spec was written the idea was that if two nodes can communicate on a link (e.g. using global addresses) it would be nice if they could continue to communicate even if the router(s) to the link disappear. I don't recall if there were any assumptions about the relative lifetime of the addresses they are configured (using stateless, dhcp, or manual) and the on-link prefixes advertised by the routers. But given that the ND spec allows a configuration where the routers don't advertise on-link prefixes (which causes initial packets to go through the router and then be redirected to the on-link destination) it would seem useful to be able to communicate after the router has gone away. Erik From owner-v6ops@ops.ietf.org Sun Mar 16 21:32:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16450 for ; Sun, 16 Mar 2003 21:32:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ukQo-000DVY-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 18:32:54 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 18ukQj-000DVK-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 18:32:49 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2H2VL124275 for ; Mon, 17 Mar 2003 04:31:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 04:32:44 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 04:32:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Mon, 17 Mar 2003 04:32:44 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0193C527@esebe005.ntc.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLWqtLnM+t50MRiScKHkxGVtbVEhASzGDpgAKYmc7A= From: To: Cc: X-OriginalArrivalTime: 17 Mar 2003 02:32:44.0588 (UTC) FILETIME=[7DABA6C0:01C2EC2D] X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16450 Hi, Alain! Thanks for your comments! Finally replying to you... -----Original Message----- From: ext BAUDOT Alain FTRD/DMI/CAE [mailto:alain.baudot@rd.francetelecom.com] Sent: 13 March, 2003 18:45 First paragraphe of section 2 : "The scope of this document is to describe the possible transition scenarios in the 3GPP defined GPRS network where a UE connects to, or is contacted from, the Internet or another UE. The document describes scenarios with and without the usage of the SIP based IP Multimedia Core Network Subsystem (IMS). " Since the abstract specifies that "The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet.", it is no clear to me wether the other UE may be connected to the same network than the UE initiating the connection, or not. JW: The other UE can be connected to the same network or then to a different network. We are not making limitations in this document. (note that the peer node can be any node, e.g. an application server). I've been rather surprised by the last paragraphe of section 2 : "These scenarios may or may not be found feasible, or even likely in further study." One may be confused since one may understand scenarios have nothing to do with reallity. It maybe rephrased stating that the scenarios match real cases and that a subset of them are likely to be met in a given architecture. JW: Yep, we will make some rewording (as I already commented on the list). Last, second paragraph section 4.1 : "Transition scenarios of the GPRS internal interfaces are outside of the scope of this document." I guess this is because the UE has limited ressources and that running internal transition mechanism is likely to be avoided. I wonder in that case if it should explicitly specified. JW: This comment is related to the 3GPP architecture. As you probably know, we have two IP layers there, let's call them user IP layer and network IP layer. We only analyze the (upper) user IP layer here and do not analyze the network IP layer. That means that e.g. the IP layer between the SGSN and the GGSN is out of scope. I hope this helps a bit. JW: Certainly - many thanks! Cheers, -Juha W. From owner-v6ops@ops.ietf.org Mon Mar 17 00:25:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20859 for ; Mon, 17 Mar 2003 00:25:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18un8k-000LaQ-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 21:26:26 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18un8h-000La4-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 21:26:23 -0800 Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22487 for ; Sun, 16 Mar 2003 22:26:23 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBV00MDYOFYIB@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sun, 16 Mar 2003 22:26:23 -0700 (MST) Received: from sun.com ([130.129.139.210]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBV00EUSOFX3F@mail.sun.net> for v6ops@ops.ietf.org; Sun, 16 Mar 2003 22:26:22 -0700 (MST) Date: Sun, 16 Mar 2003 21:26:21 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default In-reply-to: To: Erik Nordmark Cc: Sebastien Roy , "Bound, Jim" , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Sunday, March 16, 2003, at 10:38 AM, Erik Nordmark wrote: >> That's a really good question. I'm not sure what would be the best >> way >> to address this. What we're saying in this draft is that operational >> experience has shown that this part of ND could be problematic in some >> circumstances. Does ND need to be changed as a result? Probably not. >> There are no MUST's surrounding that bit of ND. As implementors, >> we're >> free to interpret the spec in a sane mannor. With this draft, we're >> pointing out reasons why implementors may want to be careful with that >> part of ND. There is informational value in this alone without having >> to muck with the ND spec itself. > > A possible way to approach this problem would be to make > the choice between A and AAAA be a function of whether there > is one or more IPv6 route off-link (or at least one IPv6 router > sending RAs). > > That way you don't have to tweak ND. But you do end up with some > having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() > needs to already do some checks in order to implement the default > address > selection document. What is the benefit of doing so versus doing the change in ndpd? > >> If you don't have a route to the destination, why try to reach it >> on-link just in case the destination might happen to be on-link? Is >> there a situation where this would be useful? > > If you have two nodes communicating on a link and the router > dies for long enough time it seems useful to be able to > continue to communicate. In that case, it make sense to maintain the local subnet route but remove the default route. Destination on the local subnet will still be reachable, other further destination won't and we will not try them. This can be done in ndpd. > Of course, the communication will fail > once the addresses become invalid but that might take a long time. > > Erik > From owner-v6ops@ops.ietf.org Mon Mar 17 00:28:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20919 for ; Mon, 17 Mar 2003 00:28:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18unCN-000LoT-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 21:30:11 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18unCL-000LoG-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 21:30:09 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 675F04FE7; Mon, 17 Mar 2003 00:30:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 00:30:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Mon, 17 Mar 2003 00:30:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCD3@tayexc13.americas.cpqcorp.net> Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLro9BxlDThWtqyS/SqBhqMiYGz4gAohoTw From: "Bound, Jim" To: "Mika Liljeberg" Cc: "Sebastien Roy" , "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 17 Mar 2003 05:30:06.0279 (UTC) FILETIME=[449CD570:01C2EC46] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA20919 Hi Mika, > > I think today this is the bottom line only answer. > > That's too bad, because it means that the DNS resolver would > have do this for the whole candidate destination address > list. That takes time. I would much prefer do a route search only. I agree with you and I still have reservations about source address selection for those performance reasons. > > > But your mail thread makes me wonder if we need to do more > and I think > > so. > > RFC1122 clarified and corrected several small details in the > IPv4 specifications. I think the node requirements spec could > do the same for any fuzzy bits in the IPv6 specificatons. > > > But it would have to be in the context of ND. ND is a > requirement to > > use IPv6. > > I agree. This is just a detail that needs to be clarified somehow. Yes. I can be done with new ICMP types or options. > > > Feels like an edge that could be "do this if ND don't work"? > > No. It's a very specific case of "how to implement the > following bit of next-hop determination" in a host with > multiple network interfaces and how it relates to RFC3484 and > destination address selection: > > If the Default Router List is empty, > the sender assumes that the destination is on-link. > > Until there is a clear understanding, we are sticking with: > > If the route search fails, > the sender assumes the destination is unreachable. > > I haven't seen comments from any other implementors. It would > be very interesting to hear if you have solved this and how > you implemented it. Agreed. Others need to jump in here. I think we have a hole. /jim > > Thanks, > > MikaL > > From owner-v6ops@ops.ietf.org Mon Mar 17 01:46:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22962 for ; Mon, 17 Mar 2003 01:46:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uoPp-000Pxl-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 22:48:09 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18uoPm-000PxZ-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 22:48:07 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA19878; Mon, 17 Mar 2003 06:48:05 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA09301; Mon, 17 Mar 2003 06:48:04 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2H6m4L24705; Mon, 17 Mar 2003 06:48:04 GMT Date: Mon, 17 Mar 2003 06:48:04 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-ID: <20030317064804.GG24236@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Mar 16, 2003 at 07:38:09PM +0100, Erik Nordmark wrote: > > A possible way to approach this problem would be to make > the choice between A and AAAA be a function of whether there > is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). Note this cuts both ways. I've been in dual-protocol networks where IPv4 has been down and IPv6 up, so we ought to consider the general case of availability of connectivity off-link for either protocol. (But I do appreciate the issues here is - I think - what to do when deploying an IPv6 enabled host which receives AAAA responses in an IPv4-only network) A not-uncommon enterprise deployment method for dual-protocol now is to have a parallel IPv6 infrastructure with a separate off-site IPv6 link, such that IPv6 is routed within the site using (for example) BSD routers with RA's for subnets injected into the v4 VLANs (if your BSD box can VLAN-tag on a single interface, very few cables may be needed :). Thus the router giving connectivity off each subnet is different (in one case, the "smart" L2/L3 VLAN switching equipment, in the other, PC-based routers) , and either could fail. Such a deployment method is a short-term one until Cisco, Alcatel, etc offer v6 L2/L3 functionality as exists for v4 now. Most dual-protocol networks will probably in the medium-term fate-share IPv4 and IPv6, so the distinction will then be somewhat moot. Tim From owner-v6ops@ops.ietf.org Mon Mar 17 01:52:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23068 for ; Mon, 17 Mar 2003 01:52:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uoW3-0000Ku-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 22:54:35 -0800 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 18uoVx-0000Kb-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 22:54:29 -0800 Received: (cpmta 6200 invoked from network); 16 Mar 2003 22:54:27 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 16 Mar 2003 22:54:27 -0800 X-Sent: 17 Mar 2003 06:54:27 GMT Message-ID: <002201c2ec52$3f61e990$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: "Wijnen, Bert \(Bert\)" , , , References: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> Subject: Re: Question about IPv6 Management Date: Mon, 17 Mar 2003 08:55:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2EC63.00F57940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.1 required=5.0 tests=BIG_FONT,HTML_50_70,HTML_FONT_COLOR_BLUE,MAILTO_LINK, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT_OE version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C2EC63.00F57940 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Thank you. I have been reading: RFC 2452 IP v6 MIB for the TCP RFC 2454 IP v6 MIB for the UDP RFC 2466 MIB for IP v6 ICMP=20 But didn't see anything more detailed. Thanks for the information. Eric ----- Original Message -----=20 From: Wijnen, Bert (Bert)=20 To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ; = ipng@sunroof.eng.sun.com=20 Sent: Monday, March 17, 2003 2:48 AM Subject: RE: Question about IPv6 Management We have been defining a number of things so that IP (or better = Internet) addresses can be represented in an IPversion neutral matter. See for example = RFC3291. We are checking all MIB modules to be IPv4 and IPv6 capable (unless a = module is for one specific IP version).=20 We have defined TCs so that we also have IPv6 transport addresses so = that=20 SNMP can go over IPv6. See RFC3419 Various MIB modules are being reqorked in the IPv6 WG=20 Hope this helps Thanks,Bert=20 -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: zondag 16 maart 2003 11:19 To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com Subject: Question about IPv6 Management I appologize, this is being possted to multiple WG's as it seems to = cross areas. Is there any information about the requirment changes in the Network = Management Systems (NMS) or Operations Support Systems (OSS) necesary to = support IPv6? I have looked at the various MIB RFC's and such, but can not find = anything more than you need bigger address support and some SNMPv2 = compliance. This seems too simple to me. Eric ------=_NextPart_000_001F_01C2EC63.00F57940 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Thank you. I have been = reading:

RFC 2452 IP = v6 MIB for=20 the TCP

RFC 2454 IP = v6 MIB for=20 the UDP

RFC=20 2466 MIB for IP v6 ICMP
 
But=20 didn't see anything more detailed. Thanks for the = information.
Eric
----- Original Message -----
From:=20 Wijnen, Bert=20 (Bert)
To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ;=20 ipng@sunroof.eng.sun.com =
Sent: Monday, March 17, 2003 = 2:48=20 AM
Subject: RE: Question about = IPv6=20 Management

We=20 have been defining a number of things so that IP (or better Internet)=20 addresses
can=20 be represented in an IPversion neutral matter. See for example=20 RFC3291.
 
We=20 are checking all MIB modules to be IPv4 and IPv6 capable (unless a=20 module
is=20 for one specific IP version).
 
We=20 have defined TCs so that we also have IPv6 transport addresses so that =
SNMP=20 can go over IPv6. See RFC3419
 
Various MIB modules are being reqorked in = the IPv6 WG=20
 
Hope=20 this helps

Thanks,Bert

-----Original Message-----
From: EricLKlein=20 [mailto:ericlklein@softhome.net]
Sent: zondag 16 maart = 2003=20 11:19
To: v6ops@ops.ietf.org; eos@ops.ietf.org;=20 ipng@sunroof.eng.sun.com
Subject: Question about IPv6=20 Management

I appologize, this is being possted = to multiple=20 WG's as it seems to cross areas.
 
Is there any information about the = requirment=20 changes in the Network Management Systems (NMS) or Operations=20 Support Systems (OSS) necesary to support = IPv6?
 
I have looked at the various MIB RFC's = and such,=20 but can not find anything more than you need bigger address support = and some=20 SNMPv2 compliance.
 
This seems too simple to me.
 
 Eric
------=_NextPart_000_001F_01C2EC63.00F57940-- From owner-v6ops@ops.ietf.org Mon Mar 17 02:29:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05406 for ; Mon, 17 Mar 2003 02:29:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18up57-0002Gx-00 for v6ops-data@psg.com; Sun, 16 Mar 2003 23:30:49 -0800 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18up51-0002F2-00 for v6ops@ops.ietf.org; Sun, 16 Mar 2003 23:30:44 -0800 Received: from localhost (wl-140-223.wireless.ietf56.ietf.org [130.129.140.223]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CF6B215252; Mon, 17 Mar 2003 16:30:53 +0900 (JST) Date: Mon, 17 Mar 2003 16:31:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mika Liljeberg Cc: "Bound, Jim" , Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default In-Reply-To: <1047809277.13138.88.camel@devil> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> <1047809277.13138.88.camel@devil> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 55 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On 16 Mar 2003 12:07:57 +0200, >>>>> Mika Liljeberg said: > No. It's a very specific case of "how to implement the following bit of > next-hop determination" in a host with multiple network interfaces and > how it relates to RFC3484 and destination address selection: > If the Default Router List is empty, > the sender assumes that the destination is on-link. > Until there is a clear understanding, we are sticking with: > If the route search fails, > the sender assumes the destination is unreachable. > I haven't seen comments from any other implementors. It would be very > interesting to hear if you have solved this and how you implemented it. We (KAME) adopted a simple (and perhaps naive approach); using the default interface. However, we disabled the ability to specify the default interface by default due to the exact reason discussed here. For more details, please refer to Section 1.2 of the KAME implementation note, the latest version of which is available at: http://orange.kame.net/dev/cvsweb2.cgi/kame/IMPLEMENTATION?rev=1.329&content-type=text/x-cvsweb-markup The following is the related part of the note. IPv6 on-link determination rule (RFC2461) is quite different from assumptions in BSD IPv4 network code. To implement the behavior in RFC2461 section 6.3.6 (3), the kernel needs to know the default outgoing interface. To configure the default outgoing interface, use commands like "ndp -I de0" as root. Then the kernel will have a "default" route to the interface with the cloning "C" bit being on. This default route will cause to make a neighbor cache entry for every destination that does not match an explicit route entry. Note that we intentionally disables configuring the default interface by default. This is because we found it sometimes caused inconvenient situation while it was rarely useful in practical usage. For example, consider a destination that has both IPv4 and IPv6 addresses but is only reachable via IPv4. Since our getaddrinfo(3) prefers IPv6 by default, an (TCP) application using the library with PF_UNSPEC first tries to connect to the IPv6 address. If we turn on RFC 2461 6.3.6 (3), we have to wait for quite a long period before the first attempt to make a connection fails. If we turn it off, the first attempt will immediately fail with EHOSTUNREACH, and then the application can try the next, reachable address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Mar 17 04:51:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08888 for ; Mon, 17 Mar 2003 04:51:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urI9-0007cu-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 01:52:25 -0800 Received: from alc239.alcatel.be ([195.207.101.239] helo=relay2.alcatel.be) by psg.com with esmtp (Exim 3.36 #1) id 18urI6-0007cc-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 01:52:22 -0800 Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h2H9q8A27819; Mon, 17 Mar 2003 10:52:09 +0100 (MET) From: Robert.Peschi@alcatel.be Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: Erik Nordmark Cc: v6ops@ops.ietf.org Date: Mon, 17 Mar 2003 10:52:07 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/17/2003 10:52:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The intent is something along the lines of: > > If the encapsulator does not implement dynamic > tunnel MTU it will use a fixed MTU for the tunnel. > The fixed MTU MUST default to 1280. It MAY be > configurable but in that case the default MUST > be 1280. > > Is that more clear? Quite fine, thanks, Robert From owner-v6ops@ops.ietf.org Mon Mar 17 08:25:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12853 for ; Mon, 17 Mar 2003 08:25:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uucG-000EZy-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 05:25:24 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18uucE-000EZj-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 05:25:22 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01983; Mon, 17 Mar 2003 06:25:20 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HDP9P08026; Mon, 17 Mar 2003 14:25:10 +0100 (MET) Date: Mon, 17 Mar 2003 14:21:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Alain Durand Cc: Erik Nordmark , Sebastien Roy , "Bound, Jim" , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > What is the benefit of doing so versus doing the change in ndpd? NDP working as designed in RFC 2461. > In that case, it make sense to maintain the local subnet route > but remove the default route. Destination on the local subnet will > still be reachable, other further destination won't and we will not > try them. This can be done in ndpd. In another message I think I pointed out that we want NDP to work when there are no prefixes advertised with the O-bit set (even though the prefixes are on-link). For instance, this might be part of a potential solution to better deal with hidden terminal problems in wireless networks. Erik From owner-v6ops@ops.ietf.org Mon Mar 17 12:05:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20569 for ; Mon, 17 Mar 2003 12:05:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uy3R-000Pb4-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:05:41 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18uy3G-000PaA-01 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 09:05:30 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18uxAk-0001wA-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 11:09:11 -0500 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC1E.EEDF5846" From: "Wijnen, Bert (Bert)" To: EricLKlein , v6ops@ops.ietf.org, eos@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: RE: Question about IPv6 Management Date: Mon, 17 Mar 2003 01:48:32 +0100 X-Spam-Status: No, hits=1.8 required=5.0 tests=BIG_FONT,HTML_FONT_COLOR_BLUE,MIME_NULL_BLOCK,RESENT_TO, SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org 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_01C2EC1E.EEDF5846 Content-Type: text/plain; charset="windows-1255" [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] We have been defining a number of things so that IP (or better Internet) addresses can be represented in an IPversion neutral matter. See for example RFC3291. We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module is for one specific IP version). We have defined TCs so that we also have IPv6 transport addresses so that SNMP can go over IPv6. See RFC3419 Various MIB modules are being reqorked in the IPv6 WG Hope this helps Thanks,Bert -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: zondag 16 maart 2003 11:19 To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com Subject: Question about IPv6 Management I appologize, this is being possted to multiple WG's as it seems to cross areas. Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6? I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance. This seems too simple to me. Eric ------_=_NextPart_001_01C2EC1E.EEDF5846 Content-Type: text/html; charset="windows-1255"
We have been defining a number of things so that IP (or better Internet) addresses
can be represented in an IPversion neutral matter. See for example RFC3291.
 
We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module
is for one specific IP version).
 
We have defined TCs so that we also have IPv6 transport addresses so that
SNMP can go over IPv6. See RFC3419
 
Various MIB modules are being reqorked in the IPv6 WG
 
Hope this helps

Thanks,Bert

-----Original Message-----
From: EricLKlein [mailto:ericlklein@softhome.net]
Sent: zondag 16 maart 2003 11:19
To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com
Subject: Question about IPv6 Management

I appologize, this is being possted to multiple WG's as it seems to cross areas.
 
Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6?
 
I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance.
 
This seems too simple to me.
 
 Eric
------_=_NextPart_001_01C2EC1E.EEDF5846-- From owner-v6ops@ops.ietf.org Mon Mar 17 12:05:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20603 for ; Mon, 17 Mar 2003 12:05:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uy3H-000Pah-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:05:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18uy3E-000PaA-02; Mon, 17 Mar 2003 09:05:29 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18uxat-00026D-00; Mon, 17 Mar 2003 11:36:11 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 08:36:10 -0800 To: v6ops@ops.ietf.org Subject: changing deck chairs on the titanic :-) Message-Id: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit thomas narten is retiring back to the sunny palms of the iesg holiday cruise after some years of getting this wg on the rails. thanks thomas. as readers of swedish will already know, Kurtis Lindqvist is joing sean as co-chair of the wg. be kind to him. [ my wife would say "think of the people on the titanic who declined dessert" ] From owner-v6ops@ops.ietf.org Mon Mar 17 12:17:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21060 for ; Mon, 17 Mar 2003 12:17:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyGY-0000Y5-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:19:14 -0800 Received: from ms-smtp-02.southeast.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #1) id 18uyGO-0000Ww-00; Mon, 17 Mar 2003 09:19:04 -0800 Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2HHHFgU028709; Mon, 17 Mar 2003 12:17:19 -0500 (EST) Received: from nc.rr.com ([130.129.130.143]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 17 Mar 2003 12:16:43 -0500 Message-ID: <3E7602FE.9070505@nc.rr.com> Date: Mon, 17 Mar 2003 12:16:46 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EricLKlein CC: v6ops@ops.ietf.org, eos@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Question about IPv6 Management References: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> <002201c2ec52$3f61e990$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Take a look at the following: draft-ietf-ipv6-rfc2096-update-02.txt draft-ietf-ipv6-rfc2013-update-00.txt draft-ietf-ipv6-rfc2012-update-02.txt draft-ietf-ipv6-rfc2011-update-02.txt Regards, Brian EricLKlein wrote: > Thank you. I have been reading: > RFC 2452 IP v6 MIB for the TCP > > RFC 2454 IP v6 MIB for the UDP > > RFC 2466 MIB for IP v6 ICMP > > But didn't see anything more detailed. Thanks for the information. > Eric > ----- Original Message ----- > From: Wijnen, Bert (Bert) > To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ; ipng@sunroof.eng.sun.com > Sent: Monday, March 17, 2003 2:48 AM > Subject: RE: Question about IPv6 Management > > > We have been defining a number of things so that IP (or better Internet) addresses > can be represented in an IPversion neutral matter. See for example RFC3291. > > We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module > is for one specific IP version). > > We have defined TCs so that we also have IPv6 transport addresses so that > SNMP can go over IPv6. See RFC3419 > > Various MIB modules are being reqorked in the IPv6 WG > > Hope this helps > Thanks,Bert > > -----Original Message----- > From: EricLKlein [mailto:ericlklein@softhome.net] > Sent: zondag 16 maart 2003 11:19 > To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com > Subject: Question about IPv6 Management > > > I appologize, this is being possted to multiple WG's as it seems to cross areas. > > Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6? > > I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance. > > This seems too simple to me. > > Eric > From owner-v6ops@ops.ietf.org Mon Mar 17 12:23:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21273 for ; Mon, 17 Mar 2003 12:23:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyMP-0000pH-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:25:17 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18uyMM-0000oz-00; Mon, 17 Mar 2003 09:25:14 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2HHQbKW005790; Mon, 17 Mar 2003 18:26:40 +0100 (CET) Date: Mon, 17 Mar 2003 18:26:32 +0100 Subject: Re: changing deck chairs on the titanic :-) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: v6ops@ops.ietf.org To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <988C895C-589D-11D7-B5E1-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21273 I am glad to see that I am not the only one who doesn't read headers..:) - kurtis - On mndag, mar 17, 2003, at 17:36 Europe/Stockholm, Randy Bush wrote: > thomas narten is retiring back to the sunny palms of the iesg > holiday cruise after some years of getting this wg on the rails. > thanks thomas. > > as readers of swedish will already know, Kurtis Lindqvist > is joing sean as co-chair of the wg. > be kind to him. > > [ my wife would say "think of the people on the titanic who > declined dessert" ] > > From owner-v6ops@ops.ietf.org Mon Mar 17 12:31:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21620 for ; Mon, 17 Mar 2003 12:31:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyTs-0001Uq-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:33:00 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18uyTm-0001UR-00; Mon, 17 Mar 2003 09:32:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18uyTl-0002Py-00; Mon, 17 Mar 2003 12:32:53 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 09:32:53 -0800 To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Subject: Re: changing deck chairs on the titanic :-) References: <20030317172057.17571791@starfruit.itojun.org> Message-Id: X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> thomas narten is retiring back to the sunny palms of the iesg >> holiday cruise after some years of getting this wg on the rails. >> thanks thomas. >> >> as readers of swedish will already know, Kurtis Lindqvist >> is joing sean as co-chair of the wg. >> be kind to him. >> >> [ my wife would say "think of the people on the titanic who >> declined dessert" ] > > it was sent to v6ops. why? beacuse i am an idiot? randy From owner-v6ops@ops.ietf.org Mon Mar 17 12:32:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21727 for ; Mon, 17 Mar 2003 12:32:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyVe-0001fV-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 09:34:50 -0800 Received: from wl-142-194.wireless.ietf56.ietf.org ([130.129.142.194] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18uyVa-0001eV-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 09:34:46 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E73BE791; Tue, 18 Mar 2003 02:34:08 +0900 (JST) To: Randy Bush Cc: v6ops@ops.ietf.org In-reply-to: randy's message of Mon, 17 Mar 2003 08:36:10 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: changing deck chairs on the titanic :-) From: Jun-ichiro itojun Hagino Date: Tue, 18 Mar 2003 02:34:08 +0900 Message-Id: <20030317173408.E73BE791@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >thomas narten is retiring back to the sunny palms of the iesg >holiday cruise after some years of getting this wg on the rails. >thanks thomas. >as readers of swedish will already know, Kurtis Lindqvist > is joing sean as co-chair of the wg. >be kind to him. i guess it's about multi6, right? itojun From owner-v6ops@ops.ietf.org Mon Mar 17 14:09:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25418 for ; Mon, 17 Mar 2003 14:09:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzyc-0008Bw-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 11:08:50 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18uzyY-0008B4-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 11:08:46 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06080; Mon, 17 Mar 2003 12:08:43 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HJ8fP13472; Mon, 17 Mar 2003 20:08:41 +0100 (MET) Date: Mon, 17 Mar 2003 19:15:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-huitema-v6ops-unmaneval-00.txt To: Christian Huitema Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > When it comes to traversing NAT, the issue is how to "come in", not how to > "go out". AFAIK, teredo is the only solution that allows "self deploy" > because it let UDP packets "come in". All the other solutions are variations > on fixed tunnels, and thus require some form of contract between a user and > a tunnel endpoint. You can clearly do PPP over TCP, but you can only do that > if you initiate the connection from inside the NAT towards a fixed tunnel > end-point; in that case, I believe that a UDP base tunnel will provide a > lesser overhead, and will avoid the "head of line blocking" issues found in > TCP. RFC 2893 tunneling only works with some NAT, and as such cannot be a > generic solution. While I disagree with your conclusion, the point of this email is merely that the document doesn't seem to be consistent with what your conclusion. Above you say that there is only one (type of) solution which solves the problem. Yet the draft says that there are two: Teredo [TEREDO], or UDP tunnels. Did you intend that the draft say "Teredo which uses UDP tunnels" or something like that? Erik From owner-v6ops@ops.ietf.org Mon Mar 17 14:09:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25434 for ; Mon, 17 Mar 2003 14:09:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzyd-0008C5-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 11:08:51 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18uzya-0008BN-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 11:08:48 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06137; Mon, 17 Mar 2003 12:08:47 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HJ8iP13476; Mon, 17 Mar 2003 20:08:44 +0100 (MET) Date: Mon, 17 Mar 2003 19:38:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Tim Chown Cc: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030317064804.GG24236@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > A possible way to approach this problem would be to make > > the choice between A and AAAA be a function of whether there > > is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). > > Note this cuts both ways. I've been in dual-protocol networks where IPv4 > has been down and IPv6 up, so we ought to consider the general case of > availability of connectivity off-link for either protocol. Good point and I agree in principle. But the rules for detecting the lack of connectivity are likely to be different in the IPv6 and IPv4 cases. In IPv6 either RAs or some routing protocol provides routes to the node. Thus the existence of (non manually configured) off-link routes indicate the at least the first hop IPv6 routing is working. In IPv4 in addition to dynamic schemes, the DHCP server can hand out a default route. But that router itself might not be working. Thus would it make sense to be more "suspecious" about IPv4 default routes than in the IPv6 case somehow? Erik From owner-v6ops@ops.ietf.org Mon Mar 17 19:32:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10097 for ; Mon, 17 Mar 2003 19:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v52Q-0006q1-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 16:33:06 -0800 Received: from [2001:218:1f01:10::2] (helo=guri.nttv6.jp) by psg.com with esmtp (Exim 3.36 #1) id 18v52O-0006mi-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 16:33:04 -0800 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 8E081B162D; Tue, 18 Mar 2003 09:32:33 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id 69A81125CD6; Tue, 18 Mar 2003 09:32:32 +0900 (JST) Date: Tue, 18 Mar 2003 09:32:31 +0900 (JST) Message-Id: <20030318.093231.102551814.yasuhiro@nttv6.jp> To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re: comments on shirasaki-dualstack-service-00 From: SHIRASAKI Yasuhiro In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, SUBJ_HAS_UNIQ_ID version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, > 2. Requirements > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [RFC2119]. > > ==> I'd remove this section completely and switch to lower case must, > should, etc. because this isn't exactly a document with interop interest :-) agree. I'll remove it. > When CPE receives packets which are destined for the delegated > prefix, CPE MUST NOT forward the packets to a PE. CPE SHOULD return > ICMPv6 Destination Unreachable message to a source address or > silently discard the packets. > > ==> would it be worthwhile to describe how this is accomplished? Null0 > route is at least trivial, but it won't return an unreachable message > except by explicit config in some implementations. But maybe this is > outside of scope.. I've imagined reject route behavior of KAME stack first at that time. Anyway, thank you for your comments. I'll update the draft. -- SHIRASAKI Yasuhiro @ NTT Communications From owner-v6ops@ops.ietf.org Mon Mar 17 23:36:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17466 for ; Mon, 17 Mar 2003 23:36:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v8rQ-000Jsu-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 20:38:00 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18v8rK-000JsH-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 20:37:54 -0800 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 UAA15522; Mon, 17 Mar 2003 20:37:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2I4bn910158; Mon, 17 Mar 2003 20:37:49 -0800 X-mProtect: <200303180437> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.152, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnrHkcQ; Mon, 17 Mar 2003 20:37:47 PST Message-ID: <3E76A29A.6020708@iprg.nokia.com> Date: Mon, 17 Mar 2003 20:37:46 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Sebastien Roy , "Bound, Jim" , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm just dropping into this thread, and maybe this idea has already come up. But, when the DNS returns both A and AAAA records for a destination and when there is no v6 route, why can't the source just do automatic v6-in-v4 tunneling using an address from an AAAA record as the v6dst and an address from an A record as the v4dst? Gives you a decision tree of sorts, i.e.: 1) when an AAAA record and a v6 route exist, use native v6. Else: 2) when both AAAA and A records exist, but no v6 route, use automatic v6-in-v4 tunneling. Else: 3) when an A record exists, use v4. Else: 4) destination unreachable Fred ftemplin@iprg.nokia.com Erik Nordmark wrote: >>That's a really good question. I'm not sure what would be the best way >>to address this. What we're saying in this draft is that operational >>experience has shown that this part of ND could be problematic in some >>circumstances. Does ND need to be changed as a result? Probably not. >>There are no MUST's surrounding that bit of ND. As implementors, we're >>free to interpret the spec in a sane mannor. With this draft, we're >>pointing out reasons why implementors may want to be careful with that >>part of ND. There is informational value in this alone without having >>to muck with the ND spec itself. >> >> > >A possible way to approach this problem would be to make >the choice between A and AAAA be a function of whether there >is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). > >That way you don't have to tweak ND. But you do end up with some >having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() >needs to already do some checks in order to implement the default address >selection document. > > > >>If you don't have a route to the destination, why try to reach it >>on-link just in case the destination might happen to be on-link? Is >>there a situation where this would be useful? >> >> > >If you have two nodes communicating on a link and the router >dies for long enough time it seems useful to be able to >continue to communicate. Of course, the communication will fail >once the addresses become invalid but that might take a long 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-v6ops@ops.ietf.org Tue Mar 18 00:37:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19305 for ; Tue, 18 Mar 2003 00:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v9nv-000MqH-00 for v6ops-data@psg.com; Mon, 17 Mar 2003 21:38:27 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18v9ns-000Mpr-00 for v6ops@ops.ietf.org; Mon, 17 Mar 2003 21:38:24 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id FAA15105; Tue, 18 Mar 2003 05:38:23 GMT Received: from pandora.ecs.soton.ac.uk (pandora.ecs.soton.ac.uk [152.78.68.157]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h2I5cGgq025424; Tue, 18 Mar 2003 05:38:16 GMT Received: (from tjc@localhost) by pandora.ecs.soton.ac.uk (8.11.6+Sun/8.11.6) id h2I5cGP15618; Tue, 18 Mar 2003 05:38:16 GMT Date: Tue, 18 Mar 2003 05:38:16 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-ID: <20030318053812.GF15110@pandora.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com References: <3E76A29A.6020708@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E76A29A.6020708@iprg.nokia.com> User-Agent: Mutt/1.3.25i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Mar 17, 2003 at 08:37:46PM -0800, Fred L. Templin wrote: > I'm just dropping into this thread, and maybe this idea has already come up. > But, when the DNS returns both A and AAAA records for a destination and > when there is no v6 route, why can't the source just do automatic v6-in-v4 > tunneling using an address from an AAAA record as the v6dst and an address > from an A record as the v4dst? Gives you a decision tree of sorts, i.e.: In principle reasonable, but many things may still cause failure, e.g. - the tunnelling fails due to firewall blocks - the IPv4 connectivity is down - the A and AAAA records may point to different hosts Tim From owner-v6ops@ops.ietf.org Tue Mar 18 11:06:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15160 for ; Tue, 18 Mar 2003 11:06:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vJZV-0000IN-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 08:04:13 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vJZT-0000I7-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 08:04:11 -0800 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 IAA05739; Tue, 18 Mar 2003 08:04:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2IG49r03402; Tue, 18 Mar 2003 08:04:09 -0800 X-mProtect: <200303181604> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.49.236, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtwfZ39; Tue, 18 Mar 2003 08:04:07 PST Message-ID: <3E774377.2050002@iprg.nokia.com> Date: Tue, 18 Mar 2003 08:04:07 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>As currently worded, the specification could result in harmful levels of >>fragmentation in >>the network when encapsulators implement only the base specification. >> >> > >My understanding from the previous discussion on the draft the WG did >not want to mandate the dynamic MTU discovery from encapsulator to >decapsulator. Hence it is optional in the new draft. > No; I was only referring to the scheme that allows configured MTUs larger than 1280 when the DF bit is not set. But, see below: >But limiting the size of the packets sent into the tunnel to 1280+20 >doesn't cause any more fragmentation than the dynamic scheme. >Essentially the mandatory part of the specification means that >the tunnel over IPv4 will provide the link specific fragmentation >(for the link that is IPv4) that the IPv6 base specification requires >for links that can not support 1280 bytes of IPv6 packets. > True; in some cases, link layer fragmentation is unavoidable. >Having the encapsulator discover the IPv4 MTU doesn't allow us to reduce the >amount of ressembly that the decapsulator needs to perform. >And I don't think the level of fragmentation is harmful - especially given >that most Internet paths support an MTU of 1500 bytes. > Yes, most paths support an MTU of 1500 bytes. But, the majority of those that don't will fragment at 576 bytes. Hence, an MTU closer to 1480+20 bytes will result in no more fragments (i.e., 3) than 1280+20 in most cases. Still to be considered are bumps in the stack/wire and middleboxes that add further layers of encapsulation (e.g., L2TP, IPsec, etc.) so a safe bet is to choose something like 1380+20 leaving 100bytes for additional encapsulation. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 18 16:33:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01205 for ; Tue, 18 Mar 2003 16:33:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vOhy-000GjJ-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 13:33:18 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vOht-000Gj3-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 13:33:13 -0800 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 NAA19180; Tue, 18 Mar 2003 13:33:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2ILXAf07740; Tue, 18 Mar 2003 13:33:10 -0800 X-mProtect: <200303182133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7uwfUG; Tue, 18 Mar 2003 13:33:09 PST Message-ID: <3E7791D9.8030407@iprg.nokia.com> Date: Tue, 18 Mar 2003 13:38:33 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>>The recent changes (copied from the document): >>> - Clarified that the dynamic path MTU mechanism in section 3.2 is >>> OPTIONAL but if it is implemented it should follow the rules in >>> section 3.2. >>> >> >>This method is susceptible to black holes (see RFC 2923). > > > Yes, if ICMPv4 "too big" packets are blocked by firewalls between > the encapsulator and decapsulator. Yes. Also at issue are spoofed ICMPv4 "fragmentation needed" packets as a form of denial of service, and forwarding nodes that do not generate ICMPv4 "frag needed"'s at all. > It definitely makes sure additing warnings about this in the spec. OK. >>> - Stated that implementations MAY have a knob by which the MTU can >>> be set to larger values on a tunnel by tunnel basis, but that >>> the default MUST be 1280 and that decapsulators need to be >>> configured to match the encapsulaltor's MTU. >>> >> >>This method should only be used when care is taken to avoid harmful >>levels of >>fragmentation in the network (please see my previous note on this >>subject). This >>needs to be clarified in the draft. > > > I can add warnings about this in the draft. Better than warnings are mechanisms that would allow the encapsulator to efficiently probe/monitor the path MTU to the decapsulator. See: http://www.geocities.com/osprey67/isatap-pre13.txt http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 18 17:01:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02436 for ; Tue, 18 Mar 2003 17:01:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPAU-000IF1-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 14:02:46 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vPAR-000IEY-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 14:02:43 -0800 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 OAA19994; Tue, 18 Mar 2003 14:02:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2IM2bq29956; Tue, 18 Mar 2003 14:02:37 -0800 X-mProtect: <200303182202> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqtazeb; Tue, 18 Mar 2003 14:02:35 PST Message-ID: <3E7798BF.4040801@iprg.nokia.com> Date: Tue, 18 Mar 2003 14:07:59 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Another comment on 'draft-ietf-v6ops-mech-v2-00.txt'. In section 3.5, I see the following text: Total Length: Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e., IPv6 payload length plus a constant 60 bytes) Suggest changing this to: Total Length: Payload length from IPv6 header plus length of IPv6 and IPv4 headers plus length of optional padding (i.e., IPv6 payload length plus a minimum of 60 bytes) Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 18 17:37:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03283 for ; Tue, 18 Mar 2003 17:37:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPip-000KBs-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 14:38:15 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18vPij-000KBD-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 14:38:09 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27597; Tue, 18 Mar 2003 15:38:08 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2IMc5P12222; Tue, 18 Mar 2003 23:38:06 +0100 (MET) Date: Tue, 18 Mar 2003 23:34:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E7791D9.8030407@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Better than warnings are mechanisms that would allow the encapsulator > to efficiently probe/monitor the path MTU to the decapsulator. See: Yes, the document already has a dynamic tunnel MTU scheme. The issue is what we require when folks want to use a static MTU for the tunnel. Given that feedback in the past has been to allow the static scheme since it is more widely implemented than the dynamic scheme it would seem odd to mandate a dynamic scheme - whether the current one in the draft or the one in your recent draft. Erik From owner-v6ops@ops.ietf.org Tue Mar 18 17:52:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03660 for ; Tue, 18 Mar 2003 17:52:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPyA-000LRZ-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 14:54:06 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18vPy4-000LQS-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 14:54:00 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08246; Tue, 18 Mar 2003 15:53:59 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2IMruP13125; Tue, 18 Mar 2003 23:53:56 +0100 (MET) Date: Tue, 18 Mar 2003 23:49:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E7798BF.4040801@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Total Length: > Payload length from IPv6 header plus length of IPv6 and > IPv4 headers plus length of optional padding (i.e., IPv6 > payload length plus a minimum of 60 bytes) I don't understand the motivation for your suggestion. The document doesn't talk about any optional padding. Are you proposing that we add the ability to optionally pad the packets as part of encapsulating them? What problem would allowing optional padding solve? Erik From owner-v6ops@ops.ietf.org Tue Mar 18 19:11:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07420 for ; Tue, 18 Mar 2003 19:11:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRBe-000PXM-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 16:12:06 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vRBb-000PX9-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 16:12:03 -0800 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 QAA26295; Tue, 18 Mar 2003 16:12:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2J0C2J13163; Tue, 18 Mar 2003 16:12:02 -0800 X-mProtect: <200303190012> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.123, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRPx00V; Tue, 18 Mar 2003 16:12:00 PST Message-ID: <3E77B5CF.80508@iprg.nokia.com> Date: Tue, 18 Mar 2003 16:11:59 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, So that there is no misunderstanding, my opinion is that the static scheme is a MUST and any dynamic scheme is a qualified MAY. Fred ftemplin@iprg.nokia.com Erik Nordmark wrote: >>Better than warnings are mechanisms that would allow the encapsulator >>to efficiently probe/monitor the path MTU to the decapsulator. See: >> >> > >Yes, the document already has a dynamic tunnel MTU scheme. >The issue is what we require when folks want to use a static MTU for >the tunnel. > >Given that feedback in the past has been to allow the static scheme since >it is more widely implemented than the dynamic scheme it would seem >odd to mandate a dynamic scheme - whether the current one in the draft >or the one in your recent draft. > > Erik > > > From owner-v6ops@ops.ietf.org Tue Mar 18 19:17:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07567 for ; Tue, 18 Mar 2003 19:17:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRII-000Plb-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 16:18:58 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vRIB-000Pku-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 16:18:52 -0800 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 QAA26627; Tue, 18 Mar 2003 16:18:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2J0Iop17330; Tue, 18 Mar 2003 16:18:50 -0800 X-mProtect: <200303190018> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.123, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5tSW88; Tue, 18 Mar 2003 16:18:48 PST Message-ID: <3E77B768.80804@iprg.nokia.com> Date: Tue, 18 Mar 2003 16:18:48 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> Total Length: >> Payload length from IPv6 header plus length of IPv6 and >> IPv4 headers plus length of optional padding (i.e., IPv6 >> payload length plus a minimum of 60 bytes) >> >> > >I don't understand the motivation for your suggestion. > >The document doesn't talk about any optional padding. >Are you proposing that we add the ability to optionally pad >the packets as part of encapsulating them? > Yes. >What problem would allowing optional padding solve? > Two possible applications for the optional padding are: 1) traffic confidentiality 2) path MTU probing using arbitrary data packets Moreover, I see no requirement that a decapsulator check that IPv4_len = IPv6_len + 60. To be sure, the only requirement for correct operation is that IPv4_len >= IPv6_len +60. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 18 19:37:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08755 for ; Tue, 18 Mar 2003 19:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRbl-0000ee-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 16:39:05 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18vRbi-0000eR-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 16:39:02 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10245; Tue, 18 Mar 2003 17:39:01 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2J0cwP21313; Wed, 19 Mar 2003 01:38:58 +0100 (MET) Date: Wed, 19 Mar 2003 01:34:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E77B5CF.80508@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > So that there is no misunderstanding, my opinion is that the static > scheme is > a MUST and any dynamic scheme is a qualified MAY. That is what the draft currently says. Erik From owner-v6ops@ops.ietf.org Tue Mar 18 19:55:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09558 for ; Tue, 18 Mar 2003 19:55:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRsf-0001Qf-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 16:56:33 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18vRsc-0001QT-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 16:56:30 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16030; Tue, 18 Mar 2003 17:56:27 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2J0uPP22132; Wed, 19 Mar 2003 01:56:25 +0100 (MET) Date: Wed, 19 Mar 2003 01:52:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-v6ops-mech-v2-00.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E77B768.80804@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Two possible applications for the optional padding are: > > 1) traffic confidentiality > 2) path MTU probing using arbitrary data packets > > Moreover, I see no requirement that a decapsulator check that > IPv4_len = IPv6_len + 60. To be sure, the only requirement > for correct operation is that IPv4_len >= IPv6_len +60. To allow padding to be applied in the future the key thing for this spec is to make it clear that the decapsulator must do the second check above. I'll add that, but I don't think we need to say something specific about the encapsulator adding padding. Erik From owner-v6ops@ops.ietf.org Tue Mar 18 20:22:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10746 for ; Tue, 18 Mar 2003 20:22:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vSIr-0002X7-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 17:23:37 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vSIp-0002Wu-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 17:23:35 -0800 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 RAA28956; Tue, 18 Mar 2003 17:23:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2J1NX712691; Tue, 18 Mar 2003 17:23:33 -0800 X-mProtect: <200303190123> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.178, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnez87v; Tue, 18 Mar 2003 17:23:32 PST Message-ID: <3E77C694.9060104@iprg.nokia.com> Date: Tue, 18 Mar 2003 17:23:32 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>So that there is no misunderstanding, my opinion is that the static >>scheme is >>a MUST and any dynamic scheme is a qualified MAY. >> >> > >That is what the draft currently says. > We're in agreement here, but this is not what is at issue. Still at issue are the following points: 1) When the static MTU mechanism in 'mech-v2-00.txt' is used, the 1280+20 limitation seems too restrictive. Suggest changing to 1380+20. 2) When the dynamic MTU scheme in 'mech-v2-00.txt' is used, black holes and/or denial of service can result. Suggest considering the dynamic MTU schemes in 'draft-templin-isatap-pre13.txt'. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 18 20:24:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10773 for ; Tue, 18 Mar 2003 20:24:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vSLI-0002eE-00 for v6ops-data@psg.com; Tue, 18 Mar 2003 17:26:08 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18vSLF-0002e2-00 for v6ops@ops.ietf.org; Tue, 18 Mar 2003 17:26:05 -0800 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 RAA29047; Tue, 18 Mar 2003 17:26:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2J1Q4815296; Tue, 18 Mar 2003 17:26:04 -0800 X-mProtect: <200303190126> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.178, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdil0Sjj; Tue, 18 Mar 2003 17:26:02 PST Message-ID: <3E77C72A.60502@iprg.nokia.com> Date: Tue, 18 Mar 2003 17:26:02 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >To allow padding to be applied in the future the key thing for this >spec is to make it clear that the decapsulator must do the second check >above. I'll add that, but I don't think we need to say something specific >about the encapsulator adding padding. > Sounds reasonable. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 19 13:31:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29465 for ; Wed, 19 Mar 2003 13:31:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18viJ8-00033f-00 for v6ops-data@psg.com; Wed, 19 Mar 2003 10:28:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18viJ4-00033S-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 10:28:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18viJ4-0000cd-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 10:28:54 -0800 Message-ID: <20030319123412.GA80494@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: Wed, 19 Mar 2003 12:34:12 +0000 From: David Malone To: v6ops@psg.com Subject: New prefix lengths in router renumbering X-Spam-Status: No, hits=0.3 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I've been browsing the RFC 2894, in an attempt to understand router renumbering. The RFC describes how the bits in the new prefix are formed from the UsePrefix and the existing prefix by taking UseLen bits from the UsePrefix and then taking the corrisponding KeepLen bits from the existing prefix. However, it doesn't seem to be explicitly stated how to calculate the length of the newly formed prefix. There seem to be two obvious ways - first to use (UseLen+KeepLen) and the second to copy the length from the original prefix. My only hint as to which one is intended is this comment at the end of example 9.2, where UseLen = 64 and KeepLen = 0: Any temptation to set KeepLen = 64 in the second Use-Prefix Part above should be resisted, as it would instruct the router to sidestep address configuration. I'm guessing that if UseLen+KeepLen = 128, we get a prefix too long to be used in address configuration? So, my two questions are, how should the new prefix length be calculated and is my understanding of example 9.2 correct? David. From owner-v6ops@ops.ietf.org Wed Mar 19 16:08:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08257 for ; Wed, 19 Mar 2003 16:08:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vknO-000FIh-00 for v6ops-data@psg.com; Wed, 19 Mar 2003 13:08:22 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18vknK-000FHr-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 13:08:18 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25306; Wed, 19 Mar 2003 10:29:04 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JHT1K09067; Wed, 19 Mar 2003 18:29:02 +0100 (MET) Date: Wed, 19 Mar 2003 18:25:01 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt To: Margaret Wasserman Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the late comment. Major comment: Section 4 says at the end of the first paragraph "simple and easy". I think we should replace this with "secure and robust" or add all the motherhood and apple pie. My point is that by only including two motherhood words and not others an attempt to use this document to evaluate potential solutions might be slanted towards "easy" instead of "good". I suspect the WG needs to discuss this aspect of the spec. Section 3 makes a, in my opinion artificial, distinction between "p2p" and "server" and then goes on to conclude that server is out of scope due to the difficulty with DNS updates. This distinction seems a bit artificial since the p2p aspect (that the same nodes both initiate and respond to traffic) doesn't preclude that DNS is used. So I'd think the document should capture that DNS updates might have issues when the network is unmanaged that is independent of the types of applications in section 3. Minor things: Per the rfc-editor the abstract and introduction should not be identical. Section 2: I'm assuming (but the document isn't clear) that if somebody figures out how to autoconfigure a set of routers ("zerouter") that a network with multiple links would be in scope. Or is the intent that such networks always be out of scope? It would be good to make this clear. Section 3.2: Is outbound SIP calls an example of a client application? The reason I think it makes sense to make this explicit is because the current examples are those that trivially work across a NAT box and if this is the definition of "client application" it would make sense to make it clear, and if the definiting is something different (an entity that initiates communication) it would make sense to make that clear. Section 4.1 says: The security of local applications is enhanced if these applications can be effectively isolated from the global Internet. Seems orthogonal to this document and a distraction. Section 5.1.2 says "have to involve tunneling over UDP" but in general using PPP over TCP works over NAT as well. If you are trying to capture some specific requirement that excludes PPP/TCP that needs to be explicit (and I suspect some folks will disagree with such a requirement). Section 5.2.3 talks about There must be a way to resolve the name of local hosts to their IPv4 or IPv6 addresses. Why isn't this a requirement in section 5.1.3 as well? Section 6 says: - the guarantee that local applications are only used locally, I fail to see what this has to do with the coexistence between IPv4 and IPv6. *If* there is such a requirement wouldn't that requirement exist today in IPv4 and wouldn't it exist in IPv6 even after IPv4 goes away? If this is the case I don't think the requirement belongs in this document but in a document for "requirements on home networks" or something like that. Erik From owner-v6ops@ops.ietf.org Wed Mar 19 20:08:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19041 for ; Wed, 19 Mar 2003 20:08:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18voYN-0002RV-00 for v6ops-data@psg.com; Wed, 19 Mar 2003 17:09:07 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18voYH-0002QG-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 17:09:01 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h2K18Xu46099 for ; Wed, 19 Mar 2003 20:08:33 -0500 (EST) Date: Wed, 19 Mar 2003 20:07:59 -0500 From: Marc Blanchet To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <347250000.1048122479@classic.viagenie.qc.ca> In-Reply-To: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> References: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-v6ops-unman-scenarios-00.txt says: 5.3 Case C, IPv6 connectivity without provider support ... 5.3.2 Addresses and connectivity in Case C The upgraded gateway will behave as an IPv6 router; not the only way to do it. one host inside the internal network could be the v6 router. Text should be fixed. it will continue providing the IPv4 connectivity of non-upgraded NAT. Nodes in the local network will obtain: - IPv4 natted addresses, - IPv6 link local addresses, - IPv6 global addresses. The clients could also obtain IPv6 site local addresses, if the gateway advertises a site local prefix; this raises the same issues already discussed in case B. There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels provided by the [6TO4] technology, or configured tunnels. not the only ways. Both technologies have advantages and limitations, which will be studied in a companion document. additional comment: I've not found text that clearly states that prefix delegation is required. Marc. From owner-v6ops@ops.ietf.org Wed Mar 19 20:54:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20606 for ; Wed, 19 Mar 2003 20:54:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vpI1-0004ad-00 for v6ops-data@psg.com; Wed, 19 Mar 2003 17:56:17 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 18vpHn-0004ZZ-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 17:56:04 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Wed, 19 Mar 2003 17:56:03 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Mar 2003 17:56:03 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Mar 2003 17:55:54 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Mar 2003 17:55:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Mar 2003 17:56:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Operational experience with 3 degrees Date: Wed, 19 Mar 2003 17:55:55 -0800 Message-ID: Thread-Topic: Operational experience with 3 degrees Thread-Index: AcLnQddVmKV3KbBGRLygmAfUqlceqgHQXyRM From: "Christian Huitema" To: "Bob Fink" , X-OriginalArrivalTime: 20 Mar 2003 01:56:19.0747 (UTC) FILETIME=[E6A49F30:01C2EE83] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA20606 Bob, Due to timing, I could not present the scheduled paper "Operational experience with Microsoft IPv6 based P2P application ("threedegrees") - Huitema, 10 mins". So I guess I will instead send a short abstract of my presentation in this message. Here it is. On 2/26/03 we started the beta trial of "three degrees" (http://www.threedegrees.com ), a P2P IPv6 based application. ThreeDegrees allows users to organized in Small groups of peers, exchange IM, photos and winks, i.e. on screen animations, as well as jointly listen to music. There have been several thousand download of the beta. The peer to peer exchanges are performed only over IPv6; in places where native connectivity is not available, the hosts use either 6to4 if they have a global IPv4 address, or Teredo if they don't. This deployment is in effect the first beta trial of the Teredo technology; Microsoft is providing a Teredo server for use by the Three Degrees hosts. The short summary is that "it works", and that many of the early users are very happy. IPv6 is just "instantly deployed", validating the use of 6to4 and Teredo. The quality of the service, be it RTT or bandwidth, is adequate. But there are issues: some web servers became unreachable, some native IPv6 labs complained that they could not use the application, users behind symmetric NAT were left out, and there is a lack of Teredo relays. After downloading and installing the beta, some users found themselves without access to a few of their favorite web sites; there were wild speculations that Microsoft had somehow disabled access to the sites. Well, Microsoft indeed did not do anything like that; the disabling of some web sites was a side effect of enabling IPv6. The version of Internet Explorer on Windows XP is IPv6 enabled. If IPv6 enabled on machine, IE will call "getaddrinfo" which in conformance with the IETF recommendation will look for AAAA record for the web site, and then look for an A record if there is no AAAA available. The problem is that, upon receiving a query for a AAAA record, some DNS servers returned a "no such domain" error, upon which getaddrinfo gave up. The issue affects about 20 of the top 500 web sites. We are glad that we found it during a limited size beta rather than during a wide scale deployment. We are working with the vendors of the affected DNS products and are confident that the bug will soon be fixed. The second issue affected some native IPv6 networks, typically test laboratories in which a tester would load the three degrees application, and then complain that "it does not work in my IPv6 lab". The symptom was that the application will refuse to start, because it could not initialize the P2P software. This initialization requires that the host contacts the P2P "seed server", in order to obtain the address of a few other peers and connect to the peer-to-peer "cloud". The "seed server" is located at a 6to4 address, and is unreachable if UDP traffic is blocked by an IPv6 firewall, or in absence of a route to 2002:/16. The problem can be fixed by loosening firewall rules, and by making sure that the native IPv6 network has good connectivity with 6to4 nodes. The third issue was not really a surprise. In our deployment, the only way for users located behind NAT to get IPv6 connectivity is to use Teredo, and Teredo only works through about 90% of the NAT available on the market; the others are "symmetric" NAT. Since users buying NATs have no clue whether their NAT is symmetric or not, this results in complaints such as "the application does not work behind a NAT of brand X". After the feedback from the beta, we better know the size of the problem, and we are making sure that several solutions will be available, to be used as appropriate. The Teredo software will be updated to automatically reserve a UDP port using the UPNP protocol when the NAT support this protocol, or to use a user assigned port when the user is able to open a port in the NAT using a management interface. If that fails, the user will in some cases be able to get a new firmware for the existing NAT, without having to buy a new NAT. Indeed, another solution would be to have generous third parties provide tunnel servers... The fourth issue concerns the lack of Teredo relays. In our early deployment, Microsoft only runs a Teredo server, and each peer tries to run a "host specific" Teredo relay - a piece of software that intercept traffic bound to Teredo addresses and send it over UDP. However, a peer located behind symmetric NAT or firewall does not have enough IPv4 connectivity to properly run a Teredo relay, which results in connection failures in the P2P application. The solution is obviously to deploy a Teredo relay in the site exit routers of the peer sites, or possibly in the ISP networks. Teredo relays are even simpler to implement than Teredo clients or servers, and can incorporate a number of "stateful" traffic control features that make them resistant to attacks. To facilitate this deployment, we should provide a very short Teredo relay specification. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Mar 20 02:09:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07359 for ; Thu, 20 Mar 2003 02:09:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vuBA-000MD0-00 for v6ops-data@psg.com; Wed, 19 Mar 2003 23:09:32 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18vuB6-000MCn-00 for v6ops@ops.ietf.org; Wed, 19 Mar 2003 23:09:28 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06130 for ; Thu, 20 Mar 2003 00:09:27 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HC100LRQD7R13@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 20 Mar 2003 00:09:27 -0700 (MST) Received: from sun.com ([130.129.135.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HC100EPBD7P2A@mail.sun.net> for v6ops@ops.ietf.org; Thu, 20 Mar 2003 00:09:27 -0700 (MST) Date: Wed, 19 Mar 2003 23:09:25 -0800 From: Alain Durand Subject: IPv6 operational issues To: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I could not present this issue this morning, as the meeting was running out of time. We probably collectively (wg chairs, IAB members, wg group participants, myself) need to do a better job at time keeping. IMHO, saving meeting time for discussing operational issues is important. That said, here is a link to my slides: http://playground.sun.com/ipv6/IPv6ONbyDefault.pdf The bottom line is that while deploying IPv6 internally, we have identified 2 cases that are problematic: 1- a node with v6 enable (on by default) in a v4 RFC1918 network with no v6 connectivity. With current Neighbor Discovery 'on-link' assumption, current destination address selection rules and current stub resolver behavior, this can lead to unacceptable delays before connections succeed. A fix is necessary in at least one of the 3 items described above. 2- a dual stack node in a foreign v4/v6 network connecting to a v4/v6 enterprise network via a v4 only VPN. a) there are some serious security issues with this model. b) TCP SYN time-outs induce unacceptable delays. This can be fixed operationally, either by getting a v6 aware VPN or turning IPv4 off before firing up the v4 VPN. - Alain. From owner-v6ops@ops.ietf.org Thu Mar 20 11:35:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23863 for ; Thu, 20 Mar 2003 11:35:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w30x-0001ZK-00 for v6ops-data@psg.com; Thu, 20 Mar 2003 08:35:35 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18w30s-0001YP-00 for v6ops@ops.ietf.org; Thu, 20 Mar 2003 08:35:30 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2KGZJ900551; Thu, 20 Mar 2003 18:35:19 +0200 Date: Thu, 20 Mar 2003 18:35:19 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Bob Fink , Subject: Re: Operational experience with 3 degrees In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Commeting on the last issues. On Wed, 19 Mar 2003, Christian Huitema wrote: > The third issue was not really a surprise. In our deployment, the only > way for users located behind NAT to get IPv6 connectivity is to use > Teredo, and Teredo only works through about 90% of the NAT available on > the market; the others are "symmetric" NAT. Since users buying NATs have > no clue whether their NAT is symmetric or not, this results in > complaints such as "the application does not work behind a NAT of brand > X". After the feedback from the beta, we better know the size of the > problem, and we are making sure that several solutions will be > available, to be used as appropriate. This has been one of my objections to Teredo: even if it works on more or less 90% of NAT boxes, and fails on the rest, the 10% is still a large amount of appliances, and.. > The Teredo software will be > updated to automatically reserve a UDP port using the UPNP protocol when > the NAT support this protocol, or to use a user assigned port when the > user is able to open a port in the NAT using a management interface. If > that fails, the user will in some cases be able to get a new firmware > for the existing NAT, without having to buy a new NAT. .. such firmware would *actually* make the NAT more insecure. You can implement NAT's in "loose" or "strict" mode. What you're advocating is turning relatively secure NAT's to insecure ones. (Btrw, I don't find it realistic to assume NAT's which have this issue will support UPNP, but YMMV.) > Indeed, another > solution would be to have generous third parties provide tunnel > servers... This seems similar to 6to4 relays; they are not there in abundance, and there seems to be little sign the trend will change any time soon. What Teredo is doing is splitting the IPv6 address space in two: those who can use it, can communicate bidirectionally relatively nicely. But the connectivity to the rest of the Internet is a pain. That doesn't look me to as a desirable approach. > The solution is obviously to deploy a > Teredo relay in the site exit routers of the peer sites, or possibly in > the ISP networks. Teredo relays are even simpler to implement than > Teredo clients or servers, and can incorporate a number of "stateful" > traffic control features that make them resistant to attacks. To > facilitate this deployment, we should provide a very short Teredo relay > specification. I have doubts about this actually happening. Believe me, it's not about the code size. 6to4 relay implementation is less than 10 lines of code at th minimum. Code size is a factor for those who implement it (and consequently those who want to deploy it), but *not* those who don't intend to. To avoid fragmentation of IPv6 Internet and keeping things simple and working for all NAT users, I'm strongly favoring "bidirectional tunneling through NAT" approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Mar 20 17:26:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10353 for ; Thu, 20 Mar 2003 17:26:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w8RX-0001ho-00 for v6ops-data@psg.com; Thu, 20 Mar 2003 14:23:23 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18w8RV-0001hc-00 for v6ops@ops.ietf.org; Thu, 20 Mar 2003 14:23:21 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24569; Thu, 20 Mar 2003 15:23:15 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2KMNCK29783; Thu, 20 Mar 2003 23:23:13 +0100 (MET) Date: Thu, 20 Mar 2003 23:19:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Operational experience with 3 degrees To: Christian Huitema Cc: Bob Fink , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for sharing this information. > If IPv6 enabled on machine, IE will call "getaddrinfo" which in conformance > with the IETF recommendation will look for AAAA record for the web site, and > then look for an A record if there is no AAAA available. The problem is > that, upon receiving a query for a AAAA record, some DNS servers returned a > "no such domain" error, upon which getaddrinfo gave up. The issue affects > about 20 of the top 500 web sites. We are glad that we found it during a > limited size beta rather than during a wide scale deployment. We are working > with the vendors of the affected DNS products and are confident that the bug > will soon be fixed. Is this caused by load balancing boxes? This is an issue for IPv6 deployment in general and not specific to Teredo. If it would be useful to have a document to point the vendors to, perhaps we can arm-twist somebody to write a short document (could be done in dnsop or by a willing individual I think?) Erik From owner-v6ops@ops.ietf.org Thu Mar 20 17:53:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11484 for ; Thu, 20 Mar 2003 17:53:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w8vy-0002im-00 for v6ops-data@psg.com; Thu, 20 Mar 2003 14:54:50 -0800 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18w8vu-0002i3-00 for v6ops@ops.ietf.org; Thu, 20 Mar 2003 14:54:46 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 445BE89DE; Thu, 20 Mar 2003 23:54:40 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id EFEAB898A; Thu, 20 Mar 2003 23:54:30 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Christian Huitema'" Cc: "'Bob Fink'" , Subject: RE: Operational experience with 3 degrees Date: Thu, 20 Mar 2003 23:55:28 +0100 Organization: Unfix Message-ID: <002201c2ef33$cdbf44b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Thanks for sharing this information. > The problem is > > that, upon receiving a query for a AAAA record, some DNS > > servers returned a "no such domain" error, upon which > > getaddrinfo gave up. The issue affects about 20 of the > > top 500 web sites. We are glad that we found it during a > > limited size beta rather than during a wide scale deployment. > > We are working with the vendors of the affected DNS products > > and are confident that the bug will soon be fixed. > > Is this caused by load balancing boxes? > This is an issue for IPv6 deployment in general and not specific > to Teredo. If it would be useful > to have a document to point the vendors to, perhaps we can > arm-twist somebody > to write a short document (could be done in dnsop or by a > willing individual I think?) There was something related, or most probably the same problem last year with the resolvers running on the bbc.co.uk domain and some others, check here: http://www.cctec.com/maillists/nanog/historical/0204/msg00559.html "incorrect NXDOMAIN response from DNS server" For the over 2 years now that I have been using an IPv6 enabled IE I haven't come across that problem much times though, at least not that I have noticed. But then again I am probably not a typical top500 website crawler :) Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Mar 20 18:08:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12571 for ; Thu, 20 Mar 2003 18:08:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w9AP-0003C5-00 for v6ops-data@psg.com; Thu, 20 Mar 2003 15:09:45 -0800 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18w9AM-0003Br-00 for v6ops@ops.ietf.org; Thu, 20 Mar 2003 15:09:43 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D568489DC; Fri, 21 Mar 2003 00:09:39 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1917D89DE; Fri, 21 Mar 2003 00:09:26 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Christian Huitema'" Cc: "'Bob Fink'" , Subject: RE: Operational experience with 3 degrees Date: Fri, 21 Mar 2003 00:10:24 +0100 Organization: Unfix Message-ID: <003201c2ef35$e3cdb690$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12571 Pekka Savola wrote: > Commeting on the last issues. > > On Wed, 19 Mar 2003, Christian Huitema wrote: > > The third issue was not really a surprise. In our deployment, the only > > way for users located behind NAT to get IPv6 connectivity is to use > > Teredo, and Teredo only works through about 90% of the NAT available on > > the market; the others are "symmetric" NAT. Since users buying NATs have > > no clue whether their NAT is symmetric or not, this results in > > complaints such as "the application does not work behind a NAT of brand > > X". After the feedback from the beta, we better know the size of the > > problem, and we are making sure that several solutions will be > > available, to be used as appropriate. > > This has been one of my objections to Teredo: even if it > works on more or less 90% of NAT boxes, and fails on the rest, > the 10% is still a large amount of appliances, and.. Can someone enlighten me with the reasons why there is no defacto IPv6-over-IPv4-TCP standard. Or is it too common to use a tinc/vtund tunnel to establish those connections. I have been thinking about implementing such a scheme for tunneling to the SixXS systems. Thus allowing connections to be made from behind most firewalls especially if we combinate it with the fact that we could use port 143 to connect to, or even better use a real ssl tunnel or httpproxy to get across it. In most ways I think that a TCP connection has more chance of crossing in&out a NAT and even a firewall than any UDP packet. Ofcourse the big 'disadvantage' here is that it requires configured tunnels. PS: I've even take some of my spare time to fix myself up with a /dev/tun for Win2k/XP which acts like a network card, using a small netcat alike tool it simply acts like a native IPv6 link, without IPv4 over it :) Though it is experimental and really needs to be implemented correctly using tinc/vtund or a similar tool. (And yes I was annoyed by the fact that I couldn't do IPv6 from behind some firewalled places. And as I have some handy boxes that are only accessible over v6 I do find it quite handy to be able to access them from everywhere ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Sat Mar 22 21:38:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11145 for ; Sat, 22 Mar 2003 21:38:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wvLv-0008We-00 for v6ops-data@psg.com; Sat, 22 Mar 2003 18:36:51 -0800 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18wvLs-0008WR-00 for v6ops@ops.ietf.org; Sat, 22 Mar 2003 18:36:48 -0800 Received: from localhost (unknown [3ffe:501:4819:2000:28a6:eb6f:6041:b6dd]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CB0E715214; Sun, 23 Mar 2003 11:37:18 +0900 (JST) Date: Sun, 23 Mar 2003 11:37:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Christian Huitema , Bob Fink , v6ops@ops.ietf.org Subject: Re: Operational experience with 3 degrees In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 42 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT version=2.44 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Thu, 20 Mar 2003 23:19:10 +0100 (CET), >>>>> Erik Nordmark said: >> If IPv6 enabled on machine, IE will call "getaddrinfo" which in conformance >> with the IETF recommendation will look for AAAA record for the web site, and >> then look for an A record if there is no AAAA available. The problem is >> that, upon receiving a query for a AAAA record, some DNS servers returned a >> "no such domain" error, upon which getaddrinfo gave up. The issue affects >> about 20 of the top 500 web sites. We are glad that we found it during a >> limited size beta rather than during a wide scale deployment. We are working >> with the vendors of the affected DNS products and are confident that the bug >> will soon be fixed. > Is this caused by load balancing boxes? > This is an issue for IPv6 deployment in general and not specific > to Teredo. If it would be useful > to have a document to point the vendors to, perhaps we can arm-twist somebody > to write a short document (could be done in dnsop or by a > willing individual I think?) I agree. As far as I know, there are several "broken" DNS servers (or load balancers) wrt AAAA queries: - some of them return NXDOMAIN against AAAA (as reported in this thread). - some ignore AAAA queries (causing a delay to fallback). you can see this when you try to resolve AAAA for "ftp.mozilla.org" at 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) - some return broken answers for AAAA queries. Some resolvers handle such cases as "server fail," and will not use the servers). you can see this by asking an AAAA RR for "www.gslb.mainichi.co.jp" at 210.173.172.2. - some constantly indicates a (loop) delegation for any queries except A. Resolvers interpret this as a lame delegation. You can see this by asking AAAA for "www.united.com" at 64.95.89.4. I guess there may be a comprehensive document already, but I myself don't know one. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Mar 24 05:28:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09584 for ; Mon, 24 Mar 2003 05:28:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xP9r-000KWQ-00 for v6ops-data@psg.com; Mon, 24 Mar 2003 02:26:23 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18xP9K-000KQG-00 for v6ops@ops.ietf.org; Mon, 24 Mar 2003 02:25:50 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26541; Mon, 24 Mar 2003 03:25:26 -0700 (MST) 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 h2OAPPK13307; Mon, 24 Mar 2003 11:25:25 +0100 (MET) Date: Mon, 24 Mar 2003 11:21:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Operational experience with 3 degrees To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Christian Huitema , Bob Fink , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Clarifying question: > - some ignore AAAA queries (causing a delay to fallback). > you can see this when you try to resolve AAAA for "ftp.mozilla.org" > at 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) And those boxes do not ignore A queries for the same name? The reason I'm asking is because I think there are DNS servers which silently ignore queries for names that they don't have any information (instead of sending a referral). If they treat A and AAAA differently that would be news to me. > I guess there may be a comprehensive document already, but I myself > don't know one. It seems useful to take your list (and other issues folks report) and put in an I-D as a starting point. Erik From owner-v6ops@ops.ietf.org Wed Mar 26 11:16:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02342 for ; Wed, 26 Mar 2003 11:16:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yDWL-000Nbf-00 for v6ops-data@psg.com; Wed, 26 Mar 2003 08:12:57 -0800 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18yDWJ-000NbS-00 for v6ops@ops.ietf.org; Wed, 26 Mar 2003 08:12:55 -0800 Received: from localhost (PPP120.air128.dti.ne.jp [210.170.212.132]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A4B2C15214; Thu, 27 Mar 2003 01:12:47 +0900 (JST) Date: Thu, 27 Mar 2003 01:13:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: v6ops@ops.ietf.org Subject: Re: Operational experience with 3 degrees In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 65 X-Spam-Status: No, hits=-24.8 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_NJABL, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Mon, 24 Mar 2003 11:21:24 +0100 (CET), >>>>> Erik Nordmark said: >> I guess there may be a comprehensive document already, but I myself >> don't know one. > It seems useful to take your list (and other issues folks report) > and put in an I-D as a starting point. (I'll first answer the second point) okay, if no one else has a comprehensive list, I'll try to make one. (I'm not sure if an I-D is the best place to describe this kind of topic, but an I-D is probably not a bad one.) BTW: we may need to raise this issue in a place where DNS experts are. Perhaps dnsop? >> - some ignore AAAA queries (causing a delay to fallback). >> you can see this when you try to resolve AAAA for "ftp.mozilla.org" >> at 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) > And those boxes do not ignore A queries for the same name? No. The boxes only ignore AAAA (actually non-A) queries, but process A queries correctly. > The reason I'm asking is because I think there are DNS servers which > silently ignore queries for names that they don't have any information > (instead of sending a referral). > If they treat A and AAAA differently that would be news to me. The following is a more detailed description. If you try to resolve an RR for ftp.mozilla.org, you'll follow a CNAME chain and will eventually see the name is in fact an alias for ftp-mozilla.gftp-mozilla.netscape.com. Also, you'll see 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) is an NS for the gftp-mozilla.netscape.com zone. Now we're ready to do some experiments. The server answers a query for an A RR: % dig a +norec +short @64.12.182.70 ftp-mozilla.gftp-mozilla.netscape.com. 64.12.168.243 but (apparently) ignore a query for a AAAA RR: % dig aaaa +norec +short @64.12.182.70 ftp-mozilla.gftp-mozilla.netscape.com. ;; connection timed out; no servers could be reached or for an MX RR: % dig mx +norec +short @64.12.182.70 ftp-mozilla.gftp-mozilla.netscape.com. ;; connection timed out; no servers could be reached or for an A6 RR: % dig a6 +norec +short @64.12.182.70 ftp-mozilla.gftp-mozilla.netscape.com. ;; connection timed out; no servers could be reached JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Wed Mar 26 13:59:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07398 for ; Wed, 26 Mar 2003 13:59:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yG6v-0007CM-00 for v6ops-data@psg.com; Wed, 26 Mar 2003 10:58:53 -0800 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18yG6s-0007By-00 for v6ops@ops.ietf.org; Wed, 26 Mar 2003 10:58:50 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 615138376; Wed, 26 Mar 2003 19:58:42 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 805088FA1; Wed, 26 Mar 2003 19:58:30 +0100 (CET) From: "Jeroen Massar" To: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" Cc: Subject: RE: Operational experience with 3 degrees Date: Wed, 26 Mar 2003 19:59:33 +0100 Organization: Unfix Message-ID: <00da01c2f3c9$d79d6df0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07398 JINMEI Tatuya wrote: > BTW: we may need to raise this issue in a place where DNS experts are. > Perhaps dnsop? That might be quite a good place indeed as it is mostly DNS orientated. Subject change would be nice too :) > >> - some ignore AAAA queries (causing a delay to fallback). > >> you can see this when you try to resolve AAAA for "ftp.mozilla.org" > >> at 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) > > > And those boxes do not ignore A queries for the same name? > > No. The boxes only ignore AAAA (actually non-A) queries, but process > A queries correctly. > > > The reason I'm asking is because I think there are DNS servers which > > silently ignore queries for names that they don't have any > information > > (instead of sending a referral). > > If they treat A and AAAA differently that would be news to me. > > The following is a more detailed description. > > If you try to resolve an RR for ftp.mozilla.org, you'll follow a CNAME > chain and will eventually see the name is in fact an alias for > ftp-mozilla.gftp-mozilla.netscape.com. From RFC2181: 8<----------------------------- 10.1. CNAME resource records The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. ----------------------------->8 I interpret this as "CNAME chains are not allowed" thus the above system should not work at all... apparently in some cases it works though. I wonder why this does work for A records ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Mar 26 23:05:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01591 for ; Wed, 26 Mar 2003 23:05:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yOdy-000MMu-00 for v6ops-data@psg.com; Wed, 26 Mar 2003 20:05:34 -0800 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18yOdu-000MMe-00 for v6ops@ops.ietf.org; Wed, 26 Mar 2003 20:05:30 -0800 Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A0F9715214; Thu, 27 Mar 2003 13:05:30 +0900 (JST) Date: Thu, 27 Mar 2003 13:06:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Jeroen Massar" Cc: Subject: Re: Operational experience with 3 degrees In-Reply-To: <00da01c2f3c9$d79d6df0$210d640a@unfix.org> References: <00da01c2f3c9$d79d6df0$210d640a@unfix.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 50 X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Wed, 26 Mar 2003 19:59:33 +0100, >>>>> "Jeroen Massar" said: >> >> - some ignore AAAA queries (causing a delay to fallback). >> >> you can see this when you try to resolve AAAA for "ftp.mozilla.org" >> >> at 64.12.182.70 (gdns-02-ftp-dom.ns.aol.com) (snip) >> If you try to resolve an RR for ftp.mozilla.org, you'll follow a CNAME >> chain and will eventually see the name is in fact an alias for >> ftp-mozilla.gftp-mozilla.netscape.com. > >> From RFC2181: > 8<----------------------------- > 10.1. CNAME resource records > The DNS CNAME ("canonical name") record exists to provide the > canonical name associated with an alias name. There may be only one > such canonical name for any one alias. -----------------------------> 8 > I interpret this as "CNAME chains are not allowed" thus the above > system should not work at all... apparently in some cases it works > though. First of all, "CNAME chains" are not the essential part of this problem. The point is that we cannot resolve a non-A RR for gftp-mozilla.netscape.com zone at 64.12.182.70, to which CNAMEs are not related at all. Secondly, Section 10.1 of RFC 2181 talks about so-called "multiple CNAMEs", which is a different notion from what I called "a CNAME chain". Multiple CNAMEs are multiple different CNAMEs for a single domain name in a single zone, like: www.jinmei.org. IN CNAME www1.jinmei.org. www.jinmei.org. IN CNAME www2.jinmei.org. While I used the word a "CNAME chain" like this: foo.jinmei.org. IN CNAME bar.jinmei.org. bar.jinmei.org. IN CNAME baz.jinmei.org. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Thu Mar 27 06:52:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23995 for ; Thu, 27 Mar 2003 06:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yVwC-000Gvz-00 for v6ops-data@psg.com; Thu, 27 Mar 2003 03:52:52 -0800 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18yVwA-000Gvj-00 for v6ops@ops.ietf.org; Thu, 27 Mar 2003 03:52:50 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 721BA8991; Thu, 27 Mar 2003 12:52:44 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8AF628376; Thu, 27 Mar 2003 12:52:39 +0100 (CET) From: "Jeroen Massar" To: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" Cc: Subject: RE: Operational experience with 3 degrees Date: Thu, 27 Mar 2003 12:53:44 +0100 Organization: Unfix Message-ID: <002001c2f457$84dccc30$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23995 JINMEI Tatuya / _B [mailto:jinmei@isl.rdc.toshiba.co.jp] wrote: > >>>>> On Wed, 26 Mar 2003 19:59:33 +0100, > >>>>> "Jeroen Massar" said: > > First of all, "CNAME chains" are not the essential part of this > problem. The point is that we cannot resolve a non-A RR for > gftp-mozilla.netscape.com zone at 64.12.182.70, to which CNAMEs are > not related at all. > > Secondly, Section 10.1 of RFC 2181 talks about so-called "multiple > CNAMEs", which is a different notion from what I called "a CNAME > chain". Multiple CNAMEs are multiple different CNAMEs for a single > domain name in a single zone, like: That's indeed more logical than my interpretation ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Mar 27 10:29:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03320 for ; Thu, 27 Mar 2003 10:29:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yZLa-000IyA-00 for v6ops-data@psg.com; Thu, 27 Mar 2003 07:31:18 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18yZLX-000Ixq-00 for v6ops@ops.ietf.org; Thu, 27 Mar 2003 07:31:15 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22190; Thu, 27 Mar 2003 07:31:13 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2RFVCK00339; Thu, 27 Mar 2003 16:31:12 +0100 (MET) Date: Thu, 27 Mar 2003 16:27:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Operational experience with 3 degrees To: Jeroen Massar Cc: "=?iso-8859-1?Q?'JINMEI_Tatuya_/_=90_-=BE'B=8D=C6'?=" , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <00da01c2f3c9$d79d6df0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > From RFC2181: > 8<----------------------------- > 10.1. CNAME resource records > > The DNS CNAME ("canonical name") record exists to provide the > canonical name associated with an alias name. There may be only one > such canonical name for any one alias. > ----------------------------->8 > > I interpret this as "CNAME chains are not allowed" thus the above > system should not work at all... apparently in some cases it works > though. > I wonder why this does work for A records ;) My interpretation of the above text is that you can only have one CNAME record for a given name; not that there can not be chains. Erik From owner-v6ops@ops.ietf.org Thu Mar 27 10:29:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03338 for ; Thu, 27 Mar 2003 10:29:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yZJn-000IVA-00 for v6ops-data@psg.com; Thu, 27 Mar 2003 07:29:27 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18yZJj-000IUh-00 for v6ops@ops.ietf.org; Thu, 27 Mar 2003 07:29:23 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11525; Thu, 27 Mar 2003 08:29:22 -0700 (MST) 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 h2RFTLK00016; Thu, 27 Mar 2003 16:29:21 +0100 (MET) Date: Thu, 27 Mar 2003 16:25:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: DNS AAAA [was: Operational experience with 3 degrees] To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > (I'll first answer the second point) okay, if no one else has a > comprehensive list, I'll try to make one. (I'm not sure if an I-D is > the best place to describe this kind of topic, but an I-D is probably > not a bad one.) > > BTW: we may need to raise this issue in a place where DNS experts are. > Perhaps dnsop? Yes, once we have the list it would make sense to present it to dnsop. Your email is a good starting point but the issues might need to be fleshed out a bit more. If there is a need to produce a document pointing out existing bad practises we need to discuss where that can be best made - it definitely needs to be done with dns clue involved. Erik From owner-v6ops@ops.ietf.org Thu Mar 27 10:36:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03672 for ; Thu, 27 Mar 2003 10:36:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yZSA-000K0h-00 for v6ops-data@psg.com; Thu, 27 Mar 2003 07:38:06 -0800 Received: from web14805.mail.yahoo.com ([216.136.224.221]) by psg.com with smtp (Exim 3.36 #1) id 18yZS7-000K0T-00 for v6ops@ops.ietf.org; Thu, 27 Mar 2003 07:38:03 -0800 Message-ID: <20030327153802.43223.qmail@web14805.mail.yahoo.com> Received: from [65.213.193.49] by web14805.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:38:02 PST Date: Thu, 27 Mar 2003 07:38:02 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-812470475-1048779482=:42458" X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_20,HTML_10_20,RCVD_IN_OSIRUSOFT_COM version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-812470475-1048779482=:42458 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-812470475-1048779482=:42458 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-812470475-1048779482=:42458-- From owner-v6ops@ops.ietf.org Thu Mar 27 11:48:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07384 for ; Thu, 27 Mar 2003 11:48:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yaY2-0003hV-00 for v6ops-data@psg.com; Thu, 27 Mar 2003 08:48:14 -0800 Received: from proxy1.addr.com ([209.249.147.28]) by psg.com with esmtp (Exim 3.36 #1) id 18yaXy-0003eM-00 for v6ops@ops.ietf.org; Thu, 27 Mar 2003 08:48:10 -0800 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h2RGm7TQ074978 for ; Thu, 27 Mar 2003 08:48:09 -0800 (PST) Message-Id: <5.2.0.9.0.20030327084554.0202f4a8@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Mar 2003 08:48:06 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: first draft minutes of IETF-56 v6ops meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folk, First draft cut of v6ops minutes are available at: please let me knowof additions/corrections. Thanks, Bob From owner-v6ops@ops.ietf.org Sat Mar 29 07:24:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20173 for ; Sat, 29 Mar 2003 07:24:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zFLM-000Dsq-00 for v6ops-data@psg.com; Sat, 29 Mar 2003 04:21:52 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18zFLI-000Dse-00 for v6ops@ops.ietf.org; Sat, 29 Mar 2003 04:21:48 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Sat, 29 Mar 2003 13:20:29 +0100 Message-ID: <00c801c2f5ed$e02dd6f0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "ipv6cluster List Member" , , , , , <6bone@ISI.EDU>, , Subject: next Madrid 2003 Global IPv6 Summit Date: Sat, 29 Mar 2003 13:22:18 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C2F5F6.38D04B50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_20,HTML_20_30,OPPORTUNITY_2 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C2F5F6.38D04B50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, In case you still not noticed, the next major IPv6 Summit in Europe will = take place in Madrid (May 12-14th). This is the bigger European IPv6 = Forum event, and probably the bigger international one. You can't miss = it ! See http://www.ipv6-es.com; register now and take advantage of the early = registration offer. A lot of surprises will be discovered, including the Award Ceremony of = the IPv6 Appli-Contest 2003 (if you want to participate see = http://www.v6pc.jp/apc/en/index.html). Regards, Jordi Almost a hundred projects are demonstrating that IPv6 is working well. = The European Union=92s expectations regarding the new protocol, in order = to support its leadership as a future economic power, are becoming real. = The "Madrid 2003 Global IPv6 Summit" is the major European event of the = year where you can learn of the latest developments in IPv6 standards = and deployment.=20 For the third consecutive year we invite you to participate in this key = event about Internet developments. You have a unique opportunity to = discover more about the evolution of the Internet to deliver new = applications and services. ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.com ------=_NextPart_000_00C5_01C2F5F6.38D04B50 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

In case you still not = noticed, the=20 next major IPv6 Summit in Europe will take place in Madrid (May = 12-14th). This=20 is the bigger European IPv6 Forum event, and probably the bigger = international=20 one. You can't miss it !

See http://www.ipv6-es.com; register now = and take=20 advantage of the early registration offer.
 
A lot of surprises will be discovered, = including=20 the Award Ceremony of the IPv6 Appli-Contest 2003 (if you want to = participate=20 see http://www.v6pc.jp/apc/en/i= ndex.html).

Regards,
Jordi


Almost a = hundred projects=20 are demonstrating that IPv6 is working well. The European Union=92s = expectations=20 regarding the new protocol, in order to support its leadership as a = future=20 economic power, are becoming real. The "Madrid 2003 Global IPv6 Summit" = is the=20 major European event of the year where you can learn of the latest = developments=20 in IPv6 standards and deployment.

For the third consecutive year = we=20 invite you to participate in this key event about Internet developments. = You=20 have a unique opportunity to discover more about the evolution of the = Internet=20 to deliver new applications and services.

*****************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Register at:
http://www.ipv6-es.com ------=_NextPart_000_00C5_01C2F5F6.38D04B50-- From sylviepetit@skynet.be Mon Mar 31 11:30:08 2003 Received: from riker.skynet.be (riker.skynet.be [195.238.3.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13112 for ; Mon, 31 Mar 2003 11:30:05 -0500 (EST) Received: from Skoprvg (130.253-200-80.adsl-fix.skynet.be [80.200.253.130]) by riker.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with SMTP id h2VGW0Un014080 for ; Mon, 31 Mar 2003 18:32:00 +0200 (MET DST) (envelope-from ) Date: Mon, 31 Mar 2003 18:32:00 +0200 (MET DST) Message-Id: <200303311632.h2VGW0Un014080@riker.skynet.be> From: postmaster To: v6ops-archive@ietf.org Subject: Returned mail--"MS, Arial, Helvetica" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=L3G46d9cLY198qK82MV133O1J5J2Jv4093 --L3G46d9cLY198qK82MV133O1J5J2Jv4093 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable The following mail can't be sent to netmaster@Space.Net:

From: v6ops-archive@lists.ietf.org
To: netmaster@Space.Net
Subject: MS, Arial, Helvetica
The file is the original mail --L3G46d9cLY198qK82MV133O1J5J2Jv4093 Content-Type: application/octet-stream; name=Tei.exe Content-ID: Content-Transfer-Encoding: base64 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAHcbau4vLy8XAwCABIKAgASgBoC BtwsNh4ALDYeAFy4vhoAgBoCBtweBKyuXDAWOA4oAgCAABY03BgOOBRcFA4QHhqAGgIG3A4e ClwMAgASCgIAEoAaAgbcLgI2BhZcDAIAEgoCABKAGgIG3DQCBlwyHg4MHgASgBoCBoAMCtw2 FBhcMBY4DigCAIAAFjTcOg46XAwCABIKAgASgBoCBtw0HhgYFlwUDhAeGoAaAgbcGDY6DFww FjgOKAIAgAAWNNwGNgoeXDIYhggePB4AgBoCgAg83DQCCi4CXDIYhggePB4AgBoCgAg83EIQ NB4EBgI8HhoeFgYYNlw2AgSAGgIGgBg43BY6PBYaDhQOFjoWBFw2AgSAGgIGgBg43AYeOBoC OlwaEDQwgBoCBoAYONwaAgwCOlw2AgSAGgIGgBg43Eg2ODYYGgIAXDYCBIAaAgaAGDjcEA4a DBY4XBAOGgwWOIAaAgaAGDjcCDgCOh4eFDBcABY0OAIAgBoCBoAYONx0UHhWTnReelwQEjCA GDjcGAo4GgIAOjYENFw2AgSAGgIGgBg43BgKOFwYCjiGBAI8FjoGHhoMHhQCgBoCBoAYONw8 HjYEAhQOAB44NBZcNgIEgBoCBoAYONwGHjgaDgIQFgAOLFw2AgSAGgIGgBg43BgWBAQQNjg0 HhQCXAI8FgAEDgAKgBoCBoAYONwUAjgOOi4WMlwaLhgWODIeLoAaAgaAOhLcMhYYBh46NBY4 XB4MhgYWgBoCBtw6Njw8Ajg0XB4MhgYWgBoCBtxaAnoeQAI6dDheXDoKLgAWNIAYFtw6LgQw DhY8FjQONFw6Ci4AFjSAGBbcFB4wFh4AEhYEXDoyDgASgBgW3Bo4FjQCAFw6Ci4AFjSAGBbc EB68vq64vL5cOgouABY0gBgW3DwYFhYaCgYeAFw6Mg4AEoAYFtwMNhgWODRcFjY4FhIOAoAA FjTcEB68vra6tL5cOgouABY0gBgW3AYCACgeNDgeADpcOgouABY0gBgW3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3KhkfDgCEjgeBpxQDgQWOmReFB48NBYa ZHoMHjgWFGRWWlRanFYAEg4AFmQyBhg2OACABhY43IAEOA7cLAgE3B4EgAQUANzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3NwGPKzcgBYsFtyAOho43IA8DhDcgBgeNNzc3Nzc3Nzc3Nzc 3NyANCw03IAMNAbcgAw0BgTcgDIeGNyAHjo83IAUAhrcgDg0ENyALAQ63IAIPBLcgBo8PNyA GtyAPB463IAGPBLcgAY8FhLcgBgeCtyABjy63IA8FBDc3HoCEDQyHjgWZEYOGjgCOgIQNGRy DgAUAjI6ZFo2ODgWADRwFjg6DgIAZNxePDycfB40DDrceDYA3Hg2AEIAGhbcei46NBYGZFo2 ODgWADRaAgA0OAIEehY0ZHoWODAOGhY63HoCEDQyHjgWZEYOGjgCOgIQNGRyXlhkcl5YtGRy HhicUA4EFpxAHgYW3Hg2AHoWODAOGhY63E4ANBY4ABY0nHoWNDQOABI6ZFoeGgwWZHweNAw6 3Nzc3Nzc3NxMDoTcTBYEBAKE3HgWqNxQMqjcdgAUFgQOMBY4HhgEFpwGHg4EhoaYljqY3HgW NDY4ABYUnAYeDgSGhpiWOpjc3Nzc3B6cljqcljqcEh4GFtwenJY6nJY6nDQCAgTcHpyWOpyW OpwyFhg6DjQW3B6cljqcljqcPB40GgzcljqcOBYGAjAeBJw0AgIEOtzc3Nzc3NzcABYy3BA2 AAAu3AAOGhbcDDYGAjY43BYsGg40FtwSAgIU3DwCMhA2BNxyDgBsfNxOVpywgLzccrq4gFYE ChY4AJzccrq4gEoEFiiAVtzcDAIynB44FpwuAjbcBBY0kjqcGBacEDgOFgAUOtwUHjgEDgAS 3DoCnBoCAgScHpwQBB46DIQWAAgCLpwONNwuAjY4nDweOjoyAjgU3AwCABYu3DoCBhacPjYW OjQOAgA63DwEFh46Fpw0OC6cHhIeDgDcMhYEGgIGFpw0ApwGLpwMAgYWNAIyANw0DBacUh44 FBYAnAIQnFYUFgDcDgA0OAIUNho0DgIAnAIAnF5UekTcBhYWNA4AEpwAAjQOGhbcPjYWOjQO AgAAHg44FtwaAgASOB40NgQeNA4CADrcOgI6ntwIHjweABY6FpwSDjgEnHB6nDwEHi4YAi7c BAICCoQGLpwYFh42NA4QNgScEg44BJwQOA4WABTcFh4SFjicNAKcOhYWnC4CNtw6PA4aFpwS DjgEOpKcMAIaHgScGgIAGhY4NNwIHjweABY6FpwEHjo6kpw6FiwunDwOGjQ2OBY63Nzc3Hou Bh4ANBYa3EYaHhAWFtxQhnoWGjY4Ftx6AjwMAjrcdDgWABQGDho4AtxKHjo8Fjg6Ci7c3Nzc UDgCBqic3HQCqJzcejYYCBYaNKic3NzcdAwWnBACBAQCMg4AEpwGHg4EnBoeAJI0nBgWnDoW ADScNAKcljqo3HQMFpweNDQeGgwGFgA03HQMFpwQDgQW3JwOOpw0DBacAjgOEg4AHgScBh4O BNycEg4wFpwuAjacNAwWnJY63JwOOpwenJY6nBQeABIWOAI2OpwwDjg2Opw0DB40nJY63Boe AJwOABAWGjScAgCccg4ArqyCRhaCuLy8vIJsfIDcOjw4Fh4UnDQMOAI2EgycFgYeDgSA3DAW OC6c3Do8FhoOHgSc3Aw0NDyogoLcMjIygNyAGgIG3FACOJwGAjgWnA4AEAI4Bh40DgIAhDwE Fh46FpwwDjoONJzcdAwOOpwOOpzcTpyWOpwuAjacMgI2BBScljqcDjSA3BYACAIu3AQOChbc Mg46DNwMAjwW3BYsPBYaNNzcWgw4Djo0Bh463EAWMpwuFh443HoeDgA0nHAeBBYANA4AFpI6 nFQeLtxeBAQMHgQEAjIGHjrcXjw4DgScUAICBDqSnFQeLtxEHhQunFQeLtxeOjo2Bjw0DgIA 3FoeABQEFgYeOtxeBAScegI2BDqSVB4u3FY8DjwMHgAu3Nzc3NxMHjw8LpzcTB4wFpwenNzc pBg4oMbI3MbI3DwCOjQGHjo0Fjjc3NxyDgAK3NxOBh4SFnweNAzcRk5GVoZwFjg6DgIAqJy+ gLzGyFoCADQWADSGdC48FqicBjYENA48Hjg0gh4ENBY4AB40DjAWqsbIzhgCNgAUHjguptxa AgA0FgA0hnQuPBaonDQWLDSCDDQGBKrGyFoCADQWADSGdDgeADoQFjiGVgAaAhQOABKonD42 AjQWFIY8OA4ANB4YBBbGyMbIpEx0RkSgpExWXlSgpIJMVl5UoKRYQlRuoJY6xsikUEJAdKDc 3KSCUEJAdKCkglhCVG6gpIJMdEZEoNzc3FoCADQWADSGdC48FqicljqqxsjOAB4GFqaWOsbI WgIANBYANIZ0OB4AOhAWOIZWABoCFA4AEqicGB46FrC0xshaAgA0FgA0hk5UqJykljqg3Nzc 3Nzc3Nzc3B42FA4CgiyGMh4w3B42FA4CgiyGBg4UDtwePDwEDhoeNA4CAIICGjQWNIY6NDgW Hgbc3Nzc3Nzc3NzGyKQOEDgeBhacOjgaprpUGg4UqJY6nAwWDhIMNKa6VLycMg4UNAymulS8 oMbIpIIOEDgeBhag3HQMDjqcEh4GFpwOOpwGLpwQDjg6NJwyAjgKgKQYOKDGyG4CNpI4Fpw0 DBacEA44OjScPAQeLhY4gNxCTlp+3Hw4AhI4HgZQDgQWOlQOONzc3Nw6BjQ8gNxiXnB8urjc Yl5wfFpa3EBCVLq43EB8enpwWtxAeFZ6frq43EB6WkxWVLq43EB6WkxWVEB03EB6fER2Uk5A 3EBecNxAXnBefHpwWtxAXnBefHK6uNxAXnBEdrq43EBecHh2QHjcQF5wcrq43GJecHxG3F5E Vnh0enBa3F5GQkDcXnB8urjcXnB8WlrcXnB8RtxAurh6Wl5ActxAXnByQHTcXkB0TnBOeNxe cHx2fFTcXnBSWnR4RNxecHJOQK623HpaXkC6uNxwekxyTkC6uNxQhnp0Qnxy3FCGfHhCdK62 3F5aSnJOQLq43HBWdHR4Xm7ccFZ0rrbcenJWVnyuttx8WlpyTkCurNxOQkZCQK6s3F5wfHRa 3F5wVrq43F5wWkJAekJE3FB8hnJOQNxUcHyuttxQhl5SQHSuttxaRF5yrrbcQHBarrbcelpe QNxwTnh2etxEQlpKVEJyQLi8vLzcQAI4NAIA3EYaHhAWFtxeADQOMA443HReekpGUnjc3Nzc 3Nzc3Nzc3Nzc3Nzc3NzcXkB0ToZwTniAVF503FpMSkROenSAVF503FpMSkROenSARnrcWkxK RE56dIBafHrcWkxKRE56dIB0XnDcTnBYgEB0aNx6Rl54dFpMSoBGetx6Rl54dFpMSoBafHrc XnBSfnSAVF503F5Sdl54VIBUXnTc3Nzc3NzcegwEMh48DoAUBATcShY4ABYEuriAFAQE3AAW NB48Drq4gBQEBNw6EBqAFAQE3Nzc3Nx6DjgaHgbcQA4GFB7cWgIUFngWFNxyfkpGRrqssqzc UnhOVlC6rLKs3FA2AJxEAjAOABKcWjgOBg4AHgTcQAI4NAIA3EYaHhAWFtxeADQOMA443F4w GgIAOgIE3FCGenRCfHLcUIZ6Fho2OBbcegI8DAI63DAOODY63F5wfJxGAgAONAI43F5wfJx2 PBQeNBY63E4AAho2BB40Fk503HxahhoOBAQOANx6LgYeADQWGtx0OBYAFJxGDho4AtxQhnx4 QnTcnEBCVLq4nNzc3HgWEg46NBY4ehY4MA4aFnw4AhoWOjrcQBY0egweOBZeFBTcekxUFgQW NBZKFi5e3HoQGk46UA4EFnw4AjQWGjQWFNxAFjR6DB44FlIWNE4AEALcQBY0XjwOWDYQEBY4 UDgWFtzc3NzcVmx8REJ4VnjcWkZGUnjcBjoOBgDcDhoyGgIAANwyDgAoDjzc3Nzc3Hw4AhI4 HgbcljqcpJY6oNxeWFpUVlBSTE5ISkRGQEJ8fnh6dHZwcmxuaB4YGhQWEBIMDggKBAYAAjw+ ODo0NjAyLC4ovL64urS2sLKsroqC3DoWNDY83A4AOjQeBATcFBYGAtw6AAICPC7cPA4aHho2 3AoONDQu3DwEHi7cOAIaCtzc3Nzc3NzceB44nujS3EP9Otzcxtzc3Nzc3Nzc3IA4Hjjc3DIO AA4AFjSAFAQE3E4ANBY4ABY0UhY0WgIAABYaNBYUejQeNBbc3NxUDjgWGjQCOC7cFAQEGh4a DBbc3HoWVBYYNhJ8OA4wDgQWEhbcehZ0Ghh8OA4wDgQWEhbc3Nzc3Nzc3NwyGIYIHjweAIAa AoAIPNwwFjgOKAIAgAAWNNweOD42DjgWFIAWOtwUDhAeGoAaAgbc3HoCEDQyHjgWZEYOGjgC OgIQNGROADQWOAAWNJxeGhoCNgA0nEYeAB4SFjhkXhoaAjYANDpk3HpGdHycehY4MBY43HpG dHycVgYeDgScXhQUOBY6OtzccgI4BpxKBBYogFacDgYGNgAONC7c3EoEFiiAVpwOOpw0DBac BgI6NJwaAgYGAgCcMgI4BBSGMg4UFpw6PDgWHhQOABKcMgI4BoBONJI6nDAWOC6cFB4AEhY4 AjY6nBgunBoCODg2PDQOABKcLgI2OJwQDgQWOoCkGDigxshYFhoeNjoWnAIQnA40OpwwFjgu nDoGHjg0nDo0Fh4ENAycHgAUnB4ANA6GHgA0DoYwDjg2Opw0FhoMAA4ahAYCOjScGgIGBgIA nF5wnDoCEDQyHjgWnBoeAJI0nBQWNBYaNJwCOJwaBBYeAJwONICkGDigxshyFpwUFjAWBAI8 FhScNAwOOpwQOBYWnA4GBjYADjQunDQCAgScNAKcFBYQFh40nDQMFpwGHgQOGg4CNjqcMA44 NjqApBg4oMbIbgI2nAIABC6cABYWFJw0Apw4NgCcNAwOOpw0AgIEnAIAGhaEHgAUnDQMFgCc SgQWKJwyDgQEnAAWMBY4nBoCBhacDgA0ApwuAjY4nHxagKQYOKDGyEBCdFaonFgWGh42Ohac NAwOOpw0AgIEnB4aNDqcHjqcHpwQHgoWnEoEFiicNAKcEAICBJw0DBacOBYeBJwyAjgGhDoC BhacXnCcBgIADjQCOJwGHi4YFpwaOC6cMgwWAJwuAjacODYAnA40gKQYOKDGyE4QnDoChE4S AAI4Fpw0DBacMh44AA4AEoQeABScOhYEFho0nJIaAgA0DgA2FpKApBg4oMbIThCcLgI2nAwe MBacHgAunD42Fjo0DgIAhDwEFh46FpykHpwMOBYQprpUBh4OBDQCqJY6oAYeDgScNAKcBhak gh6ggNzc3Nzc3NzcxshyDgC6uJxKBBYonHC4gLy+nJCccg4AuricUAI4AjYsnHC+gLzGyFoC PC44DhIMNJy4vLy4hAYeFBacDgCcXjoOHsbIXhgCNjScSgQWKJxwuIC8vqjGyM6+hEYeDgCc Bg46Og4CAJwOOpw0Apw4FgQWHjoWnDQMFpwAFjKcGB4YLpx8VpwwDjg2OoRyDgC6uJxQAjgC NizGyM64hEACnDoOEgAOEA4aHgA0nBoMHgASFoBAApwYNhKcEA4sFhSAQAKcHgAunDweLgQC HhSAxsheGAI2NJxyDgC6uJxQAjgCNiycjDwEKJwKFhY8nDQMFpwAHgYWhDQMHgAsjsbIzr6E UDYEBJwaAgY8HjQOGAQWnHIOALq4nHxWnDAOODY6nAIAnHIOAK5sgrhKgkB0gmx8xsjOuIRy DjQMnDAWOC6cDgA0FjgWOjQOABKcEBYeNDY4FoBaDBYaCpwONJ7GyM66hEACnB4ALpw8Hi4E Ah4UgEACnB4ALpwCPDQOBg4oHjQOAgDGyM60hEACNJwYNhKcEDgWFoQYFhoeNjoWnAIQnB6c DDY4OC6cMgI4CoBAApwGAjgWnDQMHgCcNAw4FhacMhYWCjqcEDgCBpwMHjAOABKcOjYaDJwO FBYenDQCnB4aGgIGPAQOOgwOABKcGgIUDgASnB4AFJw0Fjo0DgASxsjcAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAaCwAgHgAAIABAAAAoAAAgAIAAAC4AACAAwAAAMABAIAEAAAA SAIAgAUAAACAAgCABgAAAEgEAIAJAAAAeAcAgAoAAACQBwCADAAAAMgHAIAOAAAA4AcAgBAA AABACACA8AAAAFgIAIAAAAAAAAAAAAQAAAAAAAMA5AUAAHgIAIDlBQAAkAgAgOgFAACoCACA AAAAAAAAAAAEAAAAAAABAAsAAADACACAAAAAAAAAAAAEAAAAAAAfAN4FAADYCACA3wUAAPAI AIDhBQAACAkAgNIHAAAgCQCA1AcAADgJAIDmBwAAUAkAgPIHAABoCQCA/wcAAIAJAIALCAAA mAkAgCoIAACwCQCATwgAAMgJAIBmCAAA4AkAgG0IAAD4CQCAcggAABAKAIB0CAAAKAoAgIII AABACgCAhQgAAFgKAICGCAAAcAoAgIcIAACICgCAjggAAKAKAICUCAAAuAoAgJ0IAADQCgCA oggAAOgKAICjCAAAAAsAgK0IAAAYCwCArggAADALAICyCAAASAsAgLMIAABgCwCAAQoAAHgL AIChDwAAkAsAgIwTAACoCwCAAAAAAAAAAAAEAAAAAAAPAAEAAADACwCAAgAAANgLAIADAAAA 8AsAgAQAAAAIDACABQAAACAMAIAGAAAAOAwAgAcAAABQDACACAAAAGgMAIAJAAAAgAwAgAoA AACYDACADAAAALAMAIANAAAAyAwAgA4AAADgDACADwAAAPgMAIAQAAAAEA0AgAAAAAAAAAAA BAAAAAAABQADCAAAKA0AgNYJAABADQCA2AkAAFgNAID/CQAAcA0AgLsLAACIDQCAAAAAAAAA AAAEAAAAAAA3AOwDAACgDQCA7QMAALgNAIDvAwAA0A0AgPUDAADoDQCA9gMAAAAOAID3AwAA GA4AgP0DAAAwDgCAAQQAAEgOAIADBAAAYA4AgAQEAAB4DgCAIgQAAJAOAIAsBAAAqA4AgDcE AADADgCA0QcAANgOAIDaBwAA8A4AgOQHAAAIDwCA6QcAACAPAIDwBwAAOA8AgPQHAABQDwCA 9QcAAGgPAID7BwAAgA8AgPwHAACYDwCA/QcAALAPAIAMCAAAyA8AgBAIAADgDwCAEggAAPgP AIAWCAAAEBAAgBcIAAAoEACAGAgAAEAQAIAfCAAAWBAAgCEIAABwEACAIggAAIgQAIB1CAAA oBAAgHcIAAC4EACAmQgAANAQAICeCAAA6BAAgKYIAAAAEQCAqwgAABgRAIDHCQAAMBEAgMkJ AABIEQCAywkAAGARAIDVCQAAeBEAgOcJAACQEQCA+gkAAKgRAID+CQAAwBEAgAAKAADYEQCA BgoAAPARAIAKCgAACBIAgAwKAAAgEgCADQoAADgSAIDxCwAAUBIAgIkTAABoEgCAihMAAIAS AICNEwAAmBIAgI4TAACwEgCAAAAAAAAAAAAEAAAAAABkAIQBAADIEgCAhQEAAOASAICGAQAA +BIAgIcBAAAQEwCAiAEAACgTAICJAQAAQBMAgIoBAABYEwCAjAEAAHATAICNAQAAiBMAgI4B AACgEwCAjwEAALgTAICQAQAA0BMAgJEBAADoEwCAkwEAAAAUAICUAQAAGBQAgJUBAAAwFACA lgEAAEgUAICXAQAAYBQAgJgBAAB4FACAmwEAAJAUAICcAQAAqBQAgJ0BAADAFACAngEAANgU AICfAQAA8BQAgKABAAAIFQCAoQEAACAVAICiAQAAOBUAgKMBAABQFQCApAEAAGgVAIClAQAA gBUAgKYBAACYFQCAqAEAALAVAICpAQAAyBUAgLYBAADgFQCAtwEAAPgVAIC4AQAAEBYAgLkB AAAoFgCAugEAAEAWAIC7AQAAWBYAgLwBAABwFgCAvQEAAIgWAIC+AQAAoBYAgL8BAAC4FgCA wAEAANAWAIDBAQAA6BYAgMIBAAAAFwCAwwEAABgXAIDEAQAAMBcAgMUBAABIFwCAxgEAAGAX AIDHAQAAeBcAgMgBAACQFwCAyQEAAKgXAIDKAQAAwBcAgMsBAADYFwCAzAEAAPAXAIDNAQAA CBgAgM4BAAAgGACAzwEAADgYAIDuAQAAUBgAgO8BAABoGACA9QEAAIAYAID2AQAAmBgAgPcB AACwGACA+AEAAMgYAID5AQAA4BgAgPoBAAD4GACA+wEAABAZAID8AQAAKBkAgP0BAABAGQCA /gEAAFgZAID/AQAAcBkAgAACAACIGQCAAQIAAKAZAIACAgAAuBkAgAMCAADQGQCABAIAAOgZ AIBSAgAAABoAgFMCAAAYGgCAVAIAADAaAIBVAgAASBoAgFYCAABgGgCAVwIAAHgaAIBlAgAA kBoAgGYCAACoGgCAZwIAAMAaAIBoAgAA2BoAgGkCAADwGgCAagIAAAgbAICwAgAAIBsAgLIC AAA4GwCAswIAAFAbAIBGAwAAaBsAgEcDAACAGwCATgMAAJgbAIBPAwAAsBsAgNwDAADIGwCA 3QMAAOAbAIDeAwAA+BsAgN8DAAAQHACAAAAAAAAAAAAEAAAAAAABAOMHAAAoHACAAAAAAAAA AAAEAAAABQAAAHwsAIBAHACApCwAgFgcAIDaLACAcBwAgP4sAICIHACALi0AgKAcAIAAAAAA AAAAAAQAAAAAAAEAEQQAALgcAIAAAAAAAAAAAAQAAAAAAAoA6QMAANAcAIDuAwAA6BwAgPsD AAAAHQCAOwQAABgdAIA8BAAAMB0AgNMHAABIHQCA+gcAAGAdAIAKCAAAeB0AgAsKAACQHQCA DAoAAKgdAIAAAAAAAAAAAAQAAAAAAAEAAQAAAMAdAIAAAAAAAAAAAAQAAAAAAAIAxwkAANgd AIAACgAA8B0AgAAAAAAAAAAABAAAAAAAAQAJBAAACB4AAAAAAAAAAAAABAAAAAAAAQAJBAAA GB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAKB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAOB4AAAAA AAAAAAAABAAAAAAAAQAJBAAASB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAWB4AAAAAAAAAAAAA BAAAAAAAAQANBAAAaB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAeB4AAAAAAAAAAAAABAAAAAAA AQAJBAAAiB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAmB4AAAAAAAAAAAAABAAAAAAAAQAJBAAA qB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAuB4AAAAAAAAAAAAABAAAAAAAAQAJBAAAyB4AAAAA AAAAAAAABAAAAAAAAQAJBAAA2B4AAAAAAAAAAAAABAAAAAAAAQAJBAAA6B4AAAAAAAAAAAAA BAAAAAAAAQAJBAAA+B4AAAAAAAAAAAAABAAAAAAAAQAJBAAACB8AAAAAAAAAAAAABAAAAAAA AQAJBAAAGB8AAAAAAAAAAAAABAAAAAAAAQAJBAAAKB8AAAAAAAAAAAAABAAAAAAAAQAJBAAA OB8AAAAAAAAAAAAABAAAAAAAAQAJBAAASB8AAAAAAAAAAAAABAAAAAAAAQAJBAAAWB8AAAAA AAAAAAAABAAAAAAAAQAJBAAAaB8AAAAAAAAAAAAABAAAAAAAAQAJBAAAeB8AAAAAAAAAAAAA BAAAAAAAAQAJBAAAiB8AAAAAAAAAAAAABAAAAAAAAQAJBAAAmB8AAAAAAAAAAAAABAAAAAAA AQAJBAAAqB8AAAAAAAAAAAAABAAAAAAAAQAJBAAAuB8AAAAAAAAAAAAABAAAAAAAAQAJBAAA yB8AAAAAAAAAAAAABAAAAAAAAQANBAAA2B8AAAAAAAAAAAAABAAAAAAAAQAJBAAA6B8AAAAA AAAAAAAABAAAAAAAAQAJBAAA+B8AAAAAAAAAAAAABAAAAAAAAQAJBAAACCAAAAAAAAAAAAAA BAAAAAAAAQAJBAAAGCAAAAAAAAAAAAAABAAAAAAAAQAJBAAAKCAAAAAAAAAAAAAABAAAAAAA AQAJBAAAOCAAAAAAAAAAAAAABAAAAAAAAQAJBAAASCAAAAAAAAAAAAAABAAAAAAAAQAJBAAA WCAAAAAAAAAAAAAABAAAAAAAAQAJBAAAaCAAAAAAAAAAAAAABAAAAAAAAQAJBAAAeCAAAAAA AAAAAAAABAAAAAAAAQAJBAAAiCAAAAAAAAAAAAAABAAAAAAAAQAJBAAAmCAAAAAAAAAAAAAA BAAAAAAAAQAJBAAAqCAAAAAAAAAAAAAABAAAAAAAAQAJBAAAuCAAAAAAAAAAAAAABAAAAAAA AQAJBAAAyCAAAAAAAAAAAAAABAAAAAAAAQAJBAAA2CAAAAAAAAAAAAAABAAAAAAAAQAJBAAA 6CAAAAAAAAAAAAAABAAAAAAAAQAJBAAA+CAAAAAAAAAAAAAABAAAAAAAAQAJBAAACCEAAAAA AAAAAAAABAAAAAAAAQAJBAAAGCEAAAAAAAAAAAAABAAAAAAAAQAJBAAAKCEAAAAAAAAAAAAA BAAAAAAAAQAJBAAAOCEAAAAAAAAAAAAABAAAAAAAAQAJBAAASCEAAAAAAAAAAAAABAAAAAAA AQAJBAAAWCEAAAAAAAAAAAAABAAAAAAAAQAJBAAAaCEAAAAAAAAAAAAABAAAAAAAAQAJBAAA eCEAAAAAAAAAAAAABAAAAAAAAQAJBAAAiCEAAAAAAAAAAAAABAAAAAAAAQAJBAAAmCEAAAAA AAAAAAAABAAAAAAAAQAJBAAAqCEAAAAAAAAAAAAABAAAAAAAAQAJBAAAuCEAAAAAAAAAAAAA BAAAAAAAAQAJBAAAyCEAAAAAAAAAAAAABAAAAAAAAQAJBAAA2CEAAAAAAAAAAAAABAAAAAAA AQAJBAAA6CEAAAAAAAAAAAAABAAAAAAAAQAJBAAA+CEAAAAAAAAAAAAABAAAAAAAAQAJBAAA CCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAGCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAKCIAAAAA AAAAAAAABAAAAAAAAQAJBAAAOCIAAAAAAAAAAAAABAAAAAAAAQAJBAAASCIAAAAAAAAAAAAA BAAAAAAAAQAJBAAAWCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAaCIAAAAAAAAAAAAABAAAAAAA AQAJBAAAeCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAiCIAAAAAAAAAAAAABAAAAAAAAQAJBAAA mCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAqCIAAAAAAAAAAAAABAAAAAAAAQAJBAAAuCIAAAAA AAAAAAAABAAAAAAAAQAJBAAAyCIAAAAAAAAAAAAABAAAAAAAAQAJBAAA2CIAAAAAAAAAAAAA BAAAAAAAAQAJBAAA6CIAAAAAAAAAAAAABAAAAAAAAQAJBAAA+CIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAD== --L3G46d9cLY198qK82MV133O1J5J2Jv4093 Content-Type: application/octet-stream; name=images[6].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CABtAI0DAREAAhEBAxEB/8QAHAABAAEFAQEAAAAAAAAAAAAAAAUBAgMEBgcI/8QAQBAAAQQB AQYDBQUGAgsAAAAAAQACAxEEBQYSITFBURMUIgdhcYGxIzJSkaEVFhczQnLB0iQ1Q1RidISS lNHw/8QAGgEBAAMBAQEAAAAAAAAAAAAAAAEDBAIFBv/EAC8RAQACAgECAwYGAgMAAAAAAAAB AgMRBBIxEyFBBQYyYXGxFCIzUVLBgaGR0fD/2gAMAwEAAhEDEQA/APf0BAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQaZyM4PePJNLAfSRMLdx7Vw4cUGRrnZAaHNLAAC8X1/Df1QbCAgICAgICA gICAgIKEbzSDfHsghHRZbnPjODk+Fe6Ky6FDqK4jkpQ2tLE4szw5Mbt3/aziQcz29wB+ahKS Qee+0Tb4aDH+ztN8DIzXC8gF1+CzhzHc/pzIIK0YMHiT+byhnzZvDj8vnKR2N2lxdo9Jjx3v p7aLfVRdRuj13hQsHn7xxNWTHbHbpssx5IyV6odHl4IfG0xBzntIABlLRVi+XPguFjaghbBE I2lxA/ESfqgyICAgICAgICAgICDhPantPreyugQ5mkRw7sknhTTPaXGKx6SBy6Hib6d1NY2r y2msbh5Z7OdvtRh29jk1jPlyIdRAx5XzPsNdfoIHIAE1w4U4rqY8lGPJPV5ve2a5p+ZlHAxs kSZTovEEYBB3L3d6+1qvcb02dM66vR4ZtzspmaBrDpWySTl9vinfxM7erXd3AcD3H5LTxeR0 T4OT4Z7K+Xx4y18fF5WjvH9oLQtak0LOjzMdxGM9wDwOJjdzFcfmOPEWLsWN+XF4sdM/FHaf 3eZiy+HPXHae/wAn0Vs5r0Ou6cyZr2GUNG+GngeHMe5eTMTE6l6tbRaNwmAQRYNg9QoSw5WH BmsDZ2FwabFOLSPmEERlYkzcvch0lssLa3ZfOFhNAVw+P0RDJiac3JDhlYD8bdrcrKLj15Ue HT/4IJWDHjxmFkQIBNm3E/VEsqAgICAg0n5GZjl7pMYSxiyDCbdXQUevRBlgz8XJNRTsc66L LpwPYg8RyP5II3arSHa9s/kaUI43MyhuPL/6BzDh7wQCFMItG40+SM3EydL1GfEyWmPIxpXR vA6Oaa4Kxgmsw930zWzqWyei7ZwAHO0x/l9QjjFb0fJwr5hw7bx7LPljpnqj0+z1eJbxKzjn 1+70HV8HT9pdGOPJ9tFK0Piki4lpqw5p5AqbVi0alzS9sdtw8o0z2Vanma/kRZhGLgscWzvD bE45gx9OPM/hPfkNWPlXjH037x2lmz8XHOTrx9p7w9D0fQMTZTE8pjS4pZED9pkOc59nqRdD j0ACqyXnJbqs6pjjHXpqlJdTmhmfE/KwGOa3eq3Ej4j8lw7bMEmoy7km9huhdxtu9fyQRGoE u1TLBJNPaBx5ehq+G94eZyMPM6cd5iNR2mfm38elbU3MN7Qif9IFkgFvAm+i9r3cz5c3Em2W 02nqnv5+kKeTWK31CZXvs4gtc9rBbnAfEoKghwBBBB6hBVAQUe7dY51E0LoCyUETk+RyIxJN jZDOJAd4DrafkLHPmiENrWRtBhQxZOPA1+n4hEzpGTuEr4g2nNexzedEkcTxaFEzK2sUmNb8 3kXtD2Y1DUNbxcrAw5cjKymCLIZG0uJewemUmqpzKPYUbpdx32y3idTGu/3TOy2y+r7GYla0 5j8PUnbsmFDKHFu6xzrcfu8QCKF3fuUXtG4j93eDFasTbfbzdHje2XZnFxosfH0vU44Y2hrG NiiAaByA9a1xwcumeedj357TON7U9BkgORksy8SCmFrpYrLi7eoU2/wkrJaOm80nvD0MOC+a lb443v8Apl/inseeepSf+LL/AJVC78DyP4g9qex1/wCs3j/ppf8AKh+B5H8fs3JtoIM/JA01 00nlXMMzWhzQQ7dcPj6b6LDyZyzmxxj7RP5vppTFOmu7evb/AJa02ZHNqGY8+i5BQPbcaPra +V94eFyM3M6sdJmNR2j6tPGyVimplfjai2ODLZD63Sboa5juN8jVdl6XsXBnw+zslZrMX3Ov Se0aVZrVtljz8kjoWuQZvmMIeOcjDLWzF7CeLhY4/Duve4s3nDWMnxajf10qyV1O47T2TJk7 MeT7hX1WhW5vO1mT96zpE2JFJijFimbvNt2+6bw+d1VHta56vz9PyWTSPC6/npP4+LFBI50e PHFYAtvMgcAulbYQEBAQamVhHJkDhlZEPADdjcAOBvtz6fBBaIMkTvdIYJIDx3RH6z243SCM z8fA1MQnLwMtwikJYySFzhZbR5dKdXb8k0RaYiY/dzWq+yLZ3Nt+PFlae/vjyb7Pm11n8qC1 U5eWvrtmvxMdvTSIz/ZRn5jfBxNVxfLRRxMjL2O3nua0g7wH3eZ781ltu2Sbz6vX4XLrxqVr ret/05PUfZdtVgEubhMy2N/rxpQ79DTv0R62P2pgt8Xk5fJ07NwchsGbiz40hNBs0ZYf1Utk cjHeszSYl9BbJtYzaPaVkZBY2WFrSOwYQqafFb/3o+Wy/p0+k/d1pa13NoPxCtUK0OyDkNnW +JtXtW0Ocy54fU3mPQVVT47L8n6dP8/dPDGkkzJQMnNYGkHjW4TXThy/xVqhzeff8RjW9fkM fl/zQVUfq/4Xz+h/n+naq1QICAgICDDkmVsJdC+NhHEmQEiuvJBGftOV8zIIsvCdM8eloY4g n4g8qpEKS6s+KaSN2bghzDuuaWusGh7/AHhBIY7JJIg/J8IvNU6Gxwrvz7olm3ZG/deHDs7/ ANoMcohlj3MqBpZ1EjQ5qCLyY8PSsySfFwmvyNQcHSvDjbiKANcejulLLn5EYclKa+Odf62s iJtXv2Yzq2SJ5owzw9x+7TrJ+6D1+K8b2p7eng5/BjH1eUT31/S3Fx/Er1bGa3lBsxMPiCNz bIaao+8clt4XtT8TxLcqa66d+W99o2rvi6bxTbDs3p+ZFqur6pL4TYdQkjkiaLJAa2jfKlv4 9/EpGX+URP8ApOS0ain7b+7ox4oPEMI78lepcrmabnzbdecZi3j+ShYZL9O83IDyOXOha41P ib+S2bR4PT67dW1xLiCwgDqa4rtUuQEFryRG4gEkA8G8/kgxtY9zQ7xZG2LohvD9EFGseYw7 x5hwuiG39EFcaXxoGuLJWnkRK2nfNBmoIKbjbvdF/BBqZ0QlYxt5Lav+Q7dPLqg0S2QwPfWq Ah3pZvNvl093x7ohsYDJBM4vdm1z+3c0t/REtqXCglkZIWVIw21zeFHh8ugVd8VLzFrRuY7f JMTMdnO53iN1TLunjxG+4/cavgfeWInnT9Iehxv025obY8hubHI0lpe22n+0L3vdukW4E0t5 xMz9oZ+TOsm4TcUTIY2xxt3WNFAdl9FWsUrFa9oZpna9dAgICAgICAgICAgICAgINGfScXIn fM8SB7yC4tkI6V/gsHI9l8Tk38TNTc/Wf+1lct6xqJZcPAhwQ8Q7/rNuLnE9KV/G4uHjU8PD Goc2vNp3ZsrQ5EBAQEBAQRuRreLjZj8V+/4rKsAd+3f39uvMIbYv3iwjiQ5DGzPbLe61jLcK Fmx0Q2yft3Eprhvlp3fUAK9QBHXjwcOSI2pDtBgT4jclj3eG6QRCx/UQCPqB8ShsxdfwcqSO NrnsfIaa17efFwuxw5tI/LuENpCTIhhIEsrGEgkbzgLA5/UIljOfhgEnLgAAs/aDkgHOxASD lQAjmDIEA5+G2ry4BfK5BxQV85igkeZhtpo+scD2QV85i/7xD/3hBmQEBAQEBAQULQeYCBut 7D8kFPDYTe42+9IBijIosaR7wgtbBC37sTBRvg0c0FZIYpf5kbH/ANzQUFhw8YijjxV/YEA4 mMavHiNCh6AgeUxrvy8XD/gCAcXHN3BHxIJ9I4lA8njXfl4ru/uBBmQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEFtlSFoFoFoG8gbyCtqBVAQEFEBAQUJUi3eKaAuKnQbxUaFwNhB//2T== --L3G46d9cLY198qK82MV133O1J5J2Jv4093--