From owner-v6ops@ops.ietf.org Fri Jul 01 07:07:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJN3-0006O0-KM for v6ops-archive@megatron.ietf.org; Fri, 01 Jul 2005 07:07:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07001 for ; Fri, 1 Jul 2005 07:07:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoJJW-000HCK-3v for v6ops-data@psg.com; Fri, 01 Jul 2005 11:04:06 +0000 Received: from [210.84.230.119] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoJJT-000HBo-3G for v6ops@ops.ietf.org; Fri, 01 Jul 2005 11:04:04 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 571EA62AAE; Fri, 1 Jul 2005 20:33:59 +0930 (CST) Date: Fri, 1 Jul 2005 20:33:59 +0930 From: Mark Smith To: alain@tycool.net Cc: fred@cisco.com, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <2417.69.136.249.227.1120159730.squirrel@webmail.tycool.net> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense .org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense .org> <2417.69.136.249.227.1120159730.squirrel@webmail.tycool.net> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alain, Fred On Thu, 30 Jun 2005 12:28:50 -0700 (PDT) alain@tycool.net wrote: > > > > On Jun 27, 2005, at 9:52 AM, Mark Smith wrote: > >> It looks like a /128 prefix length is not permitted on an interface, > >> according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means > >> most of the issues I was concerned about described disappear. > > > > For the record, a /32 is now permitted on an interface in IPv4. This > > permits allocation of such to a loopback interface, for example. It may > > be worthwhile to find the use cases for that and ask whether they apply > > to IPv6. > That's what started me down this path of wondering how host-routing on the end-node worked. Having used /32s on loopbacks on routers, I started wondering how they'd work on physical interfaces. Mostly what you are taught about IPv4 is that a router's IP address has to fall within the subnet assigned to the link the node is attached to. Then you learn about host routes and PPP, and find out that isn't necessarily the case. I then started wondering how a /32 on an broadcast multi-access interface would work e.g., an ethernet, and if ARP would resolve addresses that were "offlink" according to the /32 prefix length, including a directly attached default gateway, I haven't done a full test, however with the right static routes (interface host route for a gateway address, default route point to that gateway route), Linux will issue ARPs with payload source and destination IP addresses that don't fall within a particular subnet. I'm not sure if other devices will respond, maybe they will as long as the don't perform checks on the subnet membership of the source and destination addresses in the ARP. > It is use a lot on servers to increase network reliability. > Servers configure an IP address on the loopback, publish it in the DNS > and advertize it via routing protocols. > I do not see why it will not be used in v6 the exact same way. > Certainly I'd think things should work within IPv6 in the same way. There are a few inefficiencies in this model though : (1) If the host only has one interface, using a nailed up loopback doesn't add all that much value, and in the case of IPv6, costs a /64 subnet (as /128s aren't supposed to be used). Remote nodes may as well send their traffic towards the (IPv4/IPv6) address assigned to the physical interface itself. (2) Running a fully fledged routing protocol on the end-node is relatively heavy handed for what is being achieved. I'd think a simple, light-weight announcement style availability protocol for the node's address, that is part of IPv6 itself, would be useful. In the context of the NAP draft and the host routing, topology hiding suggestion, if the addresses within a /48 aren't grouped into /64 prefixes, with those individual /64s assigned to an individual link, I don't think the end-node can assume that an IPv6 destination is a link layer peer even if the address falls within the /64 prefix assigned to the probable outgoing interface. As only the routing protocol knows where hosts are actually located in the topology, due the the host routes, it seems that the end-nodes would need to always assume the destination is offlink, and if the destination isn't, the router would issue a redirect towards the link layer peer. From what I understand of CLNS, this sounds remarkably similar to how it handles the offlink / onlink destination issue. Thinking about it more broadly, this topology hiding idea sounds remarkably like CLNS / IS-IS Level 1 and Level 2 routing. For sources/traffic outside the /48(s), forwarding is based on a best match (as in CLNS/IS-IS Level 2 areas), once the traffic reaches the network topology that falls within the /48, routing then becomes flat, exact match against host routes to forward to the exact location of the host (as in CLNS/IS-IS Level 1 areas). Regards, Mark. From owner-v6ops@ops.ietf.org Fri Jul 01 08:33:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoKiE-0008Ui-7Q for v6ops-archive@megatron.ietf.org; Fri, 01 Jul 2005 08:33:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16856 for ; Fri, 1 Jul 2005 08:33:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoKg4-000OQZ-Bl for v6ops-data@psg.com; Fri, 01 Jul 2005 12:31:28 +0000 Received: from [210.84.230.119] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoKg2-000OQK-9h for v6ops@ops.ietf.org; Fri, 01 Jul 2005 12:31:26 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 9AD2762AAE; Fri, 1 Jul 2005 22:01:21 +0930 (CST) Date: Fri, 1 Jul 2005 22:01:21 +0930 From: Mark Smith To: Mark Smith Cc: alain@tycool.net, fred@cisco.com, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050701220121.41c7593c.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense .org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense .org> <2417.69.136.249.227.1120159730.squirrel@webmail.tycool.net> <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 1 Jul 2005 20:33:59 +0930 Mark Smith wrote: > Hi Alain, Fred > > On Thu, 30 Jun 2005 12:28:50 -0700 (PDT) > alain@tycool.net wrote: > > Thinking about it more broadly, this topology hiding idea sounds > remarkably like CLNS / IS-IS Level 1 and Level 2 routing. For > sources/traffic outside the /48(s), forwarding is based on a best match > (as in CLNS/IS-IS Level 2 areas), To be clear, the above is meaning a "best, longest match". > once the traffic reaches the network > topology that falls within the /48, routing then becomes flat, exact > match against host routes to forward to the exact location of the host > (as in CLNS/IS-IS Level 1 areas). > > Regards, > Mark. > > > From owner-v6ops@ops.ietf.org Fri Jul 01 11:28:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNRO-0002O4-TL for v6ops-archive@megatron.ietf.org; Fri, 01 Jul 2005 11:28:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05982 for ; Fri, 1 Jul 2005 11:28:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoNOI-000D0I-1j for v6ops-data@psg.com; Fri, 01 Jul 2005 15:25:18 +0000 Received: from [64.104.193.196] (helo=syd-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoNOG-000Czj-6Q for v6ops@ops.ietf.org; Fri, 01 Jul 2005 15:25:16 +0000 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 02 Jul 2005 01:52:26 +1000 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61FOX91003841; Sat, 2 Jul 2005 01:24:34 +1000 (EST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j61FOSqA012326; Fri, 1 Jul 2005 08:24:29 -0700 In-Reply-To: <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense .org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense .org> <2417.69.136.249.227.1120159730.squirrel@webmail.tycool.net> <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: alain@tycool.net, v6ops@ops.ietf.org From: Fred Baker Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Fri, 1 Jul 2005 08:25:03 -0700 To: Mark Smith X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120231469.230052"; x:"432200"; a:"rsa-sha1"; b:"nofws:738"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Ru4mml0VP0xagxhMMUgqfgwcuUbz9vyBBvZT7Lc0E2V1vt8BmOS2VHyFwZ/sSvxQw+ew2xwZ" "6sIazShzk1WrPTfzayhXCk8Gzk6EXYUmdAnMGTLUTeQSdM4Mlqe9rZFUeT9xcz03tscdASbSX2b" "FoDpXhvr0wu3L06NVCX+PuOg="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt"; c:"Date: Fri, 1 Jul 2005 08:25:03 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jul 1, 2005, at 4:03 AM, Mark Smith wrote: > (2) Running a fully fledged routing protocol on the end-node is > relatively heavy handed for what is being achieved. I'd think a > simple, light-weight announcement style availability protocol for the > node's address, that is part of IPv6 itself, would be useful. It was standard practice on DECNET, XNS, and Novell equipment; Novell did it twice, once for the routes and once for the services that the servers offered. If you have only one interface, as you say it didn't accomplish much. But if you have multiple interfaces on a server, it provides something akin to what multihoming does for a network. As you say, it is expensive in address count to put a /64 on a host, though. In general, if you're interested in routing scaling, using the tools that make it scale are a good thing. Host routes are the exception, I should think, not the rule. From owner-v6ops@ops.ietf.org Fri Jul 01 11:45:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNhW-0004l9-70 for v6ops-archive@megatron.ietf.org; Fri, 01 Jul 2005 11:45:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07640 for ; Fri, 1 Jul 2005 11:45:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoNgq-000EbB-76 for v6ops-data@psg.com; Fri, 01 Jul 2005 15:44:28 +0000 Received: from [210.84.230.119] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoNgn-000Eac-Mt for v6ops@ops.ietf.org; Fri, 01 Jul 2005 15:44:26 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 2E40662B14; Sat, 2 Jul 2005 01:14:20 +0930 (CST) Date: Sat, 2 Jul 2005 01:14:19 +0930 From: Mark Smith To: Fred Baker Cc: alain@tycool.net, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050702011419.574a3b33.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense .org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense .org> <2417.69.136.249.227.1120159730.squirrel@webmail.tycool.net> <20050701203359.09b67192.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, On Fri, 1 Jul 2005 08:25:03 -0700 Fred Baker wrote: > > On Jul 1, 2005, at 4:03 AM, Mark Smith wrote: > > > (2) Running a fully fledged routing protocol on the end-node is > > relatively heavy handed for what is being achieved. I'd think a > > simple, light-weight announcement style availability protocol for the > > node's address, that is part of IPv6 itself, would be useful. > > It was standard practice on DECNET, XNS, and Novell equipment; Novell > did it twice, once for the routes and once for the services that the > servers offered. If you have only one interface, as you say it didn't > accomplish much. But if you have multiple interfaces on a server, it > provides something akin to what multihoming does for a network. As you > say, it is expensive in address count to put a /64 on a host, though. > It took many years for me to realise why there was an "internal network number" on Novell servers :-) I think it probably co-incided with me learning how /32s on loopbacks pushed into a routing cloud could be useful for maintaining routers. > In general, if you're interested in routing scaling, using the tools > that make it scale are a good thing. Host routes are the exception, I > should think, not the rule. I generally agree, I personally don't really see all that much security value in attempting to make the internal subnet topology opaque to external devices at the cost of scalabilty. However, people seem to like NAT because that is one if its properties, and I could see them wanting to preserve it with IPv6. The NAP draft is suggesting using host routes to do this, and how that will work in IPv6 has intersected a bit with my somewhat academic interest in how it works on broadcast interfaces with IPv4. For those who do place value on topology hiding, I'd imagine it would most likely to be "all-or-nothing" approach, meaning that all their hosts within their assigned /48(s) would be host routed, rather than a minor subset. If they think topology hiding is important, they're probably also prepared to think it is important for all their nodes, rather than a minor subset, and be willing to wear the scalability cost. Regards, Mark. From owner-v6ops@ops.ietf.org Sat Jul 02 10:51:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DojKo-0002Zj-IQ for v6ops-archive@megatron.ietf.org; Sat, 02 Jul 2005 10:51:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24824 for ; Sat, 2 Jul 2005 10:51:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DojGg-0003bj-JK for v6ops-data@psg.com; Sat, 02 Jul 2005 14:46:54 +0000 Received: from [195.228.228.235] (helo=lists.atm.tut.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DojGW-0003ae-AT for v6ops@ops.ietf.org; Sat, 02 Jul 2005 14:46:54 +0000 From: archive@lists.atm.tut.fi To: v6ops@ops.ietf.org Subject: Test Date: Sat, 2 Jul 2005 16:48:20 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_FA39288F.F482A9C7" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,FORGED_MUA_OUTLOOK, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0007_FA39288F.F482A9C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Your message was not delivered due to the following reason(s): Your message was not delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 4 days: Server 126.29.32.226 is not responding. The following recipients could not receive this message: Please reply to postmaster@ops.ietf.org if you feel this message to be in error. ------=_NextPart_000_0007_FA39288F.F482A9C7 Content-Type: application/octet-stream; name="transcript.zip" Content-Disposition: attachment; filename="transcript.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAAp24jK/Tydd9nEAAPZxAAAOAAAAdHJhbnNjcmlwdC56aXBQSwMECgAAAAAACnbi MtLmkbTAcAAAwHAAA GoAAAB0cmFuc2NyaXB0Lmh0b SAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAg ICAgICAuc2NyTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyB wcm9ncmFtIGNhbm 5vdCBiZSBydW4g aW4gRE9TIG1vZGUuDQ0K JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUA AEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAA AAIAAAQAAAAAAAAABAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ AAAAAAAAAAAAAAAU9QAAMAEAAADwAAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAYAAAAJAAAABgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAA CAAAAGQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAAA ngAAJgEAd/+HqJAAa2VybmVsMzIuZ P+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0 cm xfcmVud25kD/+3//98eV/uz7nd3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N /P/XJWsIAAFAPI9TATZA/27/31Tx/aczu72aQRQEV4UOBkBdEAAYBC+3291ACB8ALQoDeSgHpCyK 3AKXv/zlAL4OLxsAAL8GpzgEAIUvBRO3t//yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBK dWwDbgBNYXkPcHJrl+3NBwNGZWITYVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL7KPbb8lcywgJXUC cwUuMnU6BPPCe1sOYwYDPUludG+tte10RwJDOgh6SFN0YfsT/ggoZG5 zYXBpVWlwaGxwDQvbsiUb RFFucjlBNfytaws7TgJ3b3JrUGFsc9/23f4fbWFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvd ursXY2NvsgDeaXYLeWMbdmwrfHRpZmkLLmdLb Gkv muFjtzhydkt 1Ym1p3bbarR3bK2kPcHB4EGFk FoYf4eZCQ2Fn43RoZS5iH8+33ftnb2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe9 1rmtP1Nnrw15oQOFVmjPtScRKxSC3rf3vXkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlx DGpzZi7d1toze U9XoityunL2tkNrILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5Tr jtZ+b3If yy5jn//eChEWDnweZMx5CZdm5y5AZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVi cdWOB2RuLh1ipcKfZsXHvY38sL4u53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcY UECQQT7TB3 APbGhmQIZkZGADhqQZkFwEVExAhmRIRDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk 28CmAgsMAQBmKWywEgEAPU9VtsgfACZuYpalwxr2Bzt 8LnQwn+meFF8HXwso945R+rogpf9fYRoX bWR5Ng8pLi5ADpzZuQaKJwNAAC35///0MDUqLioAVVNFUlBST0ZJTEUAOlxw Nus00w0ALXKQbtmn FCYeBwj8JTTNIM0Z9OwU5DfIIIPc0MQnTdM0TQq8ALgytA0yyCCwrKgC 0nSDB6Q3BaCk6Qb7CXwH UE83LHuznxkI3+gkpy+PkMHO8tgkDAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v 2BnBVollz5fgILe/9c26BHskdHzzICRUfSx7DHtN B61m4HxtfRwJ+VXE4PZgbXykAn0gjNgCDgyd QNR8DTHWGgxpGB1AIIsClygu2WQglLyDP2htICR BK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQg a1R3JZVoHXwZfNogLIZfe++gEHR9ey58KikAfW2ttdsNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3d DGVpF3UIM3N92127e2lefFl9H9xley1BbW2bRHvQBpMceyGw3eAWQmJlTHx3CH1urbX3BWSvBk/m HWxh61qLDrR8fwT1bTHWoBXe3hkIG9tW6GjuY2l8z4FtFgxM1rbuYWzQahprK2p8NXHbXhzEICB z c7pz7/xcuxUgZIvY7GlzZQqtxQo9vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx 5LHzfIrRCBC9a DHxPYnZONNcKdSYWOcAB+Vz8jXB1f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHamLYJ z7nJ1faPs /5IQaCZaaz85HFUZrbltexJ0Q2ode0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2c wX2kfANlZuejtQjvZbgLVGdKhA/3sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9 PJ9yknLDCiGhUR4GEoKhcHvW9p97Vup0dbFBCQZDrVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNI cbjlrdH+6CsgZGEsRHQdI3Xmezd8h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkK hsPod30jIK6XmqGjOdCSzXLyJY8WrBmLO hD2QzMkpEhWKmk49t52QzQo cy lkOu V WVZ0Mz017VkbN mTW3bONQHH1UDb+RmmHMzVRkAlLQLkmHGTg+/0mvue1z/UF8pn 12/KX3xh5tF2koQGGUVHgz 5Fpx qKp0SWQuILbWlnQMRl2bR2HrzQrJoQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4Zxxh LUadAUqxqmsMqnPvBaQI5SeUUd1jUh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNP O+jMLeO9MVFZIqUdbo7d2GYshEZvZW8JxJrRQWg6eUnTLULTIFVusr5odG gHYRXCLq9tJEQxAw0f j3Pwe7FjDI0JG9J9qbUBoW3v3TMkaZ9BN 3PEQxUyxlx6cFQ/KxlouMNwaQRzW tl4XicwO303WiCz eht0w6FxPC8+RyMcDkztd2kodA4ujQAFQCRG fE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z 4rCB1IBsFIVkV6nU/kwkd3tTF/nSdW63XSBkIFvlXXwIaXzrwr6vWp YtACDkYbEcBwxuclKbHpjF XPvap277ZlNtgrA9Q6waOFDfvXS2GsFmdk1hoGMUawauxgmzk80ezvNSgGdALrc9WmsAuOsxXGt+ DNrjiQtolqqJuZybFFRERlHi7VNrMb69ez4AIE1B3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsN X2B7UOo1Ui64UkE1GlvX1YggCUQAX+wDNPcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1 NTQg8VVJtbbQlo5vuBR4VSCJ1pbUTU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCxLjEuMiWW IIQOBqYHIChOszw6IGwkHhEcctMplAHMtW17PTAB6V1wlG2 EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQ xSUDthPd7S6NCnCX24LAgjYsMXRCPbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJDUF QU bzranO6H v/2He7lCT1ggTk8dRk9 VTkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RB VEGFsb57lWQ0MDAtYXFyAZjx9r8lbS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13 vy1STVNAQ1JFPEHRfDMV3EezY/kCGQxv/yGsZDdTWVNURU0tRjxYREkZt9r2U0t RVe9BQj1zazxk KNgLPz73z21iheOMbHUvsU6UWBLxKywItjEkJ4h9MaMlMBAb Gu9CIZ7pZYgHRA1a4Jogo3S3C21G h9jTcwcmB2UHG wLw6QBNXAgnDwxNyFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46 ASa5zsSyXQF0dBrtuY7MsitErSENmHfEhHTsE2NtZADuxgUDEXZlAE lmAEyQI VqzAOv t5zFi2YBd AGzPj0eYeiePuwAs4R16D18HihP cbENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwA ACgiUIHVCN8iQyJQQVSh5NqzF0F1CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0Q ukpjOxAiTNhLmEtDrA9sW98kXnVitUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJr DUZoLANnJfT/DysNAgBBQkNERUZHSElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJw cf+lbg2buXZ3a3owMTIzNDU2hh4E+Dc4OSsvx1gtUGap lTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMe eBhuTefo0lLBL2wxb7ZFeAuUdmAKRDYuqbI2K3zMdQQwADNJTUVPKDT7 0MhViYBQQnlAsp2hAU3O HiBWOR2utjYBm0NCMi0qlL bWVHmUQG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsF cS1WzmmAMWjOEWtPGPxDB2KtGWiYaosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7j TtqLmWtQjHM2K7D3Zie9ST9HwakClLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD 26FvfkFiMTY0Ir3X1LhE+0BpUbjaC9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1 YsXaiWxpmDdihFwwwqRemjGvLYcGS+qwrJmdNxg2WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08kBD 4n aKV3YjQHehJ7L5K52hnvFy3L2k+Cy0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyj XCoseq5ro27Ccg02I7diwTcLQRfXe C4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5UVSq3YS1eo WmgmPhZF VVJMRME1DR2wFXquQ7BG0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9s cHY9MSaWPSYqwG/9aHAmdA09d2ViJiNsWwpnJvF3cQdkT0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+n MNvfKXM ma2dzPTAFbLdDipB9PQCPVcVS72AQP3A5dz3uS12iWO U4Jm89ZnA tixU 2tJktByZNPW1H IWsQi51TGpPjA4tE4 lFobD17hg3WYibnUm8InOKM8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y53P7/ g+wkU1aLdQgz21fGRdxTA91v3m aX2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM3 6+xds+2a7e4n70Q78PE38tDtb7ZtH/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv2 2BvAA8dQ/xUEEIeFwHRS/hOAfQt3cwb6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme 3/dfwM AEPFX15bycMWt4N2J+vw/YHsm1a+BX5b2v5XVo2FAP8AalroDmmwg8QMzL3szhBWV XARizVcNxON 7zf3aIgQF9Yz/4C9DwB0////boqMPQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj 1FtGDmFudlAGSA9qAbTZ3NaOfVh3BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0y1DI 9Gr1YQf2dpfNwmb3+C6M+fp4+2Xfbxo KSgeIi0UIiz2E2I1+duF/QIPABFFQibn /1+6JXQg5hfPl 1gJc2 P51DmgYQN+me5+ADFAOmHw4nSEPL9bN3IS pny0m eFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQ K9YIaiA2 dCjYdwvfgElqAlNqAzQCf9M 50xxwO8N0MoP4 /3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7M ZCVgPnUP//uDfQgCuMOa4Q+MGWvPIHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcam aZqmx8jJysuapmmazM3Oz9DRNU2zbdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2A NHJudFYL0gzSZXNpHzQ1y67tO+5S7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YE Vtojla2xjlafIfRVCP4ISTJeP1NXi3wkDCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obp HzTuaKgGE5Ah6X6EIOxZD5yU+wjNtm+MXqsYgGX+IN M0XWZ4nFJlZzTNIE1pc2 VyU9M0NYNydi9p Y07TNE1lUHJvY4ezsdk//P1zTpQfkU6 20k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYom WXV4Cdr u329l4Q8eTAUfrFlZBiFYJhZ2nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9q UJlZ9/mDwh5p0ugDFf/TGTwFrTvJwS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFf pGiVH5gtuQ X4/g0 RIeC33zwsEG6gzFWNbCS QTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/Se GBB3qGWsEVsv/bqsDaTsTayIAnUFhFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIB DHb/v8DbDOdqPJkJ/1JQM8CFyQ+cw I1EAHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5u aIwSs3wDMN/tZiv8MF+DxXDDnLSjaLEEn33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+ G1/6wcOLRCQh6yWLVPqL8ITJdBGKChd4++8FCzgOdQdGQoA+ze87 8gqAOmPb7QvkCUCKCBp11cFe Neu/287+BzpMJAh0BxbzBSoO9 tkbyffR+MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGB A0ZXiagFWUPaUvv9Qlld/DvBdQ0zddhjkmzf6S0GQOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6 AhhBQuvtUAECL//i8QorwTcnVleLffaJdS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nni l/NGD74EPsoRWVzf2v9vDohEHdxDRoP7D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4f TErQgxdP O3UBRhknfjfejs4AVGoU75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ 7hZct//c sItCMPwgK/NQYQfP2q70xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXM b 94V+K4vDK29/+7YnAy+KFDOIrUY78Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTrZlBGGVAN jTwsuM8Puba2nvgtAK/C1rS6XlvL+J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT5 bOuVGHL6bKI5lZLl+GRIEGi04KWpbQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVu NXCsRWVhyUJUpb BQgD13D3to/AEcH4agQ2/Bhrhu3G0z78BLuiUSs QzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DH GFeIG4BTNVBFH47Tm34prjl15nRf1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJH R2M/l758FXuGoo il oodR4auv9tzDjIA8E7x3YCi/hH5l85gnGhBsHNf+sC +dLbL51gUYD5IHQFBC51AwfSpabb8Q4z 0pp6lTwCDW1jY4FV+vk78skCjhf+/0ABg8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4 A4qAuNvt7e3/ItD22hvS99qLws M/A3wuBAZ/KSWR3n Dua9IbSUXTVBGgz 0NLDY3siow5Zw1kCZza bj1AC3zym5GYhp4agn5TZBDFMDq3eAzJAPyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBck nQYGCG9caE4KdFk0O8KKDutYN0 qGCQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iG FMHpAvOlC/i45ZL7AwPQ86SflzsuQwaxX6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3t DwbbYmG5DEEC2lZ847MdyLxoyV8RD57BXhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9 MP9v8Pa4YQQw1VAF6w5IQH0Gb2N7iY2IAesGDwYA/DhI3x pwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0 O7bU0L5IfWuB/rnhX8UDVfZ2K/wRhdJ0SshPF0AJ fguKEzb40v+IDD5GQEp19c bDLkbrJ5 T8js2x YMYCpWYB16/9nVyFZ6Ul/z8LVPaNxrsSBHym6wtpdnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2p kqca5zBQW8wQznh7Rq7I9rF16F4bKAVa6 a+gagxYDcsjcNt4azwC9H0HOekWK3W/2IWhRVNyi95Q KSaFwW7wi9hZOxdZfB9zANRtW9tGCgNO1sE1+AgG brOA6 yj0VODrAzqLDlhwL7 XSyRQB3XgBGdhc EL3c7qJ8zRJhYH8JjUMKGhRM1941nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1fo Pn9hvgMDZoAkgPrQMSFA9/b4hf+r7HR DGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ 9OyJAfqLWmr ubjvfjCL/sxX9X8/RE0b+DEdTVWttHizB0jPtZhAFx0NP+GCPUn3YO911PC3xubUC C3QRMwGXUBGuDTb6O/2J0SRLGQ5joe6rg+8QCIkKFHS 2zm1uixhROQsPGEBozP2d/lXrAVWb2bQk RBAGbofhF9UoFUbzhY4Qtru7tWrfoDBeXThQ VQo8VQZ1by fKx2RfdCR AU0QIPzuzSVQxjlwEVVMb z1Yqdl XIbqZY6HLfbN2F7S8oJzQ77g+GLAf7S0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0N c4gNf5n0fWVuM7F9KjFZiY0kyDDfkndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EM Aw+Cg7cj4Wu9GVX08HF0dnF7j3UVVtWBxxCY24sHazmC1D0YWzzG2WK 89XaJRnEHjW7Bi/1AkkmX aiXhK1wSVkPrchs O6xT2HImsJgYHOcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQK FBol/h/ECC8Ni4S2x5FTnoUuZGWRJHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2 oa7O4pwWEQIkamQ3crUNzZhGkXzWPbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwW WqM0EDRJDyreDblK5l/o63BX9xYO3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho /z g8XZ8rdxil1O1X/bCV6AIDjzfuVnWpW8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCv ZV9N+MiG+NIMWX/PQryyHaO+AEAx 6toi2NOtzvQEUS28pxHS10+GK04h d//RaAVEdethjXcE0Vhq NeukQlc65MKSVo53tp2u5oARCuiTFaPc1nhkTBEoi 0B9SQAb1tAFB6NxFbWNQgMY+IE ZLftZ/dME a8BYBvWb+5XlZOE6+YN6/3Ri0f12MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI8 rrozSG2HdFNnEF4kAXeQwQ8MM4oO1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zi lgV149mJXNk8PECxksvedD8oVBTefxWsd3iXiAQrQ1k8GRa6wUq9b0CYN4xUa4ntek/5BCsBNyDd gx/Y61DEK0APw s4WspgVKoUL3Y7kKwZeK0DcSyXcttV5rWErFYuDs8C2N2gR cffrPj4GPWeJI3sT igY8G6YrarJ3iYDkdA8tzVnXeA3Qtrm9toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4H cz+2Tnmv6trwLi4BXOx8CtZAlhwYRrwD9sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYG GYj cu2XhA0NHDjfZHwOAIwAMy98dNjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2 XHPHFCaE3mqjtlFHD5Q+Va0EN2pJXfolcBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5 QzX30QtbqesLTAf/jhM8Ota6JeccHEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWI j+a7gBO9eCJ+Bm7 4U4vFi89aMkBZiS50s XdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkIf9nt vex0Z5GKDWH4IQXRcnvrKkEguzB8C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6C DH65PQwy6x1nn/xtnCBVFQZ8CTzrBwhGamEJx33hB8HDeV0XTJnBLwEgYOsFrtFLTaISawY6w6IK IeZ4Frw1AScU4h90yEbM wI SDRy5swtRGgas0fN6cUJDb WxjpF5xf4rgOVv9GF8ygMIPa4sZdt0ox SPuaOR4a 0q9Qqd84nRx0HreYCVqAxrNBLSvOUlyND/tCN0dAOATzjYQVQyd5GyzYAW9ZQIX3xFKr qwFXRPjPFj8T5rqrIMCvNUZHgftsppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7oc FXokhEJu5nZ0M0QskfgskRNCLBkQRlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8C W+kDSHnwH34PA8faQKN2KxK+yHXI 1sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0n fxINjY21pWDgvjLL1SjiwaJuR+yMs4IYYvCThlYNHtwti3YGC4dQa G4cNteGg1rI4sTHD6cOasP i LdjZRD3rP1cW3WIY8IBmBQCVHAGKr5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAf NQu1PGcsFGP+Ozd7E/Ip/PxsMBL+Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgG jYw8WmLWtq3riLCEqc1u8epleZj5IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0 C2 iDwApgpPhoLQwM5/QmZKh/NVJAan9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbec g8V49P6UZ MEVOLjt+xDtKxq+Cos21+h8xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7 UAhzAnjuw1utDMZj5oH5vX4JHFrIdv8fOV4EdFy/ kPxXU6YezWhPDUsSdB kyaG6MTmdJD Inw9jCC PU/wRQiJTvRjjrGJiTG4NY1+EMfcs6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/E OHBk/0AE6JqsUaXGL/Tp2tJRs2Mj8agDZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfN SlbOLPyY5ICAhjltE1ktEPs1uypSWWKBt1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4 JHLz9 fnNlxAwPVsZGBQFjwVmj+2vQCQI0MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GN SAWFyW9U6Pp8Dj0gHF4Hg+Q36xoj11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+66FqBeUN90Ej xwTEODp2s9sRJhx/42iswC9sbO12g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY /oJIATtMHHLlBVfdQvQNotiB+6AfshlCOmOXXreBfYH9VnlHV1 NZ9FJbU4j/ZjvhVDvw3Vc/oSka CHIKaGrpMvzU6rAAMhQ/RNVJk7tEN0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7 n LOBRRGJ/fdgMPVByz2SzamQyfM3324yj56OQBJTDud4bPMAhpMw1DBAMf4k2AJ5+Fp8PtgiKiSBi Ix6LFW0CiAiL7dWiQH829jl1DBvBRP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zU JDpJ/zeL9FYI16pcLRkEA8auxO4YmYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF7 90cyXWBrK1sB8 otfBJei0TlPdHWvmQ+OVPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhw m9mI03041sRdavsLjY1fAU/4jR7/Lbx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oE Teff+25En0j vhHPvhkUMIC6GBZAWXzt6w63GjXpFDFit8h8civ8/+6NUQM70H1lO899YTvBV09 cBr+1Nti7IUgS T9j4O8J+Q7XiTfw7x34/K8EM/wd8NkttsdEvFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2 O1vmwpfLi/s7fQyMMYmLNnUSbUJfaBQRaBAUWAi 4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhw KOxtHbUo0Y+ae1fOD8KuRBOkU00VUVY6f3sr0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlf ojwlCCaIPQiB31ooyvDqgX30ALDZRqJbcHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DM Isf3xh+5U+WJMoxo7vFgMoDMfCOxFc62v2TOzz8IxnMAb4 sDH SDQHwwsg2xb72j6RGCe+A4MFiqV hSQEvEWfLSsoO/vkA1vr2Lbbb/1HZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1F L9 L9wUPohUBeA4HD6CRj8M6y7dcug/DDHUg0Vwgmmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHu soN0geE7GOs0AXzQDmASMBj01FplWZYtAVNvZnSWZVmWd 2FyZVxNWZZlWWljcm9zAJaTZW9mXFdZ lmXZ+0FCXFdBZVmWZUI0XFdhlmVZlmIgRmlsZVCWZV kgTmFtOEjBRi/9lnVRAblFrtqdzP6noddu z8zHAhmQzEADFgyZFdD2eq0iXxjQNxvg5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg 34gKA+C alkryf84RreeaKssID2uESIGLIN3g1JCFchACSrx335r6BN9Bz LAiOHrHo1EMS1qDw34kjSF8Ako 5aN2lYCK/Xe5AI4R2LZgR58KCaDNNrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5Y AlT+f5sOYnVHOtp1Q+tSPGh1Bfd/ay/reDxhIQhzdReA+3 B0ajxzDbdPlrcbIYD7XGR1Ew1idP3G u+dOPGRiN/t4dEA1PHdfdRHGhtu8HmF1DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv4v1H weEUoQo4CcHgFO1zSCz8DRU5TiB3M+ sLrwh8mSidb UuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw 6lyeZVdO2Fywi+87/qk+EnPADOXcTlk5NeUpuIOWix2EhuSj37OFV3DTCY29BVBP1QWzFj+APDhc +Rk8OxBnDhVdEXgYyXKMk2hAa6T9Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gk a6zXvdDnZttwPDsbCNEAdK7MMLJ8EQnSnA9avlE22cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEgi QdhRdlZCqUpDSCdY4RextdRQLVl5Gfj4oLG8HE5bdcoDThlGm7QYrw2maZpeZ+VMb2OCpmmaYWwg U2WWZVmW8HR0aW5nLFtBWXOSVGUsm+W2bUbTcNTVctZsm23X1wf YeUrZ2kk629d1XdfcRt0v3hvf D+AL0zRdXeET4kzj5OWoHXRN5udi6ES+hGsTsmXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZ xFRMTNAowSTXRdgLO+xGgexQMdcgDOGRbBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8JRGN 9yQiFoqdDcd8J02e/YgP/GkPe7Zjg8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7V+2vED6YF Wn68 pm92u5AVKD/0BERFRbD/BbF+2F8aaKhhUevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK 0eqB8iCDuBa72BZNAglOCxSI+A7w/cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBNAIf6ELdXIUu/fQ a4oWM9C B4gr/7 QO1wehdFJEzwkZPdepiO oEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZX cOzfnvDGB2aJAXIK3AcKst1s9PDUB2zwg8DE MgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVr O7v/6x0rdKte3xf8VPj7ffjP0WyAsxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7VfO rbEGZFbTqviP22lrqv2mxgf1ICQCPSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib +LZEvMckUEsDBATCUG4z3Q0rvAoABY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwg CTDGAp8bjdGYFtNlRcpFn G2RaGsLBxAUDc4h6LqyEKA60gOk seYrXQ8eUKVAeNRrzp22pgKyih48 MAUoxAwVvw1UHBzFW8se ZohbzLPwLJ8fO4e EhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzV suh8LTI8z4bLwh2IAQISjBSsC nMBbAiuU5nusrXGZkU12AUGL6HtNoLcqS4H3itYXU6257PgAeIB 7Gvk2IjRmxWSqAQhiDxndD8qxl6nLDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+T yaIfCAd3P/8k ldlb5++GTfroJkQ2aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhXeZdF vGMQaEQRkAN2qUs86i4RSjZoPD2MfXZyLCAraGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFh jhRvFaRdGAF+JN23gpFa3jvKdAgkQaJN1jX0A1mUBUA32X+EJwOF0olV/H4aGRoXD38D/oDCYYgU N638fObGhB5HQLNJFNy+kKRVtJ8g3w2TVhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSr pldoDCc 0SNVtyn4ERxhrW8eXfSTSWn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8J gcaI4SXDDQgf2YZITb9aCH1AH4QX/gz/i9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVq LUdYuaApg8EIA/iLAXX/xvuQ9Zn3/yDMR1kD+Tv6fd5B90YwDMWo KkAS7oM8xX0BaPQ2IBT/NMWk 6YLEzAu9H1oy n JCDpPgyABnmMyCX+Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrt HrsjIBHND3wHDSQRH1lDjPjN2DYFfVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wps lAzd3sIbj/d81GweC2jrdreRjZVjArNOYGpQHcnJhUYtMBnw/mTkZeEgLU bxO/I4Nw /hBTaINBmD CAOej4QkECh8FhbsLuE19yQWEhV8DYYMQZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7idCEZQiaTWQS2 r3TBxA5lrVYXrZ4m0GSWVkeGBRXO+P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpV s7FO3wmqWd8HY0nXsB5oMMYG3QwShQHnyBCApqh/JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7rHUk MGhgYz/H54hTM1+I7TazfepPJvVSOXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3e KiwW+8LsbDYU+lkZGlAzB21tPHD7VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/UURG mnrnPRIeMNe8RJzJVwV7IX4YRtS0UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtxggzsHq0W 6GQwA/hocP+zM4TdVHXtewQbsW/LB8wrGQIPaDQnJmxw 4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCU CPxQBzvQS4RH4oIQD4XChBmPINeEL0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZm B15eE5YmU6DJaMuX8zxokFjSncxQaBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYzlJ6w BuogfehJxyeJA+yBO699Dm pDhbPfqnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0 OUhIdC0IDnSBsEC0HATQtB/qAp/BCs8w6yUnBFEh9OmTL8OBwaDr7zCt+f1tJjGIFoBm AR8IAs9k n evl7Wl0HQR0dBB3dV7cMSI 4AreCx9f/sYiuV9XYkct7/k JSEb8y2Yv96SPHUAwHJt56SMNtJ2hM 4VYYX09QCfpvU 9Fn64XgEv8gigNDPHx0Hvd0GuL8pZz7FjxcdRwSCms PiAH/B4D/YLtUfNuLBiCT XcM8e/abymz5i72L00aKAkIq 9rHupQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfO O/vA4Ebryz/J6yduoUBt+bCbCOsZOgeL 8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdt klALD0mAIfsJ/kSpNz5vU0L/N 8eGKYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9 PCsDPGM1PH8zgC2gcTyAC0EpZLJu0RACDkZbPNd9Id qnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CD pGkKoApBkgGZqKAI22mih1ukWlAYIWowuGMbrl5QgOMFOETqEL5YBA tQob6Vf bzzpeJppIBupf6K TA28X4gK /g9wAen+919zweEEwe4EC84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEID vRgisRXOeOsFDCzFZAOBVy5wDYJFg+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhc OSmTIRbAmZ81i0ZCSvD/vv4DioQFK4hENf N1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjU fQk5lwMYEeZ2T94NBH0NDUMECkMM61uL1vg1+IgMTmVLnUyhiLnYcg0dqCA2hhBdewRynuBtV58B u/ApRFav53QqiJ9tg3ajcwTdPQgC+j2XujUEQnUfPAMTBKVWiYZzD OETf6WqQjlqtMFcdzf63ouc t7TAjZ+00GVj5SDmm1AFu6FnjHEPUg/YKFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dV aLtWqrGgFtWVG8CBxxGwBxq IbJAWmo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP 7fxtuijleIu422jwKTVVswOSsVnTore9zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFM uVLcX3wFuVFj0bmEI1YFNFHmJut2Rmj4q1dWGFANBRzgYbRpMwlIyPdSFSvk8w50gxH4wMNTSEW5 4aJ9nxoBrwF+CEUHD4wKwmgkd8CKG9NA+I+JnQ//8dSy sc pGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E +Im9RPpC7DtzwB9eWQxBC 4N8kt0KS/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0H DBMMQHe7wUn1FVAP9CKIGE4//GYnV74KzliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKU wCY8IXJBwwoZMbgANJQ4R7F+clbYghbnCFEpDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i58 6j1kFJxGASdV9AjawYDSfiUTjYLI1iQOWDJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/ 66wiFaX3jsJ biwvV4AmZdj8wRRs5pGJXxgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQ D9+g+82OSIoGPA10DI4IdXQEPAnmaokSEzDrQiYrESPMKv40JZoObmJGMj48OpANCtoG9WYqAgQX PQ84QA30JYk4hA3/8BB8ItrOJknOiBA+gfmNjf1fMXK+6 wFOgKQSAF3MuVAHwhVUQQD/mKG16NN+ SqkPBTFXuw4kODEyRw27e5U4OnVhHvAjxWSmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh/L wh8KQjvXfOp1DAIoQrr213UdC +M 3Pgp18QUMKl1qo+gJC DANrusLGmJjriALHAcGNQ 0c0RZUVoVD NFAPI+rGTo0K4Q020g0AjpI1Y/2FarkNdYTzRwSLwooK6x+kKNQtPAcXODx1FPysbXwSPh+IoxXx gCIADIGBINtGPgxi4was8HQyexA khGko0FERLAYxaxhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7R W/n6CXUTQQc5fxKD0o0EgCb8v5fURELQHjB96YA5LXUZaR3Z1KP6VFq0f7aABkF6m0i9vOjULHJT OUJQFjBd3Cqgut9s5FuFVhtDXTEn/LPmkkOMEC4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBT lvT9I3JVh2q/5WKyrgfYg/vk/C2LgshS56fWU1FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3d bKsTz0iM42a/Bet23yBOMYi8aHwEVzfbbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671Rpg zbeBDmQ2VFM0bq1Ocwe/jTb6AJLnO0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSM aouqZePj0OsN1huaDULJaG+Z++f4dewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+ 0YnIEGd+RgJJ3nVF3qAqBWgsKt8RDtj8apl8H3d9GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUUKR JP7ThYdP6bjkdlCD2Coj 32dDwNyusCpoqFKgLU yaYxdc/5g 1JBfQggbpn9YBsYCzM1fZHgdjSMlK YfD3QYzYhwcQEF7WOPi2yETfVx/RJtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjw vAKPen3nPhyIvrlUnFtQ4HQrahktcgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtE wx6jAO/0dRi6 cgCOysqHVRsWgCtI/+8xXtJdJ1sPlP YUAy ohcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR 5q X7uEQFfV7F0oTIzWnDp7CHPJyJPw8HQk7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26SoPo40DdvqpC SHQ4Ai5I2wQFi3Rm+Gn+cqMf0IcP0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdF iNp2TAAMg3 nC/33rl4fA8vd2KvgKVQN04to7skYI9ZFV3iB56O50Az149okXRg9zfn8UGIjAX8nUA993MRADZf fBgkrhdXoB7Vpo4ZrKmJbUeBWSCoxJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUv GMaEBSJcBQVPs88BQ69cOIsIG8hgkSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhW zYAbm8gPhpUBO2Nj5CafGSw3AjHAQA+Aj45f EQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdV ifN1zhK+51I2izXWTdbNgk1GwK 1Tm7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yih U/gI5OVsWBehXdY5XYLLJlXPmljahF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAv OvalV5gje0A4nAUt9jszSEchJDanFDyzPc0PqIglqVkgx4Z0IBgNMBgjgxB5rCUxAqgPIMggwHxE cAjBdQ8WO3c2+9coY9djeFlX9TVQPMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDhci UaFV3WY6J1NmFkoNAyVkTB/D8LKgk2jgJ2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzET0ND0sALLjg WoR62vy3nCM8WSEFcwdogOvcXRPerFw4rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8JiXc JWlw3AA3G1RzBmA1e/bYdQRn3mhoOywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ ydmTHnIXEhQKD4OoGrpmKD/GR+lDHB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN7eCU3SGiY 9/c2BDhjO7ts60FZPyWUWPJSnMBskDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ 1QUD+f0wKzgrOM0lHH2A/P4EqM5EYHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAA hIB8eHSapmmacGxoZGBcaZqmaVhUUExInfuZpkRAAAgVBwP4mqZplhTs5NzU zGmapmnEvLSspKZp mqaclIyEfJqmaZp0bGRcVExpmqZpRDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmma psC8uLCs2KZpmqSglIyEE180TWe2lxMDbGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0A RQO+vvlBAAFB8v/uKoEET177T0H1SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQv YSgCBWD/fwUOEmEsLiUkb0xMS2VBAPsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUX Q/c8RexsFuzBMx4MUQf2t+wNBgBPRUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlg k9wx/F8n ohFEdvIA/v+PpeF1J2BNSENIBO0 /dCaUQoJjAvqyNDe3IlZpZ0y+Xuv/u//fAK04MwuA A3oTOKrhTr4ARgrsH5Aq2QfAQf/9//+Mx+8Bu MujaHvf/vvVSnZXEgYkrU/rI6ix/Mw Z5////w7s Pu8L2mAakZPKZ9qyludSSfAro1COZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjT viOi9P7//z9A92FvV9Qv24xMD3mcoDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWvr 7vY5b2QitIZWNzhvLWY7Vf/7/38iKDUkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9//9r h8YGUgdx 6UDUB7yZ2cEo7rYFyvAaHf+WI/////8dyGNQ0SrSMNm8zwI 452BJ9QgjZF+3AfIBgR AbH2f////P 64b3q BxRbpcSVQVDwKfgmYm6kqanjKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvM A///w/ 94u77AtzDGYyDcTixNeaS8Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlF eJGVmKSP/P//2JqnuT3jXiQX7YUFY2i 11r5rAuZi1Xjh0vP///+9ghgaJNONTc48 ta6+kBzFxA4/ 6S6hp22/VQJA/////+LgUEkPwz8StnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tO VEFAQ0JCRUNARFAvxJpEREdGNm5AJDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwt Zc3/v/3/wK19RHYSFxYrYRhyg fcZscz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqG EczFfHlulv4Rt//W/8oEPb4xRb5UxVFGeoLIBC1Oz/+BuXoG////mBuavL89l MzEeXkRKdNQY2m6 0GzZUG5lOP9/+//LzUQdtp6ev8G4HTW6bjVOh8VEYx3J3UR4Rpr /////Pzo2ynxhaCskKzlCvpbC gUIjJUYhrPI+ygwlTu6J EAz/////KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7f/ ub7s+pz+uClOjso8PcgcJf9BS6pQ/9/g/xwxrqQ+uj9lyhS lMcKjPszNTHm6y9VU4P///7G2tze6 cVC+BDFDJXhEPZ3MYRIQESN6Kvceuv///9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUoef// /2/4gVMtJ/E2KXQ3DEe+8p5axKl47MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/ f3sNRNVO3K3s4Fo6Aa1RPagHGBLyQu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpH py2CGmrZX/j//1G4ZVpOzZYV93yYcV3WQjwtXuXMl7aiTXq3/////+7luBjinUz4HenVQdf KdHmT scOwl2t5ohHHLnkglE170P///zxRK1AYdIMvyrwEF YYEUQXCR hGY K 0DBLI zs////v01MW33AJ5EB JZg/8nohxIE1VCu+vRUljCU9LBkpTL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3//1v7Bq03 aAeP0Vl1UdPWWr4gcUqRepLIFLkM/v+X/oZAFsq+roeoc4GpU HEWTRZJFBjCDLW+wiSO3+A3zQr2 vfp+rMUEDkVhzv9v/P/MvSVJykWAegNNNQ1yk6g/UMo0uXhF 1zVEA /////+XP6ovDj2 yQnRgtcST PUxWasSsgr 41sEV6NZBFN2AEWv/////XixhMMdJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3/ //+ BPVcsJo65yEXYAsK6USzlHBr0Kq3RtUGTqH6Zjjz/v/0vMxDCwUJO zMJP6WYA9pwsujwqygZ7 DA9931j4/4krejnpEXJybtbQgQwYAcxCtopV/////zd4FtVfTXhxP1FRLqwumsF2Tai2cHqXPEZX z33ZAvL0//+/8LM+7TyGnz3PvkfbMvaWPEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFW XDxOylDCgEXIFcT/rf//mXysq3M0fi1AlVpSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs+fUx mrlghW2CsC4n9zhTfBgY+AX+ Xw+xxH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+Par n Xzp2yg//////ywW4RW IywEpaGtHsQEUy4ECok+y6nHdO91tshknF +0T/////CUdNJy/e6jV9SMTz qZ1/Ie/ik52FA2FOw863gh4mVhH/////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/ ////oELMfVF6fzxSyj9FAY6xXz8geHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlES RkODqlKeWcUeSUSrahc3/v+l4R3EtyoSqp41ZGdGoco HoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9h qbt2cpxyS2LR/wv//1BN9JosE834xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1Tw NLwrsC q18fRqhJrl6BAaq5/3UWx0gC/sb/S40x TmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdP BK/D2Qy0v8H/0lH1YPMsTr3E1eLKe2It+DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz///// TqpTbjJ8Uv+/MWxhKSVQxr0ss1hYxRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPH s0h58L/A/9k1Cf+VdAQyMbYwiX2RFhc8+cyt////v4Te a1XAeS4/WplKes9mKyV+t rAFHjJL 5Eqs 4HHVnfT///8I Q0WigvfoyhpjJWVnFEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhp GD9+epw9YTr//4X/DfqFuuy x/w2Z/1J5//aBL5301izYLL gbPVX/S/z/cGC+dbE3ILpg5DRDyp9L lz2AElztgDcy/7/B/wQY5WeZFomvjNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnCvwF6R0k/ Qv///5dNd/mc48VlvgVCwrjhT0st/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8 QAcEv9H //3qvPZoC7UYphUhsHJ+dHl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGr bq/CeP/W//9tNUvbzV2T7kcrrxhJjUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/b bAQBee3f+Leul5Zw0YBMKW7Jk8IvN1cizv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P///// XCz3ExcE3pUXc4Sp2SjCkAFAGK9mfPsc gb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaL M4okjR2MDI8slm3/////1iiOIpGQbpMydor vKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOa NGqfXp4CAqE0oEkcljXd//+/XqVqpH6nF06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3 tdssknS0b7e2 N9+5uNnn9yr/0l/ou1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8y WFVANG6nLEQ6iAUR2/+/wU9j7djsgDTmgVlBSUkx ooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63 ///tM4GwBy+SSrOyN5EoIiQMJtvnETMubb2h/7/9/zZ3N368MjsN+AypxsCIsU8JbIFtIVcbkcap VRL//3/rXeSIfqZxGYFsLLS8NEgBH8CFYIIiRva/bjH/////uiuf HJ0AyEeOAR6qO5gBzaDieFYD yABRgYY3hjxWaEX+Rv//TF9KTQ3KXEULXrzewi dJQU/5oV45uob/v/G 3KjGSymztqlk3VdoMKw5K KbtaPG N3/xJ/4x6hqvZqK/JD owd0lH2X9FqFFtv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//Zu TY4R4nddU0MO974UFMgvWcjlYf9/iYVgDMPyJ54rsD9 ZM1z5/vKotyH/////7ONazAZOJll6vUeP XDpJM0uVBshKBnf68Zr3P8ggXST//y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T 5I FpuBxPGxqsQuFC+Zl5gZ+mk0VuWD4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFs rfMuwdRFNDgUbXytPaBxRrzQ//9EEilRWL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j/ //8LNhLLmcu6PbC3/gCCyrvKkIChUSdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YH TQOUmhJf+v9T7HchpyFTggo+Qm97rI6CEgs4FCr0/6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguzR FWA3OjHI4jRE/////5V5B0lii9SbqWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCi QhKakdkqvgOOyBdFNfPKigF0ATKggfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9 CNkR0TmJvh/o+VOcNtoRVRiEesqGtpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yr KgxPF4tH71IYRvLYFxT///8vlAa2ehbnc0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM 8+rqvk8eC2EKrAkGx/9/q3+64fqRQ3m/ufhm6tf8xypQOzl1OxA5of///61pEPVVRhgLtQis6y2x NGC4qcCk56JeiBwH//+/VVw1Q7aUBPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9 fzZdDDSvEWpccLcKPa2EV7aTcIeBRQg0tTua/y/Q4q9brXtpHMwvRV+E Yaj0C0L6b///zXoNup iv NRx6vN9ZI5JoH0nH+jpZNK43Vn+jErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f 0UP//// /zSabTvDaRJKw4VHmhJ 4KKLzIXoBck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX327na TWeL5fSb//+/9JyV28oNVMgNoM+LZQ7lmb1e9jv30Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydl ImWdv5heCF/U4P/fBZE1DBbOvUO96ndyiB7I vWb63+Avrsngdht1X/krzKEAf2Uaki////8XBD2m j17UnVEhc3OdSQKxl3oCSmRV5sI8RBg+2/9C/ 0as87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VG cC2Ap0MXwMMOfMz9R/5XH6RCYywkypIybBQxv8WN /tGhmng0CCA1SSptuB7DWf+g1NvbHbe9iT9P RNJT9dsb/f/fprdCW1hJgx2qP+KaFKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/ 8tAhPd4pJiEJQwg2TT8NIeQCgv///3cucXoMUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA 6GH7jjmIiHL3NUdCF8FBJq1r6f8X/ji6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85 aoLXRT9EM 7U1Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q 6hImGDH9I8y2VYgARRd3/DVIERBuVdX/G/xEWWyDWaep2zGwJSfNJoXRFu E3KPC/v+3RvPxRzRfp g8aty0C/8P//xZ2fEY sAqYTJQDOrRDJaeSmGL0tGWmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8 BM0xTeYLJy2uiF/g//+fV1I ONItPQqkk3TsH8BgplMwRFGNK8f T +L/T/QRPs9GNN+YQ48qt223KB eUI1YAHBfUK//f+3Q7hXQoLLCb4x6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyA va7f6C/0gFU/C1m5CvS+U8N7RKl9ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWoha Nku2vrhhWABCi3XJTwfJ//+/xKFiHYVOvrtNNPi9F9DZsS0lGYLyEcL+Bf//L/W aVUFCekBiBCaG AVLNHj866oyuR0m/nfv1/wv/2U03FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuTj1w+sGsRN BNhTGDwFqYz8xbhP2aRH/1Lf+kQ5NlOa+fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahv oU73/gsX+JlLyz3x1Ca+Z01Mycw+urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5y n6pcQ7aSYp68g/qPvGK/wv//20qeSlZOn/Ritkqfz575E Msq18zZr0J8//+t/4CcL/6xGGoMaStF kq/KSZKhRa1CnMHo+oF/g///SrHzQifDcx9A423E6G5MentiwNcZAWK1/f///09HZ J8j6ElZmQrK lxoZooOaV7x5xgs0tx+Igzs0mf///y90dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hT Mg6emaMDoSsBBh76XEAPVfsRoeRq6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvM CLyCa4S3WhdDgjJhx0kiA1r+/1/qrafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQ QpbLRdyR+L/FG51LyUWOijO0RhyeCYB1l////99BTlH4A57EbPf3eS dHzuteUfwwaqbbvRj6+VL5 wf+/1P/8jJEuCTNCKzkY1RA0AvGXRs65EUpSbiB86///GWPBahXOVUfI9QEvU80qFlQHGhKVekSj +tb/b/FcABLor0RJRna0ovg2oHSG4lYb/2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHE j82JPta5GNmhcoCCHX//9v+tMsCgxOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+ fEVR7TURBzoZND2CEBf/4SMX/43e+rc0SksYGe sds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumR tplaN/p b/4FCHxj5Ce5KT7V8x9ErfZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6 D/8X/jc5emBTzqzGPFHfpFcRbVc0OMpRFsH0t/jt1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2Gn SzYZ GRvAW+LtEVpAWf2H7Vv8//9QiRRMZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AG p////5dVYWhfkCmM5VC0GXuQgw7/I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6O YUVQ/63+S2VwaoDkfQYnwFGe7OI3PaU J2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/ LLxJc4gntpiaC/UaK2y0k4McA07edP9f4P9IO4Cq/9ePR1yE1WwqNfcN1nqFYcqy/CX/////29jl 6Ze Qd4k5UZKpSreasJzuzNRX5XFcY08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOx VC3/X1jos7cE6v0YNXbMzATUwveK6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80qNEna 6Gd SuskprHuTWHVfm8OXaz3tNSkulFh EB3LlP//b/+4Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2PK2t xP9f4oaHwuEa4FCavLfHS PqgBgRoRv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbF C cw4puF+q7jjZzY01HWouUl/g/zc8c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fgg RBlhSRylof///1gvbnmqZzwxGGM0pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhB vx8SJDX///9GRi4oLvK37fxOFjMoRlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P// L1YkLDERaClMCfB+mi9wMQd3JEjSL/Uv7S4iY7+nn5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQv IiD+Lr8JgP9WQK0lNC05DyAslv+/wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgN Ll0NKCMzIDM4c8RunCHYALggTi70//8zEkkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hc AhcgLcTf4P9/Sob3JG0ATg4xWwokOE/mmB2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/Q UVJ18wt4RVZIQIMJU0xDMkm3v0j/GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3 EU17pf7//2lRRhHPZFpHQi1uGFZh7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqR WJ6IW8l/f8vLQMg 9qUqTQoBV4FBwSC6Rc1xQo/MiQN5RhRhviGoY/+3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCa NEbKX8KvvU8zrPlBK90O2BFQgQwyr ioOpS7BBzKlcIhzM0zhHdi3ukk9wo41NciEL4jCQvaEDDRh ABxMC/y3f8KAQ8C8QbKVwpBAzFVuwrz5TkrxRu7LQwOUpLaoIov+0v8N9 EPCg0XIRsKGRcIINrBA jqgNl9i67xYfyLb4NanLKW3NQDbBwm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmY t98a5f9MI0iBNQTKJ8 zFdd92hXEY67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3 278zN0bIQsKCRaqZEC 0gqAJEBeaq+b4AuZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJup B7dJqvQjAHVBCgQTD5yPUf8X9gUNDUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8t aPCHIoGsYCy21Q9IKBAMQedqtbbAAs6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAk UQW/aSYgqBwBRmluZENEAaDybG9zZRtEzN4V1FNpemUX73/7TEwRQQ5NYXBWaWV3T2YPbm9hbw5V bm0QLgNycyJud8MvS0VudhBvbnario5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKs tVcaC1FD otu697ELe3BeZy1Mw25fIH5MaW JyTnlBIfZMULRQYyhLxkQ5tv1iYWx BbAZjWExhtz3sVNMqTXUD eCgbm7VbbBdyYw9+sHQQB/vnWlYdRkNvcHnFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTf cFAvaA1hCwrDVytYRB2zt0VE8W/KkbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8v mY33hg 27BWVwoTZCN+LCw7AzblqcZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNr Q4VvT0RyAeNkZUN op9xdRGw0TW9CeXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbt cEYmXL0TGYRDm DDoOm5FTLisMGkJaZwWpCImBD pNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXH HuObwGcbS2V5DE9w69yjazELRWoOgFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6H c2UwijcXa4xyEPYHaXNkvfZcCXoZ 8s4QFKJ4rltQCCI5N6ErMyphKiECSg9ms1TNIAGhVVwPFrDf TkJ1ZmZBDwtMb3f2GbYjd3ZJcpQjdwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQ A6tlWZYPCRRzOb//hLw8UEVMAQPgAA8BCwEHrnvSbBNyKoAyBBADgmxn sZA1CwIzBJlb0s0HDN Ae NHvZG9gQBwYAwHkIQIBbZHgCGAVGuMJ2K2R4AR4uL9iToJikcJDrNn+7 sAQjIAtgLmRhdGGYI+5C usH7Iid2 QL3NYBuFLuUJA MPABny/KXs0J0AbsHsNlAAASkE8CQA AAP8AAAAAAGC+AJBQAI2+AID/ /1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHo Pu/BHbEcAB23PvdQmL HoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBB Adt1B4seg+78EdsRyQHbc+91CYseg+78Ed tz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX3 6WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB 6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAA lYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q 5 V/5 aQ5QAA CcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAA AAAAAAACAAEAAABAAACAAgAAAGgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAADQAACAqAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAAAAAABADAA 4MAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAA gIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACIiIiIiIiIiIiIiIiIg AAAj////////////////4AAAIf///////////////eAAACPf/////// / /////9/gAAAj/f////////////3/4AAAI//f///////////f/+AAACP//f/////////9///gAAA j///f////////3///4AAAI////f///////f///+AAACP//93d3d3d3d3f///gAAAj//3f39/f39/ f3f//4AAAI//d/f39/f39/f3f/+AAACP939/f39/f39/f3f/gAAAh3f39/f39/f39/ f3d4AAAI9/ f39/f39/f39/f3+AAACP////////////////AAAAC P//////////////8AAAAACP//////////// /wAAAAAACP////////////AAAAAAAACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP ////////AAAAAAAAAAAACP//////8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////// ///////AAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAA A8AAAAPAAAAD wAAAA8AAAAPAAAADwAAAB+AAAA/wAAAf+AAAP/wAAH/+AAD//wAB//+AA///wAf//+AP//////// /////////8jDAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+ P8A AI+PiIiPjwAAiPf39/f4AACPf39/f38AAAj39/f38AAAAI9/f38AAAAACPf38AAAAAAAiIiAAAAA A AAAAAAAAAAAAAAAAAAA//8AAP//AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOAD AADwBwA A+A8AAPwfAAD//wAA//8AAPDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEA AAIAAAAAAAAAAAAAAAAAAAC89QAAjPUAAAAAAAAAAA AAA AAA AMn1AACc9QAAAAAAAAAAAAAAAAAA 1vUAAKT1AAAAAAAAAAAAAAAAAADh9QAArP UAAAAAAAAAA AAAAAAAAOz1AAC09QAAAAAAAAAAAA AA AAAAA AAAAAAAAAD29QAABPYAABT2AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAA AABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIu ZGxsAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3Nl S2V5AAAAbWVtc 2V0AAB3c3ByaW50ZkEAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAv/04KICqx6x Apjb yv/vz1b+TMABAia+wv1lACL887b4xWecfDg4YZLGmGOEO DhhVnsWQFQ4OGejBaAw63pZf7hoQUnr11ndW6uh16OopobolR6wC9d/r2PXf6Czv76jrcRHrf4Fl /xiePxrxnvfR6J5XX7qey4qZgWxd8Z7X7cr0IvnXBFRN0RtLYucbyj3JG8TTLd+ojikEEY1qxE0i zmm8gP2cZIUTmX1aAYb/BpOZhXGNhmZNKIZnqlCZyq1PDXpWTeI9h5D9Q6Jj4jks6F6VYbHiv6/m 4vZpiP0Eod1yH45XggRDrp0jSLOd2as unSO4oJ3XYJuCYGyunSMgx yMVfKPM39JPzNuJD9MvVjvM 01mazP2/mR4hFIPTJh8w4Q8kkk9Gf/MOyt1UDj PaTg7W/qYgObiLEcZG6g7Fig1p2sEtmb5M0IYW //yZtI2xnCU7qoY8+ 6SGHzpRhgM1+/qq7H4KmZzxCnzslp6Ff7cKkx7xFW8YhBVCLzoKmY8Q+8qr fRSLvv4L8L5vFARYWZ/lNCALtxA6 FCda0AuFQQ9vhdv6n/o4R5+2WhWAXvFLn/NoYIBPdbGAQCia gGHlp3JlZnidWaMmnYNY1Z0m7AqCLqNinaNoi50isu+dvwQYUz12E7x1w+9sarujvPiFQrz3285s aoji/KEBrvyhmE0nianrGN5XNXRmnh10Zp5ydGZZYnRiVwV0Zlll0v2udye260EfT2jGcbflKBjh Fdpe4SfxfPpWCtJPENgY4RXYb8UUf5/2/+uAAu2igCMuAIAPugGf9OZwgCEqrJ+y+FU0zTTtxPTF Nh9eP9Pbiv5mxPXHrdsLERjEgtin2wPJBK+hJK gAPBVfQHt+PV/WyMBf1sjQQGZ+SV/q+QBARRn0 b3i1fp 9JWZGfSzG8n8E2j4C9TN+AsIblnxz2s4ANVq6yZTmUXVnnuV0QR1ZCXx7PQgaAGEJUzZxd q8WVHCyhEjy29cbMjQ8xzIzRsszlCyPTesp0WJl6CsyPBiuS/92+sm4 XuF2ILdxCXe0oXaGpEV2G 1nUcJkv6XVK52UJUP4xyJYkVnQtwpZ1mC8SdGVcJghYP9YJqbDyCQc qvnWbl kbDz6n9ftD9uXxXQ 3V+0Pi5fOcQzQJepgNTcmKWMy6YucTSJz558NOKe7kUTnvs8aZ5d/Qye8q3ugQVgB4FCOgBxsFJp nmpnkp5qnHeedwKHnlgZ+55YGXaedaiYnoyUjrCu5o1fZMgDQP0YXUCfDLNAlxr3HudRvkCXH9JA 7bJJ/SjraBLu/vESbyEKEs7ZzpkHpm4NERAuEm8lSg0ZA OpxOOslnv0ZkJ579cSe3t3unu PBz57Q oGmBAR9+nuKKxyNmmrvTX3snzCUU2R +/ALDTXmgezCFL98yOXk/TvkjrdkQC2BiBUaLYIkgZmXp/ WZmd9BO Zi/QD2CBiBpkHkDlvFOwLn2uzU59wqMafRxX gny7PxJ8tGOyAzo2DgHAXqwwGeenNiV0m /D+LrSr72qYmWrct48nDhQwo4xcM0d5pLxva5cDVLnzA3c8J3yo73S/grOAvmElWLwPo/NCeJ2MO 848G/sJuPvFjlc0OChCdDp53XPEwdnrxHkeCDsKV/VBLAQIUAAoAAAAAAAp24jLS5pG0wHAAAMBw AABqAAAAAAAAAAAAIAAAAAAAAAB0cmFuc2NyaXB0Lmh0bSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAg ICAgICAgICAu c2NyUEsFBgAAAAABAAEAmAAAAEhxAAAAAFBLAQIUAAoAAAAAAAp24jK/Tydd9nEA APZxAAAOAAAAAAAAAAAAIAAAAAAAAAB0cmFuc2Ny aXB0LnppcFBLBQYAAAAAAQABADwAAAAicgAA AAA= ------=_NextPart_000_0007_FA39288F.F482A9C7-- From owner-v6ops@ops.ietf.org Mon Jul 04 11:10:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSax-0004ch-CZ for v6ops-archive@megatron.ietf.org; Mon, 04 Jul 2005 11:10:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28929 for ; Mon, 4 Jul 2005 11:10:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpSWm-0007um-T7 for v6ops-data@psg.com; Mon, 04 Jul 2005 15:06:32 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpSWj-0007uA-Qz for v6ops@ops.ietf.org; Mon, 04 Jul 2005 15:06:30 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Jul 2005 08:06:29 -0700 X-IronPort-AV: i="3.93,257,1115017200"; d="scan'208"; a="287704149:sNHT80824412" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j64F6Nod016577; Mon, 4 Jul 2005 08:06:23 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j64F5e3q028299; Mon, 4 Jul 2005 08:05:40 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Status check Date: Mon, 4 Jul 2005 08:06:25 -0700 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120489540.999666"; x:"432200"; a:"rsa-sha1"; b:"nofws:4575"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KSGsOXxFQpdK5KENORhHFhOwmXfvLGTnGpAWQpykDJ3izQS/w8w7mqy1s/NhRqh/kb822ta/" "XEh2orOhpyaDc2l2LUF5df0Q0VL5qKTKuYC3Cs4H+kGt1CkVT4J6F/xvzRSta5H5Kncks6nagzB" "EOyzXJ7sIn3oFUIUHDbEjZ08="; c:"From: Fred Baker "; c:"Subject: Fwd: Status check"; c:"Date: Mon, 4 Jul 2005 08:06:25 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI I sent the following to the various authors of v6ops drafts on Friday. I have not heard from them yet. However, it represents my understanding of our status at this point, with the exception that over the weekend the network architecture protection draft finished last call and I am now expecting an updated draft from those authors as well. I have not had any requests for time in the working group meeting, and will not allocate any unless someone tells me they want it. Commentary solicited... Fred Begin forwarded message: > From: Fred Baker > Date: July 1, 2005 12:34:24 PM PDT > To: > Cc: Lindqvist Erik Kurt , David Kessens > > Subject: Status check > > I believe that this is the current document status. Am I correct? If > so, a number of you have until 17 July to produce an update, and Tim > has until 11 July on vlan-usage. > > I am starting to put together an agenda for the coming meeting. Any of > you that want agenda time should let me know now, please. AFAIK, the > only documents that need discussion are the Secure Tunnels and the > Enterprise Analysis draft, both of which are likely to go to Last Call > after the the IETF meeting. After that, we will have no work on the > table beyond pushing documents through the IESG process. If that > status remains in the fall, I will request a one hour slot for a > status update; if other new work is presented, we will take time to > discuss it and decide whether it is appropriate to the working group. > In any event, we will need to decide whether we need to keep the > working group open (OK with me either way, and I can see good > arguments either way). > > Ralph Droms is considering requesting an hour for a BOF. I have > included his proposed BOF Charter at the end of this note. If we plan > to spend an hour on the two drafts and on WG process, that leaves an > hour available out of the two hour slot I have requested. Hmmmmmm. Is > there any problem with having that BOF simply be part of the v6ops > meeting? > > Status, per my notes: > draft-chown-v6ops-renumber-thinkabout-02.txt > State: I-D Exists > Expires: November 2005 > draft-ietf-v6ops-bb-deployment-scenarios-02.txt > State: Awaiting update to last call comments > Expires: November 2005 > draft-ietf-v6ops-ent-analysis-02.txt > State: Awaiting update to last call comments > Expires: December 2005 > draft-ietf-v6ops-nap-01.txt > State: In WG Last Call > Expires: December 2005 > draft-ietf-v6ops-natpt-to-exprmntl-00.txt > State: Awaiting update to last call comments > Expires: Tuesday > draft-ietf-v6ops-security-overview-00.txt > State: Awaiting update to last call comments > Expires: November 2005 > draft-palet-v6ops-ipv6security-02.txt > State: ID Exists, no work planned > Expires: August 2005 > draft-palet-v6ops-tun-auto-disc-03.txt > State: ID Exists, no work planned > Expires: July 2005 > draft-tschofenig-v6ops-secure-tunnels-03.txt > State: Awaiting -ietf- document for discussion > Expires: June 2005 > draft-chown-v6ops-vlan-usage-03.txt > State: Awaiting update to last call comments > (Tim/Pekka, 10 May) > Exires: already expired > > draft-ietf-v6ops-3gpp-analysis-11.txt > State: RFC Editor's Queue > draft-ietf-v6ops-mech-v2-07.txt > State: RFC Editor's Queue > draft-ietf-v6ops-renumbering-procedure-05.txt > State: RFC Editor's Queue > > > On Jul 1, 2005, at 6:05 AM, Ralph Droms wrote: > >> One of the suggestions that came out of the meetings between the >> project >> team and Cisco this week was to schedule a BOF at IETF63 to discuss >> renumbering. I've written a first draft of a request; let me know if >> you think a BOF would be a good idea, and any feedback you have on the >> request. >> >> - Ralph >> >> ===== >> >> Discussion of IPv6 Network Renumbering >> -------------------------------------- >> >> Baker, et al., have written a description a process for IPv6 network >> renumbering in "Procedures for Renumbering an IPv6 Network without a >> Flag Day" . Teams from >> University of Southampton, the JOIN Project at University of Muenster, >> Renater, PSNC and Loria-Inria have conducted a series of experiments >> in network renumbering, based on the process described by Baker. >> Results from the study include operational experience with the network >> renumbering procedure, identification of the effects of network >> renumbering on network management tools and other applications and >> recommendations for updates to the network renumbering procedure, and >> advice network administrators, application developers and others to >> ameliorate the effects of network renumbering. >> >> The purpose of this BOF is to disseminate results and conclusions from >> these experiments, stimulate discussion of IPv6 network renumbering >> and consider future work in this area. The draft agenda for the BOF >> is: >> >> Introduction Ralph Droms ( 5 >> mins) >> >> Prior art and tools, backbone renumbering JOIN/Univ. Muenster ( 5 >> mins) >> and BGP issues, SOHO renumbering >> >> Enterprise experiments and recommendations Univ. Southampton ( 5 >> mins) >> >> Router renumbering protocol Renater ( 5 >> mins) >> >> Impact of renumbering on management tools PSNC ( 5 >> mins) >> >> Maintaining management plane during Loria-Inria ( 5 >> mins) >> renumbering, monitoring renumbering >> >> Conclusions Ralph Droms ( 5 >> mins) >> >> Discussion (25 >> mins) >> > From owner-v6ops@ops.ietf.org Tue Jul 05 02:28:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpguc-0006Cz-3D for v6ops-archive@megatron.ietf.org; Tue, 05 Jul 2005 02:28:06 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23328 for ; Tue, 5 Jul 2005 02:28:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpgpS-0002U4-CE for v6ops-data@psg.com; Tue, 05 Jul 2005 06:22:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpgpQ-0002Ti-Vo for v6ops@ops.ietf.org; Tue, 05 Jul 2005 06:22:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j656KZ318512; Tue, 5 Jul 2005 09:20:35 +0300 Date: Tue, 5 Jul 2005 09:20:35 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: "'v6ops@ops.ietf.org '" Subject: Re: Fwd: Status check In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 4 Jul 2005, Fred Baker wrote: >> draft-ietf-v6ops-natpt-to-exprmntl-00.txt >> State: Awaiting update to last call comments >> Expires: Tuesday According to the ID tracker, this has been in "Waiting for AD go-ahead" since April: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12750&rfc_flag=0 .. I don't recall any last call comments that needed to be addressed? -- 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 Jul 05 03:12:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DphbA-0002KH-Fj for v6ops-archive@megatron.ietf.org; Tue, 05 Jul 2005 03:12:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04070 for ; Tue, 5 Jul 2005 03:12:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DphYE-0006zR-OB for v6ops-data@psg.com; Tue, 05 Jul 2005 07:09:02 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DphYC-0006yY-Nw for v6ops@ops.ietf.org; Tue, 05 Jul 2005 07:09:00 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DphY5-00040Y-FQ; Tue, 05 Jul 2005 08:08:53 +0100 Message-ID: <42CA3242.9000603@dial.pipex.com> Date: Tue, 05 Jul 2005 08:09:54 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Fred Baker , "'v6ops@ops.ietf.org '" Subject: Re: Fwd: Status check References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There was one last call comment to address and a new version will be out today. Regards, Elwyn Pekka Savola wrote: > On Mon, 4 Jul 2005, Fred Baker wrote: > >>> draft-ietf-v6ops-natpt-to-exprmntl-00.txt >>> State: Awaiting update to last call comments >>> Expires: Tuesday >> > > According to the ID tracker, this has been in "Waiting for AD > go-ahead" since April: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12750&rfc_flag=0 > > > .. I don't recall any last call comments that needed to be addressed? > From owner-v6ops@ops.ietf.org Tue Jul 05 18:52:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwHc-0006Ny-73 for v6ops-archive@megatron.ietf.org; Tue, 05 Jul 2005 18:52:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11968 for ; Tue, 5 Jul 2005 18:52:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpwEx-000FZy-1U for v6ops-data@psg.com; Tue, 05 Jul 2005 22:50:07 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DpwEv-000FZH-Gn for v6ops@ops.ietf.org; Tue, 05 Jul 2005 22:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DpwEr-0007bd-Kn; Tue, 05 Jul 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-security-overview-01.txt Message-Id: Date: Tue, 05 Jul 2005 18:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : IPv6 Transition/Co-existence Security Considerations Author(s) : E. Davies, et al. Filename : draft-ietf-v6ops-security-overview-01.txt Pages : 34 Date : 2005-7-5 The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-security-overview-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-security-overview-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-5171213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-security-overview-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-security-overview-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-5171213.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 06 15:55:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFzQ-0002hB-5i for v6ops-archive@megatron.ietf.org; Wed, 06 Jul 2005 15:55:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11914 for ; Wed, 6 Jul 2005 15:55:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqFuH-000Dvn-RD for v6ops-data@psg.com; Wed, 06 Jul 2005 19:50:05 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqFuF-000DuU-0G for v6ops@ops.ietf.org; Wed, 06 Jul 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DqFuD-00087U-Tw; Wed, 06 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-natpt-to-exprmntl-01.txt Message-Id: Date: Wed, 06 Jul 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : Reasons to Move NAT-PT to Experimental Author(s) : C. Aoun, E. Davies Filename : draft-ietf-v6ops-natpt-to-exprmntl-01.txt Pages : 25 Date : 2005-7-6 This document discusses general issues with all forms of IPv6-IPv4 translation and specific issues related to the form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These specific issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Standards Track to Experimental status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-natpt-to-exprmntl-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-6113844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-natpt-to-exprmntl-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-6113844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 06 16:03:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqG6q-0007Kq-O4 for v6ops-archive@megatron.ietf.org; Wed, 06 Jul 2005 16:03:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15091 for ; Wed, 6 Jul 2005 16:03:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqG4a-000F4F-CM for v6ops-data@psg.com; Wed, 06 Jul 2005 20:00:44 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqG4Y-000F3k-7q for v6ops@ops.ietf.org; Wed, 06 Jul 2005 20:00:42 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2005 13:00:42 -0700 X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="647360245:sNHT30016740" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j66K0fvM013050 for ; Wed, 6 Jul 2005 13:00:41 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j66Jxkhl011516 for ; Wed, 6 Jul 2005 12:59:46 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9aec9b9cd9997a3e0d45438d8599890a@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: I-D ACTION:draft-ietf-v6ops-security-overview-01.txt Date: Wed, 6 Jul 2005 13:00:39 -0700 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120679986.559316"; x:"432200"; a:"rsa-sha1"; b:"nofws:4214"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VpseOl9OXhN7gi4kjflghMUv8IhPN4z/fvMmnjjqcuArNR5Jyh3rdWdYS2qjBRa9sLK5QFr2" "f7hW+9DzcFnpkkFOFikvA8EPO+nYdGHdlRbw0CxgNXkjATwU8ewqJ+uWt+j1Fc7Iq6JnvUNg/Fx" "hSJK/eUaeqnRVHWljMH+Kd/o="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-ietf-v6ops-security-overview-01.txt "; c:"Date: Wed, 6 Jul 2005 13:00:39 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am presuming that this draft answers all last call comments. Would those who commented please review it, ensure that they agree that it does, and reply either to the list or to the authors, Kurt, and myself? On Jul 5, 2005, at 3:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Transition/Co-existence Security Considerations > Author(s) : E. Davies, et al. > Filename : draft-ietf-v6ops-security-overview-01.txt > Pages : 34 > Date : 2005-7-5 > > The transition from a pure IPv4 network to a network where IPv4 and > IPv6 co-exist brings a number of extra security considerations that > need to be taken into account when deploying IPv6 and operating the > dual-protocol network and the associated transition mechanisms. > This > document attempts to give an overview of the various issues grouped > into three categories: > o issues due to the IPv6 protocol itself, > o issues due to transition mechanisms, and > o issues due to IPv6 deployment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security- > overview-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-security-overview-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-security-overview-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ----------------------------------------------------------------------- > -- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ----------------------------------------------------------------------- > -- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a > seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j65MrC73018978 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > --OtherAccess-- From owner-v6ops@ops.ietf.org Wed Jul 06 16:03:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqG7H-0007aF-QM for v6ops-archive@megatron.ietf.org; Wed, 06 Jul 2005 16:03:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15172 for ; Wed, 6 Jul 2005 16:03:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqG5N-000FAB-1s for v6ops-data@psg.com; Wed, 06 Jul 2005 20:01:33 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqG5M-000F9u-0I for v6ops@ops.ietf.org; Wed, 06 Jul 2005 20:01:32 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2005 13:01:31 -0700 X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="647360475:sNHT30309888" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j66K1VvM013719; Wed, 6 Jul 2005 13:01:31 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j66Jxkhm011516; Wed, 6 Jul 2005 13:00:36 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8aaaeebbf07c33d43ca321568fe31a3c@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: I-D ACTION:draft-ietf-v6ops-natpt-to-exprmntl-01.txt Date: Wed, 6 Jul 2005 13:01:29 -0700 To: David Kessens , "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120680036.476260"; x:"432200"; a:"rsa-sha1"; b:"nofws:4238"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ZpBvQsbeoJ061+XcllB5eYuDg3JI9pfpBZlqxWw0fikfRWp5WIXPZUkM1/Ui1Z1kZ4D3SC7S" "b0Ym99ghPG/Uo1z4Q/AvRdvrg0d2x6uaqrSrFIeu4aEPtKjZjbLdrcNyrGkWw8hQxpu7zGNODa5" "MF1PomZmptym8+WwcAUuT+c4="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-ietf-v6ops-natpt-to-exprmntl-01.txt "; c:"Date: Wed, 6 Jul 2005 13:01:29 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am presuming that this draft answers all last call comments. Would those who commented please review it, ensure that they agree that it does, and reply either to the list or to the authors, Kurt, and myself? On Jul 6, 2005, at 12:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Reasons to Move NAT-PT to Experimental > Author(s) : C. Aoun, E. Davies > Filename : draft-ietf-v6ops-natpt-to-exprmntl-01.txt > Pages : 25 > Date : 2005-7-6 > > This document discusses general issues with all forms of IPv6-IPv4 > translation and specific issues related to the form of IPv6-IPv4 > protocol translation mechanism implemented by the Network Address > Translator - Protocol Translator (NAT-PT) defined in RFC 2766. > These > specific issues are sufficiently serious that recommending RFC 2766 > as a general purpose transition mechanism is no longer desirable, > and > this document recommends that the IETF should reclassify RFC 2766 > from Standards Track to Experimental status. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to- > exprmntl-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-natpt-to-exprmntl-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ----------------------------------------------------------------------- > -- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ----------------------------------------------------------------------- > -- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a > seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j66JrZbj004338 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > --OtherAccess-- From owner-v6ops@ops.ietf.org Wed Jul 06 21:23:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqL7N-0008ML-1q for v6ops-archive@megatron.ietf.org; Wed, 06 Jul 2005 21:23:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22403 for ; Wed, 6 Jul 2005 21:23:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqL3u-000GPJ-HV for v6ops-data@psg.com; Thu, 07 Jul 2005 01:20:22 +0000 Received: from [203.103.165.130] (helo=smta09.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqL3r-000GOj-Un for v6ops@ops.ietf.org; Thu, 07 Jul 2005 01:20:20 +0000 Received: from ubu.nosense.org ([210.84.230.119]) by smta09.mail.ozemail.net with ESMTP id <20050707012017.TQWX1100.smta09.mail.ozemail.net@ubu.nosense.org>; Thu, 7 Jul 2005 01:20:17 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id B7C2D62AAE; Thu, 7 Jul 2005 10:50:15 +0930 (CST) Date: Thu, 7 Jul 2005 10:50:15 +0930 From: Mark Smith To: Fred Baker Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-security-overview-01.txt Message-Id: <20050707105015.1f1b308e.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <9aec9b9cd9997a3e0d45438d8599890a@cisco.com> References: <9aec9b9cd9997a3e0d45438d8599890a@cisco.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 6 Jul 2005 13:00:39 -0700 Fred Baker wrote: > I am presuming that this draft answers all last call comments. Would > those who commented please review it, ensure that they agree that it > does, and reply either to the list or to the authors, Kurt, and myself? > I'm happy with the changes that were made regarding my comments. Regards, Mark. From owner-v6ops@ops.ietf.org Mon Jul 11 10:53:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drzf4-0006HT-4c for v6ops-archive@megatron.ietf.org; Mon, 11 Jul 2005 10:53:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17564 for ; Mon, 11 Jul 2005 10:53:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Drzbl-000Nvy-H0 for v6ops-data@psg.com; Mon, 11 Jul 2005 14:50:09 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Drzbj-000Nuw-CS for v6ops@ops.ietf.org; Mon, 11 Jul 2005 14:50:08 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Drzbd-0000Mw-Ri; Mon, 11 Jul 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt Message-Id: Date: Mon, 11 Jul 2005 10:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : Using IPsec to Secure IPv6-in-IPv4 Tunnels Author(s) : P. Savola, et al. Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt Pages : 21 Date : 2005-7-11 This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ipsec-tunnels-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-11102533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipsec-tunnels-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-11102533.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Jul 11 11:15:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds00X-0006YH-JO for v6ops-archive@megatron.ietf.org; Mon, 11 Jul 2005 11:15:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20853 for ; Mon, 11 Jul 2005 11:15:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Drzzb-0000QI-Iu for v6ops-data@psg.com; Mon, 11 Jul 2005 15:14:47 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DrzzW-0000Pe-Ga for v6ops@ops.ietf.org; Mon, 11 Jul 2005 15:14:42 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DrzzU-0006Wn-GN; Mon, 11 Jul 2005 16:14:40 +0100 Message-ID: <42D28D22.5030707@dial.pipex.com> Date: Mon, 11 Jul 2005 16:15:46 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'v6ops@ops.ietf.org '" CC: Mohacsi Janos Subject: New draft available: Best Current Practice for Filtering ICMPv6 Messages in Firewalls Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. Best Current Practice for Filtering ICMPv6 Messages in Firewalls draft-davies-v6ops-icmpv6-filtering-bcp-00.txt We sent this draft to the I-D editor just before the deadline today and hopefully it will be available from the server in due course, but in the meantime it can be downloaded from either: http://www.kurtis.se/draft-davies-v6ops-icmpv6-filtering-bcp-00.txt or http://skye.ki.iif.hu/~mohacsi/draft-davies-v6ops-icmpv6-filtering-bcp-00.txt This draft is a (considerable) expansion of a section that was previously in the Security Overview draft relating to exactly how you should filter the large number of ICMPv6 messsages in a site firewall. It is referenced in the latest version of the security overview. It also builds on some work that Janos has done in the EU 6net project and other views of how ICMPv6 should be treated in firewalls. I hope to be able to discuss it at the Paris meeting. Regards, Elwyn From owner-v6ops@ops.ietf.org Mon Jul 11 12:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds16U-0002U4-AE for v6ops-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:25:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26034 for ; Mon, 11 Jul 2005 12:25:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds14t-00060M-Ke for v6ops-data@psg.com; Mon, 11 Jul 2005 16:24:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds14p-0005zc-Kk for v6ops@ops.ietf.org; Mon, 11 Jul 2005 16:24:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6BGO7i32628; Mon, 11 Jul 2005 19:24:07 +0300 Date: Mon, 11 Jul 2005 19:24:07 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Using IPsec to Secure IPv6-in-IPv4 Tunnels > Author(s) : P. Savola, et al. > Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt > Pages : 21 > Date : 2005-7-11 > > This document gives guidance on securing manually configured IPv6-in- > IPv4 tunnels using IPsec. No additional protocol extensions are > described beyond those available with the IPsec framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt The authors believe that this version addresses all comments sent to date. There has been substantial revision in the draft. Those who previously read it are encouraged to take another look and see if it's better. If you haven't taken a look yet, now would be a good chance. The issue list is at: http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html There's also a htmlwdiff there. -- 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 Jul 11 14:12:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2lN-0004xY-Ds for v6ops-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:12:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06061 for ; Mon, 11 Jul 2005 14:12:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds2jB-000F0h-9J for v6ops-data@psg.com; Mon, 11 Jul 2005 18:10:01 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds2j7-000EzJ-Eg for v6ops@ops.ietf.org; Mon, 11 Jul 2005 18:09:57 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2005 11:09:56 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="300828635:sNHT98194062" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6BI9sVX027238 for ; Mon, 11 Jul 2005 11:09:55 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6BI7kRg014772 for ; Mon, 11 Jul 2005 11:08:41 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <123626f7a57245b527207dca447c3b3f@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Fwd: New draft available: Best Current Practice for Filtering ICMPv6 Messages in Firewalls Date: Mon, 11 Jul 2005 11:09:52 -0700 X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121105321.506222"; x:"432200"; a:"rsa-sha1"; b:"nofws:1233"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"hgg/NV7NlHBlZ4GR6+bIhEBnkukZc1CL2RbWR+e1qFydiNal2tUDuyL5ppyJ+TaE30eAB7P8" "fXEDvQfldgLgNGV5axyWtl+oYLG442GHr7UFKMG2Z/vBpczMORnqM+bgCmjtq5ztm9xyg/1r4rm" "xmT5XM65tUuAb4m85B516FYM="; c:"From: Fred Baker "; c:"Subject: Fwd: New draft available: Best Current Practice for Filteri" "ng ICMPv6 Messages in Firewalls"; c:"Date: Mon, 11 Jul 2005 11:09:52 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please review this for discussion in Paris. It is in part an extract from draft-ietf-v6ops-security-overview-00.txt, with some augmentation, and is referred to by draft-ietf-v6ops-security-overview-01.txt. > From: Elwyn Davies > Date: July 11, 2005 8:15:46 AM PDT > To: "'v6ops@ops.ietf.org '" > Cc: Mohacsi Janos > Subject: New draft available: Best Current Practice for Filtering > ICMPv6 Messages in Firewalls > > Hi. > > Best Current Practice for Filtering ICMPv6 Messages in Firewalls > draft-davies-v6ops-icmpv6-filtering-bcp-00.txt > > > We sent this draft to the I-D editor just before the deadline today > and hopefully it will be available from the server in due course, but > in the meantime it can be downloaded from either: > > http://www.kurtis.se/draft-davies-v6ops-icmpv6-filtering-bcp-00.txt > or > http://skye.ki.iif.hu/~mohacsi/draft-davies-v6ops-icmpv6-filtering- > bcp-00.txt > > This draft is a (considerable) expansion of a section that was > previously in the Security Overview draft relating to exactly how you > should filter the large number of ICMPv6 messsages in a site firewall. > It is referenced in the latest version of the security overview. > > It also builds on some work that Janos has done in the EU 6net project > and other views of how ICMPv6 should be treated in firewalls. > > I hope to be able to discuss it at the Paris meeting. > > Regards, > Elwyn > From owner-v6ops@ops.ietf.org Mon Jul 11 15:52:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds4KW-0006l4-BR for v6ops-archive@megatron.ietf.org; Mon, 11 Jul 2005 15:52:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16015 for ; Mon, 11 Jul 2005 15:52:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds4I9-000MWF-4K for v6ops-data@psg.com; Mon, 11 Jul 2005 19:50:13 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds4I8-000MVz-Dl for v6ops@ops.ietf.org; Mon, 11 Jul 2005 19:50:12 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ds4Hy-0001Tc-HT; Mon, 11 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-03.txt Message-Id: Date: Mon, 11 Jul 2005 15:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : IPv6 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-03.txt Pages : 36 Date : 2005-7-11 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ent-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-11142932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-11142932.I-D@ietf.org> --OtherAccess-- --NextPart-- From 213ligouri@about.com Tue Jul 12 18:55:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTeh-0004oS-7I for v6ops-archive@megatron.ietf.org; Tue, 12 Jul 2005 18:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28304 for ; Tue, 12 Jul 2005 18:55:08 -0400 (EDT) Received: from ca-redbch-cuda1-c6b-140.stmnca.adelphia.net ([68.68.204.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DsU6s-0000mB-R3 for v6ops-archive@ietf.org; Tue, 12 Jul 2005 19:24:25 -0400 Message-ID: <165a01c5872f$dc7c1209$c2b0b3dc@about.com> From: "Vanessa J. Smith" <213ligouri@about.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gd2hvbGVzYWxlIHByaWNl?= Date: Tue, 12 Jul 2005 22:19:59 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_490A0AB7.7E20CF44" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_490A0AB7.7E20CF44 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E00D2617.0D59DC77" ------=_NextPart_001_0001_E00D2617.0D59DC77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software possible for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Visio 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... To view full list of products go: http://www.soft-paradise.com Regards, Vanessa J. Smith _____________________________________________________ To stop further mailings, go here _____________________________________________________ ------=_NextPart_001_0001_E00D2617.0D59DC77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get all the software possible for unbelievably low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Visio 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... To view full list of products go:

http://www.soft-paradise.com

Regards,
Vanessa J. Smith


_____________________________________________________
To stop further mailings, go here
_____________________________________________________

------=_NextPart_001_0001_E00D2617.0D59DC77-- ------=_NextPart_000_0000_490A0AB7.7E20CF44-- From owner-v6ops@ops.ietf.org Wed Jul 13 15:53:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsnI8-0003pn-LR for v6ops-archive@megatron.ietf.org; Wed, 13 Jul 2005 15:53:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15747 for ; Wed, 13 Jul 2005 15:53:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsnF6-0004mk-8t for v6ops-data@psg.com; Wed, 13 Jul 2005 19:50:04 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsnF5-0004lz-DO for v6ops@ops.ietf.org; Wed, 13 Jul 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsnF3-0003Xm-CV; Wed, 13 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-Id: Date: Wed, 13 Jul 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks Author(s) : T. Chown Filename : draft-ietf-v6ops-vlan-usage-00.txt Pages : 12 Date : 2005-7-13 Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-vlan-usage-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-vlan-usage-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-vlan-usage-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-13104009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-vlan-usage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-vlan-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-13104009.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 13 16:04:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsnSi-00077N-AP for v6ops-archive@megatron.ietf.org; Wed, 13 Jul 2005 16:04:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18298 for ; Wed, 13 Jul 2005 16:04:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsnS2-0006Fn-PE for v6ops-data@psg.com; Wed, 13 Jul 2005 20:03:26 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsnS1-0006FV-Ps for v6ops@ops.ietf.org; Wed, 13 Jul 2005 20:03:25 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2005 22:03:25 +0200 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6DK3LDg019140 for ; Wed, 13 Jul 2005 22:03:22 +0200 (MEST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6DK1xFF001538 for ; Wed, 13 Jul 2005 13:02:00 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <21f795d5474b2b4035d4fee5a385b237@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Date: Wed, 13 Jul 2005 13:03:19 -0700 X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121284920.139016"; x:"432200"; a:"rsa-sha1"; b:"nofws:2612"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HOWVEm8sf9D3Rqc6bXrvi2VF4CBq3B5BMZ1kNkED8qdQD9+zalYdM+93mXZdBn+OtNGQ+8iw" "iCtSNSrXK6Q3bng9ZnQWZHS8k2m518f9HRQ+RrTS73Hh6zJggSsYWCeYXte9ORf0ZIG3Go3/L3n" "qd8viOdVp1CboSTmBtrwQRro="; c:"From: Fred Baker "; c:"Subject: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt "; c:"Date: Wed, 13 Jul 2005 13:03:19 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This passed last call a while ago, and expired immediately afterward. The only change I expected in this was that of the name; mostly, it was reposting for the IESG's benefit. If there are any further comments on this draft, please advise. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 13, 2005 12:50:01 PM PDT > To: i-d-announce@ietf.org > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.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 : Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks > Author(s) : T. Chown > Filename : draft-ietf-v6ops-vlan-usage-00.txt > Pages : 12 > Date : 2005-7-13 > > Ethernet VLANs are quite commonly used in enterprise networks for > the > purposes of traffic segregation. This document describes how such > VLANs can be readily used to deploy IPv6 networking in an > enterprise, > which focuses on the scenario of early deployment prior to > availability of IPv6-capable switch-router equipment. In this > method > IPv6 may be routed in parallel with the existing IPv4 in the > enterprise and delivered at Layer 2 via VLAN technology. The IPv6 > connectivity to the enterprise may or may not enter the site via the > same physical link. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-vlan-usage-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-vlan-usage-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-vlan-usage-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-7-13104009.I-D@ietf.org> From owner-v6ops@ops.ietf.org Thu Jul 14 02:50:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxYU-0001f9-4E for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 02:50:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10779 for ; Thu, 14 Jul 2005 02:50:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsxTq-0002NR-2t for v6ops-data@psg.com; Thu, 14 Jul 2005 06:45:58 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1DsxTk-0002Ln-7g for v6ops@ops.ietf.org; Thu, 14 Jul 2005 06:45:53 +0000 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145180.msg for ; Thu, 14 Jul 2005 08:46:47 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Jul 2005 22:37:52 +0200 Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 08:46:50 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, A couple of comments about this document. 1. Intro. I don't think is correct to say that a major impediment is the high cost and technical complexity. Sorry, but isn't the case, and we must not give this message. In some cases it might be the case, but not in general. I'm working everyday in moving real customers to support native IPv6, and haven't found this situation yet, and not talking about just a dozen of customers. Actually I'm starting to feel that most of the people is afraid of IPv6 because they got this impression. 3 ... It may be better to use instead of adversary "malicious user" or something else ? I mean adversary may seem as "business competitor" or have other connotations, which I guess are not the intended ones ? Regards, Jordi > De: "Internet-Drafts@ietf.org" > Responder a: "Internet-Drafts@ietf.org" > Fecha: Tue, 12 Jul 2005 15:50:03 -0400 > Para: > Asunto: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Security Considerations for the Tunnel Broker > Model > Author(s) : S. Yamamoto, et al. > Filename : draft-yamamoto-v6tc-security-considerations-00.txt > Pages : 9 > Date : 2005-7-12 > > Tunnel brokers must implement protections against a wide variety of > threats. This draft discusses the security considerations for a > configured tunneling configuration mechanism such as that described > by the Tunnel Broker. The emphasis in this document is on > protocol-related security issues. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yamamoto-v6tc-security-consideration > s-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-yamamoto-v6tc-security-considerations-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-yamamoto-v6tc-security-considerations-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-7-12132033.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 14 03:32:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyD2-0004fS-AR for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:32:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13081 for ; Thu, 14 Jul 2005 03:32:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsyCE-0006AY-Fc for v6ops-data@psg.com; Thu, 14 Jul 2005 07:31:50 +0000 Received: from [209.123.233.212] (helo=smtp-out2.oct.nac.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DsyCD-0006AI-Lr for v6ops@ops.ietf.org; Thu, 14 Jul 2005 07:31:49 +0000 Received: (qmail 77536 invoked by uid 0); 14 Jul 2005 03:31:48 -0400 Received: from rfgraveman@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.027209 secs); 14 Jul 2005 07:31:48 -0000 Received: from unknown (HELO webmail.nac.net) (64.21.52.85) by smtp-out2.oct.nac.net with SMTP; 14 Jul 2005 03:31:48 -0400 Received: from 194.7.124.120 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Thu, 14 Jul 2005 03:31:48 -0400 (EDT) Message-ID: <16296.194.7.124.120.1121326308.squirrel@webmail.nac.net> In-Reply-To: References: Date: Thu, 14 Jul 2005 03:31:48 -0400 (EDT) Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: rfgraveman@nac.net To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Jordi, > 3 ... It may be better to use instead of adversary "malicious user" or > something else ? I mean adversary may seem as "business competitor" or > have > other connotations, which I guess are not the intended ones ? The best definition of security I have seen in this context is due to Oded Goldreich, who says, roughly, that, "Security is about making protocols robust against anyone who tries to make them deviate from their intended behavior." "Malicious," to me, means bad or evil, which involves a value judgment. It could be that the one running the protocol is bad, and the one disrupting the protocol is good, or there may be legitimate difference of opinion about which party is good or bad. "Malicious" also has an unfortunate connotation in some security literature, whereby a "passive adversary" only observes the protocol and a "malicious adversary" actively disrupts it. I dislike this usage, but it nevertheless exists. So IMHO, "malicious" has more connotative baggage than "adversary." If you don't like "adversary," then maybe "attacker?" Regards, Richard From owner-v6ops@ops.ietf.org Thu Jul 14 03:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyOb-0002nN-Fh for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:44:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13959 for ; Thu, 14 Jul 2005 03:44:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsyO0-0007AY-Rx for v6ops-data@psg.com; Thu, 14 Jul 2005 07:44:00 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1DsyNz-0007AC-3g for v6ops@ops.ietf.org; Thu, 14 Jul 2005 07:43:59 +0000 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145360.msg for ; Thu, 14 Jul 2005 09:44:46 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 09:43:21 +0200 Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <16296.194.7.124.120.1121326308.squirrel@webmail.nac.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 09:45:13 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Richard, Yes totally agree with you ... Attacker seems to fit much better ;-) Regards, Jordi > De: > Responder a: > Fecha: Thu, 14 Jul 2005 03:31:48 -0400 (EDT) > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt > > Hi Jordi, > >> 3 ... It may be better to use instead of adversary "malicious user" or >> something else ? I mean adversary may seem as "business competitor" or >> have >> other connotations, which I guess are not the intended ones ? > > The best definition of security I have seen in this context is due to Oded > Goldreich, who says, roughly, that, "Security is about making protocols > robust against anyone who tries to make them deviate from their intended > behavior." > > "Malicious," to me, means bad or evil, which involves a value judgment. It > could be that the one running the protocol is bad, and the one disrupting > the protocol is good, or there may be legitimate difference of opinion > about which party is good or bad. > > "Malicious" also has an unfortunate connotation in some security > literature, whereby a "passive adversary" only observes the protocol and a > "malicious adversary" actively disrupts it. I dislike this usage, but it > nevertheless exists. > > So IMHO, "malicious" has more connotative baggage than "adversary." If you > don't like "adversary," then maybe "attacker?" > > Regards, Richard > > ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 14 05:47:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt0Jo-0002qQ-7G for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 05:47:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24360 for ; Thu, 14 Jul 2005 05:47:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt0I1-000JTX-8F for v6ops-data@psg.com; Thu, 14 Jul 2005 09:45:57 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1Dt0Hw-000JMO-MU for v6ops@ops.ietf.org; Thu, 14 Jul 2005 09:45:55 +0000 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145771.msg for ; Thu, 14 Jul 2005 11:46:19 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 11:44:37 +0200 Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <200507141633.HAH39568.ZNBPUBPZtNT@cn.kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 11:46:22 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shu, I don't agree either. I mean, there is no cost for changing any servers, there is no cost for replacing any routers. There may be some minor cases where your infrastructure is so old, and not kept updated, that IPv6 might imply a cost, but the cost is not because IPv6 per-se, but because you don't have a good supplier or an out-dated equipment, etc. My experience show that a good ISP and corporate will have usually their infrastructure up-dated, even with some kind of maintenance contract, which will support IPv6 as an added value, not as a dedicated cost. The only cost that some times it can brought to the table is the expertise for doing it: Training for the people who manages the network basically. Regards, Jordi > De: Shu Yamamoto > Responder a: > Fecha: Thu, 14 Jul 2005 16:33:01 +0900 > Para: , "v6ops@ops.ietf.org" > Asunto: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt > > Hi Jordi; > > Thank you for the comment and correcting the word. > We meant the cost for the replacement of IPv4 network facilities > such as routers, servers etc to IPv6 facilities. But the > technical complexity should not be stated as you pointed out. > > Best Regards, > Shu > > $B$N!"(B > "Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations- > 00.txt" $B$K$*$$$F!"(B > "JORDI PALET MARTINEZ "$B$5$s$O=q$-(B > $B$^$7$?!'(B > >> Hi, >> >> A couple of comments about this document. >> >> 1. Intro. I don't think is correct to say that a major impediment is the >> high cost and technical complexity. Sorry, but isn't the case, and we must >> not give this message. In some cases it might be the case, but not in >> general. I'm working everyday in moving real customers to support native >> IPv6, and haven't found this situation yet, and not talking about just a >> dozen of customers. >> Actually I'm starting to feel that most of the people is afraid of IPv6 >> because they got this impression. >> >> 3 ... It may be better to use instead of adversary "malicious user" or >> something else ? I mean adversary may seem as "business competitor" or have >> other connotations, which I guess are not the intended ones ? >> >> Regards, >> Jordi >> >> >> >> >>> De: "Internet-Drafts@ietf.org" >>> Responder a: "Internet-Drafts@ietf.org" >>> Fecha: Tue, 12 Jul 2005 15:50:03 -0400 >>> Para: >>> Asunto: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Security Considerations for the Tunnel Broker >>> Model >>> Author(s) : S. Yamamoto, et al. >>> Filename : draft-yamamoto-v6tc-security-considerations-00.txt >>> Pages : 9 >>> Date : 2005-7-12 >>> >>> Tunnel brokers must implement protections against a wide variety of >>> threats. This draft discusses the security considerations for a >>> configured tunneling configuration mechanism such as that described >>> by the Tunnel Broker. The emphasis in this document is on >>> protocol-related security issues. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-yamamoto-v6tc-security- > consideration >>> s-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body of the >>> message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> >>> 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-yamamoto-v6tc-security-considerations-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-yamamoto-v6tc-security-considerations-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2005-7-12132033.I-D@ietf.org> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> >> >> ************************************ >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Information available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of > the individual > (s) named above. If you are not the intended recipient be aware > that any > disclosure, copying, distribution or use of the contents of this > information, > including attached files, is prohibited. >> >> >> >> > > > -- > Shu Yamamoto > sy-yamamoto@cn.kddilabs.jp ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 14 06:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt0ka-0008K2-Sc for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 06:15:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26953 for ; Thu, 14 Jul 2005 06:15:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt0jg-000Mo7-P3 for v6ops-data@psg.com; Thu, 14 Jul 2005 10:14:32 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dt0jd-000Mni-Jb for v6ops@ops.ietf.org; Thu, 14 Jul 2005 10:14:30 +0000 Received: (qmail 93727 invoked by uid 1007); 14 Jul 2005 10:14:28 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=kDK2aW9vGZGKXixlzYMdjYe+4y8KuFrqmWqwN/nsjGr3cr1QkKOxEwUNl8LLTk2I ; Date: Thu, 14 Jul 2005 12:14:28 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Cc: "v6ops@ops.ietf.org" Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt Message-ID: <20050714101428.GM84850@Space.Net> References: <200507141633.HAH39568.ZNBPUBPZtNT@cn.kddilabs.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Jul 14, 2005 at 11:44:37AM +0200, JORDI PALET MARTINEZ wrote: > My experience show that a good ISP and corporate will have usually their > infrastructure up-dated, even with some kind of maintenance contract, which > will support IPv6 as an added value, not as a dedicated cost. Unfortunately, more and more vendors think that they can make much money out of IPv6, and as such, getting IPv6 enabled in the boxes requires an additional license. Which needs to be paid for. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Thu Jul 14 06:35:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt13a-0000mc-67 for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 06:35:06 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27753 for ; Thu, 14 Jul 2005 06:35:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt12y-000Onv-Ts for v6ops-data@psg.com; Thu, 14 Jul 2005 10:34:28 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1Dt12v-000OmO-Cj for v6ops@ops.ietf.org; Thu, 14 Jul 2005 10:34:26 +0000 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145953.msg for ; Thu, 14 Jul 2005 12:35:07 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 12:33:33 +0200 Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <20050714101428.GM84850@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 12:35:17 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Gert, Change your vendor ! This is not fair, and should not be like that. Fortunately other vendors still keep offering IPv6 at no cost when you buy a box with IPv4. In any case, is not ALL, so the wording in the document is not accurate ;-) Regards, Jordi > De: Gert Doering > Responder a: > Fecha: Thu, 14 Jul 2005 12:14:28 +0200 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ops.ietf.org" > Asunto: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt > > Hi, > > On Thu, Jul 14, 2005 at 11:44:37AM +0200, JORDI PALET MARTINEZ wrote: >> My experience show that a good ISP and corporate will have usually their >> infrastructure up-dated, even with some kind of maintenance contract, which >> will support IPv6 as an added value, not as a dedicated cost. > > Unfortunately, more and more vendors think that they can make much money > out of IPv6, and as such, getting IPv6 enabled in the boxes requires > an additional license. Which needs to be paid for. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 71007 (66629) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > > ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 14 11:22:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5XL-000513-AW for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:22:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21550 for ; Thu, 14 Jul 2005 11:22:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt5Uz-0003eu-CF for v6ops-data@psg.com; Thu, 14 Jul 2005 15:19:41 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt5Uy-0003ee-Ql for v6ops@ops.ietf.org; Thu, 14 Jul 2005 15:19:40 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2005 08:19:40 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6EFJcvM001965; Thu, 14 Jul 2005 08:19:38 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6EFIGOM008331; Thu, 14 Jul 2005 08:18:16 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "v6ops@ops.ietf.org" From: Fred Baker Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt Date: Thu, 14 Jul 2005 08:19:38 -0700 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121354296.289658"; x:"432200"; a:"rsa-sha1"; b:"nofws:649"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"bcfeb+nLZBUThbp/MrTh4D7SEfDOmEl+jlt/FAMO8G44iZF9p0q2oFXU07TE0kz97VvQnAcH" "kVNN8W88jZ8AZQ15ygZRonLMXSsj+BJw4Zhv7wvLMfkckp03VTskryZmzYcLJXeSdv44HlQjTAT" "lVtNSMS3dAbpNI8kZbZ7c3v0="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-" "00.txt"; c:"Date: Thu, 14 Jul 2005 08:19:38 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jul 14, 2005, at 2:44 AM, JORDI PALET MARTINEZ wrote: > there is no cost for replacing any routers. That depends on your router. In the case of a company I happen to have some familiarity with, some of the products we have that switch traffic in hardware require a change of card (not the entire router, unless it is old enough that it is no longer supported). The new card is IPv4+IPv6 and has a 64 or 128 bit wide word width and may have a larger TCAM where the old was IPv4 only and had a 32 bit word width. Even a software router may require additional memory to hold a larger program and parallel RIBs and FIBs. A new memory stick is a cost, and sending someone out to inventory the equipment and see if one might be needed (and testing the software before basing one's business on it) is a cost. From owner-v6ops@ops.ietf.org Thu Jul 14 11:39:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5nt-0006mC-V3 for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:39:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22881 for ; Thu, 14 Jul 2005 11:39:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt5nE-0005v5-7A for v6ops-data@psg.com; Thu, 14 Jul 2005 15:38:32 +0000 Received: from [128.182.66.106] (helo=mailer2.psc.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dt5nB-0005uj-Co for v6ops@ops.ietf.org; Thu, 14 Jul 2005 15:38:29 +0000 Received: from lassa.psc.edu (lassa.psc.edu [128.182.61.59]) (authenticated bits=0) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j6EFcPhB015731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jul 2005 11:38:27 -0400 (EDT) Date: Thu, 14 Jul 2005 11:38:25 -0400 From: Michael H Lambert To: "'v6ops@ops.ietf.org '" Subject: Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-ID: <520BBF82BF06AF94B0BD0358@lassa.psc.edu> In-Reply-To: <21f795d5474b2b4035d4fee5a385b237@cisco.com> References: <21f795d5474b2b4035d4fee5a385b237@cisco.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 July 2005 13:03:19 -0700 Fred Baker wrote: > This passed last call a while ago, and expired immediately afterward. The > only change I expected in this was that of the name; mostly, it was > reposting for the IESG's benefit. > > If there are any further comments on this draft, please advise. > I do have one comment: ---------- 2.5 IPv6 Addressing One site using this VLAN technique has chosen to number its IPv6 links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not a recommended addressing plan, but some sites may wish to consider its usage. ---------- I see two ways of reading this text. The first is that there is some fundamental flaw with this addressing format and other options should be considered. The second is that this format is just being used as an example, but the document takes no stand on any particular scheme. If Tim would please clarify... Michael -- Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 Pittsburgh Supercomputing Center FAX: +1 412 268-8200 4400 Fifth Avenue, Pittsburgh, PA 15213 USA lambert@psc.edu From owner-v6ops@ops.ietf.org Thu Jul 14 15:00:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8wj-0007B5-Ie for v6ops-archive@megatron.ietf.org; Thu, 14 Jul 2005 15:00:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09424 for ; Thu, 14 Jul 2005 15:00:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt8ud-00034T-G0 for v6ops-data@psg.com; Thu, 14 Jul 2005 18:58:23 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt8ub-00033s-Jf for v6ops@ops.ietf.org; Thu, 14 Jul 2005 18:58:21 +0000 Received: from eaglet (127.0.0.1:3607) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 14 Jul 2005 11:58:07 -0700 From: "Tony Hain" To: "'Mark Smith'" , "'Fred Baker'" Cc: , Subject: RE: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Thu, 14 Jul 2005 11:58:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050702011419.574a3b33.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcV+U+sAWa/4gnW6RJKJduwUy+tKVgKT/2Ug X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit To be clear, the NAP draft is offering host routes as one option for topology opaqueness, and I recall a discussion about text suggesting there would be scaling concerns with the IGP. Maybe that didn't make it in the current version of the draft. The other option is to use mipv6 without route optimization. The external nodes are talking to the home agent for the virtual subnet and it uses the tunnel mode to get to the current care-of for the device. This has a scaling impact on internal traffic volume due to the tunnel header, but has absolutely no impact on routing. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Mark Smith > Sent: Friday, July 01, 2005 8:44 AM > To: Fred Baker > Cc: alain@tycool.net; v6ops@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt > > Hi Fred, > > On Fri, 1 Jul 2005 08:25:03 -0700 > Fred Baker wrote: > > > > > On Jul 1, 2005, at 4:03 AM, Mark Smith wrote: > > > > > (2) Running a fully fledged routing protocol on the end-node is > > > relatively heavy handed for what is being achieved. I'd think a > > > simple, light-weight announcement style availability protocol for the > > > node's address, that is part of IPv6 itself, would be useful. > > > > It was standard practice on DECNET, XNS, and Novell equipment; Novell > > did it twice, once for the routes and once for the services that the > > servers offered. If you have only one interface, as you say it didn't > > accomplish much. But if you have multiple interfaces on a server, it > > provides something akin to what multihoming does for a network. As you > > say, it is expensive in address count to put a /64 on a host, though. > > > > It took many years for me to realise why there was an "internal network > number" on Novell servers :-) I think it probably co-incided with me > learning how /32s on loopbacks pushed into a routing cloud could be > useful for maintaining routers. > > > In general, if you're interested in routing scaling, using the tools > > that make it scale are a good thing. Host routes are the exception, I > > should think, not the rule. > > I generally agree, I personally don't really see all that much security > value in attempting to make the internal subnet topology opaque to > external devices at the cost of scalabilty. However, people seem to > like NAT because that is one if its properties, and I could see them > wanting to preserve it with IPv6. The NAP draft is suggesting > using host routes to do this, and how that will work in IPv6 has > intersected a bit with my somewhat academic interest in how it works on > broadcast interfaces with IPv4. > > For those who do place value on topology hiding, I'd imagine it would > most likely to be "all-or-nothing" approach, meaning that all their > hosts within their assigned /48(s) would be host routed, rather than a > minor subset. If they think topology hiding is important, they're > probably also prepared to think it is important for all their nodes, > rather than a minor subset, and be willing to wear the scalability cost. > > Regards, > Mark. From owner-v6ops@ops.ietf.org Fri Jul 15 15:52:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWEz-0006pA-8P for v6ops-archive@megatron.ietf.org; Fri, 15 Jul 2005 15:52:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11430 for ; Fri, 15 Jul 2005 15:52:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtWCB-000Mmi-AZ for v6ops-data@psg.com; Fri, 15 Jul 2005 19:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DtWCA-000MmD-In for v6ops@ops.ietf.org; Fri, 15 Jul 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWC9-0001qz-JO; Fri, 15 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-bb-deployment-scenarios-03.txt Message-Id: Date: Fri, 15 Jul 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 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 : ISP IPv6 Deployment Scenarios in Broadband Access Networks Author(s) : S. Asadullah, et al. Filename : draft-ietf-v6ops-bb-deployment-scenarios-03.txt Pages : 81 Date : 2005-7-15 This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-bb-deployment-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15113403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-bb-deployment-scenarios-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15113403.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sat Jul 16 08:24:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtli8-0002uu-4h for v6ops-archive@megatron.ietf.org; Sat, 16 Jul 2005 08:24:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11616 for ; Sat, 16 Jul 2005 08:24:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtleU-0008xa-R1 for v6ops-data@psg.com; Sat, 16 Jul 2005 12:20:18 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DtleQ-0008x1-6d for v6ops@ops.ietf.org; Sat, 16 Jul 2005 12:20:14 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DtleM-00032A-Rm; Sat, 16 Jul 2005 13:20:11 +0100 Message-ID: <42D8FBBD.2010506@dial.pipex.com> Date: Sat, 16 Jul 2005 13:21:17 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The latest version appears to address all the comments that I and others made, and generally looks good (give or take a few editorial fixes - see below). One minor issue with regard to the language used about how to model the tunnel end-point when specific SPD tunnel mode is used: I am not sure that it is up to this document to 'require' (s5.3, 2nd para) that they are not modelled as separate interfaces. What we are saying is that it is not really possible to build specific SPD tunnel mode on end points modelled as interfaces... Therefore we recommend that specific SPD tunnel mode end points should not be modelled as separate interfaces. This is followed through into the reccommendations in s9 para 2: suggest s/support/recommend/. There ought to be a better way of saying this but I can't think what it is at present. Regards, Elwyn A number of language/editorial nits: s1: Unexpanded acronyms: SA, SPD, ECN (SA is expanded in s2.1) s2: para 1: s/was mostly/is mostly/ s2: para 3: s/specifies following/specifies the following/, s/measures./measures:/ s2: paras4/5: make them bulleted paras to clarify that they are the 'following measures' s2.1: para 1: s/The successful/A successful/ s2.1: last para: s/kind/kinds/ s2.1: last para: Unexpanded acronyms GRE, L2TP (maybe need references). s2.2: para 1: s/The successful/A successful/ s3.2: next-to-last para: Unexpanded acronyms ISP, CPE s4: The language in this section may become slightly less clear when the drafts become RFCs s4: para 2: s/is defined in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]/was originally defined in [RFC2401] now superseded by [I-D.ietf-ipsec-rfc2401bis]/ s4: para 2: s/IPsec security/The IPsec security/, s/difference/differences/ s4: para 7: Move the first sentence {'IKE is defined in [RFC2409] (which is referred to as IKE in this document) and in [I-D.ietf-ipsec-ikev2] (which is referred to as IKEv2 in this document).'} to be the second sentence of para 2. Start a new para after this, substituting s/them/the two versions of the security architecture/. In the rest of the section - do what the IKE sentence says - use IKE and IKEv2 consistently - IKEv1 -> IKE, places where the IKE RFC/draft are used replaced by IKE/IKEv2 (e.g., Bullet point 3), para 6) [Actually IKEv1 seems to be used pretty consistently in the rest of the document!] s5: para 1: s/the IPsec tunnel establishment for/establishment of an IPsec tunnel for the/, s/we'll/we will/, s/look on/look at/ s5: Figure 5: Might be more obvious as a 'boxed' table, maybe with column headings 'Components (first to last)', 'Contains'. Also presumably the packet has a payload! s5.2: para 1: delete 'kind of' s5.2: para 3: s/whose tunnel endpoint's IPv4 address is/with tunnel endpoint IPv4 addresses/ s5.2: para 3: s/The implementations/Implementations/ s5.3.1: para 1: s/routing table/the routing table/, s/is passes/is passed/ s5.3.1: para 3: s/prevent/prevent an attacker/ s7: para 2: s/the same way/in the same way/ s7: bullet point 2: s/the NAT changes/where the NAT changes/ s7: last para: s/MOBIKE/The IETF MOBIKE working group/ s8: 1st bullet: s/off-band/out-of-band/ s9: last para: s/is to either tunnel mode with generic SPDs or transport mode, and applying/is to use either tunnel mode with generic SPDs or transport mode, and apply/ s11: para 1: s/in the tunnel/into the tunnel/ s11: para 2: s/to the both,/to both/ s11: para 3: IF you use IKE to mean IKEv1 then s/IKE/Either IKE or IKEv2/ - If you go for IKEv1 explicitly, IKE is finr. References: Whether RC2401 and RFC2409 are normative is arguable! App A: para 2: s/associations are/association is, s/interfaces/an interface/ App A: throughout: s/destination/DST/ in rules (some already do) Pekka Savola wrote: > On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >> >> Title : Using IPsec to Secure IPv6-in-IPv4 Tunnels >> Author(s) : P. Savola, et al. >> Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt >> Pages : 21 >> Date : 2005-7-11 >> >> This document gives guidance on securing manually configured IPv6-in- >> IPv4 tunnels using IPsec. No additional protocol extensions are >> described beyond those available with the IPsec framework. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt >> > > > The authors believe that this version addresses all comments sent to > date. > > There has been substantial revision in the draft. Those who > previously read it are encouraged to take another look and see if it's > better. If you haven't taken a look yet, now would be a good chance. > > The issue list is at: > http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html > > There's also a htmlwdiff there. > From owner-v6ops@ops.ietf.org Mon Jul 18 05:12:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRfx-0007Ae-Go for v6ops-archive@megatron.ietf.org; Mon, 18 Jul 2005 05:12:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24447 for ; Mon, 18 Jul 2005 05:12:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DuRcv-000F9E-1e for v6ops-data@psg.com; Mon, 18 Jul 2005 09:09:29 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DuRcs-000F8n-CZ for v6ops@ops.ietf.org; Mon, 18 Jul 2005 09:09:26 +0000 Received: (qmail 97405 invoked by uid 1007); 18 Jul 2005 09:09:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=LCVY1/DGQIkcBcRgSkMv5dYHfYUrfVIWPF+vG7GhyRixMECaUAOQQyQfKLXxU1AQ ; Date: Mon, 18 Jul 2005 11:09:22 +0200 From: Gert Doering To: Michael H Lambert Cc: "'v6ops@ops.ietf.org '" Subject: Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-ID: <20050718090922.GU84850@Space.Net> References: <21f795d5474b2b4035d4fee5a385b237@cisco.com> <520BBF82BF06AF94B0BD0358@lassa.psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520BBF82BF06AF94B0BD0358@lassa.psc.edu> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Jul 14, 2005 at 11:38:25AM -0400, Michael H Lambert wrote: > ---------- > 2.5 IPv6 Addressing > > One site using this VLAN technique has chosen to number its IPv6 > links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not > a recommended addressing plan, but some sites may wish to consider > its usage. > ---------- > > I see two ways of reading this text. The first is that there is some > fundamental flaw with this addressing format and other options should be > considered. The second is that this format is just being used as an > example, but the document takes no stand on any particular scheme. I'assume the second one is what is intended ("this is just an example, and you can do it this way, but you don't have to"), but indeed the wording could also be read as "this is NOT RECOMMENDED! don't do this!". gert -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Mon Jul 18 06:20:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSjU-0005ET-0v for v6ops-archive@megatron.ietf.org; Mon, 18 Jul 2005 06:20:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28473 for ; Mon, 18 Jul 2005 06:20:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DuShY-000KyH-CX for v6ops-data@psg.com; Mon, 18 Jul 2005 10:18:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1DuShV-000Kxq-QX for v6ops@ops.ietf.org; Mon, 18 Jul 2005 10:18:18 +0000 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001152021.msg for ; Mon, 18 Jul 2005 12:18:25 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Jul 2005 12:16:44 +0200 Subject: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 18 Jul 2005 12:19:34 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Yes, of course, its up to each router (model/config), but what is clear to me is that the real situation is more in the side of no cost or almost no cost, specially if your network is under maintenance. A good quality ISP is continuously upgrading the network, taking care of new firmware versions, etc. IPv6 is coming there as a value added. Some times you may need a hardware part replacement, right, but this is only required if you have a lot of IPv6 traffic, and in that case, it pays for it. Unless you need to actually do a hardware upgrade of the router, most of the time you will be able to take care of the new firmware and config remotely ... So most of the cost, in a correctly maintained network will not be just because IPv6 (if done with some planning), except may be training, and in any case will not be a "very high cost". If you want to do it overnight, and have no expertise, not correct planing, etc., yes, then it can cost a lot ! Regards, Jordi > De: Fred Baker > Responder a: > Fecha: Thu, 14 Jul 2005 08:19:38 -0700 > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: I-D ACTION:draft-yamamoto-v6tc-security-considerations-00.txt > > On Jul 14, 2005, at 2:44 AM, JORDI PALET MARTINEZ wrote: >> there is no cost for replacing any routers. > > That depends on your router. In the case of a company I happen to have > some familiarity with, some of the products we have that switch traffic > in hardware require a change of card (not the entire router, unless it > is old enough that it is no longer supported). The new card is > IPv4+IPv6 and has a 64 or 128 bit wide word width and may have a larger > TCAM where the old was IPv4 only and had a 32 bit word width. Even a > software router may require additional memory to hold a larger program > and parallel RIBs and FIBs. > > A new memory stick is a cost, and sending someone out to inventory the > equipment and see if one might be needed (and testing the software > before basing one's business on it) is a cost. > ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Jul 20 07:47:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvD2i-0001QZ-4N for v6ops-archive@megatron.ietf.org; Wed, 20 Jul 2005 07:47:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07885 for ; Wed, 20 Jul 2005 07:47:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvCxF-000L8n-US for v6ops-data@psg.com; Wed, 20 Jul 2005 11:41:37 +0000 Received: from [193.137.203.228] (helo=smtp.dei.uc.pt) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvCxE-000L8R-Oh for v6ops@ops.ietf.org; Wed, 20 Jul 2005 11:41:37 +0000 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.137.203.250]) by smtp.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j6KBfREP015892 for ; Wed, 20 Jul 2005 12:41:27 +0100 Received: (from nobody@localhost) by mail.dei.uc.pt (8.11.7/8.11.7) id j6KBfME13901 for v6ops@ops.ietf.org; Wed, 20 Jul 2005 12:41:22 +0100 X-Authentication-Warning: mail.dei.uc.pt: nobody set sender to tandre@dei.uc.pt using -f Received: from 194.145.62.45 ([194.145.62.45]) by mail.dei.uc.pt (IMP) with HTTP for ; Wed, 20 Jul 2005 12:41:21 +0100 Message-ID: <1121859681.42de38619e0f9@mail.dei.uc.pt> Date: Wed, 20 Jul 2005 12:41:21 +0100 From: Tiago Camilo To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is not the first router outside of the customer premises??) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-UC-FCT-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-UC-FCT-DEI-SIC-MailScanner: Found to be clean X-UC-FCT-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.599, required 3, autolearn=not spam, BAYES_00 -2.60) X-UC-FCT-DEI-SIC-MailScanner-From: tandre@dei.uc.pt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I have being following the design of the draft-ietf-v6ops-bb-deployment-scenarios, and more closely with the Broadband DSL Networks. And my doubt is concerning the DHCP-PD functionality in intermediate L3 nodes. As the author says: B. Currently the DHCP-PD functionality cannot be implemented if the DHCP-PD server is not the Edge Router. If the DHCP-PD messages are relayed, the Edge Router does not have a mechanism to learn the assigned prefixes and thus install the proper routes to make that prefix reachable. [...] Does this issue is already cover, I mean does a new solution rather than snooping is already proposed? I also agreed with the comment of Pekka Savola, when he says that: ==> shouldn't you say something like "the first router outside of the customer premises" instead of Edge Router? (or something a bit more compact.) In a Wholesale IP model, it is possible to have several L3 devices between the first router outside customer premises and the DHCP server. For instance if we consider that the DSLAM is IP enable, than it needs to be a DHCP-PD relay agent (if the DHCP server is on NSP). My question is, do we need to implement snooping mechanisms in DSLAM, so that this device could install the proper routes? What about the following nodes, the BRAS and the ER, does they need to be also DHCP relay Agents, and each one with its own snooping mechanism? Customer Premise NAP NSP |---------------| |----------------------| |----------------| +-------+ | DHCP | +----+ Server| | +-------+ | | +----------+ +--------+ +----+-----+ +-----+-----+ |CPE Router+----+ DSLAM +-+ BRAS +-+ Edge | +----------+ +--------+ +----------+ | Router + +-----------+ |----------------------------------------| IP Thanks, And best regards, Tiago Camilo University of Coimbra From owner-v6ops@ops.ietf.org Wed Jul 20 15:52:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKce-0007JU-Nf for v6ops-archive@megatron.ietf.org; Wed, 20 Jul 2005 15:52:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25775 for ; Wed, 20 Jul 2005 15:52:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvKa6-000Bve-Sq for v6ops-data@psg.com; Wed, 20 Jul 2005 19:50:14 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvKa5-000BvK-K8 for v6ops@ops.ietf.org; Wed, 20 Jul 2005 19:50:14 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZv-0007mM-NU; Wed, 20 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-security-overview-02.txt Message-Id: Date: Wed, 20 Jul 2005 15:50:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : IPv6 Transition/Co-existence Security Considerations Author(s) : E. Davies, et al. Filename : draft-ietf-v6ops-security-overview-02.txt Pages : 33 Date : 2005-7-20 The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-security-overview-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-security-overview-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: <2005-7-20134039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-security-overview-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-security-overview-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20134039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 20 23:45:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvRzx-0002q9-So for v6ops-archive@megatron.ietf.org; Wed, 20 Jul 2005 23:45:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03991 for ; Wed, 20 Jul 2005 23:45:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvRw5-0001BD-2U for v6ops-data@psg.com; Thu, 21 Jul 2005 03:41:25 +0000 Received: from [203.103.165.50] (helo=smta01.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DvRw3-0001Aw-QR for v6ops@ops.ietf.org; Thu, 21 Jul 2005 03:41:24 +0000 Received: from ubu.nosense.org ([210.84.224.184]) by smta01.mail.ozemail.net with ESMTP id <20050721034121.VLAW6478.smta01.mail.ozemail.net@ubu.nosense.org>; Thu, 21 Jul 2005 03:41:21 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8670162AAE; Thu, 21 Jul 2005 13:11:19 +0930 (CST) Date: Thu, 21 Jul 2005 13:11:19 +0930 From: Mark Smith To: elwynd@dial.pipex.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-security-overview-02.txt Message-Id: <20050721131119.57cd905a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 20 Jul 2005 15:50:03 -0400 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : IPv6 Transition/Co-existence Security Considerations > Author(s) : E. Davies, et al. > Filename : draft-ietf-v6ops-security-overview-02.txt > Pages : 33 > Date : 2005-7-20 > Don't know if comments are being solicited, I understood that this has already been through last call. Anyway, if they are ... Probably minor : 2.1.8.1 Processing Extension Headers in Middleboxes - It might be worth mentioning at the end of this section the encrypted IPSec "feature" of hiding packet fields from middle boxes. Although mentioned in a few later sections, I think it would also be useful here, as this section is directly addressing middlebox processing of fields that would be effected by IPsec. Regards, Mark. From owner-v6ops@ops.ietf.org Thu Jul 21 03:21:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVMl-0003ba-Vt for v6ops-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:21:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07278 for ; Thu, 21 Jul 2005 03:21:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvVIb-000N7W-H4 for v6ops-data@psg.com; Thu, 21 Jul 2005 07:16:53 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DvVIa-000N7C-Jc for v6ops@ops.ietf.org; Thu, 21 Jul 2005 07:16:52 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2005 00:16:52 -0700 X-IronPort-AV: i="3.93,306,1115017200"; d="scan'208"; a="649798615:sNHT39680508" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6L7GmJL014871; Thu, 21 Jul 2005 00:16:51 -0700 (PDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 03:16:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is not the first router outside of the customer premises??) Date: Thu, 21 Jul 2005 03:16:47 -0400 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F4624945@xmb-rtp-213.amer.cisco.com> Thread-Topic: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is not the first router outside of the customer premises??) Thread-Index: AcWNIO5jKnHPEwOVSC+ZYuzOQSToKgAmyZKA From: "Chip Popoviciu \(cpopovic\)" To: "Tiago Camilo" , X-OriginalArrivalTime: 21 Jul 2005 07:16:48.0353 (UTC) FILETIME=[288F8D10:01C58DC4] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Tiago, The document discussed the options available today and points out gaps that should be further addressed in other work. Solutions to the DHCP-PD problem are being worked on and snooping is one of them. Regarding the text comment, I think it is just a matter of context and terminology. In the context and terminology of the three models described, the Edge router is the Layer 3 next hop for the customers. In the LAA model for example there are indeed multiple routers between the first (access) router and the Edge Router but all of them transport the customer traffic encapsulated and do not handle it at Layer 3. Despite all these routers (that are part of the NAP infrastructure), as far as the customer is concerned, its Layer 3 next hop is the Edge Router. In the case of a snooping based implementation, only customer's Layer 3 first hop router (be it the IP enabled DSLAM, the BRAS or the ER depending on the service model) will have to support the snooping feature. This router has to learn from the snooped DHCP packets what static routes it should install for the prefixes that were delegated to the customer connected to it (directly on an interface or virtually over PPPoE+L2TP for example), the rest of the network will learn from this router (through the redistribution of the static routes in a IGP) how to get to the delegated prefixes. I hope this answers your questions. Best Regards, Chip -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tiago Camilo Sent: Wednesday, July 20, 2005 7:41 AM To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is not the first router outside of the customer premises??) Hi, I have being following the design of the draft-ietf-v6ops-bb-deployment-scenarios, and more closely with the Broadband DSL Networks. And my doubt is concerning the DHCP-PD functionality in intermediate L3 nodes. As the author says: B. Currently the DHCP-PD functionality cannot be implemented if the DHCP-PD server is not the Edge Router. If the DHCP-PD messages are relayed, the Edge Router does not have a mechanism to learn the assigned prefixes and thus install the proper routes to make that prefix reachable. [...] Does this issue is already cover, I mean does a new solution rather than snooping is already proposed? I also agreed with the comment of Pekka Savola, when he says that: =3D=3D> shouldn't you say something like "the first router outside of = the customer premises" instead of Edge Router? (or something a bit more compact.)=20 In a Wholesale IP model, it is possible to have several L3 devices between the first router outside customer premises and the DHCP server.=20 For instance if we consider that the DSLAM is IP enable, than it needs to be a DHCP-PD relay agent (if the DHCP server is on NSP). My question is, do we need to implement snooping mechanisms in DSLAM, so that this device could install the proper routes? What about the following nodes, the BRAS and the ER, does they need to be also DHCP relay Agents, and each one with its own snooping mechanism? Customer Premise NAP NSP |---------------| |----------------------| |----------------| +-------+ | DHCP | +----+ Server| | +-------+ | | +----------+ +--------+ +----+-----+ +-----+-----+ |CPE Router+----+ DSLAM +-+ BRAS +-+ Edge | +----------+ +--------+ +----------+ | Router + +-----------+ |----------------------------------------| IP Thanks, And best regards, Tiago Camilo University of Coimbra From owner-v6ops@ops.ietf.org Thu Jul 21 04:05:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvW3I-0005Gs-60 for v6ops-archive@megatron.ietf.org; Thu, 21 Jul 2005 04:05:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10380 for ; Thu, 21 Jul 2005 04:05:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvW1W-0001Pt-Vi for v6ops-data@psg.com; Thu, 21 Jul 2005 08:03:18 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DvW1T-0001PU-K4 for v6ops@ops.ietf.org; Thu, 21 Jul 2005 08:03:16 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6L83EIh013436; Thu, 21 Jul 2005 10:03:14 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6L83DIq015132; Thu, 21 Jul 2005 10:03:13 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6L83Dgm015131; Thu, 21 Jul 2005 10:03:13 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 21 Jul 2005 10:03:13 +0200 From: Stig Venaas To: Gert Doering Cc: Michael H Lambert , "'v6ops@ops.ietf.org '" Subject: Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-ID: <20050721080313.GA15046@storhaugen.uninett.no> References: <21f795d5474b2b4035d4fee5a385b237@cisco.com> <520BBF82BF06AF94B0BD0358@lassa.psc.edu> <20050718090922.GU84850@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050718090922.GU84850@Space.Net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jul 18, 2005 at 11:09:22AM +0200, Gert Doering wrote: > Hi, > > On Thu, Jul 14, 2005 at 11:38:25AM -0400, Michael H Lambert wrote: > > ---------- > > 2.5 IPv6 Addressing > > > > One site using this VLAN technique has chosen to number its IPv6 > > links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not > > a recommended addressing plan, but some sites may wish to consider > > its usage. > > ---------- > > > > I see two ways of reading this text. The first is that there is some > > fundamental flaw with this addressing format and other options should be > > considered. The second is that this format is just being used as an > > example, but the document takes no stand on any particular scheme. > > I'assume the second one is what is intended ("this is just an example, > and you can do it this way, but you don't have to"), but indeed the wording > could also be read as "this is NOT RECOMMENDED! don't do this!". I also think the second is the intention. However, I think it might be a bad idea, so I would perhaps prefer to read it as "don't do this". When picking IPv6 prefixes for links people use all kinds of creative tricks where the prefixes have some meaning. This is one example. I understand it can make it easier for some administrator initially. Problem is that you may later be forced to renumber just to preserve your naming, or you don't and then you have exceptions to the rule that was initially created. Stig > gert > -- > Total number of prefixes smaller than registry allocations: 71007 (66629) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > From owner-v6ops@ops.ietf.org Thu Jul 21 04:57:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWrs-0000pA-Fz for v6ops-archive@megatron.ietf.org; Thu, 21 Jul 2005 04:57:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13123 for ; Thu, 21 Jul 2005 04:57:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvWqM-00060p-Q5 for v6ops-data@psg.com; Thu, 21 Jul 2005 08:55:50 +0000 Received: from [193.137.203.228] (helo=smtp.dei.uc.pt) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvWqK-00060C-HV for v6ops@ops.ietf.org; Thu, 21 Jul 2005 08:55:48 +0000 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.137.203.250]) by smtp.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j6L8sUlC015699; Thu, 21 Jul 2005 09:54:30 +0100 Received: (from nobody@localhost) by mail.dei.uc.pt (8.11.7/8.11.7) id j6L8sPW27289; Thu, 21 Jul 2005 09:54:25 +0100 X-Authentication-Warning: mail.dei.uc.pt: nobody set sender to tandre@dei.uc.pt using -f Received: from 194.145.62.45 ([194.145.62.45]) by mail.dei.uc.pt (IMP) with HTTP for ; Thu, 21 Jul 2005 09:54:24 +0100 Message-ID: <1121936064.42df62c101178@mail.dei.uc.pt> Date: Thu, 21 Jul 2005 09:54:25 +0100 From: Tiago Camilo To: "Chip Popoviciu (cpopovic)" Cc: v6ops@ops.ietf.org Subject: RE: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is not the first router outside of the customer premises??) References: <3D1C81E7AA3CD64FA20B04D269FEF7F4624945@xmb-rtp-213.amer.cisco.com> In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F4624945@xmb-rtp-213.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-UC-FCT-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-UC-FCT-DEI-SIC-MailScanner: Found to be clean X-UC-FCT-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.599, required 3, autolearn=not spam, BAYES_00 -2.60) X-UC-FCT-DEI-SIC-MailScanner-From: tandre@dei.uc.pt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Chip, Thanks for your reply, Can you inform me who are the people involved in the snooping issue? We are concerning about scalabilities problems.. Thank once again, Tiago Camilo Quoting "Chip Popoviciu (cpopovic)" : > > Hello Tiago, > > The document discussed the options available today and points out gaps > that should be further addressed in other work. Solutions to the DHCP-PD > problem are being worked on and snooping is one of them. > > Regarding the text comment, I think it is just a matter of context and > terminology. In the context and terminology of the three models > described, the Edge router is the Layer 3 next hop for the customers. In > the LAA model for example there are indeed multiple routers between the > first (access) router and the Edge Router but all of them transport the > customer traffic encapsulated and do not handle it at Layer 3. Despite > all these routers (that are part of the NAP infrastructure), as far as > the customer is concerned, its Layer 3 next hop is the Edge Router. > > In the case of a snooping based implementation, only customer's Layer 3 > first hop router (be it the IP enabled DSLAM, the BRAS or the ER > depending on the service model) will have to support the snooping > feature. This router has to learn from the snooped DHCP packets what > static routes it should install for the prefixes that were delegated to > the customer connected to it (directly on an interface or virtually over > PPPoE+L2TP for example), the rest of the network will learn from this > router (through the redistribution of the static routes in a IGP) how to > get to the delegated prefixes. > > I hope this answers your questions. > > Best Regards, > Chip > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Tiago Camilo > Sent: Wednesday, July 20, 2005 7:41 AM > To: v6ops@ops.ietf.org > Subject: draft-ietf-v6ops-bb-deployment-scenarios(if DHCP-PD server is > not the first router outside of the customer premises??) > > Hi, > I have being following the design of the > draft-ietf-v6ops-bb-deployment-scenarios, and more closely with the > Broadband DSL Networks. And my doubt is concerning the DHCP-PD > functionality in intermediate L3 nodes. > As the author says: > > B. Currently the DHCP-PD functionality cannot be implemented if the > DHCP-PD server is not the Edge Router. If the DHCP-PD messages are > relayed, the Edge Router does not have a mechanism to learn the assigned > prefixes and thus install the proper routes to make that prefix > reachable. [...] > > Does this issue is already cover, I mean does a new solution rather than > snooping is already proposed? > > I also agreed with the comment of Pekka Savola, when he says that: > > ==> shouldn't you say something like "the first router outside of the > customer premises" instead of Edge Router? (or something a bit more > compact.) > > In a Wholesale IP model, it is possible to have several L3 devices > between the first router outside customer premises and the DHCP server. > For instance if we consider that the DSLAM is IP enable, than it needs > to be a DHCP-PD relay agent (if the DHCP server is on NSP). My question > is, do we need to implement snooping mechanisms in DSLAM, so that this > device could install the proper routes? What about the following nodes, > the BRAS and the ER, does they need to be also DHCP relay Agents, and > each one with its own snooping mechanism? > > Customer Premise NAP NSP > |---------------| |----------------------| |----------------| > +-------+ > | DHCP | > +----+ Server| > | +-------+ > | | > +----------+ +--------+ +----+-----+ +-----+-----+ > |CPE Router+----+ DSLAM +-+ BRAS +-+ Edge | > +----------+ +--------+ +----------+ | Router + > +-----------+ > |----------------------------------------| > IP > > Thanks, > And best regards, > Tiago Camilo > University of Coimbra > From owner-v6ops@ops.ietf.org Thu Jul 21 06:06:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvXwZ-0002tX-E5 for v6ops-archive@megatron.ietf.org; Thu, 21 Jul 2005 06:06:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16451 for ; Thu, 21 Jul 2005 06:06:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvXte-000BxC-W5 for v6ops-data@psg.com; Thu, 21 Jul 2005 10:03:18 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DvXtb-000Bwh-CG for v6ops@ops.ietf.org; Thu, 21 Jul 2005 10:03:15 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 534FC3921E; Thu, 21 Jul 2005 12:03:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30813-02; Thu, 21 Jul 2005 12:03:13 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8D529395A8; Thu, 21 Jul 2005 12:03:12 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 832DB38FB0F; Thu, 21 Jul 2005 11:25:05 +0200 (CEST) Date: Thu, 21 Jul 2005 11:25:04 +0200 From: Juergen Schoenwaelder To: Stig Venaas Cc: Gert Doering , Michael H Lambert , "'v6ops@ops.ietf.org '" Subject: Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-ID: <20050721092504.GB12743@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Stig Venaas , Gert Doering , Michael H Lambert , "'v6ops@ops.ietf.org '" References: <21f795d5474b2b4035d4fee5a385b237@cisco.com> <520BBF82BF06AF94B0BD0358@lassa.psc.edu> <20050718090922.GU84850@Space.Net> <20050721080313.GA15046@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721080313.GA15046@storhaugen.uninett.no> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 21, 2005 at 10:03:13AM +0200, Stig Venaas wrote: > I also think the second is the intention. However, I think it might be a > bad idea, so I would perhaps prefer to read it as "don't do this". When > picking IPv6 prefixes for links people use all kinds of creative tricks > where the prefixes have some meaning. This is one example. I understand > it can make it easier for some administrator initially. I have recently adopted this scheme and so far this has proven to be a nice idea although we had a discussion whether we translate VLAN numbers into equivalent hexadecimal numbers or whether we literally translate the numbers. We decided to literally translate the numbers, that is VLAN 1234 becomes IPv6 prefix .1234 since the goal of this scheme is to make things really easy for administrators. (A nice benefit of this approach is also that all prefixes with at least one hexadecimal letter are kind of preserved and can be used for other purposes later on.) Anyway, what I really would have liked to see is a discussion what the pros and cons are and for example whether you translate numbers literally or the real numbers. This would have added practical value to the document. (But I do not complain since I myself did not submit concrete text to add to the document so far. Perhaps this is a start now.) The argument that "once you decide on a scheme you might later regret it if you have to change the scheme" is not totally convincing. I believe this scheme has operationally clear advantages, especially if your VLAN setup is rather stable. A downside I am more worried about is that using the literal mapping scheme reduces the practically used IPv6 address space and makes it a bit more feasible to heuristically search IPv6 address spaces. Not sure how much this is a real issue in practical installations - but I think this deserves to be mentioned somewhere. > Problem is that you may later be forced to renumber just to preserve > your naming, or you don't and then you have exceptions to the rule > that was initially created. Sure, this is a point to add. The scheme requires to be consistent. If you change your VLAN numbers without changing the IPv6 prefixes, you loose all the benefits and the scheme turns very quickly against you. So yes, this should be spelled out and people adopting the scheme should be prepared to do such renumberings. We are clearly prepared to do just that in case VLANs will be renumbered (something I hardly imagine to happen - it is usually more likely that VLANs are split apart into new VLANs in our environment. But even in these cases, we prefer to renumber the IPv6 clouds as well for consistency. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Thu Jul 21 08:04:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZn2-0007gC-BS for v6ops-archive@megatron.ietf.org; Thu, 21 Jul 2005 08:04:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23850 for ; Thu, 21 Jul 2005 08:04:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvZjR-000MWk-Jk for v6ops-data@psg.com; Thu, 21 Jul 2005 12:00:53 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DvZjP-000MWM-GS for v6ops@ops.ietf.org; Thu, 21 Jul 2005 12:00:51 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6LC0nIh030691; Thu, 21 Jul 2005 14:00:49 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6LC0nld015559; Thu, 21 Jul 2005 14:00:49 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6LC0nRH015558; Thu, 21 Jul 2005 14:00:49 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 21 Jul 2005 14:00:49 +0200 From: Stig Venaas To: Gert Doering , Michael H Lambert , "'v6ops@ops.ietf.org '" Subject: Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt Message-ID: <20050721120049.GB15258@storhaugen.uninett.no> References: <21f795d5474b2b4035d4fee5a385b237@cisco.com> <520BBF82BF06AF94B0BD0358@lassa.psc.edu> <20050718090922.GU84850@Space.Net> <20050721080313.GA15046@storhaugen.uninett.no> <20050721092504.GB12743@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721092504.GB12743@boskop.local> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jul 21, 2005 at 11:25:04AM +0200, Juergen Schoenwaelder wrote: > On Thu, Jul 21, 2005 at 10:03:13AM +0200, Stig Venaas wrote: > > > I also think the second is the intention. However, I think it might be a > > bad idea, so I would perhaps prefer to read it as "don't do this". When > > picking IPv6 prefixes for links people use all kinds of creative tricks > > where the prefixes have some meaning. This is one example. I understand > > it can make it easier for some administrator initially. > > I have recently adopted this scheme and so far this has proven to be > a nice idea although we had a discussion whether we translate VLAN > numbers into equivalent hexadecimal numbers or whether we literally > translate the numbers. We decided to literally translate the numbers, > that is VLAN 1234 becomes IPv6 prefix .1234 since the goal of > this scheme is to make things really easy for administrators. (A nice > benefit of this approach is also that all prefixes with at least one > hexadecimal letter are kind of preserved and can be used for other > purposes later on.) Right. I do see why this is useful of course. And I agree that it's more convenient to literally translate them like you say. > Anyway, what I really would have liked to see is a discussion what the > pros and cons are and for example whether you translate numbers > literally or the real numbers. This would have added practical value > to the document. (But I do not complain since I myself did not submit > concrete text to add to the document so far. Perhaps this is a start > now.) I suppose the idea is to make it easy to relate addresses to vlans, so it definitely seems best to not do any hex conversions. I know other cases also where people have chosen the "literal" way, simply because humans need more than a split second to convert between hex and decimal... > The argument that "once you decide on a scheme you might later regret it > if you have to change the scheme" is not totally convincing. I believe > this scheme has operationally clear advantages, especially if your VLAN > setup is rather stable. A downside I am more worried about is that using I understand what you're saying, but I don't find that totally convincing either (: > the literal mapping scheme reduces the practically used IPv6 address > space and makes it a bit more feasible to heuristically search IPv6 > address spaces. Not sure how much this is a real issue in practical > installations - but I think this deserves to be mentioned somewhere. Right, I'm not sure these are worth worrying about though. > > Problem is that you may later be forced to renumber just to preserve > > your naming, or you don't and then you have exceptions to the rule > > that was initially created. > > Sure, this is a point to add. The scheme requires to be consistent. If > you change your VLAN numbers without changing the IPv6 prefixes, you > loose all the benefits and the scheme turns very quickly against you. > So yes, this should be spelled out and people adopting the scheme > should be prepared to do such renumberings. We are clearly prepared > to do just that in case VLANs will be renumbered (something I hardly > imagine to happen - it is usually more likely that VLANs are split > apart into new VLANs in our environment. But even in these cases, Right, splitting or merging of VLANs should not be a problem. You will always have to renumber "half" of the hosts. So the question then is whether any of this should be in the draft. All of this seems pretty obvious, but if the draft starts suggesting possible ways of choosing IPv6 prefixes, then it should perhaps add some pros and cons as you say. Another comment regarding the draft. The example in the appendix seems needlessly complex, in particular there is some load balancing that could be avoided. Well, as I understand it's been through last call already, it may not be worth changing the document... Stig > we prefer to renumber the IPv6 clouds as well for consistency. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Mon Jul 25 04:33:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyP0-0000Ab-8s for v6ops-archive@megatron.ietf.org; Mon, 25 Jul 2005 04:33:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27466 for ; Mon, 25 Jul 2005 04:33:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DwyLR-000MS8-Vv for v6ops-data@psg.com; Mon, 25 Jul 2005 08:29:53 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwyLP-000MRp-Oj for v6ops@ops.ietf.org; Mon, 25 Jul 2005 08:29:52 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6P8ThIh014227; Mon, 25 Jul 2005 10:29:43 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6P8TgmM022865; Mon, 25 Jul 2005 10:29:42 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6P8TgNx022864; Mon, 25 Jul 2005 10:29:42 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 25 Jul 2005 10:29:42 +0200 From: Stig Venaas To: Mark Smith Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-ID: <20050725082942.GA22657@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: > Hi, > > On Sat, 18 Jun 2005 01:18:42 +0930 > Mark Smith wrote: > > > Hi, > > > > "6.2 Subnet topology masking > > > > There really is no functional gap here as a centrally assigned > > pool of addresses in combination with host routes in the IGP is an > > effective way to mask topology. " > > > > I'm wondering if the above is actually the case. > > > > I think host routes are easy enough to understand from the point of view > > of propagating /128s around within an IGP. > > > > What I'm curious about is how the end-nodes are configured and how they > > operate, in particular when they are attached to a broadcast > > multi-access link e.g., an ethernet. Has this operation been discussed or > > described in an ID or RFC that I'm not aware of ? > > > > It looks like a /128 prefix length is not permitted on an interface, > according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means > most of the issues I was concerned about described disappear. You're refering to 2.5.1 where it says For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. I guess. I can't say I like this. I believe it's quite common in IPv6 to use /128 for addresses on loopback interfaces on routers and inject those into IGP (just like IPv4 /32). If I understand this correctly, one would then be forced to use a different /64 for each router loopback. It's also pretty common to use a longer than 64 prefix for tunnels, e.g. /126. Is strictly speaking an interface identifier always needed? As it says in 2.5.1 it's used to identify interfaces on a link, but for loopback there isn't really any link... You wouldn't need to do ND etc for the loopback addresses. > I'm still not sure exactly how host routing would work from the > end-nodes point of view, so I'll continue to do some reading. It seems > to me that hiding the network or subnet topology by not grouping IPv6 > addresses according to their common data links means that the subnet bit > portion of the address loses its significance when determining whether a > destination address is off or onlink, during Neighbour Discovery. The way I see it the hosts would have physical interfaces connected to a physical link and have addresses for those doing ND etc as usual. In addition they would have some kind of virtual interface with some /128 addresses and somehow inject host routes for those on the physical interfaces so that next-hop would be the (e.g. /64) addresses on the physical links. This is how I believe it works today when you use loopbacks with /128 for routers. Stig > > Thanks, > Mark. From owner-v6ops@ops.ietf.org Mon Jul 25 07:00:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0hS-0000jl-JF for v6ops-archive@megatron.ietf.org; Mon, 25 Jul 2005 07:00:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06289 for ; Mon, 25 Jul 2005 07:00:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx0eo-0009Yz-QL for v6ops-data@psg.com; Mon, 25 Jul 2005 10:58:02 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dx0em-0009Yb-T2 for v6ops@ops.ietf.org; Mon, 25 Jul 2005 10:58:01 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6PAvqIh010089; Mon, 25 Jul 2005 12:57:52 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6PAvq4E023531; Mon, 25 Jul 2005 12:57:52 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6PAvqOU023530; Mon, 25 Jul 2005 12:57:52 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 25 Jul 2005 12:57:52 +0200 From: Stig Venaas To: Mark Smith Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-ID: <20050725105752.GA23494@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050725082942.GA22657@storhaugen.uninett.no> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jul 25, 2005 at 10:29:42AM +0200, Stig Venaas wrote: [...] > On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: [...] > You're refering to 2.5.1 where it says > > For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > I guess. I can't say I like this. I believe it's quite common in IPv6 > to use /128 for addresses on loopback interfaces on routers and inject > those into IGP (just like IPv4 /32). If I understand this correctly, > one would then be forced to use a different /64 for each router loopback. > It's also pretty common to use a longer than 64 prefix for tunnels, e.g. > /126. Come to think of it, is there anything preventing using the last 64 bits of an address as an IID when it is /126 (/128 or whatever >64)? On say a tunnel with /126, you would then have 64 bit IIDs that are unique to the link because the last 2 bits are unique to the link. Stig From owner-v6ops@ops.ietf.org Mon Jul 25 10:53:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4Ke-0003E6-HE for v6ops-archive@megatron.ietf.org; Mon, 25 Jul 2005 10:53:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27087 for ; Mon, 25 Jul 2005 10:53:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx4IL-0006AZ-Nt for v6ops-data@psg.com; Mon, 25 Jul 2005 14:51:05 +0000 Received: from [203.103.165.70] (helo=smta03.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dx4II-00069r-0u for v6ops@ops.ietf.org; Mon, 25 Jul 2005 14:51:02 +0000 Received: from ubu.nosense.org ([210.84.225.248]) by smta03.mail.ozemail.net with ESMTP id <20050725145057.HVQC5688.smta03.mail.ozemail.net@ubu.nosense.org>; Mon, 25 Jul 2005 14:50:57 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 59A5B62AAE; Tue, 26 Jul 2005 00:20:55 +0930 (CST) Date: Tue, 26 Jul 2005 00:20:55 +0930 From: Mark Smith To: Stig Venaas Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050725082942.GA22657@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stig, On Mon, 25 Jul 2005 10:29:42 +0200 Stig Venaas wrote: > On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: > > Hi, > > > > > It looks like a /128 prefix length is not permitted on an interface, > > according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means > > most of the issues I was concerned about described disappear. > > You're refering to 2.5.1 where it says > > For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > I guess. I can't say I like this. I believe it's quite common in IPv6 > to use /128 for addresses on loopback interfaces on routers and inject > those into IGP (just like IPv4 /32). If I understand this correctly, > one would then be forced to use a different /64 for each router loopback. I'd interpret it that way. > It's also pretty common to use a longer than 64 prefix for tunnels, e.g. > /126. > > Is strictly speaking an interface identifier always needed? As it says > in 2.5.1 it's used to identify interfaces on a link, but for loopback > there isn't really any link... You wouldn't need to do ND etc for the > loopback addresses. > That's a good point. Generally, the prefix length on an interface address assignment indicates what destinations are on-link or offlink, although with IPv6, unlike IPv4, ICMP redirects for a link router can also indicate that "offlink" destinations, ie. those that don't fall within the host's currently known /64s, are actually onlink, at a host level. With a loopback (assigned either a /128 or just a /64), all other destinations are offlink, and obviously there aren't going to be any routers on the loopback "link" to correct any wrong offlink assumptions via an ICMP redirect. From what I've read in Christian Huitema's "IPv6 - The New Internet Protocol", and what I remember of it, the origins of the /64 length were some discussions of the idea of being able to swap the top 64 bits at routing domain boundaries, allowing for easy re-addressesing, proposed by Mike O'Dell. The book indicates that that idea wasn't fully agreed with, however it did cause the /64 boundary to be put in place in case something like that idea could be useful in the future. I don't remember enough about the reasons for the /64 boundary, I wonder if using /128s on loopbacks would contradict them. Some of the arguments against /127s on point-to-point links in RFC3627 "Use of /127 Prefix Length Between Routers Considered Harmful" may be worth considering in the context of /128s on loopbacks. Regarding loopbacks, irrespective of whether they are assigned a /128 or a /64, I'd guess the loopback interface would never see any RAs from any routers at all, which means that any automated RA address assignment / renumbering mechanisms e.g., prefix lifetimes, etc., won't be able to be used on them either. > > I'm still not sure exactly how host routing would work from the > > end-nodes point of view, so I'll continue to do some reading. It seems > > to me that hiding the network or subnet topology by not grouping IPv6 > > addresses according to their common data links means that the subnet bit > > portion of the address loses its significance when determining whether a > > destination address is off or onlink, during Neighbour Discovery. > > The way I see it the hosts would have physical interfaces connected to a > physical link and have addresses for those doing ND etc as usual. In > addition they would have some kind of virtual interface with some /128 > addresses and somehow inject host routes for those on the physical > interfaces so that next-hop would be the (e.g. /64) addresses on the > physical links. This is how I believe it works today when you use > loopbacks with /128 for routers. > I think that would work. However, even if it is accepted to run some form of routing protocol on the end-nodes to push host routes into the routing cloud, there would still have to be a manual address assignment process for the /128s on the loopback interfaces, because as you mentioned before, the loopback interfaces probably won't receive any ND protocol messages such as RAs. That could arguably be considered an impractical solution "in this day and age", because staticly configured addresses on hosts in IPv6 is so pre-DHCP IPv4 :-) To hide the network topology from nodes external to this network domain, then I'd think the /64s assigned to the links would have to be ULAs, although I think the link-local addresses might be enough to support forwarding the packets from the edge of the routing domain to the host within it and vice-versa. The problem there though is that any ICMP messages generated by routers, targeted towards external nodes, such as Destination Unreachables, Packet Too Big would have "private" source addresses, and would likely to be dropped by the routers at the edge that are using source address filtering to prevent things like SYN attacks. IOW, the same problems that occur now if somebody uses RFC1918 private addresses on their internal links. I suppose as long as all the routers as well had /128s on loopback addresses (not a bad idea at all), and as long as the ICMP messages used the loopback addresses as the source addresses, that problem might not occur. Regards, Mark. From owner-v6ops@ops.ietf.org Mon Jul 25 10:57:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4P0-0006Cd-Ot for v6ops-archive@megatron.ietf.org; Mon, 25 Jul 2005 10:57:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27521 for ; Mon, 25 Jul 2005 10:57:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx4Ob-000723-Bx for v6ops-data@psg.com; Mon, 25 Jul 2005 14:57:33 +0000 Received: from [203.103.165.90] (helo=smta05.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dx4OZ-00071a-2j for v6ops@ops.ietf.org; Mon, 25 Jul 2005 14:57:31 +0000 Received: from ubu.nosense.org ([210.84.225.248]) by smta05.mail.ozemail.net with ESMTP id <20050725145728.HPSQ9768.smta05.mail.ozemail.net@ubu.nosense.org>; Mon, 25 Jul 2005 14:57:28 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 75C9762AAE; Tue, 26 Jul 2005 00:27:27 +0930 (CST) Date: Tue, 26 Jul 2005 00:27:27 +0930 From: Mark Smith To: Stig Venaas Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050726002727.6a8828d8.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050725105752.GA23494@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> <20050725105752.GA23494@storhaugen.uninett.no> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stig, On Mon, 25 Jul 2005 12:57:52 +0200 Stig Venaas wrote: > On Mon, Jul 25, 2005 at 10:29:42AM +0200, Stig Venaas wrote: > [...] > > On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: > [...] > > You're refering to 2.5.1 where it says > > > > For all unicast addresses, except those that start with binary value > > 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format. > > > > I guess. I can't say I like this. I believe it's quite common in IPv6 > > to use /128 for addresses on loopback interfaces on routers and inject > > those into IGP (just like IPv4 /32). If I understand this correctly, > > one would then be forced to use a different /64 for each router loopback. > > It's also pretty common to use a longer than 64 prefix for tunnels, e.g. > > /126. > > Come to think of it, is there anything preventing using the last 64 bits > of an address as an IID when it is /126 (/128 or whatever >64)? On say a > tunnel with /126, you would then have 64 bit IIDs that are unique to the > link because the last 2 bits are unique to the link. > I'm not sure I fully understand what you're getting at here, are you able to expand on it a bit more ? In some of my thinking about this host routing issue, I realised that prefix lengths on addresses assigned to interfaces actually indicate two things : - what portion of the address is the node address i.e., where the boundary between the network and node parts falls - what destination addresses are onlink or offlink I think it would be possible to have those two values different for a node's interface, although IPv6 doesn't separate them at the moment. Is that something along the lines of what you're describing with your /126 tunnel suggestion ? Regards, Mark. From owner-v6ops@ops.ietf.org Tue Jul 26 06:59:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxN9e-00021e-Kg for v6ops-archive@megatron.ietf.org; Tue, 26 Jul 2005 06:59:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06229 for ; Tue, 26 Jul 2005 06:59:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxN5y-000AgP-3L for v6ops-data@psg.com; Tue, 26 Jul 2005 10:55:34 +0000 Received: from [62.189.30.132] (helo=paddock.ermy.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DxN5u-000Ae8-Jf for v6ops@ops.ietf.org; Tue, 26 Jul 2005 10:55:30 +0000 Received: (qmail 1132 invoked from network); 26 Jul 2005 11:01:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 26 Jul 2005 11:01:12 -0000 In-Reply-To: <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <583F25A0-55F3-4F19-A037-0B1CC1584EB4@ecs.soton.ac.uk> Cc: Stig Venaas , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Tue, 26 Jul 2005 11:55:24 +0100 To: Mark Smith X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, Stig, On 25 Jul 2005, at 15:50, Mark Smith wrote: > On Mon, 25 Jul 2005 10:29:42 +0200 > Stig Venaas wrote: > >> On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: >>> It looks like a /128 prefix length is not permitted on an interface, >>> according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think >>> means >>> most of the issues I was concerned about described disappear. > > Some of the arguments against /127s > on point-to-point links in RFC3627 "Use of /127 Prefix Length Between > Routers Considered Harmful" may be worth considering in the context of > /128s on loopbacks. We use /112s for point-to-point links, following Pekka's argument in RFC3627, and haven't yet (touch-wood) experienced any difficulties in so doing. However, we have tried to ensure that the u/g bits are set appropriately as if they would have the EUI-64 specified meaning were the addresses under a 64-bit prefix, so that should any implementations blindly assume that node addresses have the bottom 64- bits as an interface identifier, the semantics still hold. Given that this is all under globally aggregatable unicast address space, the topology is such that each /112 will be globally unique and thus the bottom 64-bits unique also, and so the inferred intention of the spec is still obeyed (that is: the bottom 64 bits of the interface's address can be used as an identifier) >>> I'm still not sure exactly how host routing would work from the >>> end-nodes point of view >> >> The way I see it the hosts would have physical interfaces >> connected to a >> physical link and have addresses for those doing ND etc as usual. In >> addition they would have some kind of virtual interface with some / >> 128 >> addresses and somehow inject host routes for those on the physical >> interfaces so that next-hop would be the (e.g. /64) addresses on the >> physical links. This is how I believe it works today when you use >> loopbacks with /128 for routers. > > I think that would work. However, even if it is accepted to run some > form of routing protocol on the end-nodes to push host routes into the > routing cloud, there would still have to be a manual address > assignment > process for the /128s on the loopback interfaces, because as you > mentioned before, the loopback interfaces probably won't receive > any ND > protocol messages such as RAs. That could arguably be considered an > impractical solution "in this day and age", because staticly > configured > addresses on hosts in IPv6 is so pre-DHCP IPv4 :-) One solution might be a new DHCPv6 option to assign addresses on interfaces other than the one we're using to send the DHCPv6 query from. (What would that message look like? Is there scope for some DHCPv6 server-to-router signalling to have the host route injected to the local network, too?) > To hide the network topology from nodes external to this network > domain, > then I'd think the /64s assigned to the links would have to be ULAs, > although I think the link-local addresses might be enough to support > forwarding the packets from the edge of the routing domain to the host > within it and vice-versa. Better pray that you're not using multicast of scopes wider than 5, then ;-) (RFC3484 default policy doesn't bode well when you're using ULAs and multicast together - but that's a different discussion) > The problem there though is that any ICMP messages generated by > routers, targeted towards external nodes, such as > Destination Unreachables, Packet Too Big would have "private" source > addresses, and would likely to be dropped by the routers at the edge > that are using source address filtering to prevent things like SYN > attacks. IOW, the same problems that occur now if somebody uses > RFC1918 > private addresses on their internal links. This is possibly one of the few cases where address translation is desirable with IPv6: at the border router propagating errors outward, masking the internal routing topology. > I suppose as long as all the routers as well had /128s on loopback > addresses (not a bad idea at all), and as long as the ICMP messages > used > the loopback addresses as the source addresses, that problem might not > occur. Taking traceroute as an example (and likely to be the first utility about which users will complain about not returning useful information...) - what is there to guarantee that the address used for ICMP Time exceeded messages would be the global loopback address of the reporting router, rather than it's ULA/private address of the interface on which the message is generated? regards, Mark/ -- Dr Mark K. Thompson Electronics and Computer Science a School of the University of Southampton, UK From owner-v6ops@ops.ietf.org Tue Jul 26 07:13:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNMt-0005DP-Gf for v6ops-archive@megatron.ietf.org; Tue, 26 Jul 2005 07:13:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06937 for ; Tue, 26 Jul 2005 07:13:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxNMB-000CMq-MC for v6ops-data@psg.com; Tue, 26 Jul 2005 11:12:19 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DxNM8-000CMZ-VT for v6ops@ops.ietf.org; Tue, 26 Jul 2005 11:12:17 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6QBC3Ih000717; Tue, 26 Jul 2005 13:12:03 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6QBC3LE029750; Tue, 26 Jul 2005 13:12:03 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6QBC3lJ029749; Tue, 26 Jul 2005 13:12:03 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 26 Jul 2005 13:12:03 +0200 From: Stig Venaas To: "Mark K. Thompson" Cc: Mark Smith , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-ID: <20050726111203.GH29226@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> <583F25A0-55F3-4F19-A037-0B1CC1584EB4@ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <583F25A0-55F3-4F19-A037-0B1CC1584EB4@ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 26, 2005 at 11:55:24AM +0100, Mark K. Thompson wrote: > Hi Mark, Stig, > > On 25 Jul 2005, at 15:50, Mark Smith wrote: > > >On Mon, 25 Jul 2005 10:29:42 +0200 > >Stig Venaas wrote: > > > >>On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote: > >>>It looks like a /128 prefix length is not permitted on an interface, > >>>according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think > >>>means > >>>most of the issues I was concerned about described disappear. > > > >Some of the arguments against /127s > >on point-to-point links in RFC3627 "Use of /127 Prefix Length Between > >Routers Considered Harmful" may be worth considering in the context of > >/128s on loopbacks. > > We use /112s for point-to-point links, following Pekka's argument in > RFC3627, and haven't yet (touch-wood) experienced any difficulties in > so doing. > > However, we have tried to ensure that the u/g bits are set > appropriately as if they would have the EUI-64 specified meaning were > the addresses under a 64-bit prefix, so that should any > implementations blindly assume that node addresses have the bottom 64- > bits as an interface identifier, the semantics still hold. > > Given that this is all under globally aggregatable unicast address > space, the topology is such that each /112 will be globally unique > and thus the bottom 64-bits unique also, and so the inferred > intention of the spec is still obeyed (that is: the bottom 64 bits of > the interface's address can be used as an identifier) Right, I think so. This is more or less what I had in mind on my last post yesterday. I think I should go back and re-read some of the RFCs though. > >>>I'm still not sure exactly how host routing would work from the > >>>end-nodes point of view > >> > >>The way I see it the hosts would have physical interfaces > >>connected to a > >>physical link and have addresses for those doing ND etc as usual. In > >>addition they would have some kind of virtual interface with some / > >>128 > >>addresses and somehow inject host routes for those on the physical > >>interfaces so that next-hop would be the (e.g. /64) addresses on the > >>physical links. This is how I believe it works today when you use > >>loopbacks with /128 for routers. > > > >I think that would work. However, even if it is accepted to run some > >form of routing protocol on the end-nodes to push host routes into the > >routing cloud, there would still have to be a manual address > >assignment > >process for the /128s on the loopback interfaces, because as you > >mentioned before, the loopback interfaces probably won't receive > >any ND > >protocol messages such as RAs. That could arguably be considered an > >impractical solution "in this day and age", because staticly > >configured > >addresses on hosts in IPv6 is so pre-DHCP IPv4 :-) > > One solution might be a new DHCPv6 option to assign addresses on > interfaces other than the one we're using to send the DHCPv6 query > from. (What would that message look like? Is there scope for some I'm not sure I like that in general. One thing to consider in general is doing DHCP on multiple links. But we're now talking about virtual interfaces that are not connected to any links, so that's a special case. > DHCPv6 server-to-router signalling to have the host route injected to > the local network, too?) There's been discussion regarding DHCPv6 PD and route injection. This is sort of a degenerated case of that (: I believe how to do injection is the biggest issue here. I don't quite believe in all hosts in a site injection routes. Maybe some kind of tunneling is easier. Mechanisms for injecting host routes could be useful for people doing anycast though. This is done today but then with just a few trusted hosts, not all the hosts in a site. I must say though that I never understood what one gains by hiding the topology, and there's lots of complexity and pain related to this. I guess the idea with NAP draft though is that if some silly people insist on hiding their topology, then it should tell them how it can be done. > >To hide the network topology from nodes external to this network > >domain, > >then I'd think the /64s assigned to the links would have to be ULAs, > >although I think the link-local addresses might be enough to support > >forwarding the packets from the edge of the routing domain to the host > >within it and vice-versa. ULAs? The question is what addresses you use for packets leaving the site, right? ULA would hopefully mostly be used only internally. > Better pray that you're not using multicast of scopes wider than 5, > then ;-) (RFC3484 default policy doesn't bode well when you're using > ULAs and multicast together - but that's a different discussion) > > >The problem there though is that any ICMP messages generated by > >routers, targeted towards external nodes, such as > >Destination Unreachables, Packet Too Big would have "private" source > >addresses, and would likely to be dropped by the routers at the edge > >that are using source address filtering to prevent things like SYN > >attacks. IOW, the same problems that occur now if somebody uses > >RFC1918 > >private addresses on their internal links. > > This is possibly one of the few cases where address translation is > desirable with IPv6: at the border router propagating errors outward, > masking the internal routing topology. Address translation is never desirable. You don't want to rewrite source addresses of packet too big. > >I suppose as long as all the routers as well had /128s on loopback > >addresses (not a bad idea at all), and as long as the ICMP messages > >used > >the loopback addresses as the source addresses, that problem might not > >occur. > > Taking traceroute as an example (and likely to be the first utility > about which users will complain about not returning useful > information...) - what is there to guarantee that the address used > for ICMP Time exceeded messages would be the global loopback address > of the reporting router, rather than it's ULA/private address of the > interface on which the message is generated? > > > regards, > > Mark/ > > -- > Dr Mark K. Thompson > Electronics and Computer Science > a School of the University of Southampton, UK Stig From owner-v6ops@ops.ietf.org Tue Jul 26 07:34:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNi5-0001ji-Vn for v6ops-archive@megatron.ietf.org; Tue, 26 Jul 2005 07:34:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08463 for ; Tue, 26 Jul 2005 07:34:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxNhO-000Dxf-6m for v6ops-data@psg.com; Tue, 26 Jul 2005 11:34:14 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DxNhM-000DxQ-Nj for v6ops@ops.ietf.org; Tue, 26 Jul 2005 11:34:13 +0000 Received: (qmail 7296 invoked by uid 417); 26 Jul 2005 11:34:11 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 26 Jul 2005 11:34:11 -0000 Received: from mehr ([132.70.221.147]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 26 Jul 2005 05:34:10 -0600 Message-ID: <01b201c591d5$679e0d00$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> <583F25A0-55F3-4F19-A037-0B1CC1584EB4@ecs.soton.ac.uk> <20050726111203.GH29226@storhaugen.uninett.no> Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt [not DCHPv6] Date: Tue, 26 Jul 2005 14:30:17 +0300 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-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Stig Venaas Wrote: > There's been discussion regarding DHCPv6 PD and route injection. This > is sort of a degenerated case of that (: > > I believe how to do injection is the biggest issue here. I don't quite > believe in all hosts in a site injection routes. Maybe some kind of > tunneling is easier. > > Mechanisms for injecting host routes could be useful for people doing > anycast though. This is done today but then with just a few trusted > hosts, not all the hosts in a site. Although these are valid points, I would think that these DHCPv6 issues should be brought up in relation to the DHCPv6 drafts rather than the NAP one. > > I must say though that I never understood what one gains by hiding the > topology, and there's lots of complexity and pain related to this. I > guess the idea with NAP draft though is that if some silly people > insist on hiding their topology, then it should tell them how it can > be done. > The point of this draft was that NAT and topology hiding are not useful for security and NAP via native IPv6 can better handle the security issues. This is why we do not offer work arounds that bring back NAT topology hiding into IPv6. Eric From owner-v6ops@ops.ietf.org Tue Jul 26 11:38:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRVo-00062N-B4 for v6ops-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:38:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28535 for ; Tue, 26 Jul 2005 11:38:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxRTc-0007eX-R9 for v6ops-data@psg.com; Tue, 26 Jul 2005 15:36:16 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DxRTb-0007eI-Sy for v6ops@ops.ietf.org; Tue, 26 Jul 2005 15:36:16 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6QFaCIh017281; Tue, 26 Jul 2005 17:36:12 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6QFaCu2030698; Tue, 26 Jul 2005 17:36:12 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6QFaB7l030697; Tue, 26 Jul 2005 17:36:11 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 26 Jul 2005 17:36:11 +0200 From: Stig Venaas To: Eric Klein Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt [not DCHPv6] Message-ID: <20050726153611.GA30619@storhaugen.uninett.no> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050725082942.GA22657@storhaugen.uninett.no> <20050726002055.6473e811.ipng@69706e6720323030352d30312d31340a.nosense.org> <583F25A0-55F3-4F19-A037-0B1CC1584EB4@ecs.soton.ac.uk> <20050726111203.GH29226@storhaugen.uninett.no> <01b201c591d5$679e0d00$0401a8c0@mtc.ki.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b201c591d5$679e0d00$0401a8c0@mtc.ki.se> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 26, 2005 at 02:30:17PM +0300, Eric Klein wrote: > Stig Venaas Wrote: > > There's been discussion regarding DHCPv6 PD and route injection. This > > is sort of a degenerated case of that (: > > > > I believe how to do injection is the biggest issue here. I don't quite > > believe in all hosts in a site injection routes. Maybe some kind of > > tunneling is easier. > > > > Mechanisms for injecting host routes could be useful for people doing > > anycast though. This is done today but then with just a few trusted > > hosts, not all the hosts in a site. > > Although these are valid points, I would think that these DHCPv6 issues > should be brought up in relation to the DHCPv6 drafts rather than the NAP > one. I only noted DHCPv6 in the first sentence. Everything I say about injection is a general problem. Main point is that having host routes for all hosts (or all that is to communicate with the outside) is not really that easy in practise. So as I'm saying, tunneling might be easier, which is basically what the NAP draft suggests (using MIPv6). > > I must say though that I never understood what one gains by hiding the > > topology, and there's lots of complexity and pain related to this. I > > guess the idea with NAP draft though is that if some silly people > > insist on hiding their topology, then it should tell them how it can > > be done. > > > The point of this draft was that NAT and topology hiding are not useful for > security and NAP via native IPv6 can better handle the security issues. This > is why we do not offer work arounds that bring back NAT topology hiding into > IPv6. But you try to offer work arounds by suggesting MIPv6, right? And the question was whether other tunneling mechanisms or host routes could be an alternative. Stig > > Eric > From Mike@execs.com Tue Jul 26 13:36:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTMB-0000Xh-Jp; Tue, 26 Jul 2005 13:36:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09009; Tue, 26 Jul 2005 13:36:39 -0400 (EDT) Received: from ltm-84-242-95-66.nat.karneval.cz ([84.242.95.66] helo=doramail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxTrE-0004OR-60; Tue, 26 Jul 2005 14:08:50 -0400 From: "Feijo Jesseney" To: "Bozkurt Tolga" Subject: Re[7]: discussion about their meds Date: Tue, 26 Jul 2005 17:36:36 -0100 Message-ID: <73e301c59208$07b39eec$54007977@doramail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_456789AB.CDEF0123" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.9 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 This is a multi-part message in MIME format. ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Untitled Document
GE RI AG
NE C VI RA
CI IS & LE TRA
AL VI
we  ive ldw
del r wor ide

Spe l off Sav %! er no
cia er!  e 70  Ord w!
.............................................................= .........................................................................= ........................

OR R!
DE

.............................................................= .........................................................................= ........................
































t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. ------=_NextPart_000_0123_456789AB.CDEF0123-- From Garratt@caller.com Wed Jul 27 16:47:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxsog-00052K-Ks; Wed, 27 Jul 2005 16:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01778; Wed, 27 Jul 2005 16:47:46 -0400 (EDT) Received: from 133.red-83-54-255.pooles.rima-tde.net ([83.54.255.133] helo=sverige.nu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxtJr-0002ks-BH; Wed, 27 Jul 2005 17:20:12 -0400 From: "Berus Tanja" To: "Medro Medro" Subject: Re[3]: question with your health Date: Wed, 27 Jul 2005 20:47:42 +0300 Message-ID: <0cd901c592ec$04e42d9e$54007977@sverige.nu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4567_89ABCDEF.01234567" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 This is a multi-part message in MIME format. ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The  al Do Hal l 20 mi ore Se
Usu se is  f A pil n Bef x
  Th ewe an Saf t Wa Ph macy 
e N st  d The  es y of  ar
 
SPU M
R-
 
Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
 
100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

 

































SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa siojnrnnoirknnonnnnjnjonnpqfonomnmohsqoonkou gpkqgnkqkigrjfkljkjfkijjjrmokiktjnkqgfkfihhl kkgpftfnfggkftfujjfqgofufkfmgogkiggqglffgikngnfpgt lghihkijhqiuirmgirhrirfnfngjflhjfrfigiftjmfkgofq ihmhlgljlflnlimomuhfmrlplgljmmlflfkkmumhlrmuijmjltmp kggfgkgpgojmfofignfffrgkfhihgpggfggfkogmfqgs tsppqjqfqjqsplrsninsolnpnlniojpnnfnuounpringosom hhlkmumpikmqmkltmhmtmqlrlfjnjmkmjhfqjokkju oksjokrqsksknprosqrorirksqrqtusosjrlskopsprjsf ------=_NextPart_000_4567_89ABCDEF.01234567--
Wor de shi g wit hou
ld Wi ppin hin 24  rs