From Helena-crollai@MULTI-INSTRUMENTS.NL Fri Feb 1 00:02:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7733A686A for ; Fri, 1 Feb 2008 00:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 88.522 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=88.522 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_DICK=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: limeenso.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: limeenso.com] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [78.90.114.195 listed in dnsbl.sorbs.net] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: limeenso.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: limeenso.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: limeenso.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: limeenso.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: limeenso.com] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shd8lzRoJ2dG for ; Fri, 1 Feb 2008 00:02:15 -0800 (PST) Received: from [78.90.114.195] (unknown [78.90.114.195]) by core3.amsl.com (Postfix) with ESMTP id 493C13A685C for ; Fri, 1 Feb 2008 00:02:14 -0800 (PST) Message-ID: <001101c864a8$f944ad10$c3725a4e@stefanov> From: "Helena Tolliver" To: v6ops-archive@ietf.org Subject: ***SPAM*** 88.522 (5) Do not bow to nature It is possible to extend your manhood up to SIX inches Date: Fri, 1 Feb 2008 10:03:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C864B9.BCCD7D10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000D_01C864B9.BCCD7D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Carry yourself with confidence - get your new huge d1ck here ----------=_NextPart_000_000D_01C864B9.BCCD7D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Carry yourself with confidence - = get your new=20 huge d1ck here ----------=_NextPart_000_000D_01C864B9.BCCD7D10-- From NIELS-cuphead@MULTI-INSTRUMENTS.NL Fri Feb 1 00:05:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937EE3A6875 for ; Fri, 1 Feb 2008 00:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 98.879 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=98.879 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FS_HUGECOCK=10.357, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_DICK=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 10 FS_HUGECOCK Phrase: Huge Cock * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [78.90.114.195 listed in dnsbl.sorbs.net] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: canregit.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: canregit.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: canregit.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: canregit.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: canregit.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: canregit.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: canregit.com] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a75ljZjVHDRP for ; Fri, 1 Feb 2008 00:04:59 -0800 (PST) Received: from [78.90.114.195] (unknown [78.90.114.195]) by core3.amsl.com (Postfix) with ESMTP id 4BA113A6853 for ; Fri, 1 Feb 2008 00:04:59 -0800 (PST) Message-ID: <000c01c864a9$5b561d40$c3725a4e@stefanov> From: "NIELS Misquita" To: v6ops-archive@lists.ietf.org Subject: ***SPAM*** 98.879 (5) Evenings alone are a thing of the past with your brand new huge d1ck Date: Fri, 1 Feb 2008 10:06:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C864BA.1EDEED40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0008_01C864BA.1EDEED40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do not make the mistake of being content with your d1ck ----------=_NextPart_000_0008_01C864BA.1EDEED40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do not make the mistake of being = content with=20 your d1ck ----------=_NextPart_000_0008_01C864BA.1EDEED40-- From owner-v6ops@ops.ietf.org Fri Feb 1 00:43:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D903A687F for ; Fri, 1 Feb 2008 00:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MPShTTnyJTn for ; Fri, 1 Feb 2008 00:43:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BF19A3A686B for ; Fri, 1 Feb 2008 00:43:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKrQS-000OZl-Cu for v6ops-data@psg.com; Fri, 01 Feb 2008 08:39:08 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKrQP-000OZR-F2 for v6ops@ops.ietf.org; Fri, 01 Feb 2008 08:39:06 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A2A043EA10D; Fri, 1 Feb 2008 09:39:04 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 1CF9D3EA10E; Fri, 1 Feb 2008 09:39:04 +0100 (CET) Message-ID: <47A2DAA4.8070402@free.fr> Date: Fri, 01 Feb 2008 09:39:00 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 CC: Kevin Day , v6ops Subject: Re: 6to4 anycast IP as source address / PTR record References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka Savola wrote : > On Wed, 30 Jan 2008, Kevin Day wrote: >> When a 6to4 relay encapsulates v6 traffic and sends it to a 6to4 host >> over v4, should the source address be 192.88.99.1 or the relay's v4 >> unicast address? IMHO, pending a firm recommendation, the anycast address as source is the most natural choice, and is the best candidate for an answer to the question. (An answer which IMHO is highly desirable.) -This choice limits somewhat risks of address spoofing (if any unicast source address is permitted, any host can pretend being a 6to4 relay). - RFC1546 says about IPv4: " Hosts should accept datagrams with an anycast source address, although some transport protocols (see below) may refuse to accept them.". There is no conflict. - RFC 1884 says, but only about IPv6 "An anycast address must not be used as the source address of an IPv6 packet.". There is no conflict either. The answer to Kevin could then IMO be made official, in a new version of RFC 3068, with something like: "6to4 relay routers (between IPv4 and IPv6 public clouds) MUST use 192.88.99.1 as IPv4 source addresses of IPv6 packets they encapsulate, and check that IPv6 source addresses are not 6to4 (i.e. don't start with 2002::/16). 6to4 routers (between IPv6 private clouds and IPv4-only public networks) SHOULD accept IPv6 encapsulated packets only if: - IPv4 source addresses are not 192.88.99.1 if IPv6 source addresses are 6to4; - IPv4 source addresses are 192.88.99.1 if IPv6 source addresses are not 6to4". >> .The reason this is coming up right now... Since we've started >> running a 6to4 relay, we've had a few complaints show up at our >> abuse@ box asking what this 192.88.99.1 host is on our network, why >> its WHOIS doesn't make sense, and why it's sending them traffic. > > Why doesn't WHOIS make sense? How should this be improved? Maybe it > could say "special anycast" instead of just "special", but it does > provide a pointer.. > > NetRange: 192.88.99.0 - 192.88.99.255 > CIDR: 192.88.99.0/24 > NetName: IANA-192 > NetHandle: NET-192-88-99-0-1 > Parent: NET-192-0-0-0-0 > NetType: IANA Special Use > Comment: This block is reserved for special purposes. > Comment: Please see RFC 3068 for additional information. > Comment: > RegDate: > Updated: 2002-09-16 Full support. Maybe it could be even more reader friendly if "for additional information" would become "for its use in 6to4". Rémi From owner-v6ops@ops.ietf.org Fri Feb 1 01:39:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF90F3A6843 for ; Fri, 1 Feb 2008 01:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tERq23PK-s0G for ; Fri, 1 Feb 2008 01:39:10 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7C3043A6832 for ; Fri, 1 Feb 2008 01:39:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKsMI-0005Bl-3N for v6ops-data@psg.com; Fri, 01 Feb 2008 09:38:54 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKsMD-0005BS-UQ for v6ops@ops.ietf.org; Fri, 01 Feb 2008 09:38:52 +0000 X-IronPort-AV: E=Sophos;i="4.25,289,1199660400"; d="scan'208,217";a="4565307" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2008 10:38:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m119cmpV003255; Fri, 1 Feb 2008 10:38:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m119cdEr013760; Fri, 1 Feb 2008 09:38:43 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 10:38:43 +0100 Received: from [10.0.0.62] ([10.61.66.122]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 10:38:40 +0100 In-Reply-To: <88FDC6C9EFCCEE4CA69577595AD6DB150183926F@FRVELSMBS22.ad2.ad.alcatel.com> References: <77ead0ec0801302108w3120b3a8uefd910567f43fb28@mail.gmail.com> <77ead0ec0801310625x285deb18u4b78a0b2089354ef@mail.gmail.com> <4F19CDE8-7704-4577-A2E6-DAD0A42A2081@cisco.com> <77ead0ec0801310929o16ab4207taf7e4308a1029bec@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB1501839267@FRVELSMBS22.ad2.ad.alcatel.com> <77ead0ec0801311311q3eef469fj23a99cfeaab475f5@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB150183926E@FRVELSMBS22.ad2.ad.alcatel.com> <77ead0ec0801311417x1f30f982v9c8b021fa27b9013@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB150183926F@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-6-213215188 Message-Id: <863B3741-A42D-49B7-B16D-0B03BED9346A@cisco.com> Cc: Francois Le Faucheur IMAP , "Vishwas Manral" , , "Ooms Dirk" , From: Francois Le Faucheur IMAP Subject: Re: 6PE-Alt Date: Fri, 1 Feb 2008 10:38:34 +0100 To: DE CLERCQ Jeremy X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 01 Feb 2008 09:38:40.0977 (UTC) FILETIME=[3A95A410:01C864B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=27129; t=1201858728; x=1202722728; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=206PE-Alt |Sender:=20; bh=2LNZLcIDx5k2sJkPXmixVXEgNuKiZLKTXD5e7QpnqCM=; b=dMUVWUL2+asuyJlBd1Z+eYWeE/2jaJss9vFRxteFN2MDxAiApQCSZb4pW8 dG+p6weVgcWNhbXGs54gFbEKEw4SktvaBxZcjGOu0B4D01Df6f/M77AsT3tb ylmG21oxLZ; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-6-213215188 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 1 Feb 2008, at 00:41, DE CLERCQ Jeremy wrote: > > > So the question remains whether the possible benefits of this solution > justify bringing another alternative approach solving the same problem > into the standards. Supporting different label allocation schemes (eg Explicit-Null and per-prefix-label so IPv6 traffic is label switched) was an explicit goal of the 6PE work. The solution has been specified to achieve that flexibility and corresponding interoperability validated. One can always come up with point solutions that are somewhat leaner if you sacrifice flexibility. In this case, I personally don't see that the trade-offs of 6PE-Alt justify revisiting the current solution to either add a restriction on label-allocation (that we explicitly rejected before), or add an extra option that will only make overall interoperability more difficult. Francois > > Regards, > Jeremy. > >> >> Hi Jeremy, >> >> I agree a single level of label should not be used. The 6PE RFC >> clearly talks about reasons for the same in great detail. >> >> That option should not be used and I agree to it. However the 6PE-Alt >> approach uses 2 level of labels. The inner label is the Explicit NULL >> label and the outer label is the tunnel label which gets the packet >> from one 6Pe router to the other. The document below clearly misses >> the idea of using a predefined label as the tunnel label. >> >> I hope things are clearer now to you. >> >> Thanks, >> Vishwas >> >> On Jan 31, 2008 2:07 PM, DE CLERCQ Jeremy >> wrote: >>> Hi Vishwas, >>> >>> I was refering to e.g. section 6.2 in >>> draft-ietf-ngtrans-bgp-tunnel-02.txt, where it says >>> >>> " >>> Where a single level of label is used and no label are advertised by >>> MP-BGP, the SAFI used in MP-BGP will be one of the basic values: >>> unicast, multicast or both (1,2 or 3). >>> " >>> >>> With regards to the reason why the labelled approach was finally >>> selected: it had to do on one hand with the main >> applicability of the >>> approach for routers that typically do labelled BGP distribution for >>> VPNs, and on the other hand with the fact that the >> advantages of using >>> labelled distribution seemed to outweigh the disadvantages >> like memory >>> requirements etc. >>> >>> With regards to interoperability, what I meant was that it >> was deemed >>> better to have not too many optional and alternative >> solutions in one >>> RFC and to limit it to the chosen approach. >>> >>> Regards, >>> Jeremy. >>> >>> >>> >>>> Hi Jeremy, >>>> >>>> I did look at the draft-ietf-ngtrans-bgp-tunnel-02.txt. I >> could not >>>> find a mention of the mechanism I have mentioned. Could you please >>>> point me to the place where the mechanism is mentioned? >>>> >>>> BTW, the simple mechanism you talk about, adds a AFI/ SAFI pair to >>>> BGP, unnecessarily passes labels around which are not >> used at all. It >>>> increases the memory requirement of each route, increases >> the size of >>>> the serach key and has complicated Transit provider >> mechanisms. It in >>>> turn clutters the forwarding tables with data which could >> be easily >>>> done without. The interesting part is the same could be >> done without >>>> any extensions at all. >>>> >>>> You seem to say that due to some interoperability >> concerns you added >>>> the mechanism to explicitly signal labels, which serve no >> purpose. Can >>>> you let me know which implementations had >> interoperability concerns? >>>> It would be great if you can give a more exact technical >> reason of why >>>> the approach we intend to bring to the IETF (which by default is >>>> inter-operable - as no extensions are required). It is >> hard to for a >>>> person who has not been through the entire history to >> understand the >>>> same. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Jan 31, 2008 12:56 PM, DE CLERCQ Jeremy >>>> wrote: >>>>> Hi Vishwas, >>>>> >>>>>> I however am surprised how >>>>>> this simple mechanism was not captured earlier in the >>>> review or coding >>>>>> process. >>>>> >>>>> The work that lead to what is now known as 6PE has seen >>>> many forms and >>>>> many many iterations. Including approaches without label >>>> signaling and >>>>> allocation, even including approaches without MPLS. You >>>> should be able >>>>> to find out about this history via earlier versions of the >>>> draft like >>>>> draft-nguyen-ngtrans-bgp-tunnel-00.txt and >>>>> draft-ietf-ngtrans-bgp-tunnel-02.txt. >>>>> >>>>> So I'd say that this simple mechanism was captured earlier >>>> but that it >>>>> has been decided not to retain it, and to keep only one >> mandatory >>>>> procedure for interoperability purposes. >>>>> >>>>> At the end it was working group consensus and interoperable >>>>> implementations that lead to the current 6PE approach. >>>>> >>>>> Regards, >>>>> Jeremy >>>>> >>>> >>> >> --Apple-Mail-6-213215188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 1 Feb 2008, at 00:41, DE CLERCQ Jeremy = wrote:


So the question remains whether = the possible benefits of this solution
justify = bringing another alternative approach solving the same problem
into the = standards.

Supporting different = label allocation schemes (eg Explicit-Null and per-prefix-label so IPv6 = traffic is label switched) was an explicit goal of the 6PE work. The = solution has been specified to achieve that flexibility and = corresponding interoperability validated.

One can always come up = with point solutions that are somewhat leaner if you sacrifice = flexibility.=A0In this case, I personally don't see that the trade-offs = of 6PE-Alt justify revisiting the current solution to either add a = restriction on label-allocation (that we=A0explicitly=A0rejected = before), or add an extra option that will only make = overall=A0interoperability=A0more difficult.

Francois


Regards,

=
Hi Jeremy,

I agree = a single level of label should not be used. The 6PE RFC
clearly talks about reasons for the same in great = detail.

That option should not be used and I agree to it. = However the 6PE-Alt
approach uses 2 level of = labels. The inner label is the Explicit NULL
label and the outer label is the tunnel label which = gets the packet
from one 6Pe router to the = other. The document below clearly misses
the idea = of using a predefined label as the tunnel label.

I hope = things are clearer now to you.

Thanks,
Vishwas

On Jan 31, 2008 2:07 PM, DE = CLERCQ Jeremy
Hi Vishwas,

I was refering to e.g. section = 6.2 in

Where a single level of label is = used and no label are advertised by
MP-BGP, the = SAFI used in MP-BGP will be one of the basic values:
unicast, multicast or both (1,2 or 3).
"
With regards to the reason why = the labelled approach was finally
selected: it = had to do on one hand with the main=A0
applicability of the
approach for routers that = typically do labelled BGP distribution for
VPNs, = and on the other hand with the fact that the=A0
advantages of using
labelled distribution seemed to = outweigh the disadvantages=A0
like memory
requirements etc.

With regards = to interoperability, what I meant was that it=A0
was deemed
better to have not too many optional and = alternative=A0
=
solutions in one
=
RFC and to limit it to the = chosen approach.

Regards,



Hi Jeremy,

I did look at the = draft-ietf-ngtrans-bgp-tunnel-02.txt. I=A0
=
could not
find a = mention of the mechanism I have mentioned. Could you please
point me to the place where the mechanism is = mentioned?

BTW, the simple mechanism you talk about, adds a = AFI/ SAFI pair to
BGP, unnecessarily passes labels = around which are not=A0
=
used at all. It
=
increases the memory requirement of each route, = increases=A0
=
the size of
=
the serach key and has complicated Transit = provider=A0
=
mechanisms. It in
=
turn clutters the forwarding tables with data which = could=A0
=
be easily
done without. = The interesting part is the same could be=A0
=
done without
=
any extensions at all.

You seem to = say that due to some interoperability=A0
=
concerns you added
=
the mechanism to explicitly signal labels, which = serve no=A0
=
purpose. Can
=
you let me know which implementations had=A0
=
interoperability = concerns?
It would be great if you can give a more exact = technical=A0
=
reason of why
=
the approach we intend to bring to the IETF (which = by default is
inter-operable - as no = extensions are required). It is=A0
=
hard to for a
=
person who has not been through the entire history = to=A0
=
understand the
=
same.

Thanks,
Vishwas

On Jan 31, 2008 12:56 PM, DE = CLERCQ Jeremy
Hi Vishwas,

I = however am surprised how
this simple = mechanism was not captured earlier in the
=
review or coding
=
process.

The work that = lead to what is now known as 6PE has seen
many forms and
many many iterations. Including approaches without = label
signaling and
=
allocation, even including = approaches without MPLS. You
should = be able
to find out = about this history via earlier versions of the
draft like
draft-nguyen-ngtrans-bgp-tunnel-00.txt and
draft-ietf-ngtrans-bgp-tunnel-02.txt.

So I'd = say that this simple mechanism was captured earlier
=
but that it
has been decided not to retain = it, and to keep only one=A0
=
procedure for = interoperability purposes.

At the end it was working group = consensus and interoperable

Jeremy




=

= --Apple-Mail-6-213215188-- From neidrood1968@WABASHNATIONAL.COM Fri Feb 1 01:41:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8FE3A68C7 for ; Fri, 1 Feb 2008 01:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 97.029 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=97.029 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, MANGLED_DICK=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dumetians.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dumetians.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: dumetians.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dumetians.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dumetians.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: dumetians.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dumetians.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [196.206.87.246 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [196.206.87.246 listed in zen.spamhaus.org] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXp+VyELy36k for ; Fri, 1 Feb 2008 01:41:05 -0800 (PST) Received: from adsl196-246-87-206-196.adsl196-3.iam.net.ma (adsl196-246-87-206-196.adsl196-3.iam.net.ma [196.206.87.246]) by core3.amsl.com (Postfix) with ESMTP id 3262B3A689A for ; Fri, 1 Feb 2008 01:41:02 -0800 (PST) Message-ID: <000f01c864b7$d58b5450$f657cec4@windowsxp> From: "ghj hamlin" To: v6ops-archive@megatron.ietf.org Subject: ***SPAM*** 97.029 (5) Be the talk of the town with your new huge schl0ng Date: Fri, 1 Feb 2008 09:50:10 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C864B7.D58B5450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C864B7.D58B5450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make her dreams come true, fulfil her greatest desires with your new big = d1ck ----------=_NextPart_000_000B_01C864B7.D58B5450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make her dreams come true, fulfil = her=20 greatest desires with your new big d1ck ----------=_NextPart_000_000B_01C864B7.D58B5450-- From owner-v6ops@ops.ietf.org Fri Feb 1 02:20:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5367F3A6894 for ; Fri, 1 Feb 2008 02:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2qQjFfXGOhf for ; Fri, 1 Feb 2008 02:20:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2CE763A68B5 for ; Fri, 1 Feb 2008 02:20:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKszH-000A1g-9D for v6ops-data@psg.com; Fri, 01 Feb 2008 10:19:11 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKszE-000A1E-1e for v6ops@ops.ietf.org; Fri, 01 Feb 2008 10:19:09 +0000 Received: from [192.168.0.64] (unknown [203.173.179.166]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id D12A227699; Fri, 1 Feb 2008 23:19:05 +1300 (NZDT) Cc: v6ops WG , Daniel Lawson Message-Id: <2BBB441A-93FA-4946-BB6C-BBD3B446578C@daork.net> From: Nathan Ward To: Fred Baker In-Reply-To: <0250E729-7F3A-43A4-8F68-EF74A1C99B43@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-215645794 Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: More on bittorrent Date: Fri, 1 Feb 2008 23:19:05 +1300 References: <0250E729-7F3A-43A4-8F68-EF74A1C99B43@cisco.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-2-215645794 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit ohOn 1/02/2008, at 7:39 AM, Fred Baker wrote: > very interesting. So I gather that you didn't have to modify BT to > make it use IPv6 directly, you simply used it. That's interesting if > only because it suggests an obvious generator for IPv6 traffic. > > Does it appear to prefer one or the other, or simply try both? Do > you have to do something specific to trigger IPv6 usage? The original BT client<->tracker protocol itself doesn't support IPv6, but the Azureus and uTorrent DHT extensions do. There is also an extension to the client<->tracker protocol to allow IPv6 [1]. Jeroen runs an IPv6-only tracker. Something interesting to note, the example addresses they use on the IPv6 tracker extensions page[1] are Teredo addresses.. I'm using the DHT stuff, as I'm not downloading any torrents. I think it gets me a much much wider range of hosts to talk to. When you refer to either or both, do you mean 6to4/Teredo, or do you mean IPv6/IPv4 As I mention I am only advertising a 6to4 address with DHT. Not sure why yet, the client doesn't seem to want to pick up more than one address. I have significantly fewer Teredo clients than I do 6to4 clients. I assume that's because I am advertising a 6to4 address. Some interesting errors from the client: [net] PRUDPPacketHandler: send to /2002:c0a8:140:1:0:0:0:1:35104 failed: Network is unreachable [net] PRUDPPacketHandler: send to /2002:a00:1:1:0:0:0:1:14544 failed: Network is unreachable (RFC1918 based 6to4 addresses) I also note that those addresses are not in the standard windows 6to4 address format. Windows normally does: 2002:AABB:CCDD::AABB:CCDD, so the IPv4 address is duplicated, so those addresses must be from misconfigured Linux or BSD machines that maybe have automatic "bring up 6to4 when this interface has an IPv4 address" features. Numbers: - Unique inbound sources on 6to4: 20549 - Unique outbound destinations on 6to4: 45882 - Unique inbound source on IPv4: 115307 - Unique outbound destinations on IPv6: 169391 The ratio of inbound:outbound is better on IPv4 it seems, but I'm unclear if that is because more hosts are responding to my requests, or if there are more hosts that are probing on IPv4. I'm inclined to expect it to be the latter.. I'm hacking some code together now to give me an idea of how many hosts reply to my probes. Cheers, -- Nathan Ward [1] http://www.bittorrent.org/ipv6_tracker_extension.html --Apple-Mail-2-215645794 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
ohOn 1/02/2008, at = 7:39 AM, Fred Baker wrote:

very = interesting. So I gather that you didn't have to modify BT to make it = use IPv6 directly, you simply used it. That's interesting if only = because it suggests an obvious generator for IPv6 traffic.

Does = it appear to prefer one or the other, or simply try both? Do you have to = do something specific to trigger IPv6 = usage?

The original BT = client<->tracker protocol itself doesn't support IPv6, but the = Azureus and uTorrent DHT extensions do.

There is = also an extension to the client<->tracker protocol to allow IPv6 = [1]. Jeroen runs an IPv6-only tracker.
Something interesting = to note, the example addresses they use on the IPv6 tracker extensions = page[1] are Teredo addresses..

I'm using the DHT stuff, = as I'm not downloading any torrents. I think it gets me a much much = wider range of hosts to talk to.

When you refer = to either or both, do you mean 6to4/Teredo, or do you mean IPv6/IPv4 As = I mention I am only advertising a 6to4 address with DHT. Not sure why = yet, the client doesn't seem to want to pick up more than one address. I = have significantly fewer Teredo clients than I do 6to4 clients. I assume = that's because I am advertising a 6to4 = address.

Some interesting errors from the = client:
[net] PRUDPPacketHandler: send to = /2002:c0a8:140:1:0:0:0:1:35104 failed: Network is unreachable
(RFC1918 based 6to4 addresses)
I also note that those addresses are not in the = standard windows 6to4 address format. Windows normally does:

Numbers:
- = Unique inbound sources on 6to4: 20549
- Unique outbound = destinations on 6to4: 45882
- Unique inbound source on IPv4: = 115307
- Unique outbound destinations on = IPv6: 169391

The ratio of inbound:outbound is better on IPv4 = it seems, but I'm unclear if that is because more hosts are responding = to my requests, or if there are more hosts that are probing on IPv4. I'm = inclined to expect it to be the latter..
I'm hacking some code = together now to give me an idea of how many hosts reply to my = probes.


Cheers,

= --Apple-Mail-2-215645794-- From slaeufer@1st-support.co.uk Fri Feb 1 03:50:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617E63A696F for ; Fri, 1 Feb 2008 03:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 57.789 X-Spam-Level: ********************************************************* X-Spam-Status: Yes, score=57.789 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: rghpseopga.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: rghpseopga.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [72.224.213.198 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [72.224.213.198 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkC3QoRPnZpH for ; Fri, 1 Feb 2008 03:50:20 -0800 (PST) Received: from cpe-72-224-213-198.maine.res.rr.com (cpe-72-224-213-198.maine.res.rr.com [72.224.213.198]) by core3.amsl.com (Postfix) with ESMTP id 5E9FC3A6946 for ; Fri, 1 Feb 2008 03:50:19 -0800 (PST) Message-ID: <000a01c864c8$dd55be80$c6d5e048@mediacenter> From: "Yihhan Gausepohl" To: v6ops-archive@ietf.org Subject: ***SPAM*** 57.789 (5) Get a new huge colossal rod by clicking here. Date: Fri, 1 Feb 2008 06:52:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C8649E.F47FB680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0006_01C8649E.F47FB680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Give the girls what they want with your long and hard instrument. ----------=_NextPart_000_0006_01C8649E.F47FB680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Give the girls what they want = with your=20 long and hard instrument. ----------=_NextPart_000_0006_01C8649E.F47FB680-- From _slob-orp@1st-support.co.uk Fri Feb 1 03:54:12 2008 Return-Path: <_slob-orp@1st-support.co.uk> X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F18A3A6936 for ; Fri, 1 Feb 2008 03:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 57.789 X-Spam-Level: ********************************************************* X-Spam-Status: Yes, score=57.789 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ghecterosi.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ghecterosi.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [72.224.213.198 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [72.224.213.198 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPyZedi0qzBM for ; Fri, 1 Feb 2008 03:54:11 -0800 (PST) Received: from cpe-72-224-213-198.maine.res.rr.com (cpe-72-224-213-198.maine.res.rr.com [72.224.213.198]) by core3.amsl.com (Postfix) with ESMTP id 176173A6914 for ; Fri, 1 Feb 2008 03:54:10 -0800 (PST) Message-ID: <001001c864c9$670a6e00$c6d5e048@mediacenter> From: "Free Plaado" <_slob-orp@1st-support.co.uk> To: v6ops-archive@lists.ietf.org Subject: ***SPAM*** 57.789 (5) The end to all your frustration lies here - we have the solution to your woes. Date: Fri, 1 Feb 2008 06:55:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C8649F.7E346600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000C_01C8649F.7E346600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration lies here - we have the solution to your = woes. ----------=_NextPart_000_000C_01C8649F.7E346600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration = lies here -=20 we have the solution to your woes. ----------=_NextPart_000_000C_01C8649F.7E346600-- From overcrowdnx@addisplay.net Fri Feb 1 04:06:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79413A6826 for ; Fri, 1 Feb 2008 04:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 90.344 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=90.344 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SPAMMY_XMAILER=2.337, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.4 HELO_EQ_CZ HELO_EQ_CZ * 1.1 HOST_EQ_BROADBND HOST_EQ_BROADBND * 0.9 HOST_EQ_CZ HOST_EQ_CZ * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: immautoue.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: immautoue.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [88.101.161.223 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: immautoue.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: immautoue.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: immautoue.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: immautoue.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: immautoue.com] * 2.3 SPAMMY_XMAILER X-Mailer string is common in spam and not in ham Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWFxhlE74dLd for ; Fri, 1 Feb 2008 04:06:56 -0800 (PST) Received: from 223.161.broadband6.iol.cz (223.161.broadband6.iol.cz [88.101.161.223]) by core3.amsl.com (Postfix) with ESMTP id 2A8983A692B for ; Fri, 1 Feb 2008 04:06:55 -0800 (PST) Received: from [88.101.161.223] by mail.addisplay.net; Fri, 32 Jan 2008 13:08:29 +0100 From: "Alva Ayala" To: Subject: ***SPAM*** 90.344 (5) DickWhoppingShelia Date: Fri, 32 Jan 2008 13:08:29 +0100 Message-ID: <0db0fd74$00000004$dfa16558@overcrowdnx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal ErectileorganMassiveVonda http://www.immautoue.com From teerts@agc.bio.ns.ca Fri Feb 1 04:15:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0E63A6954 for ; Fri, 1 Feb 2008 04:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 59.7 X-Spam-Level: *********************************************************** X-Spam-Status: Yes, score=59.7 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ghecterosi.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ghecterosi.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [71.37.73.115 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [71.37.73.115 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9y9lvxLY9Et for ; Fri, 1 Feb 2008 04:15:01 -0800 (PST) Received: from 71-37-73-115.slkc.qwest.net (71-37-73-115.slkc.qwest.net [71.37.73.115]) by core3.amsl.com (Postfix) with ESMTP id 7541F3A691D for ; Fri, 1 Feb 2008 04:15:00 -0800 (PST) Message-ID: <000701c864cc$4ccd5450$73492547@office> From: "Nuttipol Rego" To: v6ops-archive@megatron.ietf.org Subject: ***SPAM*** 59.7 (5) Chicks will be AMAZED by your legendary PROWESS. Date: Fri, 1 Feb 2008 05:16:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C86491.A06E7C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0003_01C86491.A06E7C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new legendary manhood. ----------=_NextPart_000_0003_01C86491.A06E7C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new = legendary=20 manhood. ----------=_NextPart_000_0003_01C86491.A06E7C50-- From mastura@ncweb.com Fri Feb 1 06:29:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56AEC28EA9C for ; Fri, 1 Feb 2008 06:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 117.87 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=117.87 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 1.2 HELO_EQ_TELESP HELO_EQ_TELESP * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.3 HOST_EQ_BR HOST_EQ_BR * 1.0 HELO_EQ_BR HELO_EQ_BR * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: strutfootsite.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: strutfootsite.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: strutfootsite.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: strutfootsite.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: strutfootsite.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: strutfootsite.com] * 1.5 DNS_FROM_RFC_DSN RBL: Envelope sender in dsn.rfc-ignorant.org * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [200.168.21.73 listed in zen.spamhaus.org] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [200.168.21.73 listed in dnsbl.sorbs.net] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: strutfootsite.com] * 1.7 SARE_RECV_SPAM_DOMN02 Email passed through apparent spammer domain * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t61e35Zeux72 for ; Fri, 1 Feb 2008 06:29:48 -0800 (PST) Received: from 200-168-21-73.dsl.telesp.net.br (200-168-21-73.dsl.telesp.net.br [200.168.21.73]) by core3.amsl.com (Postfix) with ESMTP id 530AD28E009 for ; Fri, 1 Feb 2008 06:02:57 -0800 (PST) Message-ID: <000a01c864db$0358bc6a$9d6ba0a0@sshrq> From: "kerby narciso" To: Subject: ***SPAM*** 117.87 (5) Save today 60% Off ALL Designer Footwear such as Gucci Prada Chanel Date: Fri, 01 Feb 2008 12:17:08 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C864DB.0354569F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C864DB.0354569F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable They say first impressions are everything... Make sure you stand your ground when walking around, simply by walking = hard in Top Brand Name Designer Footwear. Forget department store prices, Enjoy DIRECT PRICING at more than 65% = OFF on a wide variety of 2008 Collections from Versace, Prada, Chanel, = Dior & More. =20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers and = Casual Shoes from Brand Names at less than WHOLESALE prices. Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR! Forget Department Store Prices, Buy Direct=20 Visit Today! Click Here.... =20 =20 strutfootsite.com ------=_NextPart_000_0007_01C864DB.0354569F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

They say first = impressions are everything...
Make sure you stand your ground when walking around, simply by walking = hard in Versace, = Prada, Chanel, Dior & More.

=20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers = and Casual Shoes from Brand Names at less than WHOLESALE prices.
Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR!

Forget Department = Store Prices, Buy Direct
Visit Today! Click Here....
------=_NextPart_000_0007_01C864DB.0354569F-- From owner-v6ops@ops.ietf.org Fri Feb 1 07:19:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9023A6A32 for ; Fri, 1 Feb 2008 07:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[AWL=-1.749, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGNAN3tBl2LX for ; Fri, 1 Feb 2008 07:19:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C776728C46E for ; Fri, 1 Feb 2008 06:52:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKxBj-000MrI-Vr for v6ops-data@psg.com; Fri, 01 Feb 2008 14:48:19 +0000 Received: from [207.5.72.225] (helo=EXHUB016-4.exch016.msoutlookonline.net) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKxBe-000Mqd-EU for v6ops@ops.ietf.org; Fri, 01 Feb 2008 14:48:18 +0000 Received: from EXVMBX016-2.exch016.msoutlookonline.net ([207.5.72.172]) by EXHUB016-4.exch016.msoutlookonline.net ([207.5.72.225]) with mapi; Fri, 1 Feb 2008 06:48:13 -0800 From: David Conrad To: Kevin Day CC: v6ops Date: Fri, 1 Feb 2008 06:48:12 -0800 Subject: Re: 6to4 anycast IP as source address / PTR record Thread-Topic: 6to4 anycast IP as source address / PTR record Thread-Index: AchkiQIZEJ2nmdFcRHCuQZSKnga73wAWHWt9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is really unrelated to real content in this discussion, so this'll be my last comment. On 1/31/08 8:13 PM, "Kevin Day" wrote: > I'd considered trying to sell the idea of a name under .arpa, but > thought that would just add even more debate over what's acceptable to > put under .arpa and what isn't. ARPA =3D "Address and Routing Parameter Area" (at least now :-)). 6to4 see= ms like it would fit in their nicely to me. I suspect all it would need would be a reference in an RFC (or perhaps merely asking the IAB to have it delegated). > I was actually going to propose something along the lines of "anycast. > 6to4.relay.see.rfc3068.net", with "www.rfc3068.net" being a very brief > description of what it's used for. My personal feeling is that use of gTLDs for infrastructure is fundamentall= y broken. While I'm sure ICANN, VeriSign, and whatever registrar you use appreciate the revenue, it isn't clear to me that this is appropriate for stuff defined (explicitly or implicitly) via IETF protocols. However, in the grand scheme of things, it probably isn't that big a deal..= . Regards, -drc From washtubs@ncyberspace.com Fri Feb 1 08:08:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598C93A69A2 for ; Fri, 1 Feb 2008 08:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 92.6 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=92.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TRACKER_ID=2.003, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 2.0 TRACKER_ID BODY: Incorporates a tracking ID number * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tiffuest.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tiffuest.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tiffuest.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tiffuest.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tiffuest.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tiffuest.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tiffuest.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [88.232.208.161 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 1.5 DNS_FROM_RFC_BOGUSMX RBL: Envelope sender in * bogusmx.rfc-ignorant.org * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgMdnK3dPHc7 for ; Fri, 1 Feb 2008 08:08:51 -0800 (PST) Received: from [88.232.208.161] (unknown [88.232.208.161]) by core3.amsl.com (Postfix) with ESMTP id F3F6D28C251 for ; Fri, 1 Feb 2008 08:07:28 -0800 (PST) Received: from [88.232.208.161] by smtp.secureserver.net; Fri, 32 Jan 2008 18:09:04 +0200 From: "Clifford Tapia" To: Subject: ***SPAM*** 92.6 (5) DanielleSizableErectileorgan Date: Fri, 32 Jan 2008 18:09:04 +0200 Message-ID: <0a70fd74$00000005$a1d0e858@washtubs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal BouffantBodypartEarl http://www.tiffuest.com From shuhui@uboc.com Fri Feb 1 08:43:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114523A698E for ; Fri, 1 Feb 2008 08:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 74.774 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=74.774 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FB_CIALIS_LEO3=3.899, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=1, MANGLED_CIALIS=2.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DRUG_GAP_C=0.003, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 SUBJECT_DRUG_GAP_C Subject contains a gappy version of 'cialis' * 2.5 MANGLED_CIALIS BODY: mangled Cialis * 3.9 FB_CIALIS_LEO3 BODY: Uses a mis-spelled version of cialis. * 1.0 GB_PHARMACY BODY: I smoke two joints at night. * 1.0 HTML_MESSAGE BODY: HTML included in message * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: travelthus.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: travelthus.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: travelthus.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: travelthus.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [24.58.188.158 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [24.58.188.158 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 1.5 DRUGS_ERECTILE_OBFU Obfuscated reference to an erectile drug * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGhbAiibyrmG for ; Fri, 1 Feb 2008 08:43:14 -0800 (PST) Received: from cpe-24-58-188-158.twcny.res.rr.com (cpe-24-58-188-158.twcny.res.rr.com [24.58.188.158]) by core3.amsl.com (Postfix) with ESMTP id 48E803A684D for ; Fri, 1 Feb 2008 08:43:14 -0800 (PST) Message-ID: <000901c864f1$05d90cd8$2fbe459a@hhvaatl> From: "lambert jole" To: Subject: ***SPAM*** 74.774 (5) Cialiis Email from ED. Date: Fri, 01 Feb 2008 14:57:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C864F1.05D8392F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C864F1.05D8392F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You may not be able to take tadalafil, or you may require a dosage = adjustment or special monitoring during treatment if you are taking any = of the medicines listed above. CIA-LIS - From a pharmacy that believes in providing excellent services = and the cheapest pr_ic_es 1ndian cheaap meedss ------=_NextPart_000_0006_01C864F1.05D8392F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You may not be able to take tadalafil, or you may require a dosage = adjustment or special monitoring during treatment if you are taking any = of the medicines listed above.

CIA-LIS - From a = pharmacy that believes in providing excellent services and the cheapest = pr_ic_es 1ndian cheaap meedss

------=_NextPart_000_0006_01C864F1.05D8392F-- From owner-v6ops@ops.ietf.org Fri Feb 1 09:17:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640F03A68F6 for ; Fri, 1 Feb 2008 09:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=2.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUEs4GM40LdX for ; Fri, 1 Feb 2008 09:17:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9DED03A69A6 for ; Fri, 1 Feb 2008 09:15:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKzNS-000GOS-B3 for v6ops-data@psg.com; Fri, 01 Feb 2008 17:08:34 +0000 Received: from [209.85.162.177] (helo=el-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKzNL-000GNc-6U for v6ops@ops.ietf.org; Fri, 01 Feb 2008 17:08:28 +0000 Received: by el-out-1112.google.com with SMTP id v27so471975ele.23 for ; Fri, 01 Feb 2008 09:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HIWrs/SjMU+mL1ACjIdlOyh4QQQBKTWPKaoQAMd9EBU=; b=JzpHQrX5ebwfuA/JmkwiIjI9SVwSfpuXBj/d1XBNNLcIQCNcwJHatARBdSAXuKWDBljfEL0wLix/4QaBTzXPCCYkda0szGYreQeiRWL+KDWu3WFXwSaoPygOuqYaE2KedTcX8hGHNBmLhOPfOwOlGowbYa+IoYB4mY76ZdTwwlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=npdLDWhADoWnjfGLa7JxkCv7u8xZMWvlgbEs+i8ln7V/PpotXYYmyedFgryifaIdE7By18xwi/dCQcVig6xZRwNUUXhEo9r/SXfC8/OxuT6aGk2gs1AipFrL/5Kv9HQO0QleG1hXJc/iJdHdmwIemv7SYtp/8l8wQB5mTq0caN0= Received: by 10.142.239.11 with SMTP id m11mr2312068wfh.183.1201885705386; Fri, 01 Feb 2008 09:08:25 -0800 (PST) Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 09:08:25 -0800 (PST) Message-ID: <77ead0ec0802010908m1db49261m9a5d3d3824604282@mail.gmail.com> Date: Fri, 1 Feb 2008 09:08:25 -0800 From: "Vishwas Manral" To: "Francois Le Faucheur IMAP" Subject: Re: 6PE-Alt Cc: "DE CLERCQ Jeremy" , v6ops@ops.ietf.org, "Ooms Dirk" , stuart.prevost@bt.com In-Reply-To: <863B3741-A42D-49B7-B16D-0B03BED9346A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0801302108w3120b3a8uefd910567f43fb28@mail.gmail.com> <77ead0ec0801310625x285deb18u4b78a0b2089354ef@mail.gmail.com> <4F19CDE8-7704-4577-A2E6-DAD0A42A2081@cisco.com> <77ead0ec0801310929o16ab4207taf7e4308a1029bec@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB1501839267@FRVELSMBS22.ad2.ad.alcatel.com> <77ead0ec0801311311q3eef469fj23a99cfeaab475f5@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB150183926E@FRVELSMBS22.ad2.ad.alcatel.com> <77ead0ec0801311417x1f30f982v9c8b021fa27b9013@mail.gmail.com> <88FDC6C9EFCCEE4CA69577595AD6DB150183926F@FRVELSMBS22.ad2.ad.alcatel.com> <863B3741-A42D-49B7-B16D-0B03BED9346A@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Francois, From your very mail it clearly shows that 6PE-Alt is already inter-operable. It also shows that because of the cumbersome extensions you made, you actually had to go through some interoperability tests too specifically to gain this functionality. You bring up some other interesting points. The first one is that the current code can anyway work with the "Explicit NULL label" which clearly means that solution works fine and has been interoperated. It also clearly means that using 6PE-Alt mechanism without all the additional signaling extensions defined in 6PE the solution could work. This also clearly means it has been added to aid some particular implementation, so that a part of the code which may be harder to change (it seems label allocation scheme) is not done, instead a whole new extension is burdened on all the other vendors. The question again is just to gain one less IPv6 lookup, for some applications for some cases, you have defined a whole gamut of new signaling extensions. And yes the IPv6 lookup is not saved in all the cases either. I would really like to raise the question to the working group, if they think we should allow protocol extensions which are not required, and can be done without, but are made so that other implementations have to do the same. Trust me it would have been simpler to just fix the label allocation schemes in implementations than to burden the whole IETF with cumbersome extensions. Thanks, Vishwas On Feb 1, 2008 1:38 AM, Francois Le Faucheur IMAP wrote: > > > On 1 Feb 2008, at 00:41, DE CLERCQ Jeremy wrote: > > > So the question remains whether the possible benefits of this solution > justify bringing another alternative approach solving the same problem > into the standards. > > Supporting different label allocation schemes (eg Explicit-Null and > per-prefix-label so IPv6 traffic is label switched) was an explicit goal of > the 6PE work. The solution has been specified to achieve that flexibility > and corresponding interoperability validated. > > One can always come up with point solutions that are somewhat leaner if you > sacrifice flexibility. In this case, I personally don't see that the > trade-offs of 6PE-Alt justify revisiting the current solution to either add > a restriction on label-allocation (that we explicitly rejected before), or > add an extra option that will only make overall interoperability more > difficult. > > Francois > > > > > Regards, > Jeremy. > > > > Hi Jeremy, > > I agree a single level of label should not be used. The 6PE RFC > clearly talks about reasons for the same in great detail. > > That option should not be used and I agree to it. However the 6PE-Alt > approach uses 2 level of labels. The inner label is the Explicit NULL > label and the outer label is the tunnel label which gets the packet > from one 6Pe router to the other. The document below clearly misses > the idea of using a predefined label as the tunnel label. > > I hope things are clearer now to you. > > Thanks, > Vishwas > > On Jan 31, 2008 2:07 PM, DE CLERCQ Jeremy > wrote: > Hi Vishwas, > > I was refering to e.g. section 6.2 in > draft-ietf-ngtrans-bgp-tunnel-02.txt, where it says > > " > Where a single level of label is used and no label are advertised by > MP-BGP, the SAFI used in MP-BGP will be one of the basic values: > unicast, multicast or both (1,2 or 3). > " > > With regards to the reason why the labelled approach was finally > selected: it had to do on one hand with the main > applicability of the > approach for routers that typically do labelled BGP distribution for > VPNs, and on the other hand with the fact that the > advantages of using > labelled distribution seemed to outweigh the disadvantages > like memory > requirements etc. > > With regards to interoperability, what I meant was that it > was deemed > better to have not too many optional and alternative > solutions in one > RFC and to limit it to the chosen approach. > > Regards, > Jeremy. > > > > > Hi Jeremy, > > I did look at the draft-ietf-ngtrans-bgp-tunnel-02.txt. I > could not > > find a mention of the mechanism I have mentioned. Could you please > point me to the place where the mechanism is mentioned? > > BTW, the simple mechanism you talk about, adds a AFI/ SAFI pair to > BGP, unnecessarily passes labels around which are not > used at all. It > > increases the memory requirement of each route, increases > the size of > > the serach key and has complicated Transit provider > mechanisms. It in > > turn clutters the forwarding tables with data which could > be easily > > done without. The interesting part is the same could be > done without > > any extensions at all. > > You seem to say that due to some interoperability > concerns you added > > the mechanism to explicitly signal labels, which serve no > purpose. Can > > you let me know which implementations had > interoperability concerns? > > It would be great if you can give a more exact technical > reason of why > > the approach we intend to bring to the IETF (which by default is > inter-operable - as no extensions are required). It is > hard to for a > > person who has not been through the entire history to > understand the > > same. > > Thanks, > Vishwas > > On Jan 31, 2008 12:56 PM, DE CLERCQ Jeremy > wrote: > Hi Vishwas, > > > I however am surprised how > this simple mechanism was not captured earlier in the > review or coding > > process. > > The work that lead to what is now known as 6PE has seen > many forms and > many many iterations. Including approaches without label > signaling and > allocation, even including approaches without MPLS. You > should be able > to find out about this history via earlier versions of the > draft like > draft-nguyen-ngtrans-bgp-tunnel-00.txt and > draft-ietf-ngtrans-bgp-tunnel-02.txt. > > So I'd say that this simple mechanism was captured earlier > but that it > has been decided not to retain it, and to keep only one > mandatory > > procedure for interoperability purposes. > > At the end it was working group consensus and interoperable > implementations that lead to the current 6PE approach. > > Regards, > Jeremy > > > > > > > > > From conservatorysi008@skspolytech.com Fri Feb 1 09:31:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF7C28C245 for ; Fri, 1 Feb 2008 09:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 89.954 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=89.954 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, INVALID_DATE=1.245, OUTLOOK_3416=1.744, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 1.7 OUTLOOK_3416 Claims to be sent by an unusual build of Outlook (3416) * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tobetobetobe.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tobetobetobe.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [190.33.143.98 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tobetobetobe.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tobetobetobe.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tobetobetobe.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tobetobetobe.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tobetobetobe.com] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfcsF0utHcCE for ; Fri, 1 Feb 2008 09:31:46 -0800 (PST) Received: from [190.33.143.98] (unknown [190.33.143.98]) by core3.amsl.com (Postfix) with ESMTP id B751128C387 for ; Fri, 1 Feb 2008 09:31:39 -0800 (PST) Received: from [190.33.143.98] by skspolytech.com.inbound10.mxlogic.net; Fri, 32 Jan 2008 12:33:14 -0500 From: "Adam Spears" To: Subject: ***SPAM*** 89.954 (5) BodypartGrandAlfred Date: Fri, 32 Jan 2008 12:33:14 -0500 Message-ID: <0170fd74$00000004$628f21be@conservatorysi008> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal RonaldDickTitanic http://www.tobetobetobe.com From owner-v6ops@ops.ietf.org Fri Feb 1 09:50:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2AE3A6888 for ; Fri, 1 Feb 2008 09:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp505P3qttUs for ; Fri, 1 Feb 2008 09:50:34 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 96D4128C3AD for ; Fri, 1 Feb 2008 09:49:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKzxv-000LTO-Vy for v6ops-data@psg.com; Fri, 01 Feb 2008 17:46:15 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKzxt-000LSx-3B for v6ops@ops.ietf.org; Fri, 01 Feb 2008 17:46:14 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1C55F20D004F for ; Fri, 1 Feb 2008 09:46:12 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 0653D28057 for ; Fri, 1 Feb 2008 09:46:12 -0800 (PST) X-AuditID: 11807130-a6c3fbb0000028a7-a4-47a35ae36436 Received: from [17.151.78.206] (unknown [17.151.78.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 8E0FC28081 for ; Fri, 1 Feb 2008 09:46:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: 6to4 anycast IP as source address / PTR record Date: Fri, 1 Feb 2008 09:46:03 -0800 To: v6ops X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Jan 31, 2008, at 22:15, Pekka Savola wrote: > > Only the host-based 6to4 approach has gained measurable deployment, > which leads me to think that we should focus on that in the > specifications. The 6to4 router function is turned on by default in these products (currently). I'm confident in saying that deployment of these boxes is measurable. I've seen the measurements. -- james woodyatt member of technical staff, communications engineering From bewachst1999@SKLADPROFY.RU Fri Feb 1 10:00:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323B03A681A for ; Fri, 1 Feb 2008 10:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 90.552 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=90.552 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_MESSAGE=1, J_CHICKENPOX_13=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.6 J_CHICKENPOX_13 BODY: 1alpha-pock-3alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: lefoursm.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lefoursm.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [99.139.86.30 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz9wJEG18-cG for ; Fri, 1 Feb 2008 10:00:31 -0800 (PST) Received: from adsl-99-139-86-30.dsl.hstntx.sbcglobal.net (adsl-99-139-86-30.dsl.hstntx.sbcglobal.net [99.139.86.30]) by core3.amsl.com (Postfix) with ESMTP id 4E2873A6837 for ; Fri, 1 Feb 2008 10:00:31 -0800 (PST) Message-ID: <001101c864fc$8db20710$1e568b63@mew99u0a8fwyi8> From: "Lousie Fegan" To: v6ops-archive@lists.ietf.org Subject: ***SPAM*** 90.552 (5) There will be no stopping you after this. Your powers are soon to be unleashed. Date: Fri, 1 Feb 2008 12:02:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C864CA.43179710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000D_01C864CA.43179710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Always wondered how others could have some big d1cks? Here's the answer. ----------=_NextPart_000_000D_01C864CA.43179710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Always wondered how others could = have some=20 big d1cks? Here's the answer. ----------=_NextPart_000_000D_01C864CA.43179710-- From cilreaps@algometrics.co.uk Fri Feb 1 10:15:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EB93A6975 for ; Fri, 1 Feb 2008 10:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 75.485 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=75.485 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 0.6 HELO_EQ_IT HELO_EQ_IT * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: coupmes.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: coupmes.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: coupmes.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: coupmes.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: coupmes.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [79.32.119.95 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALlftZnUuquE for ; Fri, 1 Feb 2008 10:15:13 -0800 (PST) Received: from host165-116-dynamic.27-79-r.retail.telecomitalia.it (unknown [79.32.119.95]) by core3.amsl.com (Postfix) with ESMTP id 21BEE3A67F2 for ; Fri, 1 Feb 2008 10:14:23 -0800 (PST) Message-ID: <001101c864fe$73a93940$a5741b4f@userfppo8pazl1> From: "lisbeth cory" To: v6ops-archive@megatron.ietf.org Subject: ***SPAM*** 75.485 (5) Get a new huge colossal rod by clicking here. Date: Fri, 1 Feb 2008 19:15:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C86506.D56DA140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000D_01C86506.D56DA140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make your own home sex video, and show off your new big schlong to the = world. ----------=_NextPart_000_000D_01C86506.D56DA140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make your own home sex video, and = show off=20 your new big schlong to the world. ----------=_NextPart_000_000D_01C86506.D56DA140-- From utamawi1986@SPAMweb.de Fri Feb 1 10:32:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E41B3A69AF for ; Fri, 1 Feb 2008 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 72.096 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=72.096 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=1, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: magefro.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: magefro.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: magefro.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: magefro.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [77.194.213.102 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjV-nRSw2S-t for ; Fri, 1 Feb 2008 10:32:40 -0800 (PST) Received: from 102.213.194-77.rev.gaoland.net (unknown [77.194.213.102]) by core3.amsl.com (Postfix) with ESMTP id 6E8F03A6A11 for ; Fri, 1 Feb 2008 10:32:11 -0800 (PST) Message-ID: <000f01c86500$fbb8b250$66d5c24d@famillePLY> From: "Bodhi Niemela" To: v6ops-archive@ietf.org Subject: ***SPAM*** 72.096 (5) A well hung SCHLONG will get you places you've never been before. Date: Fri, 1 Feb 2008 19:33:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C86509.5D7D1A50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C86509.5D7D1A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get a new huge colossal rod by clicking here. ----------=_NextPart_000_000B_01C86509.5D7D1A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get a new huge colossal rod by = clicking=20 here. ----------=_NextPart_000_000B_01C86509.5D7D1A50-- From owner-v6ops@ops.ietf.org Fri Feb 1 10:44:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141728C5AA for ; Fri, 1 Feb 2008 10:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GljEsBfgH7Ca for ; Fri, 1 Feb 2008 10:44:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 18E1628C4BC for ; Fri, 1 Feb 2008 10:42:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL0jW-0003bO-G1 for v6ops-data@psg.com; Fri, 01 Feb 2008 18:35:26 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL0jS-0003aY-DO for v6ops@ops.ietf.org; Fri, 01 Feb 2008 18:35:23 +0000 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 1 Feb 2008 10:35:22 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.1.240.5; Fri, 1 Feb 2008 10:35:21 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Fri, 1 Feb 2008 10:35:21 -0800 From: Christian Huitema To: james woodyatt , v6ops Date: Fri, 1 Feb 2008 10:35:06 -0800 Subject: RE: 6to4 anycast IP as source address / PTR record Thread-Topic: 6to4 anycast IP as source address / PTR record Thread-Index: Achk+9NsscI1olxtSii9L264CxLF4QABQLSg Message-ID: References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> In-Reply-To: <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Only the host-based 6to4 approach has gained measurable deployment, > > which leads me to think that we should focus on that in the > > specifications. > > > > The 6to4 router function is turned on by default in these products > (currently). I'm confident in saying that deployment of these boxes > is measurable. I've seen the measurements. OK. So, what would we changed in 6to4 if we optimized for host-based or CPE= -based deployment? Do we trust that we will get enough 6to4 gateways deploy= ed to sustain growth, or do we need to add a "gateway discovery service" si= milar to the Teredo spec? -- Christian Huitema From fallen-haven@freeola.com Fri Feb 1 11:09:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE87428C40A for ; Fri, 1 Feb 2008 11:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 68.239 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=68.239 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, GB_ROLEX=5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 0.6 HELO_EQ_IT HELO_EQ_IT * 5.0 GB_ROLEX BODY: I don't need a new watch! * 1.0 HTML_MESSAGE BODY: HTML included in message * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dhueiije.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dhueiije.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dhueiije.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dhueiije.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dhueiije.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [79.11.76.217 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [79.11.76.217 listed in zen.spamhaus.org] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpY5sVqwqR9F for ; Fri, 1 Feb 2008 11:09:00 -0800 (PST) Received: from host217-76-dynamic.11-79-r.retail.telecomitalia.it (host217-76-dynamic.11-79-r.retail.telecomitalia.it [79.11.76.217]) by core3.amsl.com (Postfix) with ESMTP id 30CD828C779 for ; Fri, 1 Feb 2008 11:01:11 -0800 (PST) Message-ID: <000501c86505$04bdddb1$b230a097@ofmnlmrv> From: "kennedy eldred" To: Subject: ***SPAM*** 68.239 (5) Perfectly crafted luxury timepieces Date: Fri, 01 Feb 2008 17:16:43 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C86505.04B83B3A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C86505.04B83B3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at low prices. Start 2008 in stunning fashion with our perfect range of upgraded 2008 = replicas. Thousands of different models to choose from! Watches Rolex DatejustBvlgariCartierChanelPatek Philippe PENS Mont Blanc RollerballMont Blanc BallpointMont Blanc FountainLV = BallpointLV Rollerball Jewelry Tiffany & Co Jewelry=20 http://www.dhueiije.com/ ------=_NextPart_000_0002_01C86505.04B83B3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Perfectly crafted luxury = timepieces, all at low prices.
Start 2008 in stunning fashion = with our perfect range of upgraded 2008 replicas.
Thousands of different models to choose from!
Watches
  • Rolex Datejust
  • Bvlgari
  • Cartier
  • Chanel
  • Patek Philippe
 PENS
  • Mont Blanc Rollerball
  • Mont Blanc Ballpoint
  • Mont Blanc Fountain
  • LV Ballpoint
  • LV Rollerball
 Jewelry
  • Tiffany & Co Jewelry

To: Subject: ***SPAM*** 79.822 (5) Perfectly crafted luxury timepieces Date: Fri, 01 Feb 2008 17:15:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C86505.01A899C7" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C86505.01A899C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at low prices. Start 2008 in stunning fashion with our perfect range of upgraded 2008 = replicas. Thousands of different models to choose from! Watches Rolex DatejustBvlgariCartierChanelPatek Philippe PENS Mont Blanc RollerballMont Blanc BallpointMont Blanc FountainLV = BallpointLV Rollerball Jewelry Tiffany & Co Jewelry=20 http://www.dhueiije.com/ ------=_NextPart_000_0006_01C86505.01A899C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Perfectly crafted luxury = timepieces, all at low prices.
Start 2008 in stunning fashion = with our perfect range of upgraded 2008 replicas.
Thousands of different models to choose from!
Watches
  • Rolex Datejust
  • Bvlgari
  • Cartier
  • Chanel
  • Patek Philippe
 PENS
  • Mont Blanc Rollerball
  • Mont Blanc Ballpoint
  • Mont Blanc Fountain
  • LV Ballpoint
  • LV Rollerball
 Jewelry
  • Tiffany & Co Jewelry

X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CF93A681F for ; Fri, 1 Feb 2008 11:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOlM7dv2mPL for ; Fri, 1 Feb 2008 11:47:13 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 084093A681A for ; Fri, 1 Feb 2008 11:43:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL1ho-000DWd-6y for v6ops-data@psg.com; Fri, 01 Feb 2008 19:37:44 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL1hl-000DW9-PK for v6ops@ops.ietf.org; Fri, 01 Feb 2008 19:37:42 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (Postfix) with ESMTP id 0F2BF20D3277 for ; Fri, 1 Feb 2008 11:37:26 -0800 (PST) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id F239F40128 for ; Fri, 1 Feb 2008 11:37:25 -0800 (PST) X-AuditID: 11807126-99de6bb000005025-f6-47a374f53ff5 Received: from [17.215.55.220] (bu0501a-dhcp92.apple.com [17.215.55.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id D43D740006 for ; Fri, 1 Feb 2008 11:37:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: 6to4 connectivity test Date: Fri, 1 Feb 2008 11:37:21 -0800 To: v6ops Operations X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 1, 2008, at 10:35, Christian Huitema wrote: > > OK. So, what would we changed in 6to4 if we optimized for host- > based or CPE-based deployment? Do we trust that we will get enough > 6to4 gateways deployed to sustain growth, or do we need to add a > "gateway discovery service" similar to the Teredo spec? A standard method of discovering whether the 6to4 relay at the anycast address is functioning properly would be a fine idea. At the moment, some very large ISP's are now hindering transition to IPv6 by forwarding 6to4 packets to relays that are black-holing them rather than forwarding them. (This was not the case when AirPort Extreme shipped.) These ISP's have no plans to deploy 6to4 relays in their own IPv6-capable networks, nor do they have any plan to forward 6to4 traffic to relays that will carry it for them. This is making some large content providers *remove* their AAAA records when they discover that customers behind 6to4 routers, e.g. AirPort Extreme, are unable to receive service because their applications do not fall back to IPv4 when IPv6 connectivity is broken. Search the Apple discussion boards for IPv6, and you will see that a lot of people are turning off IPv6 entirely on their computers to work around the connectivity issues involved here. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Feb 1 11:55:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D603A685A for ; Fri, 1 Feb 2008 11:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4AzA99tktsr for ; Fri, 1 Feb 2008 11:55:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A7DED3A684F for ; Fri, 1 Feb 2008 11:54:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL1v1-000FOZ-S6 for v6ops-data@psg.com; Fri, 01 Feb 2008 19:51:23 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL1uy-000FNj-K2 for v6ops@ops.ietf.org; Fri, 01 Feb 2008 19:51:22 +0000 Received: (qmail 83308 invoked by uid 1007); 1 Feb 2008 19:51:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=JjH8bJ46x7Z8ssEfVxAma89vqHPlZthFfvhfHaRiUSooA99oIKcBtFM6jJAXKdMx ; Date: Fri, 1 Feb 2008 20:51:18 +0100 From: Gert Doering To: james woodyatt Cc: v6ops Operations Subject: Re: 6to4 connectivity test Message-ID: <20080201195118.GL69215@Space.Net> References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Feb 01, 2008 at 11:37:21AM -0800, james woodyatt wrote: > At the moment, some very large ISP's are now hindering transition to > IPv6 by forwarding 6to4 packets to relays that are black-holing them > rather than forwarding them. Who is that? Maybe we should raise a bit of stink in the more operational IPv6 lists... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Fri Feb 1 12:37:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B273A6912 for ; Fri, 1 Feb 2008 12:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Isx+uvpTsgtQ for ; Fri, 1 Feb 2008 12:37:53 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 04BFE3A6888 for ; Fri, 1 Feb 2008 12:37:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2Yo-000LM8-2U for v6ops-data@psg.com; Fri, 01 Feb 2008 20:32:30 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b8c] (helo=outgoing02.lava.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2Yl-000LLZ-Hi for v6ops@ops.ietf.org; Fri, 01 Feb 2008 20:32:28 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 2D355174CAB; Fri, 1 Feb 2008 10:32:27 -1000 (HST) Date: Fri, 1 Feb 2008 10:32:27 -1000 (HST) From: Antonio Querubin To: Gert Doering cc: james woodyatt , v6ops Operations Subject: Re: 6to4 connectivity test In-Reply-To: <20080201195118.GL69215@Space.Net> Message-ID: References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> <20080201195118.GL69215@Space.Net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 1 Feb 2008, Gert Doering wrote: > Who is that? Maybe we should raise a bit of stink in the more operational > IPv6 lists... That too would be an excellent idea!!! :) Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Feb 1 12:40:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBED3A6811 for ; Fri, 1 Feb 2008 12:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7gb2vLPeQpP for ; Fri, 1 Feb 2008 12:40:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B00E93A681A for ; Fri, 1 Feb 2008 12:40:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2d0-000M82-9e for v6ops-data@psg.com; Fri, 01 Feb 2008 20:36:50 +0000 Received: from [64.65.64.125] (helo=outgoing02.lava.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2cx-000M7j-Nc for v6ops@ops.ietf.org; Fri, 01 Feb 2008 20:36:48 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id F41061748C4; Fri, 1 Feb 2008 10:31:41 -1000 (HST) Date: Fri, 1 Feb 2008 10:31:41 -1000 (HST) From: Antonio Querubin To: james woodyatt cc: v6ops Operations Subject: Re: 6to4 connectivity test In-Reply-To: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Message-ID: References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 1 Feb 2008, james woodyatt wrote: > Search the Apple discussion boards for IPv6, and you will see that a lot of > people are turning off IPv6 entirely on their computers to work around the > connectivity issues involved here. I've already mentioned in private email but will re-iterate here. This is a problem caused by the CPE (the Airport in this case) not erring on the side of caution. These devices really need to leave 6to4 disabled and not allow autoconfiguration unless they can verify there is a reachable 6to4 relay. Perhaps in a revised spec it can INSIST on the pingability of the 6to4 relay so that CPEs can perform a keepalive check in determining whether to keep IPv6 autoconfiguration enabled. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Feb 1 12:52:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E81A28C377 for ; Fri, 1 Feb 2008 12:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTXZSsLiyztn for ; Fri, 1 Feb 2008 12:52:13 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 43BAD28C571 for ; Fri, 1 Feb 2008 12:50:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2lw-000Nb9-Ns for v6ops-data@psg.com; Fri, 01 Feb 2008 20:46:04 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2lu-000Nan-BO for v6ops@ops.ietf.org; Fri, 01 Feb 2008 20:46:03 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id C13D720D5068 for ; Fri, 1 Feb 2008 12:46:01 -0800 (PST) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id ABFB82808B for ; Fri, 1 Feb 2008 12:46:01 -0800 (PST) X-AuditID: 11807134-a20e6bb0000008b9-39-47a38509b4a0 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with ESMTP id 8BA8128083 for ; Fri, 1 Feb 2008 12:46:01 -0800 (PST) Received: from [17.255.97.49] (ap0101l-dhcp49.apple.com [17.255.97.49]) by ifon.apple.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVK005Q8V0ODF30@ifon.apple.com> for v6ops@ops.ietf.org; Fri, 01 Feb 2008 12:46:01 -0800 (PST) Date: Fri, 01 Feb 2008 12:45:54 -0800 From: James Woodyatt Subject: Re: 6to4 connectivity test In-reply-to: To: Antonio Querubin Cc: v6ops Operations Message-id: MIME-version: 1.0 X-Mailer: iPhone Mail (4A93) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk As I wrote privately, the 6to4 blackholes are responding to ICMP just fine. They just don't forward IPv6 from some networks (not others). -jhw On Feb 1, 2008, at 12:31, Antonio Querubin wrote: > On Fri, 1 Feb 2008, james woodyatt wrote: > >> Search the Apple discussion boards for IPv6, and you will see that >> a lot of people are turning off IPv6 entirely on their computers to >> work around the connectivity issues involved here. > > I've already mentioned in private email but will re-iterate here. > This is a problem caused by the CPE (the Airport in this case) not > erring on the side of caution. These devices really need to leave > 6to4 disabled and not allow autoconfiguration unless they can verify > there is a reachable 6to4 relay. > > Perhaps in a revised spec it can INSIST on the pingability of the > 6to4 relay so that CPEs can perform a keepalive check in determining > whether to keep IPv6 autoconfiguration enabled. > > > Antonio Querubin > whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Feb 1 12:52:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3491628C488 for ; Fri, 1 Feb 2008 12:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtZa+9g9I+bm for ; Fri, 1 Feb 2008 12:52:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 84B8528C274 for ; Fri, 1 Feb 2008 12:52:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2mc-000NeH-Tb for v6ops-data@psg.com; Fri, 01 Feb 2008 20:46:46 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL2mZ-000Ndk-SR for v6ops@ops.ietf.org; Fri, 01 Feb 2008 20:46:45 +0000 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.12830347; Fri, 01 Feb 2008 15:46:23 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 15:46:23 -0500 Received: from 147.191.8.103 ([147.191.8.103]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Feb 2008 20:46:22 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 01 Feb 2008 15:46:22 -0500 Subject: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) From: Alain Durand To: james woodyatt , v6ops Operations Message-ID: Thread-Topic: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Thread-Index: AchlDeS1KlZYMha/R+OdjI1XuO5csQABZwbV In-Reply-To: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2008 20:46:23.0014 (UTC) FILETIME=[816B5C60:01C86513] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Open relays are usually a bad think. Public anycast open relays are just worse. Even if you are not concerned about security issues, there are problems: you never know where they are, if they will be there tomorrow, if they are on the other side of the planet, if the bandwidth is reasonable, etc.. Essentially, expecting to get a functioning 6to4 relay is expecting a free lunch. Who is going to pay for it? IMHO, the entire model is broken. - Alain. On 2/1/08 2:37 PM, "james woodyatt" wrote: > A standard method of discovering whether the 6to4 relay at the > anycast address is functioning properly would be a fine idea. > > At the moment, some very large ISP's are now hindering transition to > IPv6 by forwarding 6to4 packets to relays that are black-holing them > rather than forwarding them. (This was not the case when AirPort > Extreme shipped.) These ISP's have no plans to deploy 6to4 relays in > their own IPv6-capable networks, nor do they have any plan to forward > 6to4 traffic to relays that will carry it for them. This is making > some large content providers *remove* their AAAA records when they > discover that customers behind 6to4 routers, e.g. AirPort Extreme, > are unable to receive service because their applications do not fall > back to IPv4 when IPv6 connectivity is broken. > > Search the Apple discussion boards for IPv6, and you will see that a > lot of people are turning off IPv6 entirely on their computers to > work around the connectivity issues involved here. > > > -- > james woodyatt > member of technical staff, communications engineering > > > From owner-v6ops@ops.ietf.org Fri Feb 1 13:32:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AE83A697E for ; Fri, 1 Feb 2008 13:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVT1mP3qdITU for ; Fri, 1 Feb 2008 13:32:05 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 870663A69CE for ; Fri, 1 Feb 2008 13:29:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3Me-0003Pc-MZ for v6ops-data@psg.com; Fri, 01 Feb 2008 21:24:00 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3Mc-0003KV-BN for v6ops@ops.ietf.org; Fri, 01 Feb 2008 21:23:59 +0000 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 1 Feb 2008 13:23:37 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.1.240.5; Fri, 1 Feb 2008 13:23:37 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Fri, 1 Feb 2008 13:23:36 -0800 From: Christian Huitema To: Alain Durand , james woodyatt , v6ops Operations Date: Fri, 1 Feb 2008 13:23:31 -0800 Subject: RE: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Thread-Topic: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Thread-Index: AchlDeS1KlZYMha/R+OdjI1XuO5csQABZwbVAADcR6A= Message-ID: References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Essentially, expecting to get a functioning 6to4 relay is expecting a > free lunch. Who is going to pay for it? Alain is using some extreme language, but there really is an issue with the= deployment model for 6to4 relays. James is observing that some public relays are broken, perhaps deliberately= . This point was raised during the discussion of the "anycast relay" RFC. I= t is actually a well known failure mode of the anycast model: your traffic = is just a routing update away from a black hole. The remedy is well known: = 6to4 routers ought to be configurable. If the user can somehow procure a re= liable gateway, that gateway should be used. Teredo went one step further. Public gateways can easily be abused. So Tere= do introduced a discovery mechanism to find out the best gateway on a desti= nation by destination basis. That mechanism is little more than a ping, and= could easily be ported to 6to4. We could assume that 6to4 routers maintain= a "routing cache" associating specific "native IPv6" destinations with the= "closest 6to4 gateway". Given a new IPv6 destination, the 6to4 router will= send a ping through the public server, note the IPv4 address from which th= e ping comes back, and send the rest of the traffic through that address. In short, the Teredo model places the deployment onus on the IPv6 only serv= ers. They must somehow ensure presence of a transition relay near them. The= y have an incentive to do so: serving the users of the transition technolog= y. They also have an incentive to provide good quality service. This is a b= ig contrast with the 6to4 model, which basically places the requirement on = the legacy ISP. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri Feb 1 13:53:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE193A68A9 for ; Fri, 1 Feb 2008 13:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2ZeUErQsFkD for ; Fri, 1 Feb 2008 13:53:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 731F43A6888 for ; Fri, 1 Feb 2008 13:53:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3kd-0007Ae-GT for v6ops-data@psg.com; Fri, 01 Feb 2008 21:48:47 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3ka-0007AO-VK for v6ops@ops.ietf.org; Fri, 01 Feb 2008 21:48:46 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (Postfix) with ESMTP id 5F93620D6B0C for ; Fri, 1 Feb 2008 13:48:44 -0800 (PST) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 53775402D3 for ; Fri, 1 Feb 2008 13:48:44 -0800 (PST) X-AuditID: 11807126-9e5efbb000005025-8b-47a393bc3fc4 Received: from [17.215.55.220] (bu0501a-dhcp92.apple.com [17.215.55.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 403E6402F2 for ; Fri, 1 Feb 2008 13:48:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D8EC4E8-994D-4AA1-960D-0CD6DF3E7AF8@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: 6to4 considered a bad thing Date: Fri, 1 Feb 2008 13:48:40 -0800 To: v6ops Operations X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 1, 2008, at 13:23, Christian Huitema wrote: > > James is observing that some public relays are broken, perhaps > deliberately. I'm also observing that some ISP's are refusing to deploy 6to4 relays at *private* anycast addresses inside their own interior routing domains, preferring instead to dump the 6to4 "problem" to whatever the nearest public 6to4 relay is advertising service (which may or may not actually be available). I think it would be helpful if routes to 192.88.99.1 shouldn't be advertised to peers from which protocol 41 packets will not be decapsulated and forwarded into an IPv6 domain. > Teredo went one step further. Public gateways can easily be abused. > So Teredo introduced a discovery mechanism to find out the best > gateway on a destination by destination basis. That mechanism is > little more than a ping, and could easily be ported to 6to4. We > could assume that 6to4 routers maintain a "routing cache" > associating specific "native IPv6" destinations with the "closest > 6to4 gateway". Given a new IPv6 destination, the 6to4 router will > send a ping through the public server, note the IPv4 address from > which the ping comes back, and send the rest of the traffic through > that address. This assumes the "ping" packets will pass through the same firewalls as the packets that trigger them. If they don't produce a timely response, what happens? Remember, at this point, there is a human being sitting at a console watching a stalled progress bar and waiting for a connection to go through. The connection they're attempting is IPv6 because their host has a global IPv6 address assigned (with a 2002:aabb:ccdd:xxxx:/64 prefix) and they got an answer to a request for AAAA records. Their host can connect to other hosts in 2002::/16 just fine. It's only the non-2002::/16 address that are unreachable. So, how many non-6to4 destinations do we have to "ping" before we decide to stop advertising an IPv6 default route for those 2002:aabb:ccdd:xxxx::/64 addresses altogether? At this point, if large IPv6-capable ISP's cannot be persuaded to deploy 6to4 relays in their interior IPv6/IPv4 routing domains for the use of their paying, retail IPv4 customers, then I have to say that 6to4 is a failure as a transition strategy, and we should move now to deprecate it. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Feb 1 13:56:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875823A6888 for ; Fri, 1 Feb 2008 13:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBhd4pvU+ItK for ; Fri, 1 Feb 2008 13:56:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DAF1A28C1DD for ; Fri, 1 Feb 2008 13:56:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3rE-00080U-Tn for v6ops-data@psg.com; Fri, 01 Feb 2008 21:55:36 +0000 Received: from [2001:a60:f044:1000:216:3eff:fe00:5] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3rB-0007zz-TR for v6ops@ops.ietf.org; Fri, 01 Feb 2008 21:55:35 +0000 Received: from [IPv6:2001:6f8:9ee:0:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:6f8:9ee:0:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTP id 63ADA402026; Fri, 1 Feb 2008 22:55:31 +0100 (CET) Message-ID: <47A39552.80300@spaghetti.zurich.ibm.com> Date: Fri, 01 Feb 2008 22:55:30 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Christian Huitema CC: Alain Durand , james woodyatt , v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BA20C92E0C559C92190928D" X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BA20C92E0C559C92190928D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Christian Huitema wrote: >> Essentially, expecting to get a functioning 6to4 relay is expecting a >> free lunch. Who is going to pay for it? >=20 > Alain is using some extreme language, but there really is an issue with= > the deployment model for 6to4 relays. >=20 > James is observing that some public relays are broken, perhaps delibera= tely. > This point was raised during the discussion of the "anycast relay" RFC= =2E Instead of trying to "fix" 6to4, which also has this rather annoying=20 issue called NAT which it can't 1,2,3 bypass, why not simply push Teredo = forward which has all these points resolved already? Greets, Jeroen --------------enig6BA20C92E0C559C92190928D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHo5VTKaooUjM+fCMRAj5FAJ9GMiyDJ3pWBqBVxRmw5SCV1y0EggCcC3Qv qLszMP3JoSTI6Z4jUats3JA= =26NF -----END PGP SIGNATURE----- --------------enig6BA20C92E0C559C92190928D-- From owner-v6ops@ops.ietf.org Fri Feb 1 14:00:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BB928C231 for ; Fri, 1 Feb 2008 14:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkkHtXZSkFso for ; Fri, 1 Feb 2008 14:00:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1F39A28C20B for ; Fri, 1 Feb 2008 13:59:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3sZ-0008I4-4N for v6ops-data@psg.com; Fri, 01 Feb 2008 21:56:59 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL3sW-0008Fy-4R for v6ops@ops.ietf.org; Fri, 01 Feb 2008 21:56:57 +0000 Received: (qmail 29169 invoked by uid 1007); 1 Feb 2008 21:56:55 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=OMhfAgCBl2ldBwZALBbz2qpHvY+Lrxl/NTs3r8w3xK4Vhw2W57uYpYHOWQ2Fxw0n ; Date: Fri, 1 Feb 2008 22:56:55 +0100 From: Gert Doering To: Alain Durand Cc: james woodyatt , v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Message-ID: <20080201215654.GO69215@Space.Net> References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote: > Essentially, expecting to get a functioning 6to4 relay is expecting a free > lunch. Who is going to pay for it? If enough ISPs provide working 6to4 relays, serving their own customers (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the model would work just fine. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Fri Feb 1 14:59:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C946C3A693D for ; Fri, 1 Feb 2008 14:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Jc0IDAYrm8 for ; Fri, 1 Feb 2008 14:59:46 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EC4B328C229 for ; Fri, 1 Feb 2008 14:59:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL4oB-000Gc3-9M for v6ops-data@psg.com; Fri, 01 Feb 2008 22:56:31 +0000 Received: from [204.9.54.5] (helo=tokyo01.jp.mail.your.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL4o8-000Gbh-L6 for v6ops@ops.ietf.org; Fri, 01 Feb 2008 22:56:29 +0000 Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id DB5122AD55B5; Fri, 1 Feb 2008 22:56:24 +0000 (UTC) Received: from pool014.dhcp.your.org (pool014.dhcp.your.org [69.31.99.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 1ECA1A0A454; Fri, 1 Feb 2008 22:56:23 +0000 (UTC) Cc: v6ops Operations Message-Id: <1729C76B-5CF4-475A-A95C-32152F32729E@dragondata.com> From: Kevin Day To: james woodyatt In-Reply-To: <0D8EC4E8-994D-4AA1-960D-0CD6DF3E7AF8@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: 6to4 considered a bad thing Date: Fri, 1 Feb 2008 16:55:14 -0600 References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> <0D8EC4E8-994D-4AA1-960D-0CD6DF3E7AF8@apple.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 1, 2008, at 3:48 PM, james woodyatt wrote: >> Teredo went one step further. Public gateways can easily be abused. >> So Teredo introduced a discovery mechanism to find out the best >> gateway on a destination by destination basis. That mechanism is >> little more than a ping, and could easily be ported to 6to4. We >> could assume that 6to4 routers maintain a "routing cache" >> associating specific "native IPv6" destinations with the "closest >> 6to4 gateway". Given a new IPv6 destination, the 6to4 router will >> send a ping through the public server, note the IPv4 address from >> which the ping comes back, and send the rest of the traffic through >> that address. > > > This assumes the "ping" packets will pass through the same firewalls > as the packets that trigger them. If they don't produce a timely > response, what happens? Remember, at this point, there is a human > being sitting at a console watching a stalled progress bar and > waiting for a connection to go through. The connection they're > attempting is IPv6 because their host has a global IPv6 address > assigned (with a 2002:aabb:ccdd:xxxx:/64 prefix) and they got an > answer to a request for AAAA records. > > Their host can connect to other hosts in 2002::/16 just fine. It's > only the non-2002::/16 address that are unreachable. So, how many > non-6to4 destinations do we have to "ping" before we decide to stop > advertising an IPv6 default route for those 2002:aabb:ccdd:xxxx::/64 > addresses altogether? Could requiring that anycasted 6to4 relays respond to an ICMP echo on their v6 address, then sending a ping to 2002:c058:6301:: help? That would at least prove connectivity to 192.88.99.1, and that something there is listening. That works for our relay, anyway: $ ping6 2002:c058:6301:: PING6(56=40+8+8 bytes) 2002:451f:630e:1::1 --> 2002:c058:6301:: 16 bytes from 2002:c058:6301::, icmp_seq=0 hlim=64 time=6.398 ms And this proves at the very least that: v6 6to4 address selection on my system came up with the right IP I can reach 192.88.99.1 over v4 6to4 made it through my router/firewall The 6to4 relay at 192.88.99.1 is decapsulating/encapsulating packets correctly It doesn't prove that the 6to4 relay actually has v6 connectivity, but I think that's getting beyond the scope of this problem. If that helps, maybe this gives additional ammo for an updated 6to4 anycast RFC that includes an ICMP echo requirement. -- Kevin From owner-v6ops@ops.ietf.org Fri Feb 1 15:25:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9802E28C444 for ; Fri, 1 Feb 2008 15:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlEGUbEgUord for ; Fri, 1 Feb 2008 15:25:10 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AE54C28C289 for ; Fri, 1 Feb 2008 15:25:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5Eg-000KUg-8V for v6ops-data@psg.com; Fri, 01 Feb 2008 23:23:54 +0000 Received: from [24.40.8.146] (helo=pacdcimo02.cable.comcast.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5Ed-000KUG-Ly for v6ops@ops.ietf.org; Fri, 01 Feb 2008 23:23:52 +0000 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.16359795; Fri, 01 Feb 2008 18:23:35 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 18:23:35 -0500 Received: from 71.230.35.40 ([71.230.35.40]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Feb 2008 23:23:35 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 01 Feb 2008 18:23:34 -0500 Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) From: Alain Durand To: Gert Doering CC: james woodyatt , v6ops Operations Message-ID: Thread-Topic: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Thread-Index: AchlHWc2tE4hDQb7S1OxvKOZ5erkKQADA+Bs In-Reply-To: <20080201215654.GO69215@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2008 23:23:35.0757 (UTC) FILETIME=[77C5B7D0:01C86529] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/1/08 4:56 PM, "Gert Doering" wrote: > Hi, > > On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote: >> Essentially, expecting to get a functioning 6to4 relay is expecting a free >> lunch. Who is going to pay for it? > > If enough ISPs provide working 6to4 relays, serving their own customers > (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the > model would work just fine. Why should ISP X pay to run a 6to4 relay that would in essence offer transit for customers of other ISPs? And let's say that ISP X offer the outband relay for its customers only, how would the packets come back from the real IPv6 Internet to ISP X IPv4 network? Is ISP X suppose to announce a de-aggregate of 2002://16? That would create a huge increase in the routing table size... - Alain. From owner-v6ops@ops.ietf.org Fri Feb 1 15:45:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27273A687B for ; Fri, 1 Feb 2008 15:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeieKYgdSNG4 for ; Fri, 1 Feb 2008 15:45:33 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E3CFD28C260 for ; Fri, 1 Feb 2008 15:44:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5We-000Mtr-B7 for v6ops-data@psg.com; Fri, 01 Feb 2008 23:42:28 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5Wb-000MtW-TO for v6ops@ops.ietf.org; Fri, 01 Feb 2008 23:42:27 +0000 Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.51505314; Fri, 01 Feb 2008 18:42:12 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 18:42:12 -0500 Received: from 71.230.35.40 ([71.230.35.40]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Feb 2008 23:42:12 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 01 Feb 2008 18:42:11 -0500 Subject: Re: 6to4 considered a bad thing From: Alain Durand To: Kevin Day , james woodyatt CC: v6ops Operations Message-ID: Thread-Topic: 6to4 considered a bad thing Thread-Index: AchlKTAPE5HA2EyTTHCLjCRsksiZ+gAAuBw6 In-Reply-To: <1729C76B-5CF4-475A-A95C-32152F32729E@dragondata.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2008 23:42:12.0715 (UTC) FILETIME=[1187FBB0:01C8652C] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/1/08 5:55 PM, "Kevin Day" wrote: > > It doesn't prove that the 6to4 relay actually has v6 connectivity, but > I think that's getting beyond the scope of this problem. This does not give any indication about the effective bandwidth available either. The fundamentals issue there are: - there is no way to select which anycast relay to use for inbound and outbound packets - there is no contract nor SLA between the customer and the anycast 6to4 relays (inbound/outband), so there is little incentive to whoever operates those relay to fix problems - Alain. From owner-v6ops@ops.ietf.org Fri Feb 1 15:55:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF273A693F for ; Fri, 1 Feb 2008 15:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Htyngy7GsWf for ; Fri, 1 Feb 2008 15:55:03 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DC50B3A688F for ; Fri, 1 Feb 2008 15:55:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5gp-000OfD-7R for v6ops-data@psg.com; Fri, 01 Feb 2008 23:52:59 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL5gm-000OaX-B1 for v6ops@ops.ietf.org; Fri, 01 Feb 2008 23:52:57 +0000 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.51505568; Fri, 01 Feb 2008 18:52:35 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 18:52:35 -0500 Received: from 71.230.35.40 ([71.230.35.40]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Feb 2008 23:52:34 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 01 Feb 2008 18:52:33 -0500 Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) From: Alain Durand To: Jeroen Massar , Christian Huitema CC: james woodyatt , v6ops Operations Message-ID: Thread-Topic: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Thread-Index: AchlHTYmO8gw9eXxR+23fnWiTO/gogAEE0Yn In-Reply-To: <47A39552.80300@spaghetti.zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2008 23:52:35.0128 (UTC) FILETIME=[8484AB80:01C8652D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/1/08 4:55 PM, "Jeroen Massar" wrote: > Instead of trying to "fix" 6to4, which also has this rather annoying > issue called NAT which it can't 1,2,3 bypass, why not simply push Teredo > forward which has all these points resolved already? The Teredo model, actually from our observation with available code from its major source, is that both end need to have it configured to enable a reliable connection. We tried with an open Teredo relay, and packets went sometimes to Korea, sometimes nowhere. In other words, this is fine to get IPv6 working between 2 PCs in different homes separated by NAT boxes, but this is not usable to access a regular IPv6 server on the Internet **UNLESS** that server also deploys Teredo... So, going that route, if an IPv6 server wants to offer reliable service to customers, it might have to be configured with: - a regular global IPv6 address to serve regular IPv6 native customers - a 6to4 address to serve 6to4 customers and avoid open relays - a Teredo address to serve PC behind NAT box that uses Teredo IMHO, this makes the deployment model of new servers a bit complex... - Alain. From owner-v6ops@ops.ietf.org Fri Feb 1 16:21:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC88928C23E for ; Fri, 1 Feb 2008 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.996 X-Spam-Level: X-Spam-Status: No, score=-105.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OSKDi32kksv for ; Fri, 1 Feb 2008 16:21:03 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A51A628C212 for ; Fri, 1 Feb 2008 16:21:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL64U-0002iu-MD for v6ops-data@psg.com; Sat, 02 Feb 2008 00:17:26 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL64R-0002iQ-RU for v6ops@ops.ietf.org; Sat, 02 Feb 2008 00:17:25 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 0855520DA6A2 for ; Fri, 1 Feb 2008 16:17:22 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id DA76128057 for ; Fri, 1 Feb 2008 16:17:22 -0800 (PST) X-AuditID: 11807130-a543cbb0000028a7-8d-47a3b692a7ff Received: from [17.215.55.220] (bu0501a-dhcp92.apple.com [17.215.55.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id BAD6128043 for ; Fri, 1 Feb 2008 16:17:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E15D191-0BED-4039-916F-C0E6359867B3@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: 6to4 considered a bad thing Date: Fri, 1 Feb 2008 16:17:19 -0800 To: v6ops Operations X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 1, 2008, at 15:23, Alain Durand wrote: > On 2/1/08 4:56 PM, "Gert Doering" wrote: >> On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote: >>> Essentially, expecting to get a functioning 6to4 relay is >>> expecting a free >>> lunch. Who is going to pay for it? >> >> If enough ISPs provide working 6to4 relays, serving their own >> customers >> (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated >> IPv6), the >> model would work just fine. > > Why should ISP X pay to run a 6to4 relay that would in essence > offer transit > for customers of other ISPs? No one here is asking for ISP X to advertise its 6to4 relays at public anycast addresses (either IPv4 or IPv6) into the default free zone. I think the question you want to ask is this one: why should ISP X offer 6to4 relay service to its IPv4 customers when it can force them to pay extra for the additional utility of native IPv6 service? Admittedly, I don't have an answer to that question, except to say that the "additional utility" of IPv6 is limited by the fact that 2002::/16 effectively divorced from the IPv6 default free zone by those same network operators insisting that interior 6to4 relays are harmful to their insert-noun-phrase-here. > And let's say that ISP X offer the outband > relay for its customers only, how would the packets come back from > the real > IPv6 Internet to ISP X IPv4 network? By an asymmetric IPv4 path, of course. The 6to4 relay is only a transition mechanism. It doesn't have to work as well as native IPv6. It just has to work. If it doesn't work *at all*, then we should deprecate it. > Is ISP X suppose to announce a > de-aggregate of 2002://16? That would create a huge increase in the > routing > table size... That's clearly not a good idea. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Feb 1 18:54:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259CB3A6842 for ; Fri, 1 Feb 2008 18:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgHNxYK1B30T for ; Fri, 1 Feb 2008 18:54:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3822528C2B2 for ; Fri, 1 Feb 2008 18:54:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL8Mp-000MFp-MV for v6ops-data@psg.com; Sat, 02 Feb 2008 02:44:31 +0000 Received: from [24.40.8.146] (helo=pacdcimo02.cable.comcast.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JL8Mn-000MFV-Ak for v6ops@ops.ietf.org; Sat, 02 Feb 2008 02:44:30 +0000 Received: from ([24.40.15.92]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.16363119; Fri, 01 Feb 2008 21:44:13 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 21:44:13 -0500 Received: from 71.230.35.40 ([71.230.35.40]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Sat, 2 Feb 2008 02:44:12 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 01 Feb 2008 21:44:11 -0500 Subject: Re: 6to4 considered a bad thing From: Alain Durand To: james woodyatt , v6ops Operations Message-ID: Thread-Topic: 6to4 considered a bad thing Thread-Index: AchlNT0SH/sqwyYyRrmqCCAtwa9D4wAEEBHB In-Reply-To: <1E15D191-0BED-4039-916F-C0E6359867B3@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2008 02:44:13.0258 (UTC) FILETIME=[7EAE9AA0:01C86545] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/1/08 7:17 PM, "james woodyatt" wrote: >> Is ISP X suppose to announce a >> de-aggregate of 2002://16? That would create a huge increase in the >> routing >> table size... > > That's clearly not a good idea. Now, please help me reconcile how can a return relay for ISP X *only* advertize 2002::/16 (and nothing smaller) and not offer free return transit for people that are not its customers? - Alain. From owner-v6ops@ops.ietf.org Fri Feb 1 20:39:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1393A689F for ; Fri, 1 Feb 2008 20:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-rLKsJ8y-QW for ; Fri, 1 Feb 2008 20:39:18 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1BA113A6821 for ; Fri, 1 Feb 2008 20:39:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLA4I-000ASx-G6 for v6ops-data@psg.com; Sat, 02 Feb 2008 04:33:30 +0000 Received: from [209.85.198.190] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLA4G-000ASd-7D for v6ops@ops.ietf.org; Sat, 02 Feb 2008 04:33:29 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1294825rvf.41 for ; Fri, 01 Feb 2008 20:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=2JZj25+bWwEVnv/Ykot2rFHt5Pat7tUl8ibHjaJwaKU=; b=xsnMTcFDI50cL4OxbwEiANRb/qi8iXAd5QRqtq6Cu7uIhpintR62xj+VC9YPKVuqcQUqK2xTUqTmPNaO9kKVY/P0F3XY5gY3BS7dK1JNwsHu7g/Ulp+MIlftgWnbxbjtd/Mn97AbxCSk8MMp7favTZnNc+OuC/fKUIfjXHOMNhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=TGhkr7m7guJRane8w5u6xSgrEU4pa6y50QlO628AxcUQi9VnCfafQ/KD9qEJVh4cADwh60kLfofYwye4a9K3OhWX1I38qXRh986H+C1jfjVoqOxndhceAtu69AkFBUth5vypGXVZkJu2OG45nNcGEwsBLCc2RUUdzI15jSXfB9s= Received: by 10.140.147.13 with SMTP id u13mr3008804rvd.228.1201926808013; Fri, 01 Feb 2008 20:33:28 -0800 (PST) Received: from ?10.1.1.4? ( [203.173.145.5]) by mx.google.com with ESMTPS id b5sm1345747rva.20.2008.02.01.20.33.22 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Feb 2008 20:33:23 -0800 (PST) Message-ID: <47A3F28E.4040008@gmail.com> Date: Sat, 02 Feb 2008 17:33:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt CC: v6ops Operations Subject: Re: 6to4 considered a bad thing References: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> <0D8EC4E8-994D-4AA1-960D-0CD6DF3E7AF8@apple.com> In-Reply-To: <0D8EC4E8-994D-4AA1-960D-0CD6DF3E7AF8@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk > At this point, if large IPv6-capable ISP's cannot be persuaded to deploy > 6to4 relays in their interior IPv6/IPv4 routing domains for the use of > their paying, retail IPv4 customers, then I have to say that 6to4 is a > failure as a transition strategy, and we should move now to deprecate it. > It wasn't designed as a transition strategy (actually, nothing I've worked on was designed as a transition strategy) but rather as a coexistence tool. In fact 6to4 was specifically designed as a way for cooperating sites and ISPs to get past IPv4-only ISPs. But I agree that it's unfortunate if an IPv6-enabled ISP doesn't either offer a 6to4 relay or offer IPv4 transit to an ISP that does offer a 6to4 relay. I don't think that we can get this toothpaste back in the tube, though. Brian From owner-v6ops@ops.ietf.org Fri Feb 1 20:41:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621B93A689F for ; Fri, 1 Feb 2008 20:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh21uFfbTYh1 for ; Fri, 1 Feb 2008 20:41:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 63F643A6821 for ; Fri, 1 Feb 2008 20:41:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLA8O-000Ayv-AS for v6ops-data@psg.com; Sat, 02 Feb 2008 04:37:44 +0000 Received: from [209.85.198.186] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLA8M-000AyT-3N for v6ops@ops.ietf.org; Sat, 02 Feb 2008 04:37:43 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1295693rvf.41 for ; Fri, 01 Feb 2008 20:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=m7IAqjo1poqcQOOvUfR72gnd/WuVBJ3HegoxgUPNwp4=; b=SglXri63QQhYEi3CxOo5m/zJYk3k4uDbDK71SySHGU/Gw1qNQtcRVuK37OI43WEWnhBHzwQ0OeLjFxLKYv6QLMGnqqoo7WcnbBh2Ylysd2L+DHqIC2ZNNb1PpjDiYHMioeAnuLrSmNccsBMP+6dKBZR/A8ry8di695X9XVZGWCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sUOz0yEFo+Rf2N6bhJXTG60tA4KO7JzUnhd0F/UiXehMwrT9IECukbVTDHP9TKAs/RTfYz0vruPA3pam4J6x0LFubzPlN5Mr5w4fenieu7Lz6Zo5qVXMxBUUMgMBKJds9rxgm1j/p/vQq8nZ2dIZC5JGwG35vPzNZKxO6h7yvtI= Received: by 10.141.90.17 with SMTP id s17mr3019706rvl.129.1201927059261; Fri, 01 Feb 2008 20:37:39 -0800 (PST) Received: from ?10.1.1.4? ( [203.173.145.5]) by mx.google.com with ESMTPS id 2sm3563095rvi.32.2008.02.01.20.37.37 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Feb 2008 20:37:39 -0800 (PST) Message-ID: <47A3F38C.3070107@gmail.com> Date: Sat, 02 Feb 2008 17:37:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alain Durand CC: james woodyatt , v6ops Operations Subject: Re: 6to4 considered a bad thing References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-02-02 15:44, Alain Durand wrote: > > > On 2/1/08 7:17 PM, "james woodyatt" wrote: > >>> Is ISP X suppose to announce a >>> de-aggregate of 2002://16? That would create a huge increase in the >>> routing >>> table size... >> That's clearly not a good idea. > > Now, please help me reconcile how can a return relay for ISP X *only* > advertize 2002::/16 (and nothing smaller) and not offer free return transit > for people that are not its customers? Indeed. RFC 3056 explicitly says that the scope of such an advertisement has to be limited by policy. 3. A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy how far this routing advertisement of 2002::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns. Brian From owner-v6ops@ops.ietf.org Sat Feb 2 00:42:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC473A6A1B for ; Sat, 2 Feb 2008 00:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U--iBSCP1rP8 for ; Sat, 2 Feb 2008 00:42:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E211C3A69D2 for ; Sat, 2 Feb 2008 00:42:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLDp4-000HQD-Fr for v6ops-data@psg.com; Sat, 02 Feb 2008 08:34:02 +0000 Received: from [204.9.54.5] (helo=tokyo01.jp.mail.your.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLDp1-000HPm-TZ for v6ops@ops.ietf.org; Sat, 02 Feb 2008 08:34:01 +0000 Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 4ADD92AD5691; Sat, 2 Feb 2008 08:33:54 +0000 (UTC) Received: from pool014.dhcp.your.org (pool014.dhcp.your.org [69.31.99.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 91E3EA0A44E; Sat, 2 Feb 2008 08:33:53 +0000 (UTC) Cc: v6ops Operations Message-Id: <170CD596-6F09-4B72-8EC6-7C6F7D123112@dragondata.com> From: Kevin Day To: james woodyatt In-Reply-To: <1E15D191-0BED-4039-916F-C0E6359867B3@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: 6to4 considered a bad thing Date: Sat, 2 Feb 2008 02:32:42 -0600 References: <1E15D191-0BED-4039-916F-C0E6359867B3@apple.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 1, 2008, at 6:17 PM, james woodyatt wrote: >> Why should ISP X pay to run a 6to4 relay that would in essence >> offer transit >> for customers of other ISPs? > > No one here is asking for ISP X to advertise its 6to4 relays at > public anycast addresses (either IPv4 or IPv6) into the default free > zone. > While there may not be demands placed on any ISP to do so, there are a bunch of us who are doing it anyway. Which either is or isn't allowed under RFC3068, depending on who you ask. Judging by the huge range of emails we've received since announcing 192.88.99.0/24 and 2002::/16 to the world, most ISP's and end user's knowledge of what 6to4 is ranges from "non-existent" to "misinformed". So, it's a pretty safe bet to say that there's a pretty large percentage of ISPs out there that have no current plans to either start their own relay, or make arrangements with someone who does. So, I don't mind giving up a pretty trivial amount of bandwidth to help v6 adoption along - or at the very least do our part to make sure 6to4 works for who we can. -- Kevin From owner-v6ops@ops.ietf.org Sat Feb 2 01:12:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C243A6A12 for ; Sat, 2 Feb 2008 01:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXV4L4KijI3H for ; Sat, 2 Feb 2008 01:12:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 88B763A6884 for ; Sat, 2 Feb 2008 01:12:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLEM2-000MZe-0v for v6ops-data@psg.com; Sat, 02 Feb 2008 09:08:06 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLELy-000MZF-Uz for v6ops@ops.ietf.org; Sat, 02 Feb 2008 09:08:04 +0000 Received: (qmail 32947 invoked by uid 1007); 2 Feb 2008 09:08:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=EnHJy3qU5vGjm6ucbqqbGoC272eU87uvYZfW5DfMfPzX5pkeDbNgMHYNh/c+Fajw ; Date: Sat, 2 Feb 2008 10:08:01 +0100 From: Gert Doering To: Alain Durand Cc: Gert Doering , james woodyatt , v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Message-ID: <20080202090801.GQ69215@Space.Net> References: <20080201215654.GO69215@Space.Net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y2W6FuT1obb681ia" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Y2W6FuT1obb681ia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Feb 01, 2008 at 06:23:34PM -0500, Alain Durand wrote: > On 2/1/08 4:56 PM, "Gert Doering" wrote: >=20 > > On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote: > >> Essentially, expecting to get a functioning 6to4 relay is expecting a = free > >> lunch. Who is going to pay for it? > >=20 > > If enough ISPs provide working 6to4 relays, serving their own customers > > (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the > > model would work just fine. >=20 > Why should ISP X pay to run a 6to4 relay that would in essence offer tran= sit > for customers of other ISPs?=20 Why should it, indeed. If he does not want to do that, nobody forces him to announce the IPv4 anycast address / 2002::/16 to this other ISP. > And let's say that ISP X offer the outband > relay for its customers only, how would the packets come back from the re= al > IPv6 Internet to ISP X IPv4 network? Is ISP X suppose to announce a > de-aggregate of 2002://16? That would create a huge increase in the routi= ng > table size... The response is likely to take a different path - independent of "anycast" or not. So the response is likely to take a relay that's run by the ISP (or upstream ISP) of the other end. If there are enough relays, those are well-maintained and monitored,=20 and people stop playing political bullshit games, 6to4 could work nicely. I do have some doubts about the "bullshit" part :( Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --Y2W6FuT1obb681ia Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBR6Qy8akuBuNlUUl1AQKBMQP+JzBdzhdfL4l/+TzMJO4G/XXjqvq/LYEL LikW4ZrmMPk65p21sBdnYMk+RxUdbJpJZCpTOsgMOWk1jnztUej6mH0/goQz9G4j VI72WhEm0z+wne+Nfb3KPfSBSvLCIYPjqnUlZZf9ys3Sh+9u3+J6+EtdLZHB85Aw EVj6N3tL9is= =vWjM -----END PGP SIGNATURE----- --Y2W6FuT1obb681ia-- From owner-v6ops@ops.ietf.org Sat Feb 2 01:25:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EF53A6A21 for ; Sat, 2 Feb 2008 01:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6kYF5w-Hci1 for ; Sat, 2 Feb 2008 01:25:52 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 216953A6884 for ; Sat, 2 Feb 2008 01:25:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLEZn-000OQW-6u for v6ops-data@psg.com; Sat, 02 Feb 2008 09:22:19 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLEZh-000OQ0-Du for v6ops@ops.ietf.org; Sat, 02 Feb 2008 09:22:17 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A93A83EA0D7; Sat, 2 Feb 2008 10:22:12 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 0566F3EA0DF; Sat, 2 Feb 2008 10:22:09 +0100 (CET) Message-ID: <47A43640.9080405@free.fr> Date: Sat, 02 Feb 2008 10:22:08 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alain Durand CC: james woodyatt , v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain Durand wrote : > Essentially, expecting to get a functioning 6to4 relay is expecting a free > lunch. Who is going to pay for it? Agreed. 6to4 was not designed as a general IPv6 deployment tool. It was, and remains, an effective solution for two IPv6 clouds to communicate across a v4-only infrastructure, without involving ISPs. The new approach I have been working on, and deployed by the French ISP Free, can combines advantages of 6to4 (simplicity and processing efficiency) with the fact that ISPs that operate relays do it for themselves. An I-D 00 which describes it should be available in a few days (still under individual revisions). Rémi From owner-v6ops@ops.ietf.org Sat Feb 2 18:49:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418133A6AE2 for ; Sat, 2 Feb 2008 18:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.003 X-Spam-Level: X-Spam-Status: No, score=-5.003 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdJPKOEBrbje for ; Sat, 2 Feb 2008 18:49:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 66BB23A6929 for ; Sat, 2 Feb 2008 18:49:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLUhY-000Mpq-UN for v6ops-data@psg.com; Sun, 03 Feb 2008 02:35:24 +0000 Received: from [209.85.198.186] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLUhW-000MpY-2U for v6ops@ops.ietf.org; Sun, 03 Feb 2008 02:35:23 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1528706rvf.41 for ; Sat, 02 Feb 2008 18:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=48Uy37ddzztN3lfk74xOffn/zYggHpBYtGLxWrOb3y4=; b=nb5X1qLXVi6uO1/AlkjNnoYMS+BEfdGd23Ev2Ocd/l9lAQafnFisrDC1N2D3psMfgfBQhLWUlaJsV4txs/WFR6X3GdQhDk3zUVVwfHvRlkAhpMeqfjpNlNNJfMRapT9+3ItPJfL8IduywXbFZL532Yw9Rfem6hy4wbimnB3EwhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jtSGrMEnF9O/mU61drVQV59pYFzLsbb2mO6ZAausjj+VDsJPcL2JQtyBbXXW0KpfvOkl8+AwNgPy+bS0XY2KQztKQojtQTyBDbeLcoGW4brz/i7YKG9J7hlRXm7n8QYa2Nq0wlPszJiuaSjNyHEaYCRSqXvXAIfLSDGeR3F3lVw= Received: by 10.141.37.8 with SMTP id p8mr3640113rvj.150.1202006121493; Sat, 02 Feb 2008 18:35:21 -0800 (PST) Received: from ?10.1.1.4? ( [203.173.195.112]) by mx.google.com with ESMTPS id g39sm2051247rvb.16.2008.02.02.18.35.19 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Feb 2008 18:35:21 -0800 (PST) Message-ID: <47A52862.1020803@gmail.com> Date: Sun, 03 Feb 2008 15:35:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kevin Day CC: james woodyatt , v6ops Operations Subject: Re: 6to4 considered a bad thing References: <1E15D191-0BED-4039-916F-C0E6359867B3@apple.com> <170CD596-6F09-4B72-8EC6-7C6F7D123112@dragondata.com> In-Reply-To: <170CD596-6F09-4B72-8EC6-7C6F7D123112@dragondata.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk below... On 2008-02-02 21:32, Kevin Day wrote: > > On Feb 1, 2008, at 6:17 PM, james woodyatt wrote: >>> Why should ISP X pay to run a 6to4 relay that would in essence offer >>> transit >>> for customers of other ISPs? >> >> No one here is asking for ISP X to advertise its 6to4 relays at public >> anycast addresses (either IPv4 or IPv6) into the default free zone. >> > > While there may not be demands placed on any ISP to do so, there are a > bunch of us who are doing it anyway. Which either is or isn't allowed > under RFC3068, depending on who you ask. > > Judging by the huge range of emails we've received since announcing > 192.88.99.0/24 and 2002::/16 to the world, most ISP's and end user's > knowledge of what 6to4 is ranges from "non-existent" to "misinformed". > So, it's a pretty safe bet to say that there's a pretty large percentage > of ISPs out there that have no current plans to either start their own > relay, or make arrangements with someone who does. > > So, I don't mind giving up a pretty trivial amount of bandwidth to help > v6 adoption along - or at the very least do our part to make sure 6to4 > works for who we can. Applause and kudos. Obviously, anyone who wants to filter those announcements will do so. Brian Brian From owner-v6ops@ops.ietf.org Sun Feb 3 13:13:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122023A6CA9 for ; Sun, 3 Feb 2008 13:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.029 X-Spam-Level: X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[AWL=2.570, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z69onECPR3gH for ; Sun, 3 Feb 2008 13:13:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5D1403A6C82 for ; Sun, 3 Feb 2008 13:13:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLm6y-000628-Fn for v6ops-data@psg.com; Sun, 03 Feb 2008 21:10:48 +0000 Received: from [209.85.198.184] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLm6w-00060j-3n for v6ops@ops.ietf.org; Sun, 03 Feb 2008 21:10:47 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1733687rvf.41 for ; Sun, 03 Feb 2008 13:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=C2GtW0K3lqZhlfLovL794vZo2GEVQIFD90VPg1hn4s0=; b=T2s4HNDU+FDKTmj9l7Tsj2J/2CppL448wN9bJGCThIgxr/ls02kIsfW2nWEIbUBtLpSzX3YtPej6A4l+Q34kDPf8neSvOYELYHQ6UP5437yc3IFylwLx6UXjoSAZmDoyKliipDetKyM4eFqdINTEcPfLtaIJzDrLthXx4aQD3zM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QYzxRPXt6AATTUYL9hZJYFShaxZyLn9lha8wJxZdNqKS4aqyFqtgkGFopsjEC+6UKuavaDEhk1aIe2ABEV2Gthyx6jS5dIIKEnPjKvCmsemlx/SUJhHe6/xAKUrbF6OgZvZS3rzKfymZZTurKfhTUJfLWCMqWd1SVsEJiowLlPk= Received: by 10.140.208.14 with SMTP id f14mr4174891rvg.204.1202073043594; Sun, 03 Feb 2008 13:10:43 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id g1sm1639131rvb.0.2008.02.03.13.10.42 (version=SSLv3 cipher=RC4-MD5); Sun, 03 Feb 2008 13:10:43 -0800 (PST) Message-ID: <47A62DCF.1060204@gmail.com> Date: Mon, 04 Feb 2008 10:10:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: James Woodyatt CC: IPv6 Operations Subject: Re: 6to4 connectivity test References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Roll back the clock and I'm sure you'll find email 20 years old saying things like "the blackholes are responding to ICMP just fine. They just don't forward IPv4 from some networks (not others)." As Gert hinted, this is the tedious part of deploying a new protocol, i.e. chasing down the connectivity gaps one at a time. I doubt it's specific to 6to4, though maybe we need an FAQ on running a 6to4 relay. Brian On 2008-02-02 09:45, James Woodyatt wrote: > As I wrote privately, the 6to4 blackholes are responding to ICMP just > fine. They just don't forward IPv6 from some networks (not others). > > -jhw > > On Feb 1, 2008, at 12:31, Antonio Querubin wrote: > >> On Fri, 1 Feb 2008, james woodyatt wrote: >> >>> Search the Apple discussion boards for IPv6, and you will see that a >>> lot of people are turning off IPv6 entirely on their computers to >>> work around the connectivity issues involved here. >> >> I've already mentioned in private email but will re-iterate here. >> This is a problem caused by the CPE (the Airport in this case) not >> erring on the side of caution. These devices really need to leave >> 6to4 disabled and not allow autoconfiguration unless they can verify >> there is a reachable 6to4 relay. >> >> Perhaps in a revised spec it can INSIST on the pingability of the 6to4 >> relay so that CPEs can perform a keepalive check in determining >> whether to keep IPv6 autoconfiguration enabled. >> >> >> Antonio Querubin >> whois: AQ7-ARIN > > From owner-v6ops@ops.ietf.org Sun Feb 3 13:13:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662EC3A6CEE for ; Sun, 3 Feb 2008 13:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.112 X-Spam-Level: X-Spam-Status: No, score=-4.112 tagged_above=-999 required=5 tests=[AWL=2.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtO2aIX2Rhdb for ; Sun, 3 Feb 2008 13:13:30 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A6D123A6CA9 for ; Sun, 3 Feb 2008 13:13:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLm0N-00050C-Ax for v6ops-data@psg.com; Sun, 03 Feb 2008 21:03:59 +0000 Received: from [209.85.198.189] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLm0L-0004zv-1F for v6ops@ops.ietf.org; Sun, 03 Feb 2008 21:03:58 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1732478rvf.41 for ; Sun, 03 Feb 2008 13:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=YKNQAzLYirBQcH2PZwKyxwPKNzdcadxsv6VgCfhtXE4=; b=JOGUR9/fe7UX+TeZO1wPerS/04WYevR33jCYYtriTgv5HmIeVqDnOJnmOmQH5AX4eXGRegSQRqfaLb/XvpiZQHDJIWSTCVhSF8oex16Z8HSjyiEZ6N302XIWXeBMEKCF6novdJAMmMArLMWfncDgQkbd8oMbUg8FR0Dmker96Js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Vnnd7cvGpCsuX4Hf5Meh0mMrTET5rWcPScBDcA/+zYpdvhKk28itxVi9JP6vbGS7HAn3X/ZQ9gj67+gUlWpeRiJJCE4VW0EqfdUv4nN5tdYswXK8fZYWyAaEi8Rzx41QUnk4MsoSzbGn2kCZSJ986koolcXufmJnu9MlAs9J55Y= Received: by 10.141.99.4 with SMTP id b4mr4174698rvm.40.1202072634676; Sun, 03 Feb 2008 13:03:54 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k14sm1316359rvb.6.2008.02.03.13.03.53 (version=SSLv3 cipher=RC4-MD5); Sun, 03 Feb 2008 13:03:54 -0800 (PST) Message-ID: <47A62C38.6010407@gmail.com> Date: Mon, 04 Feb 2008 10:03:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt CC: v6ops Subject: Re: 6to4 anycast IP as source address / PTR record References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> In-Reply-To: <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-02-02 06:46, james woodyatt wrote: > On Jan 31, 2008, at 22:15, Pekka Savola wrote: >> >> Only the host-based 6to4 approach has gained measurable deployment, >> which leads me to think that we should focus on that in the >> specifications. > > > > The 6to4 router function is turned on by default in these products > (currently). I'm confident in saying that deployment of these boxes is > measurable. I've seen the measurements. Yes. And in fact other CPE vendors could reach the conclusion that this is the easy way for them to offer some kind of v6 support. I agree with Pekka that the BGP mode of deployment has been a bust so far, but I don't see it as being actively harmful, so I don't really see why we'd spend cycles on it. At least we do document that 2002:: prefixes longer than /16 must not be advertised, and that seems to be useful text. Brian From owner-v6ops@ops.ietf.org Sun Feb 3 19:11:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C493A6D34 for ; Sun, 3 Feb 2008 19:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PRfx3dJ4ou5 for ; Sun, 3 Feb 2008 19:11:11 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 16CA53A6A9F for ; Sun, 3 Feb 2008 19:11:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLrYw-0004pV-MH for v6ops-data@psg.com; Mon, 04 Feb 2008 03:00:02 +0000 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLrYu-0004pE-AO for v6ops@ops.ietf.org; Mon, 04 Feb 2008 03:00:01 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:59:58 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:59:58 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:59:57 +0800 Message-ID: <47A67FAD.1030803@zyxel.com.tw> Date: Mon, 04 Feb 2008 10:59:57 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: About IPv6 private address Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2008 02:59:57.0620 (UTC) FILETIME=[06644F40:01C866DA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I want to ask if there's any reserved private IPv6 address? I know RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is used to replace deprecated site-local address. However, in user's perspective, a device will need a well-known address, such as 192.168.1.1 in IPv4, for a customer to connect to without any configuration. In RFC 4193, the address' "global ID" is generated randomly, and the address could not be known in advance. After examing all the special purposed IPv6 address, I could not find one for this kind of purpose. Thanks. BR, Yi-Wen From owner-v6ops@ops.ietf.org Sun Feb 3 19:28:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A23B3A6D81 for ; Sun, 3 Feb 2008 19:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taoVpvDXYmJ0 for ; Sun, 3 Feb 2008 19:28:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5473C3A6A9F for ; Sun, 3 Feb 2008 19:28:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLrxY-00083g-HP for v6ops-data@psg.com; Mon, 04 Feb 2008 03:25:28 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLrxW-00083L-9G for v6ops@ops.ietf.org; Mon, 04 Feb 2008 03:25:27 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2008 19:25:25 -0800 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m143POMr006038; Mon, 4 Feb 2008 04:25:24 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m143PKJb012482; Mon, 4 Feb 2008 03:25:21 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 04:25:20 +0100 Received: from [192.130.162.20] ([10.61.82.91]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 04:25:19 +0100 In-Reply-To: <47A67FAD.1030803@zyxel.com.tw> References: <47A67FAD.1030803@zyxel.com.tw> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 05:25:19 +0200 To: blue X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Feb 2008 03:25:19.0826 (UTC) FILETIME=[91B28320:01C866DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=694; t=1202095524; x=1202959524; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20About=20IPv6=20private=20address |Sender:=20; bh=aW3ex+IhgQwMavtCJ5kDmS0xLZokvfMJpFvsFPdV6AI=; b=aRcf5XY30kSHHKmjtQMxTSQrxXidHcklBruMwJIDuZ+fEzwwL0moJgHFN8 TG6gb/+gYjaJHcb1EF2/3eWon3MUtmLUyhYDBLrXlWsk4HliAEQ5Buhqwvsk 6vw9ALoYqy; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 4, 2008, at 4:59 AM, blue wrote: > I want to ask if there's any reserved private IPv6 address? I know > RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is > used to replace deprecated site-local address. However, in user's > perspective, a device will need a well-known address, such as > 192.168.1.1 in IPv4, for a customer to connect to without any > configuration. In RFC 4193, the address' "global ID" is generated > randomly, and the address could not be known in advance. No, there is no such "well known" address. Are you thinking of configuration purposes, such as a Linksys box uses - you http the magic address and configure it? From owner-v6ops@ops.ietf.org Sun Feb 3 19:49:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC763A6D8C for ; Sun, 3 Feb 2008 19:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02Te3PV9eROG for ; Sun, 3 Feb 2008 19:49:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 811773A6CEC for ; Sun, 3 Feb 2008 19:49:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLsI1-000Azx-RP for v6ops-data@psg.com; Mon, 04 Feb 2008 03:46:37 +0000 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLsHz-000AzU-E3 for v6ops@ops.ietf.org; Mon, 04 Feb 2008 03:46:36 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 11:46:34 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 11:46:33 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 11:46:33 +0800 Message-ID: <47A68A99.50304@zyxel.com.tw> Date: Mon, 04 Feb 2008 11:46:33 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: [Fwd: Re: About IPv6 private address] Content-Type: multipart/mixed; boundary="------------000002000703000409000009" X-OriginalArrivalTime: 04 Feb 2008 03:46:33.0471 (UTC) FILETIME=[88D950F0:01C866E0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000002000703000409000009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000002000703000409000009 Content-Type: message/rfc822; name="Re: About IPv6 private address" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: About IPv6 private address" Message-ID: <47A68A61.5000909@zyxel.com.tw> Date: Mon, 04 Feb 2008 11:45:37 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker Subject: Re: About IPv6 private address References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> In-Reply-To: <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fred Baker wrote: > > On Feb 4, 2008, at 4:59 AM, blue wrote: > >> I want to ask if there's any reserved private IPv6 address? I know >> RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is >> used to replace deprecated site-local address. However, in user's >> perspective, a device will need a well-known address, such as >> 192.168.1.1 in IPv4, for a customer to connect to without any >> configuration. In RFC 4193, the address' "global ID" is generated >> randomly, and the address could not be known in advance. > > > No, there is no such "well known" address. Are you thinking of > configuration purposes, such as a Linksys box uses - you http the > magic address and configure it? > Dear Fred: Yes, users need to configure our device via http, and if there's no well-known IPv6 address, how do users know which address to connect to? I have thought about a pre-configured link-local address; however, browsers such as Firefox does not support link-local address. Any suggestions? BR, Yi-Wen --------------000002000703000409000009-- From owner-v6ops@ops.ietf.org Sun Feb 3 20:29:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A113A6CD5 for ; Sun, 3 Feb 2008 20:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NikA0HAMsNKR for ; Sun, 3 Feb 2008 20:29:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 588923A6DA4 for ; Sun, 3 Feb 2008 20:25:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLspU-000GX3-Ey for v6ops-data@psg.com; Mon, 04 Feb 2008 04:21:12 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLspR-000GWR-OK for v6ops@ops.ietf.org; Mon, 04 Feb 2008 04:21:11 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2008 20:21:05 -0800 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m144L5ub013337; Mon, 4 Feb 2008 05:21:05 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m144L5Jb023338; Mon, 4 Feb 2008 04:21:05 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 05:21:04 +0100 Received: from [192.130.162.20] ([10.61.82.91]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 05:21:04 +0100 In-Reply-To: <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> <47A68A61.5000909@zyxel.com.tw> <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops Operations Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 06:21:03 +0200 To: blue X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Feb 2008 04:21:04.0443 (UTC) FILETIME=[5B3E90B0:01C866E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1750; t=1202098865; x=1202962865; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20About=20IPv6=20private=20address |Sender:=20; bh=Thj6dpVGIf/YeVPKFia3RudbWJVjxM/ZvuBgc1/gkTg=; b=uHmYh18UUrO+lo5usqBgsXONuBZ3GaRfG+D6rVnLfx1qLHtqsmvYVUJpx8 eStUD9dOT2v+PZdWMzP0qYvyA/C8f6rJxeIhYqzL7FqK6BNI3wVjaFnY2JZe Dh2/WRU0Ph; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is straight off the top of my head, without a lot of thinking. But suppose the device took a random (as random as it could come up with) ULA and decided to use it locally, and became the "router", which is to say, issued an RA? That would be needed for the host to form an address anyway. The host could then connect to the local router, whose address it by definition knows (it is the only foreign address in its neighbor database). The router could discard the ULA after configuration completed and it had a prefix issued by its ISP. Do other folks have a suggestion? On Feb 4, 2008, at 5:45 AM, blue wrote: > Fred Baker wrote: >> On Feb 4, 2008, at 4:59 AM, blue wrote: >>> I want to ask if there's any reserved private IPv6 address? I >>> know RFC4193 has defined Unique Local IPv6 Unicast Addresses, >>> which is used to replace deprecated site-local address. However, >>> in user's perspective, a device will need a well-known address, >>> such as 192.168.1.1 in IPv4, for a customer to connect to >>> without any configuration. In RFC 4193, the address' "global ID" >>> is generated randomly, and the address could not be known in >>> advance. >> >> No, there is no such "well known" address. Are you thinking of >> configuration purposes, such as a Linksys box uses - you http the >> magic address and configure it? > > Dear Fred: > > Yes, users need to configure our device via http, and if there's no > well-known IPv6 address, how do users know which address to connect > to? I have thought about a pre-configured link-local address; > however, browsers such as Firefox does not support link-local > address. Any suggestions? > > BR, > Yi-Wen From owner-v6ops@ops.ietf.org Sun Feb 3 20:39:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0933A6D97 for ; Sun, 3 Feb 2008 20:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3ec4+Fq+dfm for ; Sun, 3 Feb 2008 20:39:13 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C314C3A6B24 for ; Sun, 3 Feb 2008 20:39:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLt38-000J8h-Gy for v6ops-data@psg.com; Mon, 04 Feb 2008 04:35:18 +0000 Received: from [64.233.178.243] (helo=hs-out-2122.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLt35-000J7y-8Y for v6ops@ops.ietf.org; Mon, 04 Feb 2008 04:35:17 +0000 Received: by hs-out-2122.google.com with SMTP id x43so2213032hsb.9 for ; Sun, 03 Feb 2008 20:35:12 -0800 (PST) Received: by 10.142.128.6 with SMTP id a6mr3156211wfd.138.1202099711249; Sun, 03 Feb 2008 20:35:11 -0800 (PST) Received: by 10.143.6.6 with HTTP; Sun, 3 Feb 2008 20:35:11 -0800 (PST) Message-ID: <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> Date: Sun, 3 Feb 2008 20:35:11 -0800 From: "Erik Kline" To: blue Subject: Re: [Fwd: Re: About IPv6 private address] Cc: v6ops@ops.ietf.org In-Reply-To: <47A68A99.50304@zyxel.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A68A99.50304@zyxel.com.tw> Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/3/08, blue wrote: > > > > ---------- Forwarded message ---------- > From: blue > To: Fred Baker > Date: Mon, 04 Feb 2008 11:45:37 +0800 > Subject: Re: About IPv6 private address > Fred Baker wrote: > > > > > On Feb 4, 2008, at 4:59 AM, blue wrote: > > > >> I want to ask if there's any reserved private IPv6 address? I know > >> RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is > >> used to replace deprecated site-local address. However, in user's > >> perspective, a device will need a well-known address, such as > >> 192.168.1.1 in IPv4, for a customer to connect to without any > >> configuration. In RFC 4193, the address' "global ID" is generated > >> randomly, and the address could not be known in advance. > > > > > > No, there is no such "well known" address. Are you thinking of > > configuration purposes, such as a Linksys box uses - you http the > > magic address and configure it? > > > Dear Fred: > > Yes, users need to configure our device via http, and if there's no > well-known IPv6 address, how do users know which address to connect to? > I have thought about a pre-configured link-local address; however, > browsers such as Firefox does not support link-local address. Any > suggestions? > > BR, > Yi-Wen > > > Whatever IPv6 address you chose you'd still have to get the customer to add that network to an interface. I.e. if you don't listen to RAs and SLAAC an address (NOTE: assumes RAs and not DHCP(v6)) you'd need to include instructions on which network to add to the host interface so the customer could talk to the device. Can it instead be discoverable somehow? I.e. let the device SLAAC or DHCP its address (if possible) and then use SLP or some variant? mDNS looking for a well-known name? It's an interesting problem... From owner-v6ops@ops.ietf.org Sun Feb 3 21:08:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E362C3A6D86 for ; Sun, 3 Feb 2008 21:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ML2dDTd86LH for ; Sun, 3 Feb 2008 21:08:37 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3C8093A6C25 for ; Sun, 3 Feb 2008 21:08:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtVZ-000NWa-Er for v6ops-data@psg.com; Mon, 04 Feb 2008 05:04:41 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtVX-000NWF-14 for v6ops@ops.ietf.org; Mon, 04 Feb 2008 05:04:40 +0000 X-IronPort-AV: E=Sophos;i="4.25,300,1199660400"; d="scan'208";a="4671173" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2008 06:04:38 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1454bJ4009439; Mon, 4 Feb 2008 06:04:37 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1454aJb001006; Mon, 4 Feb 2008 05:04:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 06:04:35 +0100 Received: from [192.130.162.20] ([10.61.82.91]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 06:04:34 +0100 In-Reply-To: <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2607373F-8539-4C87-B6EF-F7B9EC285956@cisco.com> Cc: v6ops Operations Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Fwd: Re: About IPv6 private address] Date: Mon, 4 Feb 2008 07:04:20 +0200 To: blue , Erik Kline X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Feb 2008 05:04:35.0039 (UTC) FILETIME=[6F47E6F0:01C866EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1691; t=1202101477; x=1202965477; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[Fwd=3A=20Re=3A=20About=20IPv6=20privat e=20address] |Sender:=20; bh=SuWo8nYmyKnPtiATalCFqQC7XRpiCoUV2qbUMTm3B6U=; b=qF7cQedDqYgklg5ZkRny70yVunuKb1YiIrzf3LXFzRRIe1f7fgxX3JYV6R Z/aaC9QCvbGk9slNvaJwmWBK///rA4rJWIgh0KAWG9zAoTZpT6/WJcPyT6O7 Y0JlX+UITU; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm. How about the link-local-scope all routers address? That would be FF02:0:0:0:0:0:0:2. Yes, in the most general sense that would not work, being multicast. But if the operating instructions said "make sure this is the only router on the link before doing this", it should work. Small CPE routers I have used (Linksys and D-Link) have you plug the host directly to the router's UNI, which pretty much nails that requirement. I would expect the host to form a link-local address, exchange it with the router using ND, and then talk to the router. If SCTP is in use, the router could create its own link-local address and then exchange addresses (RFC 5061) when it replied. I'm not altogether sure how a link-local address would be assigned using DHCP, so I think link-local requires SAA even if other addresses are assigned using DHCP. Ralph will correct me if I'm wrong, no doubt. From RFC 4291, section 2.7.1: All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local). All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 FF05:0:0:0:0:0:0:2 The above multicast addresses identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local). -----BEGIN PGP SIGNATURE----- iD8DBQFHppzVbjEdbHIsm0MRAoSUAKCtOcc7d53E4r+LCsF8xQh9WGKMUwCgnIhL jEBoA8S+ifIxdFX85nuDEMM= =qqTz -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Feb 3 21:20:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1973A6DAD for ; Sun, 3 Feb 2008 21:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id13pp7i4Wxg for ; Sun, 3 Feb 2008 21:20:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E1B703A6C25 for ; Sun, 3 Feb 2008 21:20:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLthi-000PO5-6q for v6ops-data@psg.com; Mon, 04 Feb 2008 05:17:14 +0000 Received: from [64.233.166.179] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLthf-000PNl-Mc for v6ops@ops.ietf.org; Mon, 04 Feb 2008 05:17:12 +0000 Received: by py-out-1112.google.com with SMTP id f31so2186706pyh.19 for ; Sun, 03 Feb 2008 21:17:11 -0800 (PST) Received: by 10.142.99.21 with SMTP id w21mr3172412wfb.55.1202102230475; Sun, 03 Feb 2008 21:17:10 -0800 (PST) Received: by 10.143.6.6 with HTTP; Sun, 3 Feb 2008 21:17:10 -0800 (PST) Message-ID: <67099930802032117m38c7edb7g4358a894d4f8c322@mail.gmail.com> Date: Sun, 3 Feb 2008 21:17:10 -0800 From: "Erik Kline" To: "Fred Baker" Subject: Re: About IPv6 private address Cc: blue , "v6ops Operations" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> <47A68A61.5000909@zyxel.com.tw> <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk I think that's pretty clever, actually. It doesn't have to advertise itself as a default router which, per http://tools.ietf.org/html/rfc2461#section-6.2.3 if I read it correctly, isn't hard. The device could include a ULA generating implementation or always use a well-known ULA (chosen by the manufacturer). It certainly warrants more thought, but it seems cool to me so far. On 2/3/08, Fred Baker wrote: > This is straight off the top of my head, without a lot of thinking. > But suppose the device took a random (as random as it could come up > with) ULA and decided to use it locally, and became the "router", > which is to say, issued an RA? That would be needed for the host to > form an address anyway. The host could then connect to the local > router, whose address it by definition knows (it is the only foreign > address in its neighbor database). The router could discard the ULA > after configuration completed and it had a prefix issued by its ISP. > > Do other folks have a suggestion? > > > On Feb 4, 2008, at 5:45 AM, blue wrote: > > > Fred Baker wrote: > >> On Feb 4, 2008, at 4:59 AM, blue wrote: > >>> I want to ask if there's any reserved private IPv6 address? I > >>> know RFC4193 has defined Unique Local IPv6 Unicast Addresses, > >>> which is used to replace deprecated site-local address. However, > >>> in user's perspective, a device will need a well-known address, > >>> such as 192.168.1.1 in IPv4, for a customer to connect to > >>> without any configuration. In RFC 4193, the address' "global ID" > >>> is generated randomly, and the address could not be known in > >>> advance. > >> > >> No, there is no such "well known" address. Are you thinking of > >> configuration purposes, such as a Linksys box uses - you http the > >> magic address and configure it? > > > > Dear Fred: > > > > Yes, users need to configure our device via http, and if there's no > > well-known IPv6 address, how do users know which address to connect > > to? I have thought about a pre-configured link-local address; > > however, browsers such as Firefox does not support link-local > > address. Any suggestions? > > > > BR, > > Yi-Wen > > > > From owner-v6ops@ops.ietf.org Sun Feb 3 21:23:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF403A6DB6 for ; Sun, 3 Feb 2008 21:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ln5AOYfMWa2 for ; Sun, 3 Feb 2008 21:23:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 19D6F3A6D47 for ; Sun, 3 Feb 2008 21:23:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtlE-000Pwt-S1 for v6ops-data@psg.com; Mon, 04 Feb 2008 05:20:52 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtlC-000PwV-Hg for v6ops@ops.ietf.org; Mon, 04 Feb 2008 05:20:51 +0000 X-IronPort-AV: E=Sophos;i="4.25,300,1199692800"; d="scan'208";a="11302993" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2008 21:20:49 -0800 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m145KmfJ019950; Mon, 4 Feb 2008 06:20:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m145KmJb004031; Mon, 4 Feb 2008 05:20:48 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 06:20:48 +0100 Received: from [192.130.162.20] ([10.61.82.91]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 06:20:47 +0100 In-Reply-To: <67099930802032117m38c7edb7g4358a894d4f8c322@mail.gmail.com> References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> <47A68A61.5000909@zyxel.com.tw> <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> <67099930802032117m38c7edb7g4358a894d4f8c322@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0EC99126-2FE3-4BE2-B6A3-4A14E58F7E17@cisco.com> Cc: blue , "v6ops Operations" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 07:20:46 +0200 To: "Erik Kline" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Feb 2008 05:20:47.0600 (UTC) FILETIME=[B2F8EF00:01C866ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=184; t=1202102448; x=1202966448; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20About=20IPv6=20private=20address |Sender:=20; bh=z1RGS5mYmlfLc7AdPHhcb4SLiNtByQ5oTSlEusaG9Qo=; b=DV0B7ousxkbiuShaiZeRq3sTgSE5ziA3NNSD0MsBEkSnbBIU/Eu6dBEhMk ZFh58xu4sPpPMp56jAtlhzYfFNAB52GDP8bV2DPivVP2EXUfud0Bbkmcch1G 7NM3HhVmzK; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 4, 2008, at 7:17 AM, Erik Kline wrote: > http://tools.ietf.org/html/rfc2461#section-6.2.3 That would be http://tools.ietf.org/html/rfc4861#section-6.2.3, right? :-) From owner-v6ops@ops.ietf.org Sun Feb 3 21:38:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD95D3A6DBF for ; Sun, 3 Feb 2008 21:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eObn9tSPai6S for ; Sun, 3 Feb 2008 21:38:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 334F73A6B62 for ; Sun, 3 Feb 2008 21:38:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtwh-0001dl-Kx for v6ops-data@psg.com; Mon, 04 Feb 2008 05:32:43 +0000 Received: from [209.85.146.178] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLtwW-0001bv-TD for v6ops@ops.ietf.org; Mon, 04 Feb 2008 05:32:38 +0000 Received: by wa-out-1112.google.com with SMTP id v27so2748959wah.23 for ; Sun, 03 Feb 2008 21:32:31 -0800 (PST) Received: by 10.142.213.9 with SMTP id l9mr3153394wfg.180.1202103151148; Sun, 03 Feb 2008 21:32:31 -0800 (PST) Received: by 10.143.6.6 with HTTP; Sun, 3 Feb 2008 21:32:31 -0800 (PST) Message-ID: <67099930802032132t77fa28c1l37a1530e4f9dd064@mail.gmail.com> Date: Sun, 3 Feb 2008 21:32:31 -0800 From: "Erik Kline" To: "Fred Baker" Subject: Re: About IPv6 private address Cc: blue , "v6ops Operations" In-Reply-To: <0EC99126-2FE3-4BE2-B6A3-4A14E58F7E17@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> <47A68A61.5000909@zyxel.com.tw> <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> <67099930802032117m38c7edb7g4358a894d4f8c322@mail.gmail.com> <0EC99126-2FE3-4BE2-B6A3-4A14E58F7E17@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/3/08, Fred Baker wrote: > > On Feb 4, 2008, at 7:17 AM, Erik Kline wrote: > > > http://tools.ietf.org/html/rfc2461#section-6.2.3 > > That would be http://tools.ietf.org/html/rfc4861#section-6.2.3, right? > > :-) > That's what I get for not stopping to think carefully and clearly (and not double-checking everything)! Thanks! :) From owner-v6ops@ops.ietf.org Sun Feb 3 23:53:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAA73A6DD3 for ; Sun, 3 Feb 2008 23:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jrLLhH4iLx9 for ; Sun, 3 Feb 2008 23:53:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8004F3A6DDB for ; Sun, 3 Feb 2008 23:53:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLvzi-000M6P-8E for v6ops-data@psg.com; Mon, 04 Feb 2008 07:43:58 +0000 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLvzf-000M5i-Db for v6ops@ops.ietf.org; Mon, 04 Feb 2008 07:43:56 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 15:43:49 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 15:43:49 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 15:43:49 +0800 Message-ID: <47A6C235.1070904@zyxel.com.tw> Date: Mon, 04 Feb 2008 15:43:49 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: [Fwd: Re: About IPv6 private address] Content-Type: multipart/mixed; boundary="------------000502030204090803030802" X-OriginalArrivalTime: 04 Feb 2008 07:43:49.0200 (UTC) FILETIME=[AE012D00:01C86701] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000502030204090803030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000502030204090803030802 Content-Type: message/rfc822; name="Re: About IPv6 private address" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: About IPv6 private address" Message-ID: <47A6AFC3.70201@zyxel.com.tw> Date: Mon, 04 Feb 2008 14:25:07 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Herbst Subject: Re: About IPv6 private address References: <47A67FAD.1030803@zyxel.com.tw> <439B9210-7503-4E58-B953-5615D50CAFA1@cisco.com> <47A68A61.5000909@zyxel.com.tw> <056AAB5C-A95A-4DAF-8F86-366E85BFE842@cisco.com> <200802040558.m145wYuv012387@sj-core-1.cisco.com> In-Reply-To: <200802040558.m145wYuv012387@sj-core-1.cisco.com> Content-Type: multipart/alternative; boundary="------------060207010104080407030602" This is a multi-part message in MIME format. --------------060207010104080407030602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Even by mDNS or LLMNR, the device need to reply the queried name, such as "gateway.local.", with a valid IPv6 address except link-local address since DNS record could not allow link-local address to be carried. Without any configuration, there's no IPv6 address available besides link-local address. Or you suggest using the combination of Unique Local IPv6 address and mDNS? Thanks. BR, Yi-Wen Thomas Herbst wrote: >Couldn't this be done with a name via m-dns or something similar? > >tom > >At 08:01 PM 2/3/2008, Fred Baker wrote: > > >>This is straight off the top of my head, without a lot of thinking. >>But suppose the device took a random (as random as it could come up >>with) ULA and decided to use it locally, and became the "router", >>which is to say, issued an RA? That would be needed for the host to >>form an address anyway. The host could then connect to the local >>router, whose address it by definition knows (it is the only foreign >>address in its neighbor database). The router could discard the ULA >>after configuration completed and it had a prefix issued by its ISP. >> >>Tom and Ole, adding you to the thread. Do you have suggestions? >> >>On Feb 4, 2008, at 5:45 AM, blue wrote: >> >> >> >>>Fred Baker wrote: >>> >>> >>>>On Feb 4, 2008, at 4:59 AM, blue wrote: >>>> >>>> >>>>>I want to ask if there's any reserved private IPv6 address? I >>>>>know RFC4193 has defined Unique Local IPv6 Unicast Addresses, >>>>>which is used to replace deprecated site-local address. However, >>>>>in user's perspective, a device will need a well-known address, >>>>>such as 192.168.1.1 in IPv4, for a customer to connect to >>>>>without any configuration. In RFC 4193, the address' "global ID" >>>>>is generated randomly, and the address could not be known in >>>>>advance. >>>>> >>>>> >>>>No, there is no such "well known" address. Are you thinking of >>>>configuration purposes, such as a Linksys box uses - you http the >>>>magic address and configure it? >>>> >>>> >>>Dear Fred: >>> >>>Yes, users need to configure our device via http, and if there's no >>>well-known IPv6 address, how do users know which address to connect >>>to? I have thought about a pre-configured link-local address; >>>however, browsers such as Firefox does not support link-local >>>address. Any suggestions? >>> >>>BR, >>>Yi-Wen >>> >>> > > > > --------------060207010104080407030602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Even by mDNS or LLMNR, the device need to reply the queried name, such as "gateway.local.", with a valid IPv6 address except link-local address since DNS record could not allow link-local address to be carried. Without any configuration, there's no IPv6 address available besides link-local address. Or you suggest using the combination of Unique Local IPv6 address and mDNS?

Thanks.
BR,
Yi-Wen

Thomas Herbst wrote: 

Couldn't this be done with a name via m-dns or something similar?

tom

At 08:01 PM 2/3/2008, Fred Baker wrote:
  
This is straight off the top of my head, without a lot of thinking.  
But suppose the device took a random (as random as it could come up  
with) ULA and decided to use it locally, and became the "router",  
which is to say, issued an RA? That would be needed for the host to  
form an address anyway. The host could then connect to the local  
router, whose address it by definition knows (it is the only foreign  
address in its neighbor database). The router could discard the ULA  
after configuration completed and it had a prefix issued by its ISP.

Tom and Ole, adding you to the thread. Do you have suggestions?

On Feb 4, 2008, at 5:45 AM, blue wrote:

    
Fred Baker wrote:
      
On Feb 4, 2008, at 4:59 AM, blue wrote:
        
I want to ask if there's any reserved private IPv6 address? I  
know  RFC4193 has defined Unique Local IPv6 Unicast Addresses,  
which is  used to replace deprecated site-local address. However,  
in user's  perspective, a device will need a well-known address,  
such as  192.168.1.1 in IPv4, for a customer to connect to  
without any  configuration. In RFC 4193, the address' "global ID"  
is generated  randomly, and the address could not be known in  
advance.
          
No, there is no such "well known" address. Are you thinking of   
configuration purposes, such as a Linksys box uses - you http the   
magic address and configure it?
        
Dear Fred:

Yes, users need to configure our device via http, and if there's no  
well-known IPv6 address, how do users know which address to connect  
to? I have thought about a pre-configured link-local address;  
however, browsers such as Firefox does not support link-local  
address. Any suggestions?

BR,
Yi-Wen

--------------060207010104080407030602-- --------------000502030204090803030802-- From owner-v6ops@ops.ietf.org Mon Feb 4 02:34:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFBF3A6E88 for ; Mon, 4 Feb 2008 02:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=3.003, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLKWSQx0fBwM for ; Mon, 4 Feb 2008 02:34:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 29AF93A6BA1 for ; Mon, 4 Feb 2008 02:34:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLyZE-000P2L-2r for v6ops-data@psg.com; Mon, 04 Feb 2008 10:28:48 +0000 Received: from [203.6.132.90] (helo=mistral.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLyZB-000P1x-DI for v6ops@ops.ietf.org; Mon, 04 Feb 2008 10:28:46 +0000 Received: from 122-49-140-247.ip.adam.com.au ([122.49.140.247] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JLyau-000I6X-7f; Mon, 04 Feb 2008 21:00:32 +1030 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 972494571; Mon, 4 Feb 2008 20:58:39 +1030 (CST) Date: Mon, 4 Feb 2008 20:58:39 +1030 From: Mark Smith To: blue Cc: v6ops@ops.ietf.org Subject: Re: About IPv6 private address Message-Id: <20080204205839.fa620dca.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <47A67FAD.1030803@zyxel.com.tw> References: <47A67FAD.1030803@zyxel.com.tw> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 04 Feb 2008 10:59:57 +0800 blue wrote: > Hi, > > I want to ask if there's any reserved private IPv6 address? I know > RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is used > to replace deprecated site-local address. However, in user's > perspective, a device will need a well-known address, such as > 192.168.1.1 in IPv4, As a minor data point, while 192.168.1.1 is well used, it isn't a well known address that you can always use. I deal with a few different pieces of ADSL CPE at work, and on occasion I've also seen 192.168.0/24, 192.168.2/24, and on some occasions, to avoid colliding with existing nodes already using 192.168. [0-2]/24, it jumps to a different subnet within 192.168.[0-255] on every boot. For those devices you have to lookup the default gateway address announced via DHCP. Regardless, having the customer type in a name, not an IPv4 or IPv6 address, is far more user friendly. > for a customer to connect to without any > configuration. In RFC 4193, the address' "global ID" is generated > randomly, and the address could not be known in advance. > > After examing all the special purposed IPv6 address, I could not find > one for this kind of purpose. > > Thanks. > BR, > Yi-Wen > From owner-v6ops@ops.ietf.org Mon Feb 4 02:41:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E061D3A6E82 for ; Mon, 4 Feb 2008 02:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=2.997, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvrsvMXMfH4X for ; Mon, 4 Feb 2008 02:41:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1B7293A6D6A for ; Mon, 4 Feb 2008 02:41:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLyiR-0000WX-0C for v6ops-data@psg.com; Mon, 04 Feb 2008 10:38:19 +0000 Received: from [203.6.132.66] (helo=smtp2.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLyiO-0000WE-25 for v6ops@ops.ietf.org; Mon, 04 Feb 2008 10:38:17 +0000 Received: from 122-49-140-247.ip.adam.com.au ([122.49.140.247] helo=mail.nosense.org) by smtp2.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JLyhg-0004Zd-8l; Mon, 04 Feb 2008 21:07:32 +1030 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 4DE094571; Mon, 4 Feb 2008 21:08:13 +1030 (CST) Date: Mon, 4 Feb 2008 21:08:12 +1030 From: Mark Smith To: "Erik Kline" Cc: blue , v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Message-Id: <20080204210812.afb502a1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 3 Feb 2008 20:35:11 -0800 "Erik Kline" wrote: > On 2/3/08, blue wrote: > > > > > > > > ---------- Forwarded message ---------- > > From: blue > > To: Fred Baker > > Date: Mon, 04 Feb 2008 11:45:37 +0800 > > Subject: Re: About IPv6 private address > > Fred Baker wrote: > > > > > > > > On Feb 4, 2008, at 4:59 AM, blue wrote: > > > > > >> I want to ask if there's any reserved private IPv6 address? I know > > >> RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is > > >> used to replace deprecated site-local address. However, in user's > > >> perspective, a device will need a well-known address, such as > > >> 192.168.1.1 in IPv4, for a customer to connect to without any > > >> configuration. In RFC 4193, the address' "global ID" is generated > > >> randomly, and the address could not be known in advance. > > > > > > > > > No, there is no such "well known" address. Are you thinking of > > > configuration purposes, such as a Linksys box uses - you http the > > > magic address and configure it? > > > > > Dear Fred: > > > > Yes, users need to configure our device via http, and if there's no > > well-known IPv6 address, how do users know which address to connect to? > > I have thought about a pre-configured link-local address; however, > > browsers such as Firefox does not support link-local address. Any > > suggestions? > > > > BR, > > Yi-Wen > > > > > > > > Whatever IPv6 address you chose you'd still have to get the customer > to add that network to an interface. I.e. if you don't listen to RAs > and SLAAC an address (NOTE: assumes RAs and not DHCP(v6)) you'd need > to include instructions on which network to add to the host interface > so the customer could talk to the device. > > Can it instead be discoverable somehow? I.e. let the device SLAAC or > DHCP its address (if possible) and then use SLP or some variant? mDNS > looking for a well-known name? > Or maybe announce the device's brand and model, as printed on the outside of the device. From owner-v6ops@ops.ietf.org Mon Feb 4 05:29:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438013A6E0F for ; Mon, 4 Feb 2008 05:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qget9JfeBWfv for ; Mon, 4 Feb 2008 05:29:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 63FC33A6E93 for ; Mon, 4 Feb 2008 05:29:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM1FM-000Pkr-ME for v6ops-data@psg.com; Mon, 04 Feb 2008 13:20:28 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM1EV-000PaM-Oa for v6ops@ops.ietf.org; Mon, 04 Feb 2008 13:19:55 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 4FCA6CA0; Mon, 4 Feb 2008 14:20:30 +0100 (CET) To: blue Subject: Re: About IPv6 private address MIME-Version: 1.0 Date: Mon, 4 Feb 2008 14:20:30 +0100 From: Remi Denis-Courmont Cc: v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: <47A67FAD.1030803@zyxel.com.tw> References: <47A67FAD.1030803@zyxel.com.tw> Message-ID: <8ec9acf27b6d860525d5e0b33fcc077d@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 04 Feb 2008 10:59:57 +0800, blue wrote: > I want to ask if there's any reserved private IPv6 address? I know > RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is used > to replace deprecated site-local address. However, in user's > perspective, a device will need a well-known address, such as > 192.168.1.1 in IPv4, for a customer to connect to without any > configuration. In RFC 4193, the address' "global ID" is generated > randomly, and the address could not be known in advance. > > After examing all the special purposed IPv6 address, I could not find > one for this kind of purpose. In principle, fixed link-local address are possible. Though you'd need to know the interface identifier on the client, which makes this, as you noted, not very workable a solution. I note that this, in any case, can only work for a gateway device. Any other IP-based appliance (networked printer, networked Hi-Fi, networked toast-maker) can anyway not use a fixed address, and has to resort to multicast discovery. So... in the gateway case, you could probably use a fixed local DNS name provided by the router DNS cache, that resolves to the ULA of the router. This means the router needs to have local DNS caching server. Or then, as already proposed, you can use a fixed ULA, but that kind sucks as it kills the whole idea UNIQUENESS of ULA. -- Rémi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Mon Feb 4 06:18:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE13D3A6DAA for ; Mon, 4 Feb 2008 06:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M79HOeL4xB9V for ; Mon, 4 Feb 2008 06:18:36 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C7ED63A6C91 for ; Mon, 4 Feb 2008 06:18:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM24c-0009fB-Tk for v6ops-data@psg.com; Mon, 04 Feb 2008 14:13:26 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM24T-0009dO-Ip for v6ops@ops.ietf.org; Mon, 04 Feb 2008 14:13:19 +0000 Received: from [192.168.0.64] (unknown [203.173.179.166]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 7A0BD271B0 for ; Tue, 5 Feb 2008 03:13:15 +1300 (NZDT) Message-Id: From: Nathan Ward To: v6ops Operations In-Reply-To: <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: 6to4 connectivity test Date: Tue, 5 Feb 2008 03:13:14 +1300 References: <9F195FE7-E47F-4CC3-B93E-5FA4AAF1088A@dragondata.com> <47A24424.9010706@gmail.com> <859C270C-FB04-4CF5-8558-9FF7787DEF36@apple.com> <89C4B01D-C26D-411B-8AA5-BDB3B1AF724A@apple.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/02/2008, at 8:37 AM, james woodyatt wrote: > On Feb 1, 2008, at 10:35, Christian Huitema wrote: >> >> OK. So, what would we changed in 6to4 if we optimized for host- >> based or CPE-based deployment? Do we trust that we will get enough >> 6to4 gateways deployed to sustain growth, or do we need to add a >> "gateway discovery service" similar to the Teredo spec? > > A standard method of discovering whether the 6to4 relay at the > anycast address is functioning properly would be a fine idea. > > At the moment, some very large ISP's are now hindering transition to > IPv6 by forwarding 6to4 packets to relays that are black-holing them > rather than forwarding them. (This was not the case when AirPort > Extreme shipped.) These ISP's have no plans to deploy 6to4 relays > in their own IPv6-capable networks, nor do they have any plan to > forward 6to4 traffic to relays that will carry it for them. This is > making some large content providers *remove* their AAAA records when > they discover that customers behind 6to4 routers, e.g. AirPort > Extreme, are unable to receive service because their applications do > not fall back to IPv4 when IPv6 connectivity is broken. > > Search the Apple discussion boards for IPv6, and you will see that a > lot of people are turning off IPv6 entirely on their computers to > work around the connectivity issues involved here. Yup, I wrote an email here some time ago about this: "6to4 and 'campus' networks". My comments were more in relation to end hosts turning on 6to4 when they had non-RFC1918 addresses, but it still applies in the case of CPE turning on 6to4 in a similar situation (perhaps the CPE is behind NAT, or a firewall of some kind, or has a broken relay, etc.). Applications /do/ fall back in my experience, however they take a long time to do so - I think my Mac did it in around 90 seconds or so when I last looked. Obviously, way past the user getting impatient, and declaring it 'broken'. I'd be happy to follow it up, I've had a few thoughts about how this could work since then, and some thoughts about how it's painful. I'll write more when it's not 3am, however. Some things to leave you with for now; - 6to4 relays for the forward and reverse path between two hosts are likely to be different - Teredo gets around problems by testing the relay bidirectionally when talking to any new host (no asymmetric relaying in Teredo of course) - Any initial test needs to make sure that the following are both reachable bidirectionally, so we are sure we are not behind a stateful firewall, or NAT, etc.: o Host reachable through the magic (192.88.99.1) relay o 6to4 host that is not in 2002:c058:6301::/48 (192.88.99.1) - If we are amending some parts of 6to4, should we consider optionally doing Teredo-like tricks for discovering relays closer to the non-6to4 host? (ie. look at the IPv4 src addr in incoming packet, and use that for reaching that host in the future). Can we trigger that by doing an ICMPv6 echo request (as Teredo does), which would also verify that the selected relay is working. Cheers, -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Feb 4 07:01:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CA43A6EB2 for ; Mon, 4 Feb 2008 07:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCerbQyeaBR1 for ; Mon, 4 Feb 2008 07:01:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DA2A53A6F79 for ; Mon, 4 Feb 2008 07:00:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM2jv-000Ggt-Vn for v6ops-data@psg.com; Mon, 04 Feb 2008 14:56:07 +0000 Received: from [66.196.100.127] (helo=web58705.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM2jt-000GgL-3b for v6ops@ops.ietf.org; Mon, 04 Feb 2008 14:56:06 +0000 Received: (qmail 17330 invoked by uid 60001); 4 Feb 2008 14:56:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1Aq/hVIY/c7SPxHafFz7juM1QuiPabbEx0G2ML5dfg5r3XzZCXKhZ1ESMzVA+ADELtyWS1x21xx4shenBXSlbDp/PrNhxwVx0qhKAvxenn65RPnp8caJ58m+vYhg7YvApnBH4J/sSKPlrR6ufKRNBNlq2GGfwLj+XVziny/yLOo=; X-YMail-OSG: iagQvWAVM1mX.odXOVV9437jcJdQC.AUjBDYQSIEsktr.GHfMzlORzA04h8wiR3CCqpNhW2V83T7eVXFgzA8x5XkkKfRwfvEVoyWchtHfMdJ6qnHw0eyuZEwNOYlNDs8vR5nrW3vOXzd4g-- Received: from [99.228.183.76] by web58705.mail.re1.yahoo.com via HTTP; Mon, 04 Feb 2008 06:56:04 PST Date: Mon, 4 Feb 2008 06:56:04 -0800 (PST) From: Peter Sherbin Subject: Re: [Fwd: Re: About IPv6 private address] To: blue , v6ops@ops.ietf.org In-Reply-To: <47A68A99.50304@zyxel.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <165285.15500.qm@web58705.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I have thought about a pre-configured link-local address; however, > browsers such as Firefox does not support link-local address. Any > suggestions? Would this work assuming that you can reach your device anywhere onnet via IPv6: 1. customer turns on your device connected to CPE router/modem 2. device sents a packet to your server 3. server sends back a config file The above excludes the customer from configuration and such. Thanks, Peter --- blue wrote: > > > Date: Mon, 04 Feb 2008 11:45:37 +0800 > From: blue > To: Fred Baker > Subject: Re: About IPv6 private address > > Fred Baker wrote: > > > > > On Feb 4, 2008, at 4:59 AM, blue wrote: > > > >> I want to ask if there's any reserved private IPv6 address? I know > >> RFC4193 has defined Unique Local IPv6 Unicast Addresses, which is > >> used to replace deprecated site-local address. However, in user's > >> perspective, a device will need a well-known address, such as > >> 192.168.1.1 in IPv4, for a customer to connect to without any > >> configuration. In RFC 4193, the address' "global ID" is generated > >> randomly, and the address could not be known in advance. > > > > > > No, there is no such "well known" address. Are you thinking of > > configuration purposes, such as a Linksys box uses - you http the > > magic address and configure it? > > > Dear Fred: > > Yes, users need to configure our device via http, and if there's no > well-known IPv6 address, how do users know which address to connect to? > I have thought about a pre-configured link-local address; however, > browsers such as Firefox does not support link-local address. Any > suggestions? > > BR, > Yi-Wen > > ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-v6ops@ops.ietf.org Mon Feb 4 07:03:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABF33A6D22 for ; Mon, 4 Feb 2008 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA5R-Wj6w+FB for ; Mon, 4 Feb 2008 07:03:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9F1473A6D1C for ; Mon, 4 Feb 2008 07:03:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM2og-000HOx-P3 for v6ops-data@psg.com; Mon, 04 Feb 2008 15:01:02 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM2oS-000HNa-Jy for v6ops@ops.ietf.org; Mon, 04 Feb 2008 15:00:50 +0000 Received: from [163.117.140.35] ([163.117.140.35]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m14F0Spw029176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2008 16:00:28 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org Message-Id: <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> From: Iljitsch van Beijnum To: blue In-Reply-To: <47A6C235.1070904@zyxel.com.tw> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Fwd: Re: About IPv6 private address] Date: Mon, 4 Feb 2008 16:00:39 +0100 References: <47A6C235.1070904@zyxel.com.tw> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 4 feb 2008, at 8:43, blue wrote: > Even by mDNS or LLMNR, the device need to reply the queried name, > such as "gateway.local.", with a valid IPv6 address except link- > local address since DNS record could not allow link-local address to > be carried. Is there any particular reason we're reinventing this specific wheel for which excellent implementations exist? In my webbrowser I can look under "bonjour" (sometimes mistakenly called mDNS) and get a list of printers on the local network. From owner-v6ops@ops.ietf.org Mon Feb 4 10:06:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAA33A7015 for ; Mon, 4 Feb 2008 10:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9NBoARHnKs7 for ; Mon, 4 Feb 2008 10:06:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 647393A70A7 for ; Mon, 4 Feb 2008 10:05:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM5Ul-000LBs-3Y for v6ops-data@psg.com; Mon, 04 Feb 2008 17:52:39 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM5Uf-000LAs-BH for v6ops@ops.ietf.org; Mon, 04 Feb 2008 17:52:34 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 5BA102024CCB for ; Mon, 4 Feb 2008 09:52:32 -0800 (PST) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 452AA28089 for ; Mon, 4 Feb 2008 09:52:32 -0800 (PST) X-AuditID: 11807134-a7d7cbb0000008b9-13-47a750e03af5 Received: from [17.206.23.192] (il0602a-dhcp64.apple.com [17.206.23.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 247C828083 for ; Mon, 4 Feb 2008 09:52:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> References: <47A6C235.1070904@zyxel.com.tw> <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 09:52:31 -0800 To: v6ops Operations X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 4, 2008, at 07:00, Iljitsch van Beijnum wrote: > On 4 feb 2008, at 8:43, blue wrote: >> >> Even by mDNS or LLMNR, the device need to reply the queried name, >> such as "gateway.local.", with a valid IPv6 address except link- >> local address since DNS record could not allow link-local address >> to be carried. > > Is there any particular reason we're reinventing this specific > wheel for which excellent implementations exist? In my webbrowser I > can look under "bonjour" (sometimes mistakenly called mDNS) and get > a list of printers on the local network. On top of that, it already works, today, with IPv6-- which is a win when the browsing host has multiple network interfaces, as most personal computers do these days. IPv6 link-local addresses are scoped to the interface, so addressing conflicts are completely avoided. Some people just want to make things harder than necessary to use, I guess. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Mon Feb 4 12:24:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740683A70B7 for ; Mon, 4 Feb 2008 12:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[AWL=2.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw70cKKtBMdA for ; Mon, 4 Feb 2008 12:24:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BB0713A700C for ; Mon, 4 Feb 2008 12:24:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM7l6-000Fai-Bj for v6ops-data@psg.com; Mon, 04 Feb 2008 20:17:40 +0000 Received: from [203.6.132.90] (helo=mistral.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM7l3-000FYK-QH for v6ops@ops.ietf.org; Mon, 04 Feb 2008 20:17:39 +0000 Received: from 122-49-140-247.ip.adam.com.au ([122.49.140.247] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JM7mn-000I92-Ly; Tue, 05 Feb 2008 06:49:25 +1030 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 6E5F34571; Tue, 5 Feb 2008 06:47:32 +1030 (CST) Date: Tue, 5 Feb 2008 06:47:32 +1030 From: Mark Smith To: james woodyatt Cc: v6ops Operations Subject: Re: About IPv6 private address Message-Id: <20080205064732.419415a3.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> References: <47A6C235.1070904@zyxel.com.tw> <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 4 Feb 2008 09:52:31 -0800 james woodyatt wrote: > On Feb 4, 2008, at 07:00, Iljitsch van Beijnum wrote: > > On 4 feb 2008, at 8:43, blue wrote: > >> > >> Even by mDNS or LLMNR, the device need to reply the queried name, > >> such as "gateway.local.", with a valid IPv6 address except link- > >> local address since DNS record could not allow link-local address > >> to be carried. > > > > Is there any particular reason we're reinventing this specific > > wheel for which excellent implementations exist? In my webbrowser I > > can look under "bonjour" (sometimes mistakenly called mDNS) and get > > a list of printers on the local network. > > On top of that, it already works, today, with IPv6-- which is a win > when the browsing host has multiple network interfaces, as most > personal computers do these days. IPv6 link-local addresses are > scoped to the interface, so addressing conflicts are completely avoided. > > Some people just want to make things harder than necessary to use, I > guess. > Well, not everybody has or will have Apples, so they won't have Bonjour aware clients/browsers. There does need to be alternative methods. You're right though, service / device location is old school, Novell Netware and Appletalk got that sorted out years ago, and SLP and Bonjour seem to me to mainly be IETF versions of their techniques. Regards, Mark. From owner-v6ops@ops.ietf.org Tue Feb 5 10:35:04 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 781AA3A6780; Tue, 5 Feb 2008 10:52:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id EF26A3A861C for ; Mon, 4 Feb 2008 21:35:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMGOG-00047V-0L for v6ops-data@psg.com; Tue, 05 Feb 2008 05:30:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTTP_ESCAPED_HOST,RDNS_NONE,URI_HEX,WEIRD_PORT autolearn=no version=3.2.3 Received: from [207.5.72.164] (helo=EXHUB016-2.exch016.msoutlookonline.net) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMGO7-00042U-Sb for v6ops@ops.ietf.org; Tue, 05 Feb 2008 05:30:35 +0000 Received: from EXVMBX016-2.exch016.msoutlookonline.net ([207.5.72.172]) by EXHUB016-2.exch016.msoutlookonline.net ([207.5.72.164]) with mapi; Mon, 4 Feb 2008 21:30:30 -0800 From: David Conrad To: Christian Huitema , blue CC: Brian E Carpenter , "v6ops@ops.ietf.org" Date: Mon, 4 Feb 2008 21:30:28 -0800 Subject: Re: [Fwd: Re: About IPv6 private address] Thread-Topic: [Fwd: Re: About IPv6 private address] Thread-Index: AchnpVQJ5QZ8/gHtQ32HvXHcvHoS4AADLDCwAAGMoq4= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C3CD347436D8davidconradicannorg_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --_000_C3CD347436D8davidconradicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian, Just to be sure I understand, you're saying Microsoft has introduced someth= ing in Vista that looks a whole lot like a domain name in VeriSign's .NET d= omain namespace but that isn't really a domain name to deal with some appli= cations that had trouble dealing with IPv6 literals? Thanks, -drc On 2/4/08 8:49 PM, "Christian Huitema" wrot= e: Firefox does not do anything there. The name resolution service in Windows = Vista resolves names of the form fe80--213-49ff-fe04-507s8.ipv6-literal.net= into the corresponding IPv6 address, in that example [fe80::213:49ff:fe04:= 507%8]. For Firefox, it is just a name lookup. We put that feature in Vista because some applications had a very hard time= parsing colons and percent signs. It really is a work around... From: blue [mailto:susan.lan@zyxel.com.tw] Sent: Monday, February 04, 2008 7:15 PM To: Christian Huitema Cc: Brian E Carpenter; v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Dear Christian: Do you mean Firefox on Vista will translate the link-local address to the d= omain name suffixed "ipv6-literal.net"? Currently my platform is Microsoft Windows XP instead of Windows Vista. How= ever, I don't consider this behavior is related to the OS version. Which version is your Firefox, please? Thanks. BR, Yi-Wen Christian Huitema wrote: If you are running Firefox on Windows Vista, you should be able to try http= ://fe80--213-49ff-fe04-507s8.ipv6-literal.net/ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of blue Sent: Monday, February 04, 2008 5:34 PM To: Brian E Carpenter Cc: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Please forgive my dumbness but my Firefox version is 2.0.0.9 My IE could not connect to IPv6 URL either! (IE version 6.0) Thanks. BR, Yi-Wen Brian E Carpenter wrote: That is a Firefox configuration issue, I think. I don't see that problem (with Firefix 2.0.0.7, or with IE). Is it possible that your browser is going to a proxy? Brian On 2008-02-05 13:24, blue wrote: Hi, But after typing a link-local address, Firefox' message shows: Unable to find "www.fe80::213:49ff:fe04:507%8.com " It translated typed "http://[fe80::213:49ff:fe04:507%8]" to "http://[www.fe80::213:49ff:fe04:507%8.com]/" . However, a global unique IPv6 address worked! I thought it proved that Firefox does not support link-local address. Thanks. BR, Yi-Wen Brian E Carpenter wrote: Yes, users need to configure our device via http, and if there's no well-known IPv6 address, how do users know which address to connect to? I have thought about a pre-configured link-local address; however, browsers such as Firefox does not support link-local address. Any suggestions? How come Firefox (or any other browser) knows how to *not* support link-local addresses? As far as I can tell, it does support them. Just don't forget the [ ] brackets. When I tell Firefox to connect to http://[fe80::1 ]/ it gives me an "unable to connect" message, but that's exactly what I'd expect. When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5 = ]/ (my own link-local address) it gives me a "server not found" message, which is also exactly what I'd expect, since I'm not listening on port 80. Brian --_000_C3CD347436D8davidconradicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fwd: Re: About IPv6 private address] C= hristian,

Just to be sure I understand, you’re saying Microsoft has introduced = something in Vista that looks a whole lot like a domain name in VeriSign= 217;s .NET domain namespace but that isn’t really a domain name to de= al with some applications that had trouble dealing with IPv6 literals?

Thanks,
-drc

On 2/4/08 8:49 PM, "Christian Huitema" <huitema@windows.micros= oft.com> wrote:

Firefox d= oes not do anything there. The name resolution service in Windows Vista res= olves names of the form fe80--213-49ff-fe04-507s8.ipv6-literal.net into the correspond= ing IPv6 address, in that example [fe80::213:49ff:fe04:507%8]. For Firefox,= it is just a name lookup.
We put that feature in Vista because some applications had a very hard time= parsing colons and percent signs. It really is a work around…
 

From: blue = [mailto:susan.lan@zyxel.com.tw]<= /a>
Sent: Monday, February 04, 2008 7:15 PM
To: Christian Huitema
Cc: Brian E Carpenter; v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About IPv6 private address]
Dear Christian:

Do you mean Firefox on Vista will translate the link-local address to the d= omain name suffixed "ipv6-literal.net"?

Currently my platform is Microsoft Windows XP instead of Windows Vista. How= ever, I don't consider this behavior is related to the OS version.

Which version is your Firefox, please?

Thanks.
BR,
Yi-Wen

Christian Huitema wrote:
If you are run= ning Firefox on Windows Vista, you should be able to try http://fe80--213-49ff-fe04-507= s8.ipv6-literal.net/
 
 

From: owner= -v6ops@ops.ietf.org [mailto:ow= ner-v6ops@ops.ietf.org] On Behalf Of blue
Sent: Monday, February 04, 2008 5:34 PM
To: Brian E Carpenter
Cc: v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About IPv6 private address]
Please forgive my dumbness but my Firefox version is 2.0.0.9

My IE could not connect to IPv6 URL either! (IE version 6.0)

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote:
That is a Firefox configuration issue, I think. I do= n't see that
problem (with Firefix 2.0.0.7, or with IE).
 
Is it possible that your browser is going to a proxy?
 
   Brian
 
On 2008-02-05 13:24, blue wrote:
  
<http://www.fe80::2= 13:49ff:fe04:507%258.com> "
 
It translated typed "ht= tp://[fe80::213:49ff:fe04:507%8]" <http://%5Bfe80::213:49ff:fe04:507%258%5D> &= nbsp;to
"http://[www.f= e80::213:49ff:fe04:507%8.com]/" <http://%5Bwww.fe80::213:49ff:fe04:507%258.c= om%5D/> .
 
However, a global unique IPv6 address worked!
 
I thought it proved that Firefox does not support link-local address.
 
Thanks.
BR,
Yi-Wen
 
Brian E Carpenter wrote:
 
    
<= FONT FACE=3D"Courier New">Yes, users need = to configure our device via http, and if there's no
well-known IPv6 address, how do users know which address to connect to?
I have thought about a pre-configured link-local address; however,
browsers such as Firefox does not support link-local address. Any
suggestions?
    
          
How come Firefox (or any = other browser) knows how to *not* support
link-local addresses? As far as I can tell, it does support them.
Just don't forget the [ ] brackets.
 
When I tell Firefox to connect to http://[fe80:= :1 <http://%5Bfe80::1> ]/ it gi= ves me
an "unable to connect" message, but that's exactly what I'd expec= t.
When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5 <http://%5Bfe80::21a:a0ff:fe4a:d680%255> ]/<= BR> (my own link-local address) it gives me a "server not found" mess= age,
which is also exactly what I'd expect, since I'm not listening on
port 80.
 
   Brian
 
 
 
      

    

  
 


 --_000_C3CD347436D8davidconradicannorg_-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:36:53 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4F6873A7A60; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 349773A719C for ; Mon, 4 Feb 2008 13:44:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM94n-000OgB-GB for v6ops-data@psg.com; Mon, 04 Feb 2008 21:42:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM94i-000Of6-3x for v6ops@ops.ietf.org; Mon, 04 Feb 2008 21:42:04 +0000 Received: from [199.212.90.28] (helo=yxu1b28.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM94d-000GyT-9c; Mon, 04 Feb 2008 21:41:55 +0000 Cc: james woodyatt , v6ops Operations Message-Id: <390707A4-CB01-4D2F-88DB-ABC716417D15@ca.afilias.info> From: Joe Abley To: Mark Smith In-Reply-To: <20080205064732.419415a3.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 16:41:54 -0500 References: <47A6C235.1070904@zyxel.com.tw> <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> <20080205064732.419415a3.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 4-Feb-2008, at 15:17, Mark Smith wrote: > Well, not everybody has or will have Apples, so they won't have > Bonjour > aware clients/browsers. There does need to be alternative methods. As far as I know, though, Bonjour isn't limited to Apple devices. It's definitely available on free *ix platforms (and I say "definitely" because I've used it) and apparently available on Windows too ("apparently" because I have not had a reason to use Windows since about 1995). So it doesn't seem reasonable to discount this as a reasonable mechanism on the grounds that "not everybody uses Apple products". Joe From edwina8campbell@hotmail.com Tue Feb 5 10:36:57 2008 Return-Path: X-Original-To: v6ops-archive@megatron.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id BF1363A6B9C; Tue, 5 Feb 2008 10:53:00 -0800 (PST) Received: from e179250209.adsl.alicedsl.de (e179250209.adsl.alicedsl.de [85.179.250.209]) by mail.ietf.org (Postfix) with SMTP id A7E6B28C8D0; Tue, 5 Feb 2008 05:56:15 -0800 (PST) Received: from 144.92.56.152 by 85.179.250.209; Tue, 05 Feb 2008 16:51:41 +0300 Message-ID: From: "Deloris Hawkins" Reply-To: "Deloris Hawkins" To: atompub-archive@megatron.ietf.org Subject: Repl1ca watch is a perfect gift! Date: Tue, 05 Feb 2008 08:58:41 -0500 MIME-Version: 1.0 Newest 2008 repl1ca watch3s collection! 15% off in February and huge choose of repl1cas! http://www.oisoiske.com/ From _procomba@TRS.STATE.VA.US Tue Feb 5 10:37:23 2008 Return-Path: <_procomba@TRS.STATE.VA.US> X-Original-To: v6ops-archive@megatron.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E77A73A945D; Tue, 5 Feb 2008 10:52:53 -0800 (PST) Received: from [121.139.162.40] (unknown [121.139.162.40]) by mail.ietf.org (Postfix) with ESMTP id 915613A812F for ; Mon, 4 Feb 2008 19:32:12 -0800 (PST) Message-ID: <000b01c867a7$c9a963a0$28a28b79@maincom> From: "Jimin Clingan" <_procomba@TRS.STATE.VA.US> To: v6ops-archive@megatron.ietf.org Subject: Satisfy your chick's inner desires by clicking here. Date: Tue, 5 Feb 2008 12:32:52 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C867F3.39910BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0007_01C867F3.39910BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Be the Ladies' choice with your brand new big d-!ck. ----------=_NextPart_000_0007_01C867F3.39910BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Be the Ladies' choice with your = brand new=20 big d-!ck. ----------=_NextPart_000_0007_01C867F3.39910BA0-- From interviewss9@wqsn.com Tue Feb 5 10:38:19 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A97833A6C06; Tue, 5 Feb 2008 10:38:01 -0800 (PST) Received: from privat-aafb4af8.dzcmts001-cpe-001.datazug.ch (pub082136077122.dh-hfc.datazug.ch [82.136.77.122]) by mail.ietf.org (Postfix) with ESMTP id DD5CA28D71C for ; Tue, 5 Feb 2008 09:09:41 -0800 (PST) Received: from [82.136.77.122] by mail.mwcradio.com; Tue, 5 Feb 2008 18:11:14 +0100 From: "Lorrie Campbell" To: Subject: Queen-sizeErectileorganJohnie Date: Tue, 5 Feb 2008 18:11:14 +0100 Message-ID: <01c86822$7e778d00$7a4d8852@interviewss9> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal ReynaOversizeErectileorgan http://www.glaityes.com From owner-v6ops@ops.ietf.org Tue Feb 5 10:39:02 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 1C7DE28C8B7; Tue, 5 Feb 2008 10:53:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id A33723A8DAD for ; Tue, 5 Feb 2008 00:00:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMIck-000MpL-NM for v6ops-data@psg.com; Tue, 05 Feb 2008 07:53:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMIci-000Mp0-2t for v6ops@ops.ietf.org; Tue, 05 Feb 2008 07:53:45 +0000 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 4 Feb 2008 23:53:43 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.1.240.5; Mon, 4 Feb 2008 23:53:43 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Mon, 4 Feb 2008 23:53:43 -0800 From: Christian Huitema To: Remi Denis-Courmont , Nathan Ward CC: v6ops WG Date: Mon, 4 Feb 2008 23:53:42 -0800 Subject: RE: About IPv6 private address Thread-Topic: About IPv6 private address Thread-Index: AchnyL07g+mcHjtzRkC3ilGqscZLKwAAvyMg Message-ID: References: <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk PiBPbmUgY29tcGxhaW50IEkgaGF2ZSBoZWFyZCBzZXZlcmFsIHRpbWUgaXMsIHRoZSBub3RhdGlv biBpcyBtZXJlbHkgYSBkZQ0KPiBmYWN0byBzdGFuZGFyZCBleHRlbnNpb24gb2YgZ2V0YWRkcmlu Zm8gZXQgYWwuIEFsc28sIGFzIGZhciBhcyBJIGtub3csDQo+IFdpbmRvd3MgZG9lcyBub3QgaW1w bGVtZW50IGl0IGFuZCBmb3IgYSByZWFzb246DQo+DQo+IGZlODA6OjIxNjo0MWZmOmZlZTE6Yjdm ZCUiTmV0d29yayBBZGFwdGVyIiB3b3VsZCBub3QgYmUgdmVyeSBjb252ZW5pZW50DQo+IGFuZA0K PiBmZTgwOjoyMTY6NDFmZjpmZWUxOmI3ZmQlMSAoaWYgMSBpcyB0aGUgc2NvcGUgSUQgaXMgbm90 IHZlcnkNCj4gbWVhbmluZ2Z1bCkuDQoNCldoZXJlIGRpZCB5b3UgZ2V0IHRoYXQgbm90aW9uPyBT aXR0aW5nIGluIG15IGhvbWUgbmV0d29yaywgbXkgbGFwdG9wIGNhbiBlYXNpbHkgcGluZyBhbm90 aGVyIGNvbXB1dGVyIGluIHRoZSBzYW1lIG5ldHdvcmssIGFzIGluOg0KDQpDOlxVc2Vyc1xodWl0 ZW1hPnBpbmcgZmxvY29uDQoNClBpbmdpbmcgZmxvY29uIFtmZTgwOjpkNTE1OmM0Mzg6Zjg4MDo4 NWYyJTEzXSBmcm9tIGZlODA6OjMwMmY6MzU4YjoxNGYyOmM3OGQlMTMNCndpdGggMzIgYnl0ZXMg b2YgZGF0YToNClJlcGx5IGZyb20gZmU4MDo6ZDUxNTpjNDM4OmY4ODA6ODVmMiUxMzogdGltZT0x bXMNClJlcGx5IGZyb20gZmU4MDo6ZDUxNTpjNDM4OmY4ODA6ODVmMiUxMzogdGltZT0xbXMNClJl cGx5IGZyb20gZmU4MDo6ZDUxNTpjNDM4OmY4ODA6ODVmMiUxMzogdGltZTwxbXMNClJlcGx5IGZy b20gZmU4MDo6ZDUxNTpjNDM4OmY4ODA6ODVmMiUxMzogdGltZTwxbXMNCg0KUGluZyBzdGF0aXN0 aWNzIGZvciBmZTgwOjpkNTE1OmM0Mzg6Zjg4MDo4NWYyJTEzOg0KICAgIFBhY2tldHM6IFNlbnQg PSA0LCBSZWNlaXZlZCA9IDQsIExvc3QgPSAwICgwJSBsb3NzKSwNCkFwcHJveGltYXRlIHJvdW5k IHRyaXAgdGltZXMgaW4gbWlsbGktc2Vjb25kczoNCiAgICBNaW5pbXVtID0gMG1zLCBNYXhpbXVt ID0gMW1zLCBBdmVyYWdlID0gMG1zDQoNCk5hbWUgcmVzb2x1dGlvbiBpcyBwZXJmb3JtZWQgdXNp bmcgTExNTlIsIHJldHVybmluZyBJUHY2IGxvY2FsIGFkZHJlc3Nlcy4gU2ltcGxlIGFuZCBlYXN5 Lg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg== From naipaullz3@bikeglo.com Tue Feb 5 10:43:00 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3719F3A7EB8; Tue, 5 Feb 2008 10:53:04 -0800 (PST) Received: from h-67-102-90-13.nycmny83.covad.net (h-67-102-90-13.nycmny83.covad.net [67.102.90.13]) by mail.ietf.org (Postfix) with ESMTP id 022CA3A8326 for ; Mon, 4 Feb 2008 20:25:00 -0800 (PST) Received: from [67.102.90.13] by smtp.secureserver.net; Mon, 4 Feb 2008 23:26:35 -0500 From: "Ellen Mckay" To: Subject: BodypartPuffyGale Date: Mon, 4 Feb 2008 23:26:35 -0500 Message-ID: <01c86785$61d94780$0d5a6643@naipaullz3> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal BodypartImportantMilo http://www.glaityes.com From Zhengkan-pointees@Draexlmaier.de Tue Feb 5 10:43:02 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 2B7F03A74F8; Tue, 5 Feb 2008 10:53:04 -0800 (PST) Received: from [211.205.50.163] (unknown [211.205.50.163]) by mail.ietf.org (Postfix) with ESMTP id 0661A3A8A3E for ; Mon, 4 Feb 2008 23:04:56 -0800 (PST) Message-ID: <000c01c867c5$a2d70d40$a332cdd3@35> From: "Zhengkan mccabe" To: v6ops-archive@lists.ietf.org Subject: Blow your lady away with the largest d1ck she has seen in her life. Date: Tue, 5 Feb 2008 16:06:31 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C86811.12BEB540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0008_01C86811.12BEB540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gain several inches on your weener with this new medical discovery. ----------=_NextPart_000_0008_01C86811.12BEB540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gain several inches on your weener = with this=20 new medical discovery. ----------=_NextPart_000_0008_01C86811.12BEB540-- From jragland@fuse.net Tue Feb 5 10:43:05 2008 Return-Path: X-Original-To: v6ops-archive@megatron.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 68E9E3A68C9; Tue, 5 Feb 2008 10:52:54 -0800 (PST) Received: from genoyer.com (unknown [212.48.39.154]) by mail.ietf.org (Postfix) with SMTP id 14B693A8F87 for ; Tue, 5 Feb 2008 00:44:49 -0800 (PST) Received: from 216.68.8.214 (HELO mx4.fuse.net) by megatron.ietf.org with esmtp (EQEDLRPJG XSAAOK) id p8cCx-7vcdfu-EO for v6ops-archive@megatron.ietf.org; Tue, 05 Feb 2008 11:46:33 +0300 Message-ID: <000301c867d3$9c4ef600$c0a80113@Darrin> From: "Darrin K. Houston" To: "Eldon I. Christensen" Subject: Nice gifts for your dearest people on holidays! Date: Tue, 05 Feb 2008 11:46:33 +0300 MIME-Version: 1.0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable


----------------------
EMAIL ID: 6QfGK From ebonybeauty@sbcglobal.net Tue Feb 5 10:43:12 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id AE6213A6A43; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from cpe-071-071-008-031.triad.res.rr.com (cpe-071-071-008-031.triad.res.rr.com [71.71.8.31]) by mail.ietf.org (Postfix) with ESMTP id 362FB3A7303 for ; Mon, 4 Feb 2008 14:45:24 -0800 (PST) Message-ID: <000601c8677f$03192930$0a758995@vaehumk> From: "chanderjit michel" To: Subject: Proven effect on your boner! Date: Mon, 04 Feb 2008 20:59:41 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8677F.031455BC" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C8677F.031455BC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09The meds you need, reliable and hassle free!=20 =09Top products of top brands. Low pricing, discounts, flawless customer = support. =09Millions of customers just can't be wrong! =09thusstill.com =09 =20 ------=_NextPart_000_0003_01C8677F.031455BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=09

The meds = you need, reliable and hassle free!
=09Top products of top brands. Low pricing, discounts, flawless customer = support.
=20 =09Millions of customers just can't be wrong!

=09 =09
------=_NextPart_000_0003_01C8677F.031455BC-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:43:13 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C6D6D3A6FEF; Tue, 5 Feb 2008 10:37:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 1A57C3A93E7 for ; Tue, 5 Feb 2008 02:20:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMKoF-000GYe-CU for v6ops-data@psg.com; Tue, 05 Feb 2008 10:13:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [203.6.132.75] (helo=smtp1.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMKo8-000GXx-AP for v6ops@ops.ietf.org; Tue, 05 Feb 2008 10:13:44 +0000 Received: from 122-49-140-247.ip.adam.com.au ([122.49.140.247] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1JMKo3-000HOM-1K; Tue, 05 Feb 2008 20:43:35 +1030 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 534064571; Tue, 5 Feb 2008 20:43:34 +1030 (CST) Date: Tue, 5 Feb 2008 20:43:33 +1030 From: Mark Smith To: Joe Abley Cc: james woodyatt , v6ops Operations Subject: Re: About IPv6 private address Message-Id: <20080205204333.c359a34b.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <390707A4-CB01-4D2F-88DB-ABC716417D15@ca.afilias.info> References: <47A6C235.1070904@zyxel.com.tw> <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> <20080205064732.419415a3.ipng@69706e6720323030352d30312d31340a.nosense.org> <390707A4-CB01-4D2F-88DB-ABC716417D15@ca.afilias.info> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Joe, On Mon, 4 Feb 2008 16:41:54 -0500 Joe Abley wrote: > > On 4-Feb-2008, at 15:17, Mark Smith wrote: > > > Well, not everybody has or will have Apples, so they won't have > > Bonjour > > aware clients/browsers. There does need to be alternative methods. > > As far as I know, though, Bonjour isn't limited to Apple devices. It's > definitely available on free *ix platforms (and I say "definitely" > because I've used it) and apparently available on Windows too > ("apparently" because I have not had a reason to use Windows since > about 1995). > > So it doesn't seem reasonable to discount this as a reasonable > mechanism on the grounds that "not everybody uses Apple products". > I'm certainly not against it, just pointing out that unlike web browsers, bonjour clients aren't anywhere near as common, so it isn't quite yet a universal way of performing service discovery (and neither is SLP of course). Regards, Mark. From owner-v6ops@ops.ietf.org Tue Feb 5 10:44:00 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 0629E3A688B; Tue, 5 Feb 2008 10:52:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id E5B233A8000 for ; Mon, 4 Feb 2008 19:20:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMEH8-000Byb-FG for v6ops-data@psg.com; Tue, 05 Feb 2008 03:15:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTTP_ESCAPED_HOST,RDNS_NONE,URI_HEX,WEIRD_PORT autolearn=no version=3.2.3 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMEH5-000BwN-BN for v6ops@ops.ietf.org; Tue, 05 Feb 2008 03:15:09 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 11:14:37 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 11:14:37 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 11:14:36 +0800 Message-ID: <47A7D49E.3060208@zyxel.com.tw> Date: Tue, 05 Feb 2008 11:14:38 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Brian E Carpenter , "v6ops@ops.ietf.org" Subject: Re: [Fwd: Re: About IPv6 private address] References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> <47A7B6C4.4050801@gmail.com> <47A7BCFC.2040805@zyxel.com.tw> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040103020603090809030807" X-OriginalArrivalTime: 05 Feb 2008 03:14:36.0604 (UTC) FILETIME=[3CB85FC0:01C867A5] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040103020603090809030807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Christian: Do you mean Firefox on Vista will translate the link-local address to the domain name suffixed "ipv6-literal.net"? Currently my platform is Microsoft Windows XP instead of Windows Vista. However, I don't consider this behavior is related to the OS version. Which version is your Firefox, please? Thanks. BR, Yi-Wen Christian Huitema wrote: > If you are running Firefox on Windows Vista, you should be able to try > http://fe80--213-49ff-fe04-507s8.ipv6-literal.net/ > > > > > > *From:* owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] *On > Behalf Of *blue > *Sent:* Monday, February 04, 2008 5:34 PM > *To:* Brian E Carpenter > *Cc:* v6ops@ops.ietf.org > *Subject:* Re: [Fwd: Re: About IPv6 private address] > > > > Please forgive my dumbness but my Firefox version is 2.0.0.9 > > My IE could not connect to IPv6 URL either! (IE version 6.0) > > Thanks. > BR, > Yi-Wen > > Brian E Carpenter wrote: > >That is a Firefox configuration issue, I think. I don't see that > >problem (with Firefix 2.0.0.7, or with IE). > > > >Is it possible that your browser is going to a proxy? > > > > Brian > > > >On 2008-02-05 13:24, blue wrote: > > > >Hi, > >But after typing a link-local address, Firefox' message shows: > > > > Unable to find "www.fe80::213:49ff:fe04:507%8.com " > > > >It translated typed "http://[fe80::213:49ff:fe04:507%8]" to > >"http://[www.fe80::213:49ff:fe04:507%8.com]/" . > > > >However, a global unique IPv6 address worked! > > > >I thought it proved that Firefox does not support link-local address. > > > >Thanks. > >BR, > >Yi-Wen > > > >Brian E Carpenter wrote: > > > > > >Yes, users need to configure our device via http, and if there's no > >well-known IPv6 address, how do users know which address to connect to? > >I have thought about a pre-configured link-local address; however, > >browsers such as Firefox does not support link-local address. Any > >suggestions? > > > > > >How come Firefox (or any other browser) knows how to *not* support > >link-local addresses? As far as I can tell, it does support them. > >Just don't forget the [ ] brackets. > > > >When I tell Firefox to connect to http://[fe80::1 ]/ it gives me > >an "unable to connect" message, but that's exactly what I'd expect. > >When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5 ]/ > >(my own link-local address) it gives me a "server not found" message, > >which is also exactly what I'd expect, since I'm not listening on > >port 80. > > > > Brian > > > > > > > > > > > > > > > > > > > --------------040103020603090809030807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear Christian:

Do you mean Firefox on Vista will translate the link-local address to the domain name suffixed "ipv6-literal.net"?

Currently my platform is Microsoft Windows XP instead of Windows Vista. However, I don't consider this behavior is related to the OS version.

Which version is your Firefox, please?

Thanks.
BR,
Yi-Wen

Christian Huitema wrote:

If you are running Firefox on Windows Vista, you should be able to try http://fe80--213-49ff-fe04-507s8.ipv6-literal.net/

 

 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of blue
Sent: Monday, February 04, 2008 5:34 PM
To: Brian E Carpenter
Cc: v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About IPv6 private address]

 

Please forgive my dumbness but my Firefox version is 2.0.0.9

My IE could not connect to IPv6 URL either! (IE version 6.0)

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote: 

That is a Firefox configuration issue, I think. I don't see that
problem (with Firefix 2.0.0.7, or with IE).
 
Is it possible that your browser is going to a proxy?
 
   Brian
 
On 2008-02-05 13:24, blue wrote:
  
Hi,
But after typing a link-local address, Firefox' message shows:
 
   Unable to find "www.fe80::213:49ff:fe04:507%8.com"
 
It translated typed "http://[fe80::213:49ff:fe04:507%8]" to
"http://[www.fe80::213:49ff:fe04:507%8.com]/".
 
However, a global unique IPv6 address worked!
 
I thought it proved that Firefox does not support link-local address.
 
Thanks.
BR,
Yi-Wen
 
Brian E Carpenter wrote:
 
    
Yes, users need to configure our device via http, and if there's no
well-known IPv6 address, how do users know which address to connect to?
I have thought about a pre-configured link-local address; however,
browsers such as Firefox does not support link-local address. Any
suggestions?
    
          
How come Firefox (or any other browser) knows how to *not* support
link-local addresses? As far as I can tell, it does support them.
Just don't forget the [ ] brackets.
 
When I tell Firefox to connect to http://[fe80::1]/ it gives me
an "unable to connect" message, but that's exactly what I'd expect.
When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/
(my own link-local address) it gives me a "server not found" message,
which is also exactly what I'd expect, since I'm not listening on
port 80.
 
   Brian
 
 
 
      
 
    
 
 

 


--------------040103020603090809030807-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:44:42 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 7BFE23A7838; Tue, 5 Feb 2008 10:37:52 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 3A82C3A6953 for ; Tue, 5 Feb 2008 04:40:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMN03-0009PV-Sd for v6ops-data@psg.com; Tue, 05 Feb 2008 12:34:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMN00-0009Oz-MJ for v6ops@ops.ietf.org; Tue, 05 Feb 2008 12:34:06 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m15CXNIf023228; Tue, 5 Feb 2008 14:33:59 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 14:33:38 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 14:33:38 +0200 Received: from [10.183.129.146] (daec-linuxvpn05922.americas.nokia.com [10.241.59.22]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m15CXY89001192; Tue, 5 Feb 2008 14:33:36 +0200 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74BB1623-BB2B-44B3-BA21-3F22ABADCCA4@nokia.com> Reply-To: bob.hinden@nokia.com Content-Transfer-Encoding: 7bit From: Bob Hinden Subject: IPv6 Address Added for Root Servers in the Root Zone Date: Tue, 5 Feb 2008 14:33:33 +0200 To: IETF IPv6 Mailing List , IPv6 Operations X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 05 Feb 2008 12:33:38.0049 (UTC) FILETIME=[54FAB710:01C867F3] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI: http://www.icann.org/announcements/announcement-04feb08.htm Bob From owner-v6ops@ops.ietf.org Tue Feb 5 10:46:23 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D97C23A7871; Tue, 5 Feb 2008 10:37:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id AA9513A794C for ; Mon, 4 Feb 2008 17:10:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCHV-000MGI-Ly for v6ops-data@psg.com; Tue, 05 Feb 2008 01:07:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, WEIRD_PORT autolearn=no version=3.2.3 Received: from [64.233.178.247] (helo=hs-out-2122.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCHT-000MFs-6h for v6ops@ops.ietf.org; Tue, 05 Feb 2008 01:07:24 +0000 Received: by hs-out-2122.google.com with SMTP id x43so2529938hsb.9 for ; Mon, 04 Feb 2008 17:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=XYbii/3wu+8UBoT4jIYIbYROt2rr3/r/vFiSm8yL3PU=; b=JaO+pjXoLvWPMVGOuZoNINL7eSCH3jpySMJKPjSRcHQck1hWeBxra9gq9zdRYsT44lZ6e5bLYPD7pH3qhn7wjrX1sP/nN5nMgo2AaOVTHtoI+Kw0/r1wmOOioKsVr4IlHvvrFeWnH0OHcCCwtcVKhFmtqX0/Mp3GTyXg2Qhn7yQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=vFlJQdERqENTKudeFcbxl2LqwDl/dNk0uYDKZj9jaFkhoRddZfp9yadBzWwvHPFxppG+M9kvytcMUIeqex6t+SHRMCe+DAHOFsmwI9Bih6cE+1Jp+qp8qFlve1aORGjnaFD1saRWBhaUhPLv/+/XGeJ+d9QUK9sbN1gLEFolsyk= Received: by 10.141.169.9 with SMTP id w9mr5191757rvo.179.1202173641162; Mon, 04 Feb 2008 17:07:21 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id 3sm5924807rvi.14.2008.02.04.17.07.19 (version=SSLv3 cipher=RC4-MD5); Mon, 04 Feb 2008 17:07:20 -0800 (PST) Message-ID: <47A7B6C4.4050801@gmail.com> Date: Tue, 05 Feb 2008 14:07:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: blue CC: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> In-Reply-To: <47A7ACA4.9040009@zyxel.com.tw> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk That is a Firefox configuration issue, I think. I don't see that problem (with Firefix 2.0.0.7, or with IE). Is it possible that your browser is going to a proxy? Brian On 2008-02-05 13:24, blue wrote: > Hi, > But after typing a link-local address, Firefox' message shows: > > Unable to find "www.fe80::213:49ff:fe04:507%8.com" > > It translated typed "http://[fe80::213:49ff:fe04:507%8]" to > "http://[www.fe80::213:49ff:fe04:507%8.com]/". > > However, a global unique IPv6 address worked! > > I thought it proved that Firefox does not support link-local address. > > Thanks. > BR, > Yi-Wen > > Brian E Carpenter wrote: > >>>> Yes, users need to configure our device via http, and if there's no >>>> well-known IPv6 address, how do users know which address to connect to? >>>> I have thought about a pre-configured link-local address; however, >>>> browsers such as Firefox does not support link-local address. Any >>>> suggestions? >>>> >> >> How come Firefox (or any other browser) knows how to *not* support >> link-local addresses? As far as I can tell, it does support them. >> Just don't forget the [ ] brackets. >> >> When I tell Firefox to connect to http://[fe80::1]/ it gives me >> an "unable to connect" message, but that's exactly what I'd expect. >> When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/ >> (my own link-local address) it gives me a "server not found" message, >> which is also exactly what I'd expect, since I'm not listening on >> port 80. >> >> Brian >> >> >> > > From illinois819@vikingengineering.net Tue Feb 5 10:46:47 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 541B63A6E0E; Tue, 5 Feb 2008 10:38:00 -0800 (PST) Received: from your-4dacd0ea75.cable.net.co (unknown [190.156.173.3]) by mail.ietf.org (Postfix) with ESMTP id 7354B3A8333 for ; Mon, 4 Feb 2008 20:26:12 -0800 (PST) Received: from [190.156.173.3] by mxmail.register.com; Mon, 4 Feb 2008 23:27:47 -0500 From: "Horacio Nance" To: Subject: TanyaPhallusTitanic Date: Mon, 4 Feb 2008 23:27:47 -0500 Message-ID: <01c86785$8cc39b80$03ad9cbe@illinois819> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 Importance: Normal ErectileorganBiggerDerrick http://www.cbcxbxv.com From owner-v6ops@ops.ietf.org Tue Feb 5 10:47:02 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D803F3A7298; Tue, 5 Feb 2008 11:02:46 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id F1FAE3A8BF5 for ; Mon, 4 Feb 2008 23:23:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMI43-000IB5-9P for v6ops-data@psg.com; Tue, 05 Feb 2008 07:17:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMI40-000IAa-LA for v6ops@ops.ietf.org; Tue, 05 Feb 2008 07:17:54 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 6C2BFC97; Tue, 5 Feb 2008 08:18:54 +0100 (CET) To: Nathan Ward Subject: Re: About IPv6 private address MIME-Version: 1.0 Date: Tue, 5 Feb 2008 08:18:54 +0100 From: Remi Denis-Courmont Cc: v6ops WG Organization: Remlab.net In-Reply-To: <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> References: <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 5 Feb 2008 10:19:30 +1300, Nathan Ward wrote: > Longer term, it seems as though applications should support link local > addresses. Has there been any documentation that disagrees with that? > Safari reports link local addresses with the interface specified as > being invalid (ie. %en1 at the end = 'invalid'). One complaint I have heard several time is, the notation is merely a de facto standard extension of getaddrinfo et al. Also, as far as I know, Windows does not implement it and for a reason: fe80::216:41ff:fee1:b7fd%"Network Adapter" would not be very convenient and fe80::216:41ff:fee1:b7fd%1 (if 1 is the scope ID is not very meaningful). In any case, while applications should try to support these addresses, we need to keep in mind that: - the scope ID depends is hardware- and OS-dependant, if not boot sequence dependant, hence cannot be used in a "for-dummies" documentation, - application that rely on inet_pton(), inet_ntop() - and there may be valid reasons - are kinda screwed, - the scope being system-specific, cannot be exchanged accross the network: think HTML hyperlinks, SDP c= lines, FTP control connection... and most importantly DNS AAAA queries, so they are off limited practical usability in any case. I really think a home gateway ought to provide a ULA prefix, at least if it cannot get any valid prefix from its upstream. -- Rémi Denis-Courmont http://www.remlab.net From Grayson-sucsinap@2fatcats.co.uk Tue Feb 5 10:47:09 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D05B33A6D14; Tue, 5 Feb 2008 10:53:01 -0800 (PST) Received: from client-201.240.143.116.speedy.net.pe (unknown [201.240.143.116]) by mail.ietf.org (Postfix) with ESMTP id A000E28C8F9 for ; Tue, 5 Feb 2008 05:57:59 -0800 (PST) Message-ID: <001201c867ff$55a4e350$748ff0c9@ONLINE> From: "Grayson Kononin" To: v6ops-archive@lists.ietf.org Subject: Incredible, permanant gains on your manhood can be yours, with this simple solution Date: Tue, 5 Feb 2008 08:59:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C867D5.6CCEDB50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000E_01C867D5.6CCEDB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Love her the right way, the hard way - the LONG AND DEEP way. ----------=_NextPart_000_000E_01C867D5.6CCEDB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Love her the right way, the hard = way - the=20 LONG AND DEEP way. ----------=_NextPart_000_000E_01C867D5.6CCEDB50-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:47:35 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 403C03A6F41; Tue, 5 Feb 2008 10:37:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 863E03A8F42 for ; Tue, 5 Feb 2008 00:40:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMJH7-0002WM-Pk for v6ops-data@psg.com; Tue, 05 Feb 2008 08:35:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMJGy-0002VX-1e for v6ops@ops.ietf.org; Tue, 05 Feb 2008 08:35:25 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id E9FD18480A; Tue, 5 Feb 2008 09:35:17 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7RJGr8UKlG1U; Tue, 5 Feb 2008 09:35:11 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 7C6218476A; Tue, 5 Feb 2008 09:35:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 7B30084480; Tue, 5 Feb 2008 09:35:11 +0100 (CET) Date: Tue, 5 Feb 2008 09:35:11 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Nathan Ward cc: v6ops WG Subject: Re: About IPv6 private address In-Reply-To: <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> Message-ID: <20080205092328.E37738@mignon.ki.iif.hu> References: <47A67FAD.1030803@zyxel.com.tw> <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 5 Feb 2008, Nathan Ward wrote: > On 4/02/2008, at 3:59 PM, blue wrote: > >> Hi, >> >> I want to ask if there's any reserved private IPv6 address? I know RFC4193 >> has defined Unique Local IPv6 Unicast Addresses, which is used to replace >> deprecated site-local address. However, in user's perspective, a device >> will need a well-known address, such as 192.168.1.1 in IPv4, for a customer >> to connect to without any configuration. In RFC 4193, the address' "global >> ID" is generated randomly, and the address could not be known in advance. >> >> After examing all the special purposed IPv6 address, I could not find one >> for this kind of purpose. > > My opinions; > > Longer term, it seems as though applications should support link local > addresses. Has there been any documentation that disagrees with that? Safari > reports link local addresses with the interface specified as being invalid > (ie. %en1 at the end = 'invalid'). This would rather confusing to users: "server is reachable via fe80::123:45ff:fe67:89ab%eth0, if you use Linux with one ethernet interface" "server is reachable via fe80::123:45ff:fe67:89ab%en0, if you use MacOS X" "server is reachable via fe80::123:45ff:fe67:89ab%en1, if you use MacOS X with wireless" "server is reachable via fe80::123:45ff:fe67:89ab%fxp0, if you use *BSD with Intel card" etc. I think link-local on the user side can be used for communication: - for diagnostic purpose - for administrative purpose - for users if link-local address discoverd automaticaly and they don't have to type in. Administrators can cope with Ethernet interface name or number, but you cannot expect this from ordinary users. Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Feb 5 10:47:36 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D779F3A77E8; Tue, 5 Feb 2008 10:38:04 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 0E4983A8F49 for ; Tue, 5 Feb 2008 00:41:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMJKa-00031M-F6 for v6ops-data@psg.com; Tue, 05 Feb 2008 08:39:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMJKX-00030u-J8 for v6ops@ops.ietf.org; Tue, 05 Feb 2008 08:39:03 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 98FA8CA4; Tue, 5 Feb 2008 09:40:03 +0100 (CET) To: Christian Huitema Subject: RE: About IPv6 private address MIME-Version: 1.0 Date: Tue, 5 Feb 2008 09:40:03 +0100 From: Remi Denis-Courmont Cc: Nathan Ward , v6ops WG Organization: Remlab.net In-Reply-To: References: Message-ID: <15a971bf27abd272f26a096d3c93977b@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 4 Feb 2008 23:53:42 -0800, Christian Huitema wrote: >> One complaint I have heard several time is, the notation is merely a de >> facto standard extension of getaddrinfo et al. Also, as far as I know, >> Windows does not implement it and for a reason: >> >> fe80::216:41ff:fee1:b7fd%"Network Adapter" would not be very convenient >> and >> fe80::216:41ff:fee1:b7fd%1 (if 1 is the scope ID is not very >> meaningful). > > Where did you get that notion? The full Windows name of a network device, while it makes more sense to normal people, is too long to fit after the percent sign. I know what my Windows box "Ethernet adapter Local Area Connection", and, because I am Linux-literate, I know what my Linux box "eth0" is. As it happens, I don't know the corresponding numerical scope/interface identifier of either of them. fe80::216:41ff:fee1:b7fd%eth0 means something to me. fe80::216:41ff:fee1:b7fd%"Ethernet adapter Local Area Connection" would mean something to me, albeit it would obviously be too long for practical purposes. But fe80::216:41ff:fee1:b7fd%13 - hmm? sorry but I don't know which interface 13 might be. It does not "talk" to me. -- Rémi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Tue Feb 5 10:48:01 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A62D53A6C85; Tue, 5 Feb 2008 10:38:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id D071F3A87CD for ; Mon, 4 Feb 2008 22:17:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMH34-0009Yc-Sm for v6ops-data@psg.com; Tue, 05 Feb 2008 06:12:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE, HTTP_ESCAPED_HOST,RDNS_NONE,URI_HEX,WEIRD_PORT autolearn=no version=3.2.3 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMH2v-0009Xy-9r for v6ops@ops.ietf.org; Tue, 05 Feb 2008 06:12:44 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 4 Feb 2008 22:12:40 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.1.240.5; Mon, 4 Feb 2008 22:12:40 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Mon, 4 Feb 2008 22:12:40 -0800 From: Christian Huitema To: David Conrad , blue CC: Brian E Carpenter , "v6ops@ops.ietf.org" Date: Mon, 4 Feb 2008 22:12:37 -0800 Subject: RE: [Fwd: Re: About IPv6 private address] Thread-Topic: [Fwd: Re: About IPv6 private address] Thread-Index: AchnpVQJ5QZ8/gHtQ32HvXHcvHoS4AADLDCwAAGMoq4AAQjJcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674CANAEXMSGW602wi_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674CANAEXMSGW602wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, the "ipv6-literal.net" domain is properly registered and all that= , so it really is a "Microsoft managed subdomain". But yes, this is a work = around for the applications that have trouble parsing IPv6 literals. There = is an example of using it for sharing files using IPv6 literal addresses at= http://support.microsoft.com/kb/944007. The mechanism is described at http= ://technet.microsoft.com/en-us/library/bb726965.aspx, look for "Support for= ipv6-literal.net Names". From: David Conrad [mailto:david.conrad@icann.org] Sent: Monday, February 04, 2008 9:30 PM To: Christian Huitema; blue Cc: Brian E Carpenter; v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Christian, Just to be sure I understand, you're saying Microsoft has introduced someth= ing in Vista that looks a whole lot like a domain name in VeriSign's .NET d= omain namespace but that isn't really a domain name to deal with some appli= cations that had trouble dealing with IPv6 literals? Thanks, -drc On 2/4/08 8:49 PM, "Christian Huitema" wrot= e: Firefox does not do anything there. The name resolution service in Windows = Vista resolves names of the form fe80--213-49ff-fe04-507s8.ipv6-literal.net= into the corresponding IPv6 address, in that example [fe80::213:49ff:fe04:= 507%8]. For Firefox, it is just a name lookup. We put that feature in Vista because some applications had a very hard time= parsing colons and percent signs. It really is a work around... From: blue [mailto:susan.lan@zyxel.com.tw] Sent: Monday, February 04, 2008 7:15 PM To: Christian Huitema Cc: Brian E Carpenter; v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Dear Christian: Do you mean Firefox on Vista will translate the link-local address to the d= omain name suffixed "ipv6-literal.net"? Currently my platform is Microsoft Windows XP instead of Windows Vista. How= ever, I don't consider this behavior is related to the OS version. Which version is your Firefox, please? Thanks. BR, Yi-Wen Christian Huitema wrote: If you are running Firefox on Windows Vista, you should be able to try http= ://fe80--213-49ff-fe04-507s8.ipv6-literal.net/ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of blue Sent: Monday, February 04, 2008 5:34 PM To: Brian E Carpenter Cc: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] Please forgive my dumbness but my Firefox version is 2.0.0.9 My IE could not connect to IPv6 URL either! (IE version 6.0) Thanks. BR, Yi-Wen Brian E Carpenter wrote: That is a Firefox configuration issue, I think. I don't see that problem (with Firefix 2.0.0.7, or with IE). Is it possible that your browser is going to a proxy? Brian On 2008-02-05 13:24, blue wrote: Hi, But after typing a link-local address, Firefox' message shows: Unable to find "www.fe80::213:49ff:fe04:507%8.com " It translated typed "http://[fe80::213:49ff:fe04:507%8]" to "http://[www.fe80::213:49ff:fe04:507%8.com]/" . However, a global unique IPv6 address worked! I thought it proved that Firefox does not support link-local address. Thanks. BR, Yi-Wen Brian E Carpenter wrote: Yes, users need to configure our device via http, and if there's no well-known IPv6 address, how do users know which address to connect to? I have thought about a pre-configured link-local address; however, browsers such as Firefox does not support link-local address. Any suggestions? How come Firefox (or any other browser) knows how to *not* support link-local addresses? As far as I can tell, it does support them. Just don't forget the [ ] brackets. When I tell Firefox to connect to http://[fe80::1 ]/ it gives me an "unable to connect" message, but that's exactly what I'd expect. When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5 ]/ (my own link-local address) it gives me a "server not found" message, which is also exactly what I'd expect, since I'm not listening on port 80. Brian --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674CANAEXMSGW602wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Fwd: Re: About IPv6 private address]

Actually, the “ipv6-literal.net” domain is properly registered and all th= at, so it really is a “Microsoft managed subdomain”. But yes, this = is a work around for the applications that have trouble parsing IPv6 literals. T= here is an example of using it for sharing files using IPv6 literal addresses at= http://support.microsoft.co= m/kb/944007. The mechanism is described at http://te= chnet.microsoft.com/en-us/library/bb726965.aspx, look for “Support for ipv6-literal.net Names”.

 

From:= David Conrad [mailto:david.conrad@icann.org]
Sent: Monday, February 04, 2= 008 9:30 PM
To: Christian Huitema; blue<= br> Cc: Brian E Carpenter; v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About= IPv6 private address]

 

Christian,

Just to be sure I understand, you’re saying Microsoft has introduced something in Vista that looks a whole lot like a domain name in VeriSign’s .NET domain namespace but that isn’t really a domain name to deal with some applications that had trouble dealing with IPv6 literals?

Thanks,
-drc

On 2/4/08 8:49 PM, "Christian Huitema" <huitema@windows.microsoft.com> wrote:

Firefox does not do anything there. The name resolution service in Windows Vista resolves names of the form fe80--213-49ff-fe04-507s8.ipv6-literal.net into the corresponding IPv6 address, in that example [fe80::213:49ff:fe04:507%8]. Fo= r Firefox, it is just a name lookup.

We put that feature in Vista because some applications had a very hard time parsing colons and percent signs. It really is a work around…
 

From: blue [mailto:susan.lan@zyxel.com= .tw]
Sent: Monday, February 04, 2= 008 7:15 PM
To: Christian Huitema
Cc: Brian E Carpenter; v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About= IPv6 private address]

Dear Christian:

Do you mean Firefox on Vista will translate the link-local address to the domain name suffixed "ipv6-literal.net"?

Currently my platform is Microsoft Windows XP instead of Windows Vista. However, I don't consider this behavior is related to the OS version.

Which version is your Firefox, please?

Thanks.
BR,
Yi-Wen

Christian Huitema wrote:
If you are running Firefo= x on Windows Vista, you should be able to try http://fe80--21= 3-49ff-fe04-507s8.ipv6-literal.net/
 
 

From: owner-v6ops@ops.ietf.org [mail= to:owner-v6ops@ops.ietf.org] On Behalf Of blue
Sent: Monday, February 04, 2= 008 5:34 PM
To: Brian E Carpenter
Cc: v6ops@ops.ietf.org
Subject: Re: [Fwd: Re: About= IPv6 private address]

Please forgive my dumbness but my Firefox version is 2.0.0.9

My IE could not connect to IPv6 URL either! (IE version 6.0)

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote:
That is a Firefox configuration issue, I think. I don't see that
problem (with Firefix 2.0.0.7, or with IE).
 
Is it possible that your browser is going to a proxy?
 
   Brian
 
On 2008-02-05 13:24, blue wrote:
  

Hi,
But after typing a link-local address, Firefox' message shows:
 
   Unable to find "www.fe80::213:49ff:fe04:507%8.com <http://www.fe80::21= 3:49ff:fe04:507%258.com> "
 
It translated typed "= http://[fe80::213:49ff:fe04:507%8]" <http://%5Bfe80::21= 3:49ff:fe04:507%258%5D>  to
"http://[www= .fe80::213:49ff:fe04:507%8.com]/" <http://%5= Bwww.fe80::213:49ff:fe04:507%258.com%5D/> .
 
However, a global unique IPv6 address worked!
 
I thought it proved that Firefox does not support link-local address.
 
Thanks.
BR,
Yi-Wen
 
Brian E Carpenter wrote:
 
    

Yes, users need to configure our device via http= , and if there's no
well-known IPv6 address, how do users know which address to connect to?
I have thought about a pre-configured link-local address; however,
browsers such as Firefox does not support link-local address. Any
suggestions?
    
          <= o:p>

How come Firefox (or any other browser) knows ho= w to *not* support
link-local addresses? As far as I can tell, it does support them.
Just don't forget the [ ] brackets.
 
When I tell Firefox to connect to http://[fe80:= :1 <http://%5Bfe80::1> ]/ it gives me<= br> an "unable to connect" message, but that's exactly what I'd expec= t.
When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5 <http://%5Bfe80::21a:= a0ff:fe4a:d680%255> ]/
(my own link-local address) it gives me a "server not found" mess= age,
which is also exactly what I'd expect, since I'm not listening on
port 80.
 
   Brian
 
 
 
      


    


  

 

 

--_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674CANAEXMSGW602wi_-- From dmnck@adelphia.com Tue Feb 5 10:48:32 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4BC363A77F3; Tue, 5 Feb 2008 10:38:01 -0800 (PST) Received: from 201008073212.user.veloxzone.com.br (201008073212.user.veloxzone.com.br [201.8.73.212]) by mail.ietf.org (Postfix) with ESMTP id D69403A7301 for ; Mon, 4 Feb 2008 14:45:19 -0800 (PST) Message-ID: <000701c8677f$0668cfd8$7cbb1197@igygv> From: "giacopo marco" To: Subject: Large PE is not a dream anymore! Date: Mon, 04 Feb 2008 20:59:21 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8677F.0667530D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C8677F.0667530D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09The meds you need, reliable and hassle free!=20 =09Top products of top brands. Low pricing, discounts, flawless customer = support. =09Millions of customers just can't be wrong! =09thusstill.com =09 =20 ------=_NextPart_000_0004_01C8677F.0667530D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=09

The meds = you need, reliable and hassle free!
=09Top products of top brands. Low pricing, discounts, flawless customer = support.
=20 =09Millions of customers just can't be wrong!

=09 =09
------=_NextPart_000_0004_01C8677F.0667530D-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:48:54 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 84D843A7986; Tue, 5 Feb 2008 10:37:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id E9CDC3A715C for ; Mon, 4 Feb 2008 13:43:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM945-000OZt-Sr for v6ops-data@psg.com; Mon, 04 Feb 2008 21:41:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, WEIRD_PORT autolearn=no version=3.2.3 Received: from [209.85.198.187] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM943-000OZR-DT for v6ops@ops.ietf.org; Mon, 04 Feb 2008 21:41:20 +0000 Received: by rv-out-0910.google.com with SMTP id b22so2037311rvf.41 for ; Mon, 04 Feb 2008 13:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=x8tziVst/b3K66ppGRcBlsFu6+zFDNyc8b+lYiBYuhA=; b=QSmUzcxZSDnImfVrXUQzSog4qDQZpt7776FGmCqN6u98Kg76R2EXnNMuZmzB9aGERLYqur/6AOJuQngF4gnSd9Xnhgv3Z4Z/w1HyA3nDZeSskrERb5hOTHglg2qEaHEQzDxO42lzl7gLs3BdvooOleOj6Y/XT8H+oIzbSyVJI6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=u8DN/kuQnZEquN0sIMptCUOY0Y9rZchjlA6ySmaGtgqU4XADIeVWfJtl9+DlGVrk9mieLPKPVhrdfdpVA92CdRzX4Pzv9kTVvkyk1WhqY9pHsBmVqinhdQFNTs9R2cLnoC6i+SOKbCdnKogFMuN8YkHsXC7yIE33WxeklKaKxuw= Received: by 10.141.27.16 with SMTP id e16mr5058778rvj.259.1202161276734; Mon, 04 Feb 2008 13:41:16 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id c19sm834205rvf.30.2008.02.04.13.41.15 (version=SSLv3 cipher=RC4-MD5); Mon, 04 Feb 2008 13:41:15 -0800 (PST) Message-ID: <47A78679.8030202@gmail.com> Date: Tue, 05 Feb 2008 10:41:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: blue CC: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> In-Reply-To: <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> Yes, users need to configure our device via http, and if there's no >> well-known IPv6 address, how do users know which address to connect to? >> I have thought about a pre-configured link-local address; however, >> browsers such as Firefox does not support link-local address. Any >> suggestions? How come Firefox (or any other browser) knows how to *not* support link-local addresses? As far as I can tell, it does support them. Just don't forget the [ ] brackets. When I tell Firefox to connect to http://[fe80::1]/ it gives me an "unable to connect" message, but that's exactly what I'd expect. When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/ (my own link-local address) it gives me a "server not found" message, which is also exactly what I'd expect, since I'm not listening on port 80. Brian From owner-v6ops@ops.ietf.org Tue Feb 5 10:50:05 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 438633A749E; Tue, 5 Feb 2008 10:37:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 1D3603A73DC for ; Mon, 4 Feb 2008 15:04:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMAIq-0007ip-Hk for v6ops-data@psg.com; Mon, 04 Feb 2008 23:00:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMAId-0007fP-Jj for v6ops@ops.ietf.org; Mon, 04 Feb 2008 23:00:29 +0000 Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m14MxiQF044992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2008 00:00:00 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: v6ops WG Message-Id: <026DABBE-823D-4BBA-A131-2FC705E594FE@muada.com> From: Iljitsch van Beijnum To: Nathan Ward In-Reply-To: <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: About IPv6 private address Date: Mon, 4 Feb 2008 23:59:55 +0100 References: <47A67FAD.1030803@zyxel.com.tw> <98A80CE8-10F8-4126-B1B4-585544CF34AF@daork.net> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 4 feb 2008, at 22:19, Nathan Ward wrote: > Shorter term, having a vendor-specific (i.e. manufacturer-, or > perhaps ISP-) ULA would be a passable idea. No, it's a bad idea, because you're about to... > - What happens when there are two devices of the same model on the > link? Does that mean each has to have a unique number in the name? > (Apple airport things use part of the MAC address for the initial > name, but, this does not need to be typed by the user as is being > suggested here..) > - I'm sure I had more problems in my head a few minutes ago. ...reinvent service discovery. This all fairly complex to do right but that wheel has been invented before, no need to do it again. BTW those printers I was talking about aren't made by Apple. From owner-v6ops@ops.ietf.org Tue Feb 5 10:54:15 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E39823A6B58; Tue, 5 Feb 2008 10:38:04 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 0B9343A7369 for ; Mon, 4 Feb 2008 14:59:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMACK-0006z1-Lk for v6ops-data@psg.com; Mon, 04 Feb 2008 22:53:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 Received: from [2001:a60:f044:1000:216:3eff:fe00:5] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMABm-0006ub-Gr for v6ops@ops.ietf.org; Mon, 04 Feb 2008 22:53:54 +0000 Received: from [IPv6:2001:6f8:9ee:0:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:6f8:9ee:0:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTP id 3A913402027; Mon, 4 Feb 2008 23:53:18 +0100 (CET) Message-ID: <47A7975A.9000504@spaghetti.zurich.ibm.com> Date: Mon, 04 Feb 2008 23:53:14 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Joe Abley CC: Mark Smith , james woodyatt , v6ops Operations Subject: Re: About IPv6 private address References: <47A6C235.1070904@zyxel.com.tw> <49655D41-5012-474F-AEE6-17B08061F9C0@muada.com> <06C94EF0-65A5-4C8C-8331-E26F77707C7E@apple.com> <20080205064732.419415a3.ipng@69706e6720323030352d30312d31340a.nosense.org> <390707A4-CB01-4D2F-88DB-ABC716417D15@ca.afilias.info> In-Reply-To: <390707A4-CB01-4D2F-88DB-ABC716417D15@ca.afilias.info> X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41BC8BCEA23F49FB28C6AA35" X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41BC8BCEA23F49FB28C6AA35 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Joe Abley wrote: >=20 > On 4-Feb-2008, at 15:17, Mark Smith wrote: >=20 >> Well, not everybody has or will have Apples, so they won't have Bonjou= r >> aware clients/browsers. There does need to be alternative methods. >=20 > As far as I know, though, Bonjour isn't limited to Apple devices. It's = > definitely available on free *ix platforms (and I say "definitely"=20 > because I've used it) and apparently available on Windows too=20 > ("apparently" because I have not had a reason to use Windows since abou= t=20 > 1995). >=20 > So it doesn't seem reasonable to discount this as a reasonable mechanis= m=20 > on the grounds that "not everybody uses Apple products". IMHO mDNS definitely is rather good answer to the problem of "end-user=20 adds a router to his home network" or for that matter a large number of=20 similar issues (eg "user adds Camera", "user adds IPv6 enabled Fridge"=20 and many others of those things, "user adds IP-enabled F16" etc... :) uPNP offers a similar solution of course, as it announces the devices +=20 capabilities + url for configuration on the local network. Couple of things that can be done here: - check that there is already a router on the link ping6 ff02::2, reply? -> another one there no reply? -> you are the first one when one is the first one or there is no RA -> create a ULA + announce it otherwise use the existing prefix Then either: - use mDNS to announce the name of the host (include MAC/serial to make it unique) - use RA/DHCPv6 to provide DNS server address - create a captive portal on port 80, this portal is the configuration interface. In general of course, why would such a device need to be configured=20 anyway, except for "allow inbound connections", which I guess should be=20 off per default to protect the innocent. Greets, Jeroen --------------enig41BC8BCEA23F49FB28C6AA35 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHp5ddKaooUjM+fCMRAvJ7AJ9rzmdhG7kzy7dsHIbAPk2EnIjZlwCeOgz5 j8zeAX7k01qrhALSyXPNX+Q= =FlKa -----END PGP SIGNATURE----- --------------enig41BC8BCEA23F49FB28C6AA35-- From owner-v6ops@ops.ietf.org Tue Feb 5 10:54:48 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C5B4A3A6B11; Tue, 5 Feb 2008 10:37:53 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 341903A7A7D for ; Mon, 4 Feb 2008 17:39:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMChE-000PZz-MW for v6ops-data@psg.com; Tue, 05 Feb 2008 01:34:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,WEIRD_PORT autolearn=no version=3.2.3 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCh3-000PWA-Dw for v6ops@ops.ietf.org; Tue, 05 Feb 2008 01:33:50 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 09:33:48 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 09:33:47 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 09:33:46 +0800 Message-ID: <47A7BCFC.2040805@zyxel.com.tw> Date: Tue, 05 Feb 2008 09:33:48 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> <47A7B6C4.4050801@gmail.com> In-Reply-To: <47A7B6C4.4050801@gmail.com> Content-Type: multipart/alternative; boundary="------------090807030400080900000506" X-OriginalArrivalTime: 05 Feb 2008 01:33:46.0999 (UTC) FILETIME=[26DFE870:01C86797] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090807030400080900000506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Please forgive my dumbness but my Firefox version is 2.0.0.9 My IE could not connect to IPv6 URL either! (IE version 6.0) Thanks. BR, Yi-Wen Brian E Carpenter wrote: >That is a Firefox configuration issue, I think. I don't see that >problem (with Firefix 2.0.0.7, or with IE). > >Is it possible that your browser is going to a proxy? > > Brian > >On 2008-02-05 13:24, blue wrote: > > >>Hi, >>But after typing a link-local address, Firefox' message shows: >> >> Unable to find "www.fe80::213:49ff:fe04:507%8.com" >> >>It translated typed "http://[fe80::213:49ff:fe04:507%8]" to >>"http://[www.fe80::213:49ff:fe04:507%8.com]/". >> >>However, a global unique IPv6 address worked! >> >>I thought it proved that Firefox does not support link-local address. >> >>Thanks. >>BR, >>Yi-Wen >> >>Brian E Carpenter wrote: >> >> >> >>>>>Yes, users need to configure our device via http, and if there's no >>>>>well-known IPv6 address, how do users know which address to connect to? >>>>>I have thought about a pre-configured link-local address; however, >>>>>browsers such as Firefox does not support link-local address. Any >>>>>suggestions? >>>>> >>>>> >>>>> >>>How come Firefox (or any other browser) knows how to *not* support >>>link-local addresses? As far as I can tell, it does support them. >>>Just don't forget the [ ] brackets. >>> >>>When I tell Firefox to connect to http://[fe80::1]/ it gives me >>>an "unable to connect" message, but that's exactly what I'd expect. >>>When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/ >>>(my own link-local address) it gives me a "server not found" message, >>>which is also exactly what I'd expect, since I'm not listening on >>>port 80. >>> >>> Brian >>> >>> >>> >>> >>> >> >> > > > --------------090807030400080900000506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Please forgive my dumbness but my Firefox version is 2.0.0.9

My IE could not connect to IPv6 URL either! (IE version 6.0)

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote: 
That is a Firefox configuration issue, I think. I don't see that
problem (with Firefix 2.0.0.7, or with IE).

Is it possible that your browser is going to a proxy?

   Brian

On 2008-02-05 13:24, blue wrote:
  
Hi,
But after typing a link-local address, Firefox' message shows:

   Unable to find "www.fe80::213:49ff:fe04:507%8.com"

It translated typed "http://[fe80::213:49ff:fe04:507%8]" to
"http://[www.fe80::213:49ff:fe04:507%8.com]/".

However, a global unique IPv6 address worked!

I thought it proved that Firefox does not support link-local address.

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote:

    
Yes, users need to configure our device via http, and if there's no
well-known IPv6 address, how do users know which address to connect to?
I have thought about a pre-configured link-local address; however,
browsers such as Firefox does not support link-local address. Any
suggestions?
    
          
How come Firefox (or any other browser) knows how to *not* support
link-local addresses? As far as I can tell, it does support them.
Just don't forget the [ ] brackets.

When I tell Firefox to connect to http://[fe80::1]/ it gives me
an "unable to connect" message, but that's exactly what I'd expect.
When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/
(my own link-local address) it gives me a "server not found" message,
which is also exactly what I'd expect, since I'm not listening on
port 80.

   Brian

--------------090807030400080900000506-- From gmatt@zenweb.com Tue Feb 5 10:57:50 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 53E0A3A7C9E; Tue, 5 Feb 2008 10:37:59 -0800 (PST) Received: from zenweb.com (unknown [195.161.9.1]) by mail.ietf.org (Postfix) with SMTP id A13833A8278 for ; Mon, 4 Feb 2008 20:06:18 -0800 (PST) Received: (qmail 5813 invoked from network); Tue, 5 Feb 2008 09:07:28 +0500 Received: from unknown (HELO user2) (gmatt@zenweb.com@143.228.120.62) by 4a19a1c3zenweb.com with SMTP; Tue, 5 Feb 2008 09:07:28 +0500 Message-ID: <001301c867d6$881e2b80$06a4ed74@user2> From: Elsa J. Koenig To: v6ops-archive@ietf.org Subject: he boutique Date: Tue, 5 Feb 2008 09:07:28 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C867D6.881E2B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C867D6.881E2B80 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable experiment with alternatives. The fact that one can actually message/or im= portant documents to an individual. Electronic mail could only previously describe as becoming deeply involved with a ------=_NextPart_000_0010_01C867D6.881E2B80 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

endlessly rehashing itself. People have always exaggerated with

You can have a bi/gg er pe \n/s

As Seen On T V

Ov /er 750,000 Men aro /und the world are already sat \isfied
Gain 4 Inches In Length
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 26%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

can assist advertising and marketing tactics. Business can use
------=_NextPart_000_0010_01C867D6.881E2B80-- From tequilla22@hotmail.com Tue Feb 5 10:59:08 2008 Return-Path: X-Original-To: v6ops-archive@megatron.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id CCADA3A7FC5; Tue, 5 Feb 2008 10:38:05 -0800 (PST) Received: from Corporativos24212-15.etb.net.co (unknown [190.24.212.15]) by mail.ietf.org (Postfix) with ESMTP id 0F14C3A778B; Mon, 4 Feb 2008 16:22:21 -0800 (PST) Received: from [190.24.212.15] by mx2.hotmail.com; Mon, 4 Feb 2008 19:23:54 -0500 From: "Conrad Holder" To: Subject: Produce Stronger, Rock Hard Erections Date: Mon, 4 Feb 2008 19:23:54 -0500 Message-ID: <01c86763$7ad10100$0fd418be@tequilla22> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: Normal Gain 3+ Inches In Length http://wooglespi.com From _ljefsnoi@200mph.com Tue Feb 5 11:00:45 2008 Return-Path: <_ljefsnoi@200mph.com> X-Original-To: v6ops-archive@megatron.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5F0223A67A6; Tue, 5 Feb 2008 10:53:01 -0800 (PST) Received: from ppp-176-115.33-151.iol.it (ppp-29-116.33-151.iol.it [151.33.116.29]) by mail.ietf.org (Postfix) with ESMTP id A3DE128CF56 for ; Tue, 5 Feb 2008 07:20:04 -0800 (PST) Message-ID: <001101c8680a$a84142b0$b0732197@fbbda350c51a42b> From: "Kaiming gaudin" <_ljefsnoi@200mph.com> To: v6ops-archive@megatron.ietf.org Subject: Be the tiger in bed you always wanted to be, with 3 more inches added to your manhood Date: Tue, 5 Feb 2008 16:20:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C86813.0A05AAB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000D_01C86813.0A05AAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Incredible, permanant gains on your manhood can be yours, with this = simple solution ----------=_NextPart_000_000D_01C86813.0A05AAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Incredible, permanant gains on = your=20 manhood can be yours, with this simple solution ----------=_NextPart_000_000D_01C86813.0A05AAB0-- From gilliamuntraceried957470@yahoo.com Tue Feb 5 11:01:04 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 8E5AB3A7365; Tue, 5 Feb 2008 10:57:45 -0800 (PST) Received: from 93.Red-81-36-62.dynamicIP.rima-tde.net (93.Red-81-36-62.dynamicIP.rima-tde.net [81.36.62.93]) by mail.ietf.org (Postfix) with SMTP id BF7683A97DB; Tue, 5 Feb 2008 02:48:31 -0800 (PST) Received: from 45.124.58.64 by 81.36.62.93; Tue, 05 Feb 2008 14:43:04 +0400 Message-ID: From: "Daniel Eldridge" Reply-To: "Daniel Eldridge" To: tsvwg-request@ietf.org Subject: Repl1ca watch is a perfect gift! Date: Tue, 05 Feb 2008 05:50:04 -0500 MIME-Version: 1.0 Newest 2008 repl1ca watch3s collection! 15% off in February and huge choose of repl1cas! http://www.doieuej.com/ From cavilingbhyk7@centrepoint.net Tue Feb 5 11:01:45 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D3DFB3A7130; Tue, 5 Feb 2008 10:38:05 -0800 (PST) Received: from du104-dial.jakarta.vqbn.com (unknown [202.55.87.104]) by mail.ietf.org (Postfix) with ESMTP id 082163A7F2E for ; Mon, 4 Feb 2008 19:06:07 -0800 (PST) Received: from [202.55.87.104] by mail.centrepoint.net; Tue, 5 Feb 2008 11:07:42 +0800 From: "Mickey Pace" To: Subject: LamarMonolithicBodypart Date: Tue, 5 Feb 2008 11:07:42 +0800 Message-ID: <01c867e7$53bc1300$685737ca@cavilingbhyk7> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Importance: Normal PenisMonolithicKendra http://www.carpotiues.com From owner-v6ops@ops.ietf.org Tue Feb 5 11:02:34 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 839203A6843; Tue, 5 Feb 2008 10:37:59 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id A8E653A7DB1 for ; Mon, 4 Feb 2008 18:48:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMDl8-0007zC-DV for v6ops-data@psg.com; Tue, 05 Feb 2008 02:42:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTTP_ESCAPED_HOST,RDNS_NONE,WEIRD_PORT autolearn=no version=3.2.3 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMDl5-0007yw-PJ for v6ops@ops.ietf.org; Tue, 05 Feb 2008 02:42:05 +0000 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 4 Feb 2008 18:42:02 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.1.240.5; Mon, 4 Feb 2008 18:42:02 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Mon, 4 Feb 2008 18:42:02 -0800 From: Christian Huitema To: blue , Brian E Carpenter CC: "v6ops@ops.ietf.org" Date: Mon, 4 Feb 2008 18:41:48 -0800 Subject: RE: [Fwd: Re: About IPv6 private address] Thread-Topic: [Fwd: Re: About IPv6 private address] Thread-Index: AchnmHMW4Pn9u9kkTZSbjKQl2P4XyAAB/5IA Message-ID: References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> <47A7B6C4.4050801@gmail.com> <47A7BCFC.2040805@zyxel.com.tw> In-Reply-To: <47A7BCFC.2040805@zyxel.com.tw> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F2467475NAEXMSGW602wi_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F2467475NAEXMSGW602wi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGFyZSBydW5uaW5nIEZpcmVmb3ggb24gV2luZG93cyBWaXN0YSwgeW91IHNob3VsZCBi ZSBhYmxlIHRvIHRyeSBodHRwOi8vZmU4MC0tMjEzLTQ5ZmYtZmUwNC01MDdzOC5pcHY2LWxpdGVy YWwubmV0Lw0KDQoNCkZyb206IG93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVy LXY2b3BzQG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIGJsdWUNClNlbnQ6IE1vbmRheSwgRmVi cnVhcnkgMDQsIDIwMDggNTozNCBQTQ0KVG86IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogdjZvcHNA b3BzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Z3ZDogUmU6IEFib3V0IElQdjYgcHJpdmF0ZSBh ZGRyZXNzXQ0KDQpQbGVhc2UgZm9yZ2l2ZSBteSBkdW1ibmVzcyBidXQgbXkgRmlyZWZveCB2ZXJz aW9uIGlzIDIuMC4wLjkNCg0KTXkgSUUgY291bGQgbm90IGNvbm5lY3QgdG8gSVB2NiBVUkwgZWl0 aGVyISAoSUUgdmVyc2lvbiA2LjApDQoNClRoYW5rcy4NCkJSLA0KWWktV2VuDQoNCkJyaWFuIEUg Q2FycGVudGVyIHdyb3RlOg0KDQpUaGF0IGlzIGEgRmlyZWZveCBjb25maWd1cmF0aW9uIGlzc3Vl LCBJIHRoaW5rLiBJIGRvbid0IHNlZSB0aGF0DQoNCnByb2JsZW0gKHdpdGggRmlyZWZpeCAyLjAu MC43LCBvciB3aXRoIElFKS4NCg0KDQoNCklzIGl0IHBvc3NpYmxlIHRoYXQgeW91ciBicm93c2Vy IGlzIGdvaW5nIHRvIGEgcHJveHk/DQoNCg0KDQogICBCcmlhbg0KDQoNCg0KT24gMjAwOC0wMi0w NSAxMzoyNCwgYmx1ZSB3cm90ZToNCg0KDQoNCkhpLA0KDQpCdXQgYWZ0ZXIgdHlwaW5nIGEgbGlu ay1sb2NhbCBhZGRyZXNzLCBGaXJlZm94JyBtZXNzYWdlIHNob3dzOg0KDQoNCg0KICAgVW5hYmxl IHRvIGZpbmQgInd3dy5mZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyU4LmNvbTxodHRwOi8vd3d3LmZl ODA6OjIxMzo0OWZmOmZlMDQ6NTA3JTI1OC5jb20+Ig0KDQoNCg0KSXQgdHJhbnNsYXRlZCB0eXBl ZCAiaHR0cDovL1tmZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyU4XSI8aHR0cDovL1tmZTgwOjoyMTM6 NDlmZjpmZTA0OjUwNyUyNThdPiB0bw0KDQoiaHR0cDovL1t3d3cuZmU4MDo6MjEzOjQ5ZmY6ZmUw NDo1MDclOC5jb21dLyI8aHR0cDovL1t3d3cuZmU4MDo6MjEzOjQ5ZmY6ZmUwNDo1MDclMjU4LmNv bV0vPi4NCg0KDQoNCkhvd2V2ZXIsIGEgZ2xvYmFsIHVuaXF1ZSBJUHY2IGFkZHJlc3Mgd29ya2Vk IQ0KDQoNCg0KSSB0aG91Z2h0IGl0IHByb3ZlZCB0aGF0IEZpcmVmb3ggZG9lcyBub3Qgc3VwcG9y dCBsaW5rLWxvY2FsIGFkZHJlc3MuDQoNCg0KDQpUaGFua3MuDQoNCkJSLA0KDQpZaS1XZW4NCg0K DQoNCkJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KDQoNCg0KDQoNClllcywgdXNlcnMgbmVlZCB0 byBjb25maWd1cmUgb3VyIGRldmljZSB2aWEgaHR0cCwgYW5kIGlmIHRoZXJlJ3Mgbm8NCg0Kd2Vs bC1rbm93biBJUHY2IGFkZHJlc3MsIGhvdyBkbyB1c2VycyBrbm93IHdoaWNoIGFkZHJlc3MgdG8g Y29ubmVjdCB0bz8NCg0KSSBoYXZlIHRob3VnaHQgYWJvdXQgYSBwcmUtY29uZmlndXJlZCBsaW5r LWxvY2FsIGFkZHJlc3M7IGhvd2V2ZXIsDQoNCmJyb3dzZXJzIHN1Y2ggYXMgRmlyZWZveCBkb2Vz IG5vdCBzdXBwb3J0IGxpbmstbG9jYWwgYWRkcmVzcy4gQW55DQoNCnN1Z2dlc3Rpb25zPw0KDQoN Cg0KDQoNCkhvdyBjb21lIEZpcmVmb3ggKG9yIGFueSBvdGhlciBicm93c2VyKSBrbm93cyBob3cg dG8gKm5vdCogc3VwcG9ydA0KDQpsaW5rLWxvY2FsIGFkZHJlc3Nlcz8gQXMgZmFyIGFzIEkgY2Fu IHRlbGwsIGl0IGRvZXMgc3VwcG9ydCB0aGVtLg0KDQpKdXN0IGRvbid0IGZvcmdldCB0aGUgWyBd IGJyYWNrZXRzLg0KDQoNCg0KV2hlbiBJIHRlbGwgRmlyZWZveCB0byBjb25uZWN0IHRvIGh0dHA6 Ly9bZmU4MDo6MV0vIGl0IGdpdmVzIG1lDQoNCmFuICJ1bmFibGUgdG8gY29ubmVjdCIgbWVzc2Fn ZSwgYnV0IHRoYXQncyBleGFjdGx5IHdoYXQgSSdkIGV4cGVjdC4NCg0KV2hlbiBJIHRlbGwgRmly ZWZveCB0byBjb25uZWN0IHRvIGh0dHA6Ly9bZmU4MDo6MjFhOmEwZmY6ZmU0YTpkNjgwJTU8aHR0 cDovL1tmZTgwOjoyMWE6YTBmZjpmZTRhOmQ2ODAlMjU1Pl0vDQoNCihteSBvd24gbGluay1sb2Nh bCBhZGRyZXNzKSBpdCBnaXZlcyBtZSBhICJzZXJ2ZXIgbm90IGZvdW5kIiBtZXNzYWdlLA0KDQp3 aGljaCBpcyBhbHNvIGV4YWN0bHkgd2hhdCBJJ2QgZXhwZWN0LCBzaW5jZSBJJ20gbm90IGxpc3Rl bmluZyBvbg0KDQpwb3J0IDgwLg0KDQoNCg0KICAgQnJpYW4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQo= --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F2467475NAEXMSGW602wi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5 IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2 IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPklmIHlvdSBhcmUgcnVubmluZyBGaXJlZm94IG9uIFdpbmRvd3MgVmlzdGEsIHlvdSBz aG91bGQgYmUgYWJsZQ0KdG8gdHJ5IDxhIGhyZWY9Imh0dHA6Ly9mZTgwLS0yMTMtNDlmZi1mZTA0 LTUwN3M4LmlwdjYtbGl0ZXJhbC5uZXQvIj5odHRwOi8vZmU4MC0tMjEzLTQ5ZmYtZmUwNC01MDdz OC5pcHY2LWxpdGVyYWwubmV0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0K PGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiOw0KY29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiO2Nv bG9yOndpbmRvd3RleHQnPiBvd25lci12Nm9wc0BvcHMuaWV0Zi5vcmcNClttYWlsdG86b3duZXIt djZvcHNAb3BzLmlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPmJsdWU8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAwNCwgMjAwOCA1OjM0IFBNPGJyPg0KPGI+VG86PC9iPiBC cmlhbiBFIENhcnBlbnRlcjxicj4NCjxiPkNjOjwvYj4gdjZvcHNAb3BzLmlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbRndkOiBSZTogQWJvdXQgSVB2NiBwcml2YXRlIGFkZHJlc3Nd PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlBsZWFz ZSBmb3JnaXZlIG15IGR1bWJuZXNzIGJ1dCBteSBGaXJlZm94IHZlcnNpb24gaXMgMi4wLjAuOTxi cj4NCjxicj4NCk15IElFIGNvdWxkIG5vdCBjb25uZWN0IHRvIElQdjYgVVJMIGVpdGhlciEgKElF IHZlcnNpb24gNi4wKTxicj4NCjxicj4NClRoYW5rcy48YnI+DQpCUiw8YnI+DQpZaS1XZW48YnI+ DQo8YnI+DQpCcmlhbiBFIENhcnBlbnRlciB3cm90ZTogPG86cD48L286cD48L3A+DQoNCjxwcmU+ VGhhdCBpcyBhIEZpcmVmb3ggY29uZmlndXJhdGlvbiBpc3N1ZSwgSSB0aGluay4gSSBkb24ndCBz ZWUgdGhhdDxvOnA+PC9vOnA+PC9wcmU+PHByZT5wcm9ibGVtICh3aXRoIEZpcmVmaXggMi4wLjAu Nywgb3Igd2l0aCBJRSkuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT5JcyBpdCBwb3NzaWJsZSB0aGF0IHlvdXIgYnJvd3NlciBpcyBnb2luZyB0byBhIHBy b3h5PzxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+wqDC oCBCcmlhbjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ T24gMjAwOC0wMi0wNSAxMzoyNCwgYmx1ZSB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqAg PG86cD48L286cD48L3ByZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHByZT5IaSw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+QnV0IGFm dGVyIHR5cGluZyBhIGxpbmstbG9jYWwgYWRkcmVzcywgRmlyZWZveCcgbWVzc2FnZSBzaG93czo8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPsKgwqAgVW5h YmxlIHRvIGZpbmQgJnF1b3Q7PGENCmhyZWY9Imh0dHA6Ly93d3cuZmU4MDo6MjEzOjQ5ZmY6ZmUw NDo1MDclMjU4LmNvbSI+d3d3LmZlODA6OjIxMzo0OWZmOmZlMDQ6NTA3JTguY29tPC9hPiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+SXQgdHJh bnNsYXRlZCB0eXBlZCA8YQ0KaHJlZj0iaHR0cDovL1tmZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyUy NThdIj4mcXVvdDtodHRwOi8vW2ZlODA6OjIxMzo0OWZmOmZlMDQ6NTA3JThdJnF1b3Q7PC9hPiB0 bzxvOnA+PC9vOnA+PC9wcmU+PHByZT48YQ0KaHJlZj0iaHR0cDovL1t3d3cuZmU4MDo6MjEzOjQ5 ZmY6ZmUwNDo1MDclMjU4LmNvbV0vIj4mcXVvdDtodHRwOi8vW3d3dy5mZTgwOjoyMTM6NDlmZjpm ZTA0OjUwNyU4LmNvbV0vJnF1b3Q7PC9hPi48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPkhvd2V2ZXIsIGEgZ2xvYmFsIHVuaXF1ZSBJUHY2IGFkZHJlc3Mg d29ya2VkITxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ SSB0aG91Z2h0IGl0IHByb3ZlZCB0aGF0IEZpcmVmb3ggZG9lcyBub3Qgc3VwcG9ydCBsaW5rLWxv Y2FsIGFkZHJlc3MuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT5UaGFua3MuPG86cD48L286cD48L3ByZT48cHJlPkJSLDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT5ZaS1XZW48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PkJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgIDxvOnA+PC9vOnA+PC9wcmU+DQoNCjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPg0KDQo8YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCg0KPGJs b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHBy ZT5ZZXMsIHVzZXJzIG5lZWQgdG8gY29uZmlndXJlIG91ciBkZXZpY2UgdmlhIGh0dHAsIGFuZCBp ZiB0aGVyZSdzIG5vPG86cD48L286cD48L3ByZT48cHJlPndlbGwta25vd24gSVB2NiBhZGRyZXNz LCBob3cgZG8gdXNlcnMga25vdyB3aGljaCBhZGRyZXNzIHRvIGNvbm5lY3QgdG8/PG86cD48L286 cD48L3ByZT48cHJlPkkgaGF2ZSB0aG91Z2h0IGFib3V0IGEgcHJlLWNvbmZpZ3VyZWQgbGluay1s b2NhbCBhZGRyZXNzOyBob3dldmVyLDxvOnA+PC9vOnA+PC9wcmU+PHByZT5icm93c2VycyBzdWNo IGFzIEZpcmVmb3ggZG9lcyBub3Qgc3VwcG9ydCBsaW5rLWxvY2FsIGFkZHJlc3MuIEFueTxvOnA+ PC9vOnA+PC9wcmU+PHByZT5zdWdnZXN0aW9ucz88bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKg IDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+PC9vOnA+PC9w cmU+PC9ibG9ja3F1b3RlPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjxwcmU+SG93IGNvbWUgRmlyZWZv eCAob3IgYW55IG90aGVyIGJyb3dzZXIpIGtub3dzIGhvdyB0byAqbm90KiBzdXBwb3J0PG86cD48 L286cD48L3ByZT48cHJlPmxpbmstbG9jYWwgYWRkcmVzc2VzPyBBcyBmYXIgYXMgSSBjYW4gdGVs bCwgaXQgZG9lcyBzdXBwb3J0IHRoZW0uPG86cD48L286cD48L3ByZT48cHJlPkp1c3QgZG9uJ3Qg Zm9yZ2V0IHRoZSBbIF0gYnJhY2tldHMuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT5XaGVuIEkgdGVsbCBGaXJlZm94IHRvIGNvbm5lY3QgdG8gPGENCmhy ZWY9Imh0dHA6Ly9bZmU4MDo6MSI+aHR0cDovL1tmZTgwOjoxPC9hPl0vIGl0IGdpdmVzIG1lPG86 cD48L286cD48L3ByZT48cHJlPmFuICZxdW90O3VuYWJsZSB0byBjb25uZWN0JnF1b3Q7IG1lc3Nh Z2UsIGJ1dCB0aGF0J3MgZXhhY3RseSB3aGF0IEknZCBleHBlY3QuPG86cD48L286cD48L3ByZT48 cHJlPldoZW4gSSB0ZWxsIEZpcmVmb3ggdG8gY29ubmVjdCB0byA8YQ0KaHJlZj0iaHR0cDovL1tm ZTgwOjoyMWE6YTBmZjpmZTRhOmQ2ODAlMjU1Ij5odHRwOi8vW2ZlODA6OjIxYTphMGZmOmZlNGE6 ZDY4MCU1PC9hPl0vPG86cD48L286cD48L3ByZT48cHJlPihteSBvd24gbGluay1sb2NhbCBhZGRy ZXNzKSBpdCBnaXZlcyBtZSBhICZxdW90O3NlcnZlciBub3QgZm91bmQmcXVvdDsgbWVzc2FnZSw8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+d2hpY2ggaXMgYWxzbyBleGFjdGx5IHdoYXQgSSdkIGV4cGVj dCwgc2luY2UgSSdtIG5vdCBsaXN0ZW5pbmcgb248bzpwPjwvbzpwPjwvcHJlPjxwcmU+cG9ydCA4 MC48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPsKgwqAg QnJpYW48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPsKgwqDCoMKg wqAgPG86cD48L286cD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPsKgwqDCoCA8bzpwPjwvbzpwPjwvcHJlPjwvYmxvY2txdW90ZT4NCg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+wqAgPG86cD48L286cD48L3ByZT4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F2467475NAEXMSGW602wi_-- From Jeanny-dottieri@aki3190.jp Tue Feb 5 11:03:05 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 431D73A6C4D; Tue, 5 Feb 2008 10:37:52 -0800 (PST) Received: from 189-79-137-115.dsl.telesp.net.br (201-13-14-46.dsl.telesp.net.br [201.13.14.46]) by mail.ietf.org (Postfix) with ESMTP id 1D1BA3A829A for ; Mon, 4 Feb 2008 20:09:35 -0800 (PST) Message-ID: <000c01c867ad$26276be0$73894fbd@computador> From: "Jeanny Lolato" To: v6ops-archive@ietf.org Subject: Be the Ladies' choice with your brand new big d-!ck. Date: Tue, 5 Feb 2008 02:11:14 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C8679C.629E9BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Antivirus: avast! (VPS 080204-0, 04/02/2008), Outbound message X-Antivirus-Status: Clean ----------=_NextPart_000_0008_01C8679C.629E9BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get a new, bigger p3nis easily by clicking here. ----------=_NextPart_000_0008_01C8679C.629E9BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get a new, bigger p3nis easily by = clicking=20 here. ----------=_NextPart_000_0008_01C8679C.629E9BE0-- From owner-v6ops@ops.ietf.org Tue Feb 5 11:03:06 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id CA6483A6E08; Tue, 5 Feb 2008 10:37:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id CA1E23A7A78 for ; Mon, 4 Feb 2008 17:32:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCZd-000OZN-40 for v6ops-data@psg.com; Tue, 05 Feb 2008 01:26:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [209.85.198.191] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCZW-000OYg-13 for v6ops@ops.ietf.org; Tue, 05 Feb 2008 01:26:07 +0000 Received: by rv-out-0910.google.com with SMTP id b22so2078021rvf.41 for ; Mon, 04 Feb 2008 17:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=IY3Ah4jqYgcg7nnapiHWjzoTtcFtvYpqJqFhIIlZ3Sw=; b=Ydvpa4ycmxRf2m6aIdNRcnciRYUylLz/Pvr/e6BhlpRok8BUrQ6WUYSRJk7XUcO8PgU4V9CjTAQLepyJQI6AKt7vteIw0Ow2TVZuw0e9MVW/Q0wEL1beoGZJBFNS96iHkZWeFRSpwYczPY9EOAEtXxIK21g1sy5OvdflgEcoG3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gqI1x9uqc7Ixd7xIW32I3r5iBFsPV83KMqJKN3opaaFAO8K6/bd5Vh7y5BUaErTC/hKwVMrPgQ6O4IQuAb+0w2Q3o581jlcQO8YQVW/xNRdTvD+YVfR3b3rQP7SRQdXSHs8b1wjJJlqAWeIMAPrcfvOWAgogeAZanZN+alNSAUw= Received: by 10.140.147.18 with SMTP id u18mr5186350rvd.202.1202174760930; Mon, 04 Feb 2008 17:26:00 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l27sm9066177rvb.11.2008.02.04.17.25.58 (version=SSLv3 cipher=RC4-MD5); Mon, 04 Feb 2008 17:26:00 -0800 (PST) Message-ID: <47A7BB25.10809@gmail.com> Date: Tue, 05 Feb 2008 14:25:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alain Durand CC: Gert Doering , james woodyatt , v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-02-02 12:23, Alain Durand wrote: > > > On 2/1/08 4:56 PM, "Gert Doering" wrote: > >> Hi, >> >> On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote: >>> Essentially, expecting to get a functioning 6to4 relay is expecting a free >>> lunch. Who is going to pay for it? >> If enough ISPs provide working 6to4 relays, serving their own customers >> (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the >> model would work just fine. > > Why should ISP X pay to run a 6to4 relay that would in essence offer transit > for customers of other ISPs? And let's say that ISP X offer the outband > relay for its customers only, how would the packets come back from the real > IPv6 Internet to ISP X IPv4 network? Is ISP X suppose to announce a > de-aggregate of 2002://16? That would create a huge increase in the routing > table size... Not allowed by RFC 3056. As stated there, the scope of advertisements for 2002::/16 needs to be *managed*, because you're going to have to encapsulate anything that arrives, on the assumption that there will be a 6to4 router at the specified V4ADDR. So you'd better make sure that only the IPv6 locations you want to serve can see your particular 2002::/16 advertisement, because you have no choice about the V4ADDR destination. Similarly, the scope of IPv4 advertisements for your relay (whether it's 192.88.99.0/24 or anything else) needs to be limited to IPv4 locations that you're willing to serve for 6to4. You have no choice about the IPv6 destination. In neither case do those locations have to be your own customers, however. And there's no reason to expect symmetric paths. I always expected 6to4 relay deployments to be altruistic, not related to revenue. Brian From owner-v6ops@ops.ietf.org Tue Feb 5 11:03:08 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id AB38E3A6B9A; Tue, 5 Feb 2008 10:57:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id B6C6528C6BD for ; Tue, 5 Feb 2008 05:39:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMNy1-000IWz-WB for v6ops-data@psg.com; Tue, 05 Feb 2008 13:36:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMNxu-000IWF-08 for v6ops@ops.ietf.org; Tue, 05 Feb 2008 13:35:59 +0000 Received: from [65.93.42.34] (helo=[192.168.199.120]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMNxf-0000VD-8o; Tue, 05 Feb 2008 13:35:44 +0000 Cc: David Conrad , blue , Brian E Carpenter , "v6ops@ops.ietf.org" Message-Id: <963CBD8C-C1F3-4BDF-9ADD-6A2B9B199C1B@ca.afilias.info> From: Joe Abley To: Christian Huitema In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Fwd: Re: About IPv6 private address] Date: Tue, 5 Feb 2008 08:35:41 -0500 References: X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 5-Feb-2008, at 01:12, Christian Huitema wrote: > Actually, the =93ipv6-literal.net=94 domain is properly registered and = =20 > all that, so it really is a =93Microsoft managed subdomain=94. But = yes, =20 > this is a work around for the applications that have trouble parsing =20= > IPv6 literals. There is an example of using it for sharing files =20 > using IPv6 literal addresses at http://support.microsoft.com/kb/=20 > 944007. The mechanism is described = athttp://technet.microsoft.com/en-us/library/bb726965.aspx=20 > , look for =93Support for ipv6-literal.net Names=94. It's a shame the authoritative server concerned doesn't actually =20 return AAAA records in response to those queries (or, at least, those =20= queries which could conceivably result in global-scope answers). You just know someone on a Windows system is going to publish an URL =20 at some point that people not on Windows systems are going to follow, =20= and hilarity is going to result. (But in the absence of an authority server which can give real =20 answers, SERVFAIL is probably the right thing.) [monster:~]% dig 2001-500-2f-0-0-0-0-f.ipv6-literal.net. IN AAAA ; <<>> DiG 9.3.4-P1 <<>> 2001-500-2f-0-0-0-0-f.ipv6-literal.net. IN AAAA ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23383 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;2001-500-2f-0-0-0-0-f.ipv6-literal.net. IN AAAA ;; Query time: 914 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 5 13:34:06 2008 ;; MSG SIZE rcvd: 56 [monster:~]% Joe= From owner-v6ops@ops.ietf.org Tue Feb 5 11:03:30 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 857AE3A75EC; Tue, 5 Feb 2008 10:37:59 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id AA2B53A849A for ; Mon, 4 Feb 2008 20:57:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFka-000Nls-Br for v6ops-data@psg.com; Tue, 05 Feb 2008 04:49:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTTP_ESCAPED_HOST,RDNS_NONE,URI_HEX,WEIRD_PORT autolearn=no version=3.2.3 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMFkW-000Niu-0T for v6ops@ops.ietf.org; Tue, 05 Feb 2008 04:49:38 +0000 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 4 Feb 2008 20:49:35 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.1.240.5; Mon, 4 Feb 2008 20:49:34 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.48]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Mon, 4 Feb 2008 20:49:34 -0800 From: Christian Huitema To: blue CC: Brian E Carpenter , "v6ops@ops.ietf.org" Date: Mon, 4 Feb 2008 20:49:31 -0800 Subject: RE: [Fwd: Re: About IPv6 private address] Thread-Topic: [Fwd: Re: About IPv6 private address] Thread-Index: AchnpVQJ5QZ8/gHtQ32HvXHcvHoS4AADLDCw Message-ID: References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> <47A7B6C4.4050801@gmail.com> <47A7BCFC.2040805@zyxel.com.tw> <47A7D49E.3060208@zyxel.com.tw> In-Reply-To: <47A7D49E.3060208@zyxel.com.tw> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674AFNAEXMSGW602wi_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674AFNAEXMSGW602wi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmlyZWZveCBkb2VzIG5vdCBkbyBhbnl0aGluZyB0aGVyZS4gVGhlIG5hbWUgcmVzb2x1dGlvbiBz ZXJ2aWNlIGluIFdpbmRvd3MgVmlzdGEgcmVzb2x2ZXMgbmFtZXMgb2YgdGhlIGZvcm0gZmU4MC0t MjEzLTQ5ZmYtZmUwNC01MDdzOC5pcHY2LWxpdGVyYWwubmV0IGludG8gdGhlIGNvcnJlc3BvbmRp bmcgSVB2NiBhZGRyZXNzLCBpbiB0aGF0IGV4YW1wbGUgW2ZlODA6OjIxMzo0OWZmOmZlMDQ6NTA3 JThdLiBGb3IgRmlyZWZveCwgaXQgaXMganVzdCBhIG5hbWUgbG9va3VwLg0KDQpXZSBwdXQgdGhh dCBmZWF0dXJlIGluIFZpc3RhIGJlY2F1c2Ugc29tZSBhcHBsaWNhdGlvbnMgaGFkIGEgdmVyeSBo YXJkIHRpbWUgcGFyc2luZyBjb2xvbnMgYW5kIHBlcmNlbnQgc2lnbnMuIEl0IHJlYWxseSBpcyBh IHdvcmsgYXJvdW5k4oCmDQoNCkZyb206IGJsdWUgW21haWx0bzpzdXNhbi5sYW5Aenl4ZWwuY29t LnR3XQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNCwgMjAwOCA3OjE1IFBNDQpUbzogQ2hyaXN0 aWFuIEh1aXRlbWENCkNjOiBCcmlhbiBFIENhcnBlbnRlcjsgdjZvcHNAb3BzLmlldGYub3JnDQpT dWJqZWN0OiBSZTogW0Z3ZDogUmU6IEFib3V0IElQdjYgcHJpdmF0ZSBhZGRyZXNzXQ0KDQpEZWFy IENocmlzdGlhbjoNCg0KRG8geW91IG1lYW4gRmlyZWZveCBvbiBWaXN0YSB3aWxsIHRyYW5zbGF0 ZSB0aGUgbGluay1sb2NhbCBhZGRyZXNzIHRvIHRoZSBkb21haW4gbmFtZSBzdWZmaXhlZCAiaXB2 Ni1saXRlcmFsLm5ldCI/DQoNCkN1cnJlbnRseSBteSBwbGF0Zm9ybSBpcyBNaWNyb3NvZnQgV2lu ZG93cyBYUCBpbnN0ZWFkIG9mIFdpbmRvd3MgVmlzdGEuIEhvd2V2ZXIsIEkgZG9uJ3QgY29uc2lk ZXIgdGhpcyBiZWhhdmlvciBpcyByZWxhdGVkIHRvIHRoZSBPUyB2ZXJzaW9uLg0KDQpXaGljaCB2 ZXJzaW9uIGlzIHlvdXIgRmlyZWZveCwgcGxlYXNlPw0KDQpUaGFua3MuDQpCUiwNCllpLVdlbg0K DQpDaHJpc3RpYW4gSHVpdGVtYSB3cm90ZToNCklmIHlvdSBhcmUgcnVubmluZyBGaXJlZm94IG9u IFdpbmRvd3MgVmlzdGEsIHlvdSBzaG91bGQgYmUgYWJsZSB0byB0cnkgaHR0cDovL2ZlODAtLTIx My00OWZmLWZlMDQtNTA3czguaXB2Ni1saXRlcmFsLm5ldC8NCg0KDQpGcm9tOiBvd25lci12Nm9w c0BvcHMuaWV0Zi5vcmc8bWFpbHRvOm93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZz4gW21haWx0bzpv d25lci12Nm9wc0BvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBibHVlDQpTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDA0LCAyMDA4IDU6MzQgUE0NClRvOiBCcmlhbiBFIENhcnBlbnRlcg0KQ2M6IHY2 b3BzQG9wcy5pZXRmLm9yZzxtYWlsdG86djZvcHNAb3BzLmlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtGd2Q6IFJlOiBBYm91dCBJUHY2IHByaXZhdGUgYWRkcmVzc10NCg0KUGxlYXNlIGZvcmdpdmUg bXkgZHVtYm5lc3MgYnV0IG15IEZpcmVmb3ggdmVyc2lvbiBpcyAyLjAuMC45DQoNCk15IElFIGNv dWxkIG5vdCBjb25uZWN0IHRvIElQdjYgVVJMIGVpdGhlciEgKElFIHZlcnNpb24gNi4wKQ0KDQpU aGFua3MuDQpCUiwNCllpLVdlbg0KDQpCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCg0KVGhhdCBp cyBhIEZpcmVmb3ggY29uZmlndXJhdGlvbiBpc3N1ZSwgSSB0aGluay4gSSBkb24ndCBzZWUgdGhh dA0KDQpwcm9ibGVtICh3aXRoIEZpcmVmaXggMi4wLjAuNywgb3Igd2l0aCBJRSkuDQoNCg0KDQpJ cyBpdCBwb3NzaWJsZSB0aGF0IHlvdXIgYnJvd3NlciBpcyBnb2luZyB0byBhIHByb3h5Pw0KDQoN Cg0KICAgQnJpYW4NCg0KDQoNCk9uIDIwMDgtMDItMDUgMTM6MjQsIGJsdWUgd3JvdGU6DQoNCg0K DQpIaSwNCg0KQnV0IGFmdGVyIHR5cGluZyBhIGxpbmstbG9jYWwgYWRkcmVzcywgRmlyZWZveCcg bWVzc2FnZSBzaG93czoNCg0KDQoNCiAgIFVuYWJsZSB0byBmaW5kICJ3d3cuZmU4MDo6MjEzOjQ5 ZmY6ZmUwNDo1MDclOC5jb208aHR0cDovL3d3dy5mZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyUyNTgu Y29tPiINCg0KDQoNCkl0IHRyYW5zbGF0ZWQgdHlwZWQgImh0dHA6Ly9bZmU4MDo6MjEzOjQ5ZmY6 ZmUwNDo1MDclOF0iPGh0dHA6Ly8lNUJmZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyUyNTglNUQ+IHRv DQoNCiJodHRwOi8vW3d3dy5mZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyU4LmNvbV0vIjxodHRwOi8v JTVCd3d3LmZlODA6OjIxMzo0OWZmOmZlMDQ6NTA3JTI1OC5jb20lNUQvPi4NCg0KDQoNCkhvd2V2 ZXIsIGEgZ2xvYmFsIHVuaXF1ZSBJUHY2IGFkZHJlc3Mgd29ya2VkIQ0KDQoNCg0KSSB0aG91Z2h0 IGl0IHByb3ZlZCB0aGF0IEZpcmVmb3ggZG9lcyBub3Qgc3VwcG9ydCBsaW5rLWxvY2FsIGFkZHJl c3MuDQoNCg0KDQpUaGFua3MuDQoNCkJSLA0KDQpZaS1XZW4NCg0KDQoNCkJyaWFuIEUgQ2FycGVu dGVyIHdyb3RlOg0KDQoNCg0KDQoNClllcywgdXNlcnMgbmVlZCB0byBjb25maWd1cmUgb3VyIGRl dmljZSB2aWEgaHR0cCwgYW5kIGlmIHRoZXJlJ3Mgbm8NCg0Kd2VsbC1rbm93biBJUHY2IGFkZHJl c3MsIGhvdyBkbyB1c2VycyBrbm93IHdoaWNoIGFkZHJlc3MgdG8gY29ubmVjdCB0bz8NCg0KSSBo YXZlIHRob3VnaHQgYWJvdXQgYSBwcmUtY29uZmlndXJlZCBsaW5rLWxvY2FsIGFkZHJlc3M7IGhv d2V2ZXIsDQoNCmJyb3dzZXJzIHN1Y2ggYXMgRmlyZWZveCBkb2VzIG5vdCBzdXBwb3J0IGxpbmst bG9jYWwgYWRkcmVzcy4gQW55DQoNCnN1Z2dlc3Rpb25zPw0KDQoNCg0KDQoNCkhvdyBjb21lIEZp cmVmb3ggKG9yIGFueSBvdGhlciBicm93c2VyKSBrbm93cyBob3cgdG8gKm5vdCogc3VwcG9ydA0K DQpsaW5rLWxvY2FsIGFkZHJlc3Nlcz8gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIGl0IGRvZXMgc3Vw cG9ydCB0aGVtLg0KDQpKdXN0IGRvbid0IGZvcmdldCB0aGUgWyBdIGJyYWNrZXRzLg0KDQoNCg0K V2hlbiBJIHRlbGwgRmlyZWZveCB0byBjb25uZWN0IHRvIGh0dHA6Ly9bZmU4MDo6MTxodHRwOi8v JTVCZmU4MDo6MT5dLyBpdCBnaXZlcyBtZQ0KDQphbiAidW5hYmxlIHRvIGNvbm5lY3QiIG1lc3Nh Z2UsIGJ1dCB0aGF0J3MgZXhhY3RseSB3aGF0IEknZCBleHBlY3QuDQoNCldoZW4gSSB0ZWxsIEZp cmVmb3ggdG8gY29ubmVjdCB0byBodHRwOi8vW2ZlODA6OjIxYTphMGZmOmZlNGE6ZDY4MCU1PGh0 dHA6Ly8lNUJmZTgwOjoyMWE6YTBmZjpmZTRhOmQ2ODAlMjU1Pl0vDQoNCihteSBvd24gbGluay1s b2NhbCBhZGRyZXNzKSBpdCBnaXZlcyBtZSBhICJzZXJ2ZXIgbm90IGZvdW5kIiBtZXNzYWdlLA0K DQp3aGljaCBpcyBhbHNvIGV4YWN0bHkgd2hhdCBJJ2QgZXhwZWN0LCBzaW5jZSBJJ20gbm90IGxp c3RlbmluZyBvbg0KDQpwb3J0IDgwLg0KDQoNCg0KICAgQnJpYW4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674AFNAEXMSGW602wi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0 aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgYmdj b2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xh c3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5GaXJlZm94DQpkb2Vz IG5vdCBkbyBhbnl0aGluZyB0aGVyZS4gVGhlIG5hbWUgcmVzb2x1dGlvbiBzZXJ2aWNlIGluIFdp bmRvd3MgVmlzdGEgcmVzb2x2ZXMNCm5hbWVzIG9mIHRoZSBmb3JtIDwvc3Bhbj48L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+ZmU4MC0tMjEzLTQ5ZmYtZmUwNC01MDdzOC5pcHY2LWxpdGVyYWwubmV0DQppbnRvIHRo ZSBjb3JyZXNwb25kaW5nIElQdjYgYWRkcmVzcywgaW4gdGhhdCBleGFtcGxlIFtmZTgwOjoyMTM6 NDlmZjpmZTA0OjUwNyU4XS4NCkZvciBGaXJlZm94LCBpdCBpcyBqdXN0IGEgbmFtZSBsb29rdXAu PC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj0iIzFmNDk3ZCINCmZhY2U9Q2FsaWJyaT48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPldlDQpwdXQgdGhhdCBmZWF0dXJlIGluIFZpc3RhIGJlY2F1c2Ugc29tZSBh cHBsaWNhdGlvbnMgaGFkIGEgdmVyeSBoYXJkIHRpbWUNCnBhcnNpbmcgY29sb25zIGFuZCBwZXJj ZW50IHNpZ25zLiBJdCByZWFsbHkgaXMgYSB3b3JrIGFyb3VuZOKApiA8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPSIj MWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRp dj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9VGFob21hPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dDsNCmZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsYWNrIGZhY2U9VGFob21hPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+DQpi bHVlIFttYWlsdG86c3VzYW4ubGFuQHp5eGVsLmNvbS50d10gPGJyPg0KPGI+PHNwYW4gc3R5bGU9 J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5LCBGZWJydWFyeSAwNCwg MjAwOA0KNzoxNSBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8 L3NwYW4+PC9iPiBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdl aWdodDpib2xkJz5DYzo8L3NwYW4+PC9iPiBCcmlhbiBFIENhcnBlbnRlcjsNCnY2b3BzQG9wcy5p ZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwv c3Bhbj48L2I+IFJlOiBbRndkOiBSZTogQWJvdXQgSVB2Ng0KcHJpdmF0ZSBhZGRyZXNzXTxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFj ayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ RGVhciBDaHJpc3RpYW46PGJyPg0KPGJyPg0KRG8geW91IG1lYW4gRmlyZWZveCBvbiBWaXN0YSB3 aWxsIHRyYW5zbGF0ZSB0aGUgbGluay1sb2NhbCBhZGRyZXNzIHRvIHRoZQ0KZG9tYWluIG5hbWUg c3VmZml4ZWQgJnF1b3Q7aXB2Ni1saXRlcmFsLm5ldCZxdW90Oz88YnI+DQo8YnI+DQpDdXJyZW50 bHkgbXkgcGxhdGZvcm0gaXMgTWljcm9zb2Z0IFdpbmRvd3MgWFAgaW5zdGVhZCBvZiBXaW5kb3dz IFZpc3RhLg0KSG93ZXZlciwgSSBkb24ndCBjb25zaWRlciB0aGlzIGJlaGF2aW9yIGlzIHJlbGF0 ZWQgdG8gdGhlIE9TIHZlcnNpb24uPGJyPg0KPGJyPg0KV2hpY2ggdmVyc2lvbiBpcyB5b3VyIEZp cmVmb3gsIHBsZWFzZT88YnI+DQo8YnI+DQpUaGFua3MuPGJyPg0KQlIsPGJyPg0KWWktV2VuPGJy Pg0KPGJyPg0KQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9Q2FsaWJyaT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZg0KeW91IGFyZSBydW5uaW5n IEZpcmVmb3ggb24gV2luZG93cyBWaXN0YSwgeW91IHNob3VsZCBiZSBhYmxlIHRvIHRyeSA8YQ0K aHJlZj0iaHR0cDovL2ZlODAtLTIxMy00OWZmLWZlMDQtNTA3czguaXB2Ni1saXRlcmFsLm5ldC8i Pmh0dHA6Ly9mZTgwLS0yMTMtNDlmZi1mZTA0LTUwN3M4LmlwdjYtbGl0ZXJhbC5uZXQvPC9hPjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ow0KYm9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3Ig LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIGJsdWUnPg0KDQo8ZGl2Pg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjsNCmJvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0 LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9VGFob21hPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4 dDsNCmZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsYWNrIGZhY2U9VGFob21hPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IDxhDQpo cmVmPSJtYWlsdG86b3duZXItdjZvcHNAb3BzLmlldGYub3JnIj5vd25lci12Nm9wc0BvcHMuaWV0 Zi5vcmc8L2E+IFs8YQ0KaHJlZj0ibWFpbHRvOm93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZyI+bWFp bHRvOm93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZzwvYT5dIDxiPjxzcGFuDQpzdHlsZT0nZm9udC13 ZWlnaHQ6Ym9sZCc+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+Ymx1ZTxicj4NCjxiPjxzcGFuIHN0 eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwvc3Bhbj48L2I+IE1vbmRheSwgRmVicnVhcnkg MDQsIDIwMDgNCjU6MzQgUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ VG86PC9zcGFuPjwvYj4gQnJpYW4gRSBDYXJwZW50ZXI8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gPGENCmhyZWY9Im1haWx0bzp2Nm9wc0BvcHMu aWV0Zi5vcmciPnY2b3BzQG9wcy5pZXRmLm9yZzwvYT48YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0Z3ZDogUmU6IEFib3V0IElQ djYNCnByaXZhdGUgYWRkcmVzc108L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9Ymxh Y2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPlBsZWFzZSBmb3JnaXZlIG15IGR1bWJuZXNzIGJ1dCBt eSBGaXJlZm94IHZlcnNpb24gaXMNCjIuMC4wLjk8YnI+DQo8YnI+DQpNeSBJRSBjb3VsZCBub3Qg Y29ubmVjdCB0byBJUHY2IFVSTCBlaXRoZXIhIChJRSB2ZXJzaW9uIDYuMCk8YnI+DQo8YnI+DQpU aGFua3MuPGJyPg0KQlIsPGJyPg0KWWktV2VuPGJyPg0KPGJyPg0KQnJpYW4gRSBDYXJwZW50ZXIg d3JvdGU6IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwcmU+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+VGhhdCBpcyBhIEZpcmVmb3ggY29uZmlndXJhdGlvbiBpc3N1ZSwgSSB0aGluay4gSSBk b24ndCBzZWUgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz aXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz5wcm9ibGVtICh3aXRoIEZpcmVmaXggMi4wLjAuNywgb3Igd2l0aCBJRSkuPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFj ayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9 YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5J cyBpdCBwb3NzaWJsZSB0aGF0IHlvdXIgYnJvd3NlciBpcyBnb2luZyB0byBhIHByb3h5PzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5i c3A7Jm5ic3A7IEJyaWFuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5PbiAyMDA4LTAyLTA1IDEzOjI0LCBibHVlIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cHJlPjxmb250IHNpemU9Mg0KY29sb3I9 YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9y PWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ QnV0IGFmdGVyIHR5cGluZyBhIGxpbmstbG9jYWwgYWRkcmVzcywgRmlyZWZveCcgbWVzc2FnZSBz aG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNv bG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9 MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZuYnNwOyZuYnNwOyBVbmFibGUgdG8gZmluZCAmcXVvdDs8YQ0KaHJlZj0iaHR0cDov L3d3dy5mZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyUyNTguY29tIj53d3cuZmU4MDo6MjEzOjQ5ZmY6 ZmUwNDo1MDclOC5jb208L2E+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw cmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By ZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5JdCB0cmFuc2xhdGVkIHR5cGVkIDxhDQpocmVmPSJo dHRwOi8vJTVCZmU4MDo6MjEzOjQ5ZmY6ZmUwNDo1MDclMjU4JTVEIj4mcXVvdDtodHRwOi8vW2Zl ODA6OjIxMzo0OWZmOmZlMDQ6NTA3JThdJnF1b3Q7PC9hPiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YQ0KaHJlZj0iaHR0cDovLyU1Qnd3 dy5mZTgwOjoyMTM6NDlmZjpmZTA0OjUwNyUyNTguY29tJTVELyI+JnF1b3Q7aHR0cDovL1t3d3cu ZmU4MDo6MjEzOjQ5ZmY6ZmUwNDo1MDclOC5jb21dLyZxdW90OzwvYT4uPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Ib3dldmVyLCBhIGds b2JhbCB1bmlxdWUgSVB2NiBhZGRyZXNzIHdvcmtlZCE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkkgdGhvdWdodCBpdCBwcm92ZWQgdGhh dCBGaXJlZm94IGRvZXMgbm90IHN1cHBvcnQgbGluay1sb2NhbCBhZGRyZXNzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VGhhbmtzLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9Ymxh Y2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5CUiw8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+WWkt V2VuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xv cj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIg Y29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz5CcmlhbiBFIENhcnBlbnRlciB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w cmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHByZT48Zm9udCBzaXplPTINCmNv bG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+WWVzLCB1c2VycyBuZWVkIHRvIGNvbmZpZ3VyZSBvdXIgZGV2aWNlIHZpYSBodHRwLCBhbmQg aWYgdGhlcmUncyBubzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz aXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz53ZWxsLWtub3duIElQdjYgYWRkcmVzcywgaG93IGRvIHVzZXJzIGtub3cgd2hp Y2ggYWRkcmVzcyB0byBjb25uZWN0IHRvPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48 cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz5JIGhhdmUgdGhvdWdodCBhYm91dCBhIHByZS1jb25maWd1 cmVkIGxpbmstbG9jYWwgYWRkcmVzczsgaG93ZXZlciw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+YnJvd3NlcnMgc3VjaCBhcyBGaXJlZm94IGRv ZXMgbm90IHN1cHBvcnQgbGluay1sb2NhbCBhZGRyZXNzLiBBbnk8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+c3VnZ2VzdGlvbnM/PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0y IGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2txdW90ZT4NCg0K PC9ibG9ja3F1b3RlPg0KDQo8cHJlPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkhvdyBjb21lIEZpcmVmb3gg KG9yIGFueSBvdGhlciBicm93c2VyKSBrbm93cyBob3cgdG8gKm5vdCogc3VwcG9ydDxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5saW5rLWxvY2Fs IGFkZHJlc3Nlcz8gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIGl0IGRvZXMgc3VwcG9ydCB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9Ymxh Y2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5KdXN0 IGRvbid0IGZvcmdldCB0aGUgWyBdIGJyYWNrZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+V2hlbiBJIHRlbGwgRmlyZWZveCB0byBj b25uZWN0IHRvIDxhDQpocmVmPSJodHRwOi8vJTVCZmU4MDo6MSI+aHR0cDovL1tmZTgwOjoxPC9h Pl0vIGl0IGdpdmVzIG1lPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPmFuICZxdW90O3VuYWJsZSB0byBjb25uZWN0JnF1b3Q7IG1lc3NhZ2UsIGJ1 dCB0aGF0J3MgZXhhY3RseSB3aGF0IEknZCBleHBlY3QuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPldoZW4gSSB0ZWxsIEZpcmVmb3ggdG8gY29u bmVjdCB0byA8YQ0KaHJlZj0iaHR0cDovLyU1QmZlODA6OjIxYTphMGZmOmZlNGE6ZDY4MCUyNTUi Pmh0dHA6Ly9bZmU4MDo6MjFhOmEwZmY6ZmU0YTpkNjgwJTU8L2E+XS88bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KG15IG93biBsaW5rLWxvY2Fs IGFkZHJlc3MpIGl0IGdpdmVzIG1lIGEgJnF1b3Q7c2VydmVyIG5vdCBmb3VuZCZxdW90OyBtZXNz YWdlLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29s b3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz53aGljaCBpcyBhbHNvIGV4YWN0bHkgd2hhdCBJJ2QgZXhwZWN0LCBzaW5jZSBJJ20gbm90IGxp c3RlbmluZyBvbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl PTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5wb3J0IDgwLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250 DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48 Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7Jm5ic3A7IEJyaWFuPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2txdW90 ZT4NCg0KPHByZT48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmU+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_AFE0AC8DCDE68842B94E8EC69D5F21D639F24674AFNAEXMSGW602wi_-- From owner-v6ops@ops.ietf.org Tue Feb 5 11:03:31 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id B83F13A7DB1; Tue, 5 Feb 2008 10:38:05 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 0536F3A77AF for ; Mon, 4 Feb 2008 16:29:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMBbh-000HQ7-BM for v6ops-data@psg.com; Tue, 05 Feb 2008 00:24:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,WEIRD_PORT autolearn=no version=3.2.3 Received: from [59.124.183.66] (helo=zyfb01-66.zyxel.com.tw) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMBbe-000HPl-Gc for v6ops@ops.ietf.org; Tue, 05 Feb 2008 00:24:11 +0000 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 08:24:04 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 08:24:04 +0800 Received: from [172.23.17.100] ([172.23.17.100]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 08:24:03 +0800 Message-ID: <47A7ACA4.9040009@zyxel.com.tw> Date: Tue, 05 Feb 2008 08:24:04 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops@ops.ietf.org Subject: Re: [Fwd: Re: About IPv6 private address] References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> In-Reply-To: <47A78679.8030202@gmail.com> Content-Type: multipart/alternative; boundary="------------010209010001040300030704" X-OriginalArrivalTime: 05 Feb 2008 00:24:03.0434 (UTC) FILETIME=[69468CA0:01C8678D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------010209010001040300030704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, But after typing a link-local address, Firefox' message shows: Unable to find "www.fe80::213:49ff:fe04:507%8.com" It translated typed "http://[fe80::213:49ff:fe04:507%8]" to "http://[www.fe80::213:49ff:fe04:507%8.com]/". However, a global unique IPv6 address worked! I thought it proved that Firefox does not support link-local address. Thanks. BR, Yi-Wen Brian E Carpenter wrote: >>>Yes, users need to configure our device via http, and if there's no >>>well-known IPv6 address, how do users know which address to connect to? >>>I have thought about a pre-configured link-local address; however, >>>browsers such as Firefox does not support link-local address. Any >>>suggestions? >>> >>> > >How come Firefox (or any other browser) knows how to *not* support >link-local addresses? As far as I can tell, it does support them. >Just don't forget the [ ] brackets. > >When I tell Firefox to connect to http://[fe80::1]/ it gives me >an "unable to connect" message, but that's exactly what I'd expect. >When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/ >(my own link-local address) it gives me a "server not found" message, >which is also exactly what I'd expect, since I'm not listening on >port 80. > > Brian > > > --------------010209010001040300030704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,
But after typing a link-local address, Firefox' message shows:

    Unable to find "www.fe80::213:49ff:fe04:507%8.com"

It translated typed "http://[fe80::213:49ff:fe04:507%8]" to "http://[www.fe80::213:49ff:fe04:507%8.com]/".

However, a global unique IPv6 address worked!

I thought it proved that Firefox does not support link-local address.

Thanks.
BR,
Yi-Wen

Brian E Carpenter wrote: 
Yes, users need to configure our device via http, and if there's no
well-known IPv6 address, how do users know which address to connect to?
I have thought about a pre-configured link-local address; however,
browsers such as Firefox does not support link-local address. Any
suggestions?
      

How come Firefox (or any other browser) knows how to *not* support
link-local addresses? As far as I can tell, it does support them.
Just don't forget the [ ] brackets.

When I tell Firefox to connect to http://[fe80::1]/ it gives me
an "unable to connect" message, but that's exactly what I'd expect.
When I tell Firefox to connect to http://[fe80::21a:a0ff:fe4a:d680%5]/
(my own link-local address) it gives me a "server not found" message,
which is also exactly what I'd expect, since I'm not listening on
port 80.

    Brian

--------------010209010001040300030704-- From owner-v6ops@ops.ietf.org Tue Feb 5 11:03:58 2008 Return-Path: X-Original-To: v6ops-archive@lists.ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 9AB2F3A7944; Tue, 5 Feb 2008 10:43:10 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 521193A794B for ; Mon, 4 Feb 2008 17:11:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCEx-000LzH-Mj for v6ops-data@psg.com; Tue, 05 Feb 2008 01:04:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, WEIRD_PORT autolearn=no version=3.2.3 Received: from [64.233.184.234] (helo=wr-out-0506.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMCEs-000Lyh-4J for v6ops@ops.ietf.org; Tue, 05 Feb 2008 01:04:46 +0000 Received: by wr-out-0506.google.com with SMTP id c48so1839096wra.23 for ; Mon, 04 Feb 2008 17:04:41 -0800 (PST) Received: by 10.142.128.6 with SMTP id a6mr3912635wfd.206.1202173480144; Mon, 04 Feb 2008 17:04:40 -0800 (PST) Received: by 10.142.77.5 with HTTP; Mon, 4 Feb 2008 17:04:40 -0800 (PST) Message-ID: <67099930802041704t7c28a4dobfa194364039a0f4@mail.gmail.com> Date: Mon, 4 Feb 2008 17:04:40 -0800 From: "Erik Kline" To: blue Subject: Re: [Fwd: Re: About IPv6 private address] Cc: "Brian E Carpenter" , v6ops@ops.ietf.org In-Reply-To: <47A7ACA4.9040009@zyxel.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A68A99.50304@zyxel.com.tw> <67099930802032035m1158b4fcw88b5987ca038e8ae@mail.gmail.com> <47A78679.8030202@gmail.com> <47A7ACA4.9040009@zyxel.com.tw> Sender: owner-v6ops@ops.ietf.org Precedence: bulk I don't seem that same behaviour in my FF 2.0.0.11 Linux browser, fwiw. It seems to be trying to connect. On 2/4/08, blue wrote: > > Hi, > But after typing a link-local address, Firefox' message shows: > > Unable to find "www.fe80::213:49ff:fe04:507%8.com" > > It translated typed "http://[fe80::213:49ff:fe04:507%8]" > to "http://[www.fe80::213:49ff:fe04:507%8.com]/". > > However, a global unique IPv6 address worked! > > I thought it proved that Firefox does not support link-local address. > > Thanks. > BR, > Yi-Wen > > > Brian E Carpenter wrote: > > > Yes, users need to configure our device via http, and if there's no > well-known IPv6 address, how do users know which address to connect to? > I have thought about a pre-configured link-local address; however, > browsers such as Firefox does not support link-local address. Any > suggestions? > > How come Firefox (or any other browser) knows how to *not* support > link-local addresses? As far as I can tell, it does support them. > Just don't forget the [ ] brackets. > > When I tell Firefox to connect to http://[fe80::1]/ it gives me > an "unable to connect" message, but that's exactly what I'd expect. > When I tell Firefox to connect to > http://[fe80::21a:a0ff:fe4a:d680%5]/ > (my own link-local address) it gives me a "server not found" message, > which is also exactly what I'd expect, since I'm not listening on > port 80. > > Brian > > > > From stubnihs1962@2fatcats.co.uk Tue Feb 5 11:04:31 2008 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3E5BD3A77EF; Tue, 5 Feb 2008 10:52:53 -0800 (PST) Received: from client-201.240.143.116.speedy.net.pe (unknown [201.240.143.116]) by mail.ietf.org (Postfix) with ESMTP id 971DA28C850 for ; Tue, 5 Feb 2008 05:54:11 -0800 (PST) Message-ID: <000701c867fe$cdc12340$748ff0c9@ONLINE> From: "he Brickman" To: v6ops-archive@ietf.org Subject: She gives me head EVERY night now that I have such a large pecker Date: Tue, 5 Feb 2008 08:55:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C867D4.E4EB1B40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0003_01C867D4.E4EB1B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yesterday, I banged my ex girlfriend, and she was amazed at how large I = was now ----------=_NextPart_000_0003_01C867D4.E4EB1B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yesterday, I banged my ex = girlfriend, and=20 she was amazed at how large I was now ----------=_NextPart_000_0003_01C867D4.E4EB1B40-- From owner-v6ops@ops.ietf.org Tue Feb 5 15:25:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805063A6C53 for ; Tue, 5 Feb 2008 15:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87NXtkuFuE-2 for ; Tue, 5 Feb 2008 15:25:13 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DB5CA3A7126 for ; Tue, 5 Feb 2008 15:13:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMWrp-000128-3V for v6ops-data@psg.com; Tue, 05 Feb 2008 23:06:17 +0000 Received: from [192.203.228.196] (helo=elvis.mu.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMWrm-00011o-Oz for v6ops@ops.ietf.org; Tue, 05 Feb 2008 23:06:15 +0000 Received: by elvis.mu.org (Postfix, from userid 1098) id 4A7371A4D7E; Tue, 5 Feb 2008 15:06:14 -0800 (PST) Date: Tue, 5 Feb 2008 15:06:14 -0800 From: bill fumerola To: Joe Abley Cc: Christian Huitema , David Conrad , "v6ops@ops.ietf.org" Subject: Re: [Fwd: Re: About IPv6 private address] Message-ID: <20080205230614.GC95402@elvis.mu.org> References: <963CBD8C-C1F3-4BDF-9ADD-6A2B9B199C1B@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963CBD8C-C1F3-4BDF-9ADD-6A2B9B199C1B@ca.afilias.info> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-MUORG-20070725 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Feb 05, 2008 at 08:35:41AM -0500, Joe Abley wrote: > You just know someone on a Windows system is going to publish an URL > at some point that people not on Windows systems are going to follow, > and hilarity is going to result. beyond "not on a windows system". for those who "have to" use it because of a scoped LLADDR, what happens when someone outside the broadcast domain uses it? i agree that this idea is poorly thought out, non-standard, inconsistant, etc. it's not entirely unoriginal. $ host lurgee.local Host lurgee.local not found: 3(NXDOMAIN) $ ping -qc 1 lurgee.local 2>&1 | tail +4 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.270/0.270/0.270/0.000 ms $ uname -a ~ Darwin worrywort.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 what is worse than .local and similar is that as DRC points out .net is an actual TLD whose authority is being oh-so-subtly being railroaded by microsoft. that they registered the domain is nice, but it just adds to the confusion of what exactly happens when this domain is used. do all apps support it? just some using a particular API? yet another ugly hack we now all have to know about and deal with. -- bill From owner-v6ops@ops.ietf.org Tue Feb 5 17:02:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF24E3A6985 for ; Tue, 5 Feb 2008 17:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.092 X-Spam-Level: X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atsLa2cqqlXN for ; Tue, 5 Feb 2008 17:02:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 44ED23A63D3 for ; Tue, 5 Feb 2008 17:01:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMYZ5-000Fp0-9j for v6ops-data@psg.com; Wed, 06 Feb 2008 00:55:03 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMYZ2-000Fo8-N3 for v6ops@ops.ietf.org; Wed, 06 Feb 2008 00:55:01 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 90087204BAF0 for ; Tue, 5 Feb 2008 16:54:59 -0800 (PST) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 7A5692808B for ; Tue, 5 Feb 2008 16:54:59 -0800 (PST) X-AuditID: 11807134-a38e9bb0000008b9-0a-47a905636855 Received: from [17.151.122.95] (unknown [17.151.122.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 5851028088 for ; Tue, 5 Feb 2008 16:54:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <20080205230614.GC95402@elvis.mu.org> References: <963CBD8C-C1F3-4BDF-9ADD-6A2B9B199C1B@ca.afilias.info> <20080205230614.GC95402@elvis.mu.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [Fwd: Re: About IPv6 private address] Date: Tue, 5 Feb 2008 16:54:56 -0800 To: v6ops Operations X-Mailer: Apple Mail (2.753) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 5, 2008, at 15:06, bill fumerola wrote: > > $ host lurgee.local > Host lurgee.local not found: 3(NXDOMAIN) This could be regarded as a bug, but it's a tricky case. The /usr/ bin/host command isn't using the system name resolver. It's distributed with BIND, so it's basically doing the same thing that / usr/bin/dig is doing. It makes DNS queries only. Multicast DNS is derived from DNS, but it's not strictly the same as DNS, so /usr/bin/ host doesn't know anything about it. > $ ping -qc 1 lurgee.local 2>&1 | tail +4 > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.270/0.270/0.270/0.000 ms > $ uname - > a ~ > Darwin worrywort.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct > 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 At least, the .local domain has a long and ignoble history of not being usable as a global TLD in the DNS protocol. Apple was already doing something weird and non-standard with it back in the Mac OS 9 days, when the DNS protocol was young and dinosaurs yet roamed the Internet, so it's not like they polluted an otherwise pure water table by repurposing it for Multicast DNS. Still, IETF does have a problem. There are *two* Multicast DNS protocols. There is RFC 4795 (informational) for Link-Local Multicast Name Resolution, which is implemented in Microsoft products but not much else. And there is , the Multicast DNS protocol in Bonjour, which enjoys widespread industry adoption, in multiple implementations, currently shipping in a myriad of commercial products, but has been languishing as an under-loved individual submission to the DNSEXT working group since before the Great Cataclysm. It would be very nice to have an RFC to which we could point questioners like the originator of this thread and say to them, "Upon this rock we have built our church." Sadly, we can't. I don't know what to do about that. Absent an RFC, I think the best we can do is to tell such questioners, "Good luck. Write if you get work." -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Tue Feb 5 19:41:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5DF3A6890 for ; Tue, 5 Feb 2008 19:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MF46gSgt4TI for ; Tue, 5 Feb 2008 19:41:34 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8D2FA3A67F5 for ; Tue, 5 Feb 2008 19:41:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb4d-0009Qv-A8 for v6ops-data@psg.com; Wed, 06 Feb 2008 03:35:47 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb4a-0009Qa-AZ for v6ops@ops.ietf.org; Wed, 06 Feb 2008 03:35:45 +0000 Received: from [192.168.0.64] (unknown [203.109.213.170]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 4A32D2751C for ; Wed, 6 Feb 2008 16:35:42 +1300 (NZDT) Message-Id: <0A68FEA7-FD91-48F7-AE6B-2FB454131F51@daork.net> From: Nathan Ward To: v6ops Operations In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) Date: Wed, 6 Feb 2008 16:35:41 +1300 References: X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2/02/2008, at 12:52 PM, Alain Durand wrote: > On 2/1/08 4:55 PM, "Jeroen Massar" wrote: > >> Instead of trying to "fix" 6to4, which also has this rather annoying >> issue called NAT which it can't 1,2,3 bypass, why not simply push >> Teredo >> forward which has all these points resolved already? > > The Teredo model, actually from our observation with available code > from its > major source, is that both end need to have it configured to enable a > reliable connection. > > We tried with an open Teredo relay, and packets went sometimes to > Korea, > sometimes nowhere. > > In other words, this is fine to get IPv6 working between 2 PCs in > different > homes separated by NAT boxes, but this is not usable to access a > regular > IPv6 server on the Internet **UNLESS** that server also deploys > Teredo... > > So, going that route, if an IPv6 server wants to offer reliable > service to > customers, it might have to be configured with: > - a regular global IPv6 address to serve regular IPv6 native customers > - a 6to4 address to serve 6to4 customers and avoid open relays > - a Teredo address to serve PC behind NAT box that uses Teredo > > IMHO, this makes the deployment model of new servers a bit complex... I'm unclear as to why a server would need three different addresses, as opposed to one address, and two relays. Rather, I'm unclear as to why that would be an improvement. Deploying relays and a single address looks like: - 6to4 paths: -- client -> server - could be bad -- server -> client - goes through our relay, and over v4 for the long portion of the path - Teredo paths: -- client -> server - goes through our relay, and over v4 for the long portion of the path -- server -> client - goes through our relay, and over v4 for the long portion of the path We can improve that by encouraging ISPs to deploy 6to4 relays today even (especially!) if they don't want to do a full v6 roll out to end users. Like or or not, anyone doing v6 today should be deploying Teredo and 6to4 relays, if they desire their paths to perform well to/from 6to4 and Teredo end users. There are /lots and lots/ of them. My data would even suggest that there are more 6to4 and Teredo users than there are native v6 users, by several orders of magnitude. -- Nathan Ward -- Nathan Ward From owner-v6ops@ops.ietf.org Tue Feb 5 19:42:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628853A6800 for ; Tue, 5 Feb 2008 19:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70VgnNsVJveA for ; Tue, 5 Feb 2008 19:42:19 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 91A843A67F5 for ; Tue, 5 Feb 2008 19:42:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb0u-0008yW-6Q for v6ops-data@psg.com; Wed, 06 Feb 2008 03:31:56 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMb0r-0008yG-DT for v6ops@ops.ietf.org; Wed, 06 Feb 2008 03:31:54 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JMb0o-0004F5-JP for v6ops@ops.ietf.org; Tue, 05 Feb 2008 22:31:50 -0500 Message-ID: <47A92A1A.4060009@ca.afilias.info> Date: Tue, 05 Feb 2008 22:31:38 -0500 From: Brian Dickson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IPv6 Operations Subject: New IDs for consideration/review and time slot request Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-v6ops@ops.ietf.org Precedence: bulk I've put some useful information together into two IDs, which I'm hoping others will find interesting. They could live pretty much anywhere, but I feel it may be most relevant to those in the IPv6 ops community, as that is where the greatest amount of new address assignment growth will be occurring. If there is consensus, they might be suitable for wg documents, with intended Informational status. I would like to request a time slot to present info and do a brief Q & A on both documents, at IETF-71. Hopefully it won't take long to discuss them. Thanks, and as always, questions and comments are welcome. Brian Dickson P.S. Here are the links to the drafts: http://www.ietf.org/internet-drafts/draft-dickson-v6ops-aggregation-00.txt http://www.ietf.org/internet-drafts/draft-dickson-v6ops-assignment-00.txt ----- A new version of I-D, draft-dickson-v6ops-assignment-00.txt has been successfuly submitted by Brian Dickson and posted to the IETF repository. Filename: draft-dickson-v6ops-assignment Revision: 00 Title: A Survey and Analysis of Address Allocation Strategies for IPv4 and IPv6 Creation_date: 2008-02-06 WG ID: Independent Submission Number_of_pages: 18 Abstract: This Internet Draft describes, analyzes, and compares different strategies for allocating addresses, in a way that can be generalized for any power-of-two sized, binary address space. One such strategy is proposed as being "optimal", when viewed from the perspective of space-packing efficiency. This Draft recommends use of this technique as a "Best Current Practice", for both IPv4 and IPv6 address allocations.Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Informational Track for v6ops. ----- A new version of I-D, draft-dickson-v6ops-aggregation-00.txt has been successfuly submitted by Brian Dickson and posted to the IETF repository. Filename: draft-dickson-v6ops-aggregation Revision: 00 Title: Aggregation: Methods and Benefits, for IPv4, IPv6 or other binary addresses Creation_date: 2008-02-06 WG ID: Independent Submission Number_of_pages: 21 Abstract: This Internet Draft discusses general benefits of aggregation, with quantitative examples of different aggregation strategies for the same set of allocations. Recommended "best practices" for service providers and enterprises are listed, as well as "how-to" information.Author's Note This Internet Draft is intended for Informational status, for v6ops or other suitable WG. From owner-v6ops@ops.ietf.org Wed Feb 6 00:55:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9173A3A6B8A for ; Wed, 6 Feb 2008 00:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHH01Nr37gTk for ; Wed, 6 Feb 2008 00:55:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BDEB03A6B7E for ; Wed, 6 Feb 2008 00:55:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMfuO-000Npk-7W for v6ops-data@psg.com; Wed, 06 Feb 2008 08:45:32 +0000 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMfuK-000NnC-0B for v6ops@ops.ietf.org; Wed, 06 Feb 2008 08:45:30 +0000 Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.13.6/8.13.6) with ESMTP id m168i74B033558 for ; Wed, 6 Feb 2008 17:44:08 +0900 (JST) (envelope-from miyata@tahi.org) Received: from localhost (localhost [127.0.0.1]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id m168hweD093170 for ; Wed, 6 Feb 2008 17:43:59 +0900 (JST) (envelope-from miyata@tahi.org) Message-Id: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> From: Hiroshi MIYATA To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Simplified NAT-PT Date: Wed, 6 Feb 2008 17:43:58 +0900 X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, I submitted this document. In this document, I intended to simplify old NAT-PT. It is not yet completed, but I submitted it to introduce the simple translator solution in my mind. My another ID . It was not concrete enough and there were few discussion on it. This "sNAT-PT" is aiming to introduce concrete image of "Current translator model description"in . We have not yet concluded how to work on translator, but I submitted it to make such discussion smoother. -------------------------------------- A new version of I-D, draft-miyata-v6ops-snatpt-00.txt has been successfuly submitted by Hiroshi Miyata and posted to the IETF repository. Filename: draft-miyata-v6ops-snatpt Revision: 00 Title: sNAT-PT: Simplified Network Address Translation - Protocol Translation Creation_date: 2008-02-01 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document specifies an IPv4-to-IPv6 transition mechanism to provide accessibility for IPv6 node to IPv4 node, and vice-versa. The goal of this document is not providing the most fundamental technology which could works well with additional technology. We used to have an technology called NAT-PT[RFC2766]. NAT-PT was designed to work with problematic DNS Application Level Gateway. So, it was changed to historical state by [RFC4966]. This document attempts to simplify NAT-PT specification, removing dependability on Application Layer Gateway as well as resolving problems pointed in [RFC4966]. -------------------------------------- Actually, it is 24 pages, but if you know the original NAT-PT well, you can skip some parts. The major differences from original NAT-PT is as follows. 1) Remove ALG from Original NAT-PT 2) Add conceptual model to clarify the borderline between sAT-PT and ALGs. 3) Propose new Dummy Prefix format. This is aiming neither total nor perfect solution but aiming most basic solution. And it can be extended by additional technologies. The packet translation technique is same as original NAT-PT. Roughly speaking added and updated chapters are 2.5, 3, 4, 9, 10, 11.1, 11.2, 11.3, 13. Thanks for your comment. ....miyata From owner-v6ops@ops.ietf.org Wed Feb 6 04:14:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7043A6BE7 for ; Wed, 6 Feb 2008 04:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0ZOGbmVeaMf for ; Wed, 6 Feb 2008 04:14:18 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id ECA913A6B26 for ; Wed, 6 Feb 2008 04:14:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMj10-0000XW-Id for v6ops-data@psg.com; Wed, 06 Feb 2008 12:04:34 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMj0s-0000W1-PC for v6ops@ops.ietf.org; Wed, 06 Feb 2008 12:04:33 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id E0059C9F; Wed, 6 Feb 2008 13:05:30 +0100 (CET) To: v6ops Operations Subject: Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test) MIME-Version: 1.0 Date: Wed, 6 Feb 2008 13:05:30 +0100 From: Remi Denis-Courmont Organization: Remlab.net In-Reply-To: <0A68FEA7-FD91-48F7-AE6B-2FB454131F51@daork.net> References: <0A68FEA7-FD91-48F7-AE6B-2FB454131F51@daork.net> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 6 Feb 2008 16:35:41 +1300, Nathan Ward wrote: >>> Instead of trying to "fix" 6to4, which also has this rather annoying >>> issue called NAT which it can't 1,2,3 bypass, why not simply push >>> Teredo forward which has all these points resolved already? On the other hand, Teredo has some limitations that 6to4 does not have. For a start, it can only provide one address per end-point. As such, while it can address the "lame automatic 6to4 tunneling" PC problem (e.g. Vista), it won't fix the "lame automatic 6to4 tunneling" access point/router problem (e.g. Airport), as the router would have no prefix to advertise. Then, Teredo requires state, not only on the gateway side, but also on the relay side. Of course, fixing 6to4 to detect firewalls would unavoidably require this too, so this is a lesser issue. >> The Teredo model, actually from our observation with available code >> from its major source, is that both end need to have it configured >> to enable a reliable connection. Yep, that is, both end sites. You can share a single Teredo relay from a native V6CPE for an entire house, or for a whole server farm. >> We tried with an open Teredo relay, and packets went sometimes to >> Korea, sometimes nowhere. There are very few public/global Teredo relays. Indeed, if you don't have your own relay, your path may be very suboptimal. >> In other words, this is fine to get IPv6 working between 2 PCs in >> different >> homes separated by NAT boxes, but this is not usable to access a >> regular >> IPv6 server on the Internet **UNLESS** that server also deploys >> Teredo... The server site would preferably have to have a relay. Not necessarily the server itself. Of course, this is only useful if the server does not have IPv4 at all. If it does have IPv4, then source address selection will go for IPv4 instead of Teredo. >> So, going that route, if an IPv6 server wants to offer reliable >> service to >> customers, it might have to be configured with: >> - a regular global IPv6 address to serve regular IPv6 native customers >> - a 6to4 address to serve 6to4 customers and avoid open relays Even that won't solve most of the problems with 6to4. >> - a Teredo address to serve PC behind NAT box that uses Teredo >> IMHO, this makes the deployment model of new servers a bit complex... > I'm unclear as to why a server would need three different addresses, > as opposed to one address, and two relays. Rather, I'm unclear as to > why that would be an improvement. It would yield different result with source address selection, especially if IPv4 is also available. However, there are practical problems, such as how to put multiple IPv6 addresses with different source address selection labels in the DNS... without breaking down every second IPv6 capable DNS resolver on the client side. -- Rémi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Wed Feb 6 16:09:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32EC3A6EFE for ; Wed, 6 Feb 2008 16:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ+I+f6JH+kk for ; Wed, 6 Feb 2008 16:09:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 01C783A6E93 for ; Wed, 6 Feb 2008 16:09:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMuAb-000KGO-Nc for v6ops-data@psg.com; Wed, 06 Feb 2008 23:59:13 +0000 Received: from [192.203.228.196] (helo=elvis.mu.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMuAZ-000KG2-7i for v6ops@ops.ietf.org; Wed, 06 Feb 2008 23:59:12 +0000 Received: by elvis.mu.org (Postfix, from userid 1098) id E72191A4D7E; Wed, 6 Feb 2008 15:59:10 -0800 (PST) Date: Wed, 6 Feb 2008 15:59:10 -0800 From: bill fumerola To: james woodyatt Cc: v6ops Operations Subject: Re: [Fwd: Re: About IPv6 private address] Message-ID: <20080206235910.GO95402@elvis.mu.org> Reply-To: bill fumerola References: <963CBD8C-C1F3-4BDF-9ADD-6A2B9B199C1B@ca.afilias.info> <20080205230614.GC95402@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-MUORG-20070725 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Feb 05, 2008 at 04:54:56PM -0800, james woodyatt wrote: > On Feb 5, 2008, at 15:06, bill fumerola wrote: > >$ host lurgee.local > >Host lurgee.local not found: 3(NXDOMAIN) > > This could be regarded as a bug, but it's a tricky case. The /usr/ > bin/host command isn't using the system name resolver. It's > distributed with BIND, so it's basically doing the same thing that / > usr/bin/dig is doing. It makes DNS queries only. Multicast DNS is > derived from DNS, but it's not strictly the same as DNS, so /usr/bin/ > host doesn't know anything about it. yep. i used both a command that uses the system's resolver library and one that uses standard dns to parallel my question about just how widespread microsoft's adoption of ipv6-literal.net. e.g. just where does the 'interception' occur? i don't know how many different versions of gethostbyname() microsoft has in their libraries. then again, i shouldn't have to. much like a non-existant .local nameserver can't resolve anyone's requests of .local, ipv6-literal.net cannot resolve anyone's requests of resolution of a lladdr. except requests are going to get further than root servers and now microsoft has partially reinvented AS112 to deal with it. *sigh* > At least, the .local domain has a long and ignoble history of not > being usable as a global TLD in the DNS protocol. Apple was already > doing something weird and non-standard with it back in the Mac OS 9 > days, when the DNS protocol was young and dinosaurs yet roamed the > Internet, so it's not like they polluted an otherwise pure water > table by repurposing it for Multicast DNS. exactly. ipv6-literal.net is the worst of both worlds. > Still, IETF does have a problem. There are *two* Multicast DNS > protocols. There is RFC 4795 (informational) for Link-Local > Multicast Name Resolution, which is implemented in Microsoft products > but not much else. And there is cheshire-dnsext-multicastdns>, the Multicast DNS protocol in Bonjour, > which enjoys widespread industry adoption, in multiple > implementations, currently shipping in a myriad of commercial > products, but has been languishing as an under-loved individual > submission to the DNSEXT working group since before the Great Cataclysm. [ here is where i get off-topic for this WG, reply-to set. ] there can be no argument of the widespread adoption of cheshire-dnsext-multicastdns in implementations, applications, and userbase. given that, are there political landminds associated with trying to updating the draft (at minimum, it's expired) and working with DNSEXT to pick it up as a WG item? cheshire-dnsext-dns-sd as well? time to go read the history in the archives, i guess. -- - bill fumerola / billf@FreeBSD.org From owner-v6ops@ops.ietf.org Wed Feb 6 18:13:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4587A3A6B7C for ; Wed, 6 Feb 2008 18:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.347 X-Spam-Level: X-Spam-Status: No, score=-4.347 tagged_above=-999 required=5 tests=[AWL=2.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiHZ35BorZPc for ; Wed, 6 Feb 2008 18:13:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8E90C3A67ED for ; Wed, 6 Feb 2008 18:13:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMw8a-0006KL-AP for v6ops-data@psg.com; Thu, 07 Feb 2008 02:05:16 +0000 Received: from [209.85.198.190] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMw8X-0006K9-Tc for v6ops@ops.ietf.org; Thu, 07 Feb 2008 02:05:15 +0000 Received: by rv-out-0910.google.com with SMTP id b22so2687390rvf.41 for ; Wed, 06 Feb 2008 18:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=hNSCwjWogH9C+TG9jVaOnaF850iwfp//7+0I6FiSLDw=; b=ZBKCqoqqw7JCf2VgoZ/IA8diTdemXNVGxPLN8MpmczepsnoV1x3hfw6Ma+xINWK8ilIMr+DG7fGj+SXLfFQltwOdBL61uJTCBHDh4MFZqsQYkhRwTrYXnezK3+9xaIN2NKcWzhS9lNeIpOdAV0vXgzQz+oM3oXh8gLBBHb0SU8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qoKl9UGDmYdIiKhBhnZp3CkwZC3hP3rn/mJb6ZFR8p7VwZdAb2UUJ1dHALh5rvJg1UDW19qvXfeZTEjEl6o7IRz7hwZwcN9q0FRq+CsZLzXNH4iyXVjXRmLT6F21xzrjYWY4FjNqH1qdAR01z3wm+dr6kjVeEp4y4knJKQx9tMI= Received: by 10.140.207.2 with SMTP id e2mr7177415rvg.271.1202349913368; Wed, 06 Feb 2008 18:05:13 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id 2sm12608453rvi.32.2008.02.06.18.05.11 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Feb 2008 18:05:12 -0800 (PST) Message-ID: <47AA674E.9070102@gmail.com> Date: Thu, 07 Feb 2008 15:05:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hiroshi MIYATA CC: IPv6 Operations Subject: Re: Simplified NAT-PT References: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> In-Reply-To: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Miyata-san, I haven't completely studied this yet, but I have two quick comments. > The prefix PREFIX::/96 is advertised in the IPv6 network by the > NAT-PT gateway, and packets addressed to this PREFIX will be routed > to the NAT-PT gateway. The pre-configured PREFIX only needs to be > routable within the IPv6 network and as such it can be any routable > prefix that the network administrator chooses. This seems to assume that the NAT-PT is at the boundary between a closed IPv6 routing realm (where it's OK to advertise a /96) and the IPv4 network. What happens if someone needs to put a NAT-PT between a closed IPv4 routing realm and the open IPv6 network? > > The following 32-bit, represented as IDENT MUST be an value assigned > by IANA to indicate that translator would exist in the path. > More requirement for IDENT is described in Chapter 13. Why is this useful? Brian From owner-v6ops@ops.ietf.org Wed Feb 6 19:45:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D388C3A6E17 for ; Wed, 6 Feb 2008 19:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6hUz0dXFWOx for ; Wed, 6 Feb 2008 19:45:14 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 27C063A6DC2 for ; Wed, 6 Feb 2008 19:45:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMxXy-000DvJ-RF for v6ops-data@psg.com; Thu, 07 Feb 2008 03:35:34 +0000 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JMxXw-000Dur-3t for v6ops@ops.ietf.org; Thu, 07 Feb 2008 03:35:33 +0000 Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.13.6/8.13.6) with ESMTP id m173YCEj052467; Thu, 7 Feb 2008 12:34:12 +0900 (JST) (envelope-from miyata@tahi.org) Received: from localhost (localhost [127.0.0.1]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id m173Y3WD008612; Thu, 7 Feb 2008 12:34:03 +0900 (JST) (envelope-from miyata@tahi.org) Cc: IPv6 Operations Message-Id: <9C717E6F-50B4-4B4D-AA8C-B27E037B1D09@tahi.org> From: Hiroshi MIYATA To: Brian E Carpenter In-Reply-To: <47AA674E.9070102@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Simplified NAT-PT Date: Thu, 7 Feb 2008 12:34:02 +0900 References: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> <47AA674E.9070102@gmail.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks Brian for your comment. On 2008/02/07, at 11:05, Brian E Carpenter wrote: > Miyata-san, > > I haven't completely studied this yet, but I have two > quick comments. > >> The prefix PREFIX::/96 is advertised in the IPv6 network by the >> NAT-PT gateway, and packets addressed to this PREFIX will be routed >> to the NAT-PT gateway. The pre-configured PREFIX only needs to be >> routable within the IPv6 network and as such it can be any routable >> prefix that the network administrator chooses. > > This seems to assume that the NAT-PT is at the boundary between > a closed IPv6 routing realm (where it's OK to advertise a /96) > and the IPv4 network. What happens if someone needs to put > a NAT-PT between a closed IPv4 routing realm and the open > IPv6 network? I think advertising /64 is enough. Prefix for routing should be 64-bit. And following 32-bit is indicator used by host to detect the translator. Sorry, my description maybe confusable. > > >> >> The following 32-bit, represented as IDENT MUST be an value >> assigned >> by IANA to indicate that translator would exist in the path. >> More requirement for IDENT is described in Chapter 13. > > Why is this useful? IDENT can help end-node to know the existence of translator. And it must be unique. Then the end-node can have some options. Put dialog to user, quit the session, search other address, etc... If the end-node does not have function to detect the translator, like existing implementation, it would connect to the address. Regards, ...miyata > > > Brian > > From owner-v6ops@ops.ietf.org Thu Feb 7 14:17:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F3E3A790F for ; Thu, 7 Feb 2008 14:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.423 X-Spam-Level: X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=2.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArMfYbHGhjjb for ; Thu, 7 Feb 2008 14:17:41 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 05BF13A7908 for ; Thu, 7 Feb 2008 14:17:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNEtZ-0006WD-JW for v6ops-data@psg.com; Thu, 07 Feb 2008 22:07:01 +0000 Received: from [64.233.184.238] (helo=wr-out-0506.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNEtW-0006Vo-Fp for v6ops@ops.ietf.org; Thu, 07 Feb 2008 22:07:00 +0000 Received: by wr-out-0506.google.com with SMTP id c48so3375171wra.23 for ; Thu, 07 Feb 2008 14:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=paMVPRagEO/ixFK/zCrk6S7ilbve57M1a3eJvQYwoFI=; b=BOniDHSaMjkI9Fjejz4rb2EK4wlCfm/medGFQyTKQe5WzmTSY74Emn9a4UFTlzost7MCzm/XC3s1NYTpZCmX3urs1OiVBhqSdq33ikpLXUBecut81XaHJnFsk3SwCmaxJgrz3Q7abBoLsiQz5C3vFe98bgNGw3nu1g02ilXWtSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kqpnb9OnOxC4ahH2l8WrsV5nPlq8y4j7cd3nYey1+tBSfvl3dxi3/1AnvHAyI6eZfZTYhES0PcA8dpu5Oy4rB/pb6OPWchH5qsr3b/PvX3UezP/2JtRYZcQGVJf6B/xB3EwJgENACl3g0fw21EztMKoihpeqncKaRXclVC0lJsk= Received: by 10.141.193.1 with SMTP id v1mr7967643rvp.73.1202422014347; Thu, 07 Feb 2008 14:06:54 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l17sm11318628rvb.21.2008.02.07.14.06.53 (version=SSLv3 cipher=RC4-MD5); Thu, 07 Feb 2008 14:06:54 -0800 (PST) Message-ID: <47AB80FA.4040309@gmail.com> Date: Fri, 08 Feb 2008 11:06:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hiroshi MIYATA CC: IPv6 Operations Subject: Re: Simplified NAT-PT References: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> <47AA674E.9070102@gmail.com> <9C717E6F-50B4-4B4D-AA8C-B27E037B1D09@tahi.org> In-Reply-To: <9C717E6F-50B4-4B4D-AA8C-B27E037B1D09@tahi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello again, On 2008-02-07 16:34, Hiroshi MIYATA wrote: > Thanks Brian for your comment. > > > > On 2008/02/07, at 11:05, Brian E Carpenter wrote: > >> Miyata-san, >> >> I haven't completely studied this yet, but I have two >> quick comments. >> >>> The prefix PREFIX::/96 is advertised in the IPv6 network by the >>> NAT-PT gateway, and packets addressed to this PREFIX will be routed >>> to the NAT-PT gateway. The pre-configured PREFIX only needs to be >>> routable within the IPv6 network and as such it can be any routable >>> prefix that the network administrator chooses. >> >> This seems to assume that the NAT-PT is at the boundary between >> a closed IPv6 routing realm (where it's OK to advertise a /96) >> and the IPv4 network. What happens if someone needs to put >> a NAT-PT between a closed IPv4 routing realm and the open >> IPv6 network? > > I think advertising /64 is enough. > Prefix for routing should be 64-bit. > And following 32-bit is indicator used by host to detect the translator. > Sorry, my description maybe confusable. But you can't advertise a /64 to the Internet either... >> >> >>> >>> The following 32-bit, represented as IDENT MUST be an value assigned >>> by IANA to indicate that translator would exist in the path. >>> More requirement for IDENT is described in Chapter 13. >> >> Why is this useful? > > IDENT can help end-node to know the existence of translator. > And it must be unique. > Then the end-node can have some options. > Put dialog to user, quit the session, search other address, etc... I don't understand the value of these options. If you wanted the upper layer protocol to calculate "correct" checksums, you could play tricks with these "IDENT" bits to achieve that, I suppose. Brian > If the end-node does not have function to detect the translator, > like existing implementation, it would connect to the address. > > Regards, > > ...miyata > > >> >> >> Brian >> >> > > From owner-v6ops@ops.ietf.org Thu Feb 7 16:08:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307E33A6DF8 for ; Thu, 7 Feb 2008 16:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDsansuJHSa6 for ; Thu, 7 Feb 2008 16:08:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5A80D3A6885 for ; Thu, 7 Feb 2008 16:08:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNGgG-000L53-FR for v6ops-data@psg.com; Fri, 08 Feb 2008 00:01:24 +0000 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNGgD-000L4Y-GG for v6ops@ops.ietf.org; Fri, 08 Feb 2008 00:01:23 +0000 Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.13.6/8.13.6) with ESMTP id m18000Vd072253; Fri, 8 Feb 2008 09:00:01 +0900 (JST) (envelope-from miyata@tahi.org) Received: from localhost (localhost [127.0.0.1]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id m17Nxqu7023982; Fri, 8 Feb 2008 08:59:52 +0900 (JST) (envelope-from miyata@tahi.org) Cc: IPv6 Operations Message-Id: <02971159-353C-4A57-8892-23660F361A67@tahi.org> From: Hiroshi MIYATA To: Brian E Carpenter In-Reply-To: <47AB80FA.4040309@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Simplified NAT-PT Date: Fri, 8 Feb 2008 08:59:52 +0900 References: <89CB7C64-A8A1-4D80-AFAB-881E12CE8FE1@tahi.org> <47AA674E.9070102@gmail.com> <9C717E6F-50B4-4B4D-AA8C-B27E037B1D09@tahi.org> <47AB80FA.4040309@gmail.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, On 2008/02/08, at 7:06, Brian E Carpenter wrote: > Hello again, > > On 2008-02-07 16:34, Hiroshi MIYATA wrote: >> Thanks Brian for your comment. >> >> >> >> On 2008/02/07, at 11:05, Brian E Carpenter wrote: >> >>> Miyata-san, >>> >>> I haven't completely studied this yet, but I have two >>> quick comments. >>> >>>> The prefix PREFIX::/96 is advertised in the IPv6 network by the >>>> NAT-PT gateway, and packets addressed to this PREFIX will be >>>> routed >>>> to the NAT-PT gateway. The pre-configured PREFIX only needs to be >>>> routable within the IPv6 network and as such it can be any >>>> routable >>>> prefix that the network administrator chooses. >>> >>> This seems to assume that the NAT-PT is at the boundary between >>> a closed IPv6 routing realm (where it's OK to advertise a /96) >>> and the IPv4 network. What happens if someone needs to put >>> a NAT-PT between a closed IPv4 routing realm and the open >>> IPv6 network? >> >> I think advertising /64 is enough. >> Prefix for routing should be 64-bit. >> And following 32-bit is indicator used by host to detect the >> translator. >> Sorry, my description maybe confusable. > > But you can't advertise a /64 to the Internet either... Aggregated prefix is also fine. If the packet arrived to the gateway, it works. I think it is same as router who has stab network below. > > >>> >>> >>>> >>>> The following 32-bit, represented as IDENT MUST be an value >>>> assigned >>>> by IANA to indicate that translator would exist in the path. >>>> More requirement for IDENT is described in Chapter 13. >>> >>> Why is this useful? >> >> IDENT can help end-node to know the existence of translator. >> And it must be unique. >> Then the end-node can have some options. >> Put dialog to user, quit the session, search other address, etc... > > I don't understand the value of these options. If you wanted the > upper layer protocol to calculate "correct" checksums, you could > play tricks with these "IDENT" bits to achieve that, I suppose. Yes, above story supposes upper layer action. ;-) Thanks, ....miyata > > > Brian > >> If the end-node does not have function to detect the translator, >> like existing implementation, it would connect to the address. >> >> Regards, >> >> ...miyata >> >> >>> >>> >>> Brian >>> >>> >> >> From owner-v6ops@ops.ietf.org Fri Feb 8 08:39:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D975E28C3A4 for ; Fri, 8 Feb 2008 08:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=1.569, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6M1Ns03AhB5 for ; Fri, 8 Feb 2008 08:39:04 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C205A3A7FBE for ; Fri, 8 Feb 2008 08:39:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNW6u-000HJ7-CO for v6ops-data@psg.com; Fri, 08 Feb 2008 16:29:56 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNW6o-000HIH-M9 for v6ops@ops.ietf.org; Fri, 08 Feb 2008 16:29:51 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 992ED3EA128; Fri, 8 Feb 2008 17:29:49 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 1147A3EA0D8; Fri, 8 Feb 2008 17:29:48 +0100 (CET) Message-ID: <47AC8379.2070305@free.fr> Date: Fri, 08 Feb 2008 17:29:45 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexandru Petrescu CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> In-Reply-To: <47AC577E.8060109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alexandru Petrescu a écrit : > Internet-Drafts@ietf.org wrote: ... : >> draft--remi-despres--ipv6-rapid-deployment--00.txt Pages : >> 19 Date : 2008-02-08 > > Hello Remi and thank you for this draft. I understand the intent is to > have it discussed at IETF. Is the v6ops WG the right venue for this > discussion? I believe this would be a good choice, but there may be considerations I don't know about which WGs discuss what. > From the perspective of the end user, I have a small question on the > decision made by this deployment to deliver a /64 prefix to the end > user. With only a /64 users can not subnet their networks in house, and > use stateless address autoconfiguration at the same time; or, some > users already have IPv4 subnets in-house. > > Is there a possibility to have for example a /56 delivered with 6rd > method to end-user? > > (I'm asking this in light of the existing 6to4 method which allows a > adsl-box to deliver a /48 to end user; it appears more advantageous). Section 3.2 of the draft discusses this issue. /64 is clearly not ideal, but is guaranteed to be possible for ISPs that get only /32 from their RIR's. Free was in this case when they made the first deployment of 6rd. I just learned that they have now a shorter prefix. They will be able to support several subnets per customer site. Regards. Rémi From owner-v6ops@ops.ietf.org Fri Feb 8 10:20:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC9228C38F for ; Fri, 8 Feb 2008 10:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh0J7kJRIqLw for ; Fri, 8 Feb 2008 10:20:36 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8A22D28C1BA for ; Fri, 8 Feb 2008 10:20:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNXjN-000ATd-TD for v6ops-data@psg.com; Fri, 08 Feb 2008 18:13:45 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNXjL-000ATD-AA for v6ops@ops.ietf.org; Fri, 08 Feb 2008 18:13:44 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2008 19:13:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m18IDfhM002212; Fri, 8 Feb 2008 19:13:41 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m18IDVaR013955; Fri, 8 Feb 2008 18:13:33 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 19:13:30 +0100 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 19:13:30 +0100 Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: request for docs submitted for v6ops Date: Fri, 8 Feb 2008 10:13:28 -0800 To: Iljitsch van Beijnum , Brian E Carpenter X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 08 Feb 2008 18:13:30.0495 (UTC) FILETIME=[4F1048F0:01C86A7E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=800; t=1202494422; x=1203358422; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20request=20for=20docs=20submitted=20for=20v6ops |Sender:=20; bh=y10uspst463AiaN71GKq1tqkZWEYeAqXMSDdcw6bcRE=; b=dITt3/Jr+iCJ/p+UMKQg1/Av47oIu8PhcsesbaF+H5Us5QXWBSHvdlMvCN yqQq7o8An2cSmLkT8YJrr6pfyeOvpO0BS5brdGn1PsoV7h6pG/xLkmGhLzeL 5bfakChF2g; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Iljitsch and Brian, and more generally the working group We have had a convention in the IETF on draft names for some time. Names fall in three categories: draft-ietf---.txt: drafts adopted by a working group draft----.txt drafts the author would like to discuss in a WG draft---.txt drafts that the author doesn't know what to do with You guys have drafts named in the third category, meaning that when I go looking for drafts for my agenda or to somehow shepherd in v6ops I miss them. Please, you drafts (which have to be updated by next Friday if -00) are for discussion in v6ops at least at the present. Would you be so kind as to name them in the second category? From owner-v6ops@ops.ietf.org Mon Feb 11 10:10:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE923A6AFB for ; Mon, 11 Feb 2008 10:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiZJalKzTdLX for ; Mon, 11 Feb 2008 10:10:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9D67F3A6D09 for ; Mon, 11 Feb 2008 10:10:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOd0l-000J1b-DM for v6ops-data@psg.com; Mon, 11 Feb 2008 18:04:11 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOd0h-000J0s-EW for v6ops@ops.ietf.org; Mon, 11 Feb 2008 18:04:09 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2008 19:04:06 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1BI46pB028185 for ; Mon, 11 Feb 2008 19:04:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1BI46aR009695 for ; Mon, 11 Feb 2008 18:04:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 19:04:06 +0100 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 19:04:05 +0100 Mime-Version: 1.0 (Apple Message framework v753) References: <20080209085845.682F53A8176@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Initial agenda for IETF 71 Date: Mon, 11 Feb 2008 10:04:03 -0800 To: v6ops@ops.ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Feb 2008 18:04:06.0088 (UTC) FILETIME=[7DE3DC80:01C86CD8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2079; t=1202753046; x=1203617046; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Initial=20agenda=20for=20IETF=2071 |Sender:=20; bh=V94+dYcqYVtkw7N0yEJGUeXFfvyfpY09Kea4+2zhmxQ=; b=EJa7VPeuaoW08uVoRNb1SOowcOMY40HO14qP58taURSpA6aO6V5A0bDQYo rut+I+RyJJiPRFHt/X7dCtXT+/RGc36Os/e1OKWnbvvbtXoC61wni2pRY0W9 7YBPwzQvaR; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. I asked for two sessions, one of 2.5 and one of 2 hours, and got two 2-hour sessions. > V6OPS Session 1 (2.5 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Breakout Room > ---------------------------------------------- > V6OPS Session 2 (2 hours) > Wednesday, Morning Session I 0900-1130 > Room Name: Breakout Room > ---------------------------------------------- The agenda items include the following. Note that I include a couple of drafts for which I have been promised updates (this week for -00, by next week otherwise). I would recommend reading these in advance, so that the discussion is fruitful. Tuesday: transition session Key objective: nail down transition expectations/requirements draft-jcurran-v6transitionplan draft-bagnulo-v6ops-6man-nat64-pb-statement draft-stenberg-v6ops-pd-route-maintenance draft-durand-v6ops-natv4v6v4 draft-despres-v6ops-6rd-ipv6-rapid-deployment Iljitsch and Brian's merged proposal draft-miyata-v6ops-snatpt draft-miyata-v6ops-trans-approach Wednesday: general session Brian Dickson's suggestions draft-dickson-v6ops-aggregation draft-dickson-v6ops-assignment The RA discussion draft-chown-v6ops-rogue-ra if Tim updates it draft-vandevelde-v6ops-ra-guard CPE question Gunter's not-yet-submitted CPE-default-route-detection draft-ietf-v6ops-cpe-simple-security - ----------------------------------------------------- I did not include the two Teredo updates: draft-ietf-v6ops-teredo-security-concerns draft-krishnan-v6ops-teredo-update Since we are discussing these in v6ops, I am waiting for an update to the security-concerns document, and then will ask for last call comments on both. The "Teredo Update" may be sponsored by Mark Townsley, who sponsored Teredo. -----BEGIN PGP SIGNATURE----- iD8DBQFHsI4TbjEdbHIsm0MRAg+uAKCoXkdaqE5zCFApX9QowDLLidiVwQCg3PiR dwuHvAyePEzRKrCUpy8zRvA= =rD1x -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Feb 11 11:17:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D64C3A6C90 for ; Mon, 11 Feb 2008 11:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.97 X-Spam-Level: X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[AWL=2.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUrHbGlIWpDi for ; Mon, 11 Feb 2008 11:17:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 55F1A3A6D97 for ; Mon, 11 Feb 2008 11:17:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOe6g-00017L-Ps for v6ops-data@psg.com; Mon, 11 Feb 2008 19:14:23 +0000 Received: from [2001:4f8:3:ba:202:b3ff:fe8a:605] (helo=felix.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOe6e-000174-BT for v6ops@ops.ietf.org; Mon, 11 Feb 2008 19:14:21 +0000 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by felix.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JOe6a-0003Jt-K4; Mon, 11 Feb 2008 19:14:19 +0000 Cc: v6ops@ops.ietf.org Message-Id: <2CC5A353-C27E-43CF-A204-887EFD8FDC6C@ca.afilias.info> From: Joe Abley To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Initial agenda for IETF 71 Date: Mon, 11 Feb 2008 14:14:14 -0500 References: <20080209085845.682F53A8176@core3.amsl.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 11-Feb-2008, at 13:04, Fred Baker wrote: > FYI. I asked for two sessions, one of 2.5 and one of 2 hours, and > got two 2-hour sessions. > >> V6OPS Session 1 (2.5 hours) >> Tuesday, Afternoon Session I 1300-1500 >> Room Name: Breakout Room This one says 2.5 hours, but the times indicate 2 hours... >> ---------------------------------------------- >> V6OPS Session 2 (2 hours) >> Wednesday, Morning Session I 0900-1130 >> Room Name: Breakout Room >> ---------------------------------------------- ... and this one says 2 hours, but the times indicate 2.5. Your note at the top of the quoted session says "two 2-hour sessions". So I'm confused :-) Joe From owner-v6ops@ops.ietf.org Mon Feb 11 11:34:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D293A6C40 for ; Mon, 11 Feb 2008 11:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGi1aTcDfpV5 for ; Mon, 11 Feb 2008 11:34:44 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6C9653A6AF8 for ; Mon, 11 Feb 2008 11:34:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOePe-0003EK-6c for v6ops-data@psg.com; Mon, 11 Feb 2008 19:33:58 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOePb-0003Dz-Mh for v6ops@ops.ietf.org; Mon, 11 Feb 2008 19:33:56 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Feb 2008 20:33:54 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1BJXsjq012780; Mon, 11 Feb 2008 20:33:54 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1BJXoaT003583; Mon, 11 Feb 2008 19:33:54 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 20:33:48 +0100 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 20:33:47 +0100 In-Reply-To: <2CC5A353-C27E-43CF-A204-887EFD8FDC6C@ca.afilias.info> References: <20080209085845.682F53A8176@core3.amsl.com> <2CC5A353-C27E-43CF-A204-887EFD8FDC6C@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50124724-5CF2-4BA5-8C1E-6B0BF728F8BB@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Initial agenda for IETF 71 Date: Mon, 11 Feb 2008 11:33:37 -0800 To: Joe Abley X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Feb 2008 19:33:47.0709 (UTC) FILETIME=[05960ED0:01C86CE5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=440; t=1202758434; x=1203622434; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Initial=20agenda=20for=20IETF=2071 |Sender:=20; bh=Vjwgb70iRdU+eXC2/C0uYyuKZ8gMRVPWOOqA6HpAo8A=; b=gJYQA5om+UcuGYkD4obuVugbiW7X11lm76DNw5efAraB04HC+6gII+oDWM OKt3R2kuofN/m9tEyosfOBi6x9YBOqrDa4EWGf2qztDj41z199WByl5Nbp1D eCtF+6jW1f; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 11, 2008, at 11:14 AM, Joe Abley wrote: > So I'm confused :-) The obvious question has been placed to agenda@. I asked for, and would prefer, 2.5 hours for the transition session - at 15 minutes per topic, it's pretty full. Stay tuned. -----BEGIN PGP SIGNATURE----- iD8DBQFHsKMRbjEdbHIsm0MRAgPFAJ9x6VUrX4Q4Kr1LQlnH0jtYR83FfwCcDYRZ sLzY7OX/Q/KJnmgX04p6J9Q= =DRwN -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Feb 11 12:21:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7885928C1D2 for ; Mon, 11 Feb 2008 12:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=2.338, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVagLamf+KH6 for ; Mon, 11 Feb 2008 12:21:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DB87328C33F for ; Mon, 11 Feb 2008 12:19:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOf4F-00094j-8u for v6ops-data@psg.com; Mon, 11 Feb 2008 20:15:55 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOf4B-00092T-TR for v6ops@ops.ietf.org; Mon, 11 Feb 2008 20:15:53 +0000 Received: from [192.168.0.192] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1BKFBoI023968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Feb 2008 21:15:13 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: v6ops WG Message-Id: <11F253CB-05D7-40EB-A2E6-3EF23A96F541@muada.com> From: Iljitsch van Beijnum To: Fred Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Initial agenda for IETF 71 Date: Mon, 11 Feb 2008 21:15:27 +0100 References: <20080209085845.682F53A8176@core3.amsl.com> X-Mailer: Apple Mail (2.915) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 11 feb 2008, at 19:04, Fred Baker wrote: > The agenda items include the following. Note that I include a couple > of drafts for which I have been promised updates (this week for -00, > by next week otherwise). Note that according to: http://www.ietf.org/meetings/71-cutoff_dates.html the -00 cutoff isn't until monday: February 18, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 ET (22:00 UTC/GMT), upload using IETF ID Submission Tool. > Iljitsch and Brian's merged proposal The new name is draft-v6ops-van-beijnum-mnat-pt-00 From owner-v6ops@ops.ietf.org Mon Feb 11 20:54:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D429428CA6B for ; Mon, 11 Feb 2008 20:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnQjwo9WQFn4 for ; Mon, 11 Feb 2008 20:54:43 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id F2A073A6802 for ; Mon, 11 Feb 2008 20:54:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOn2i-000Cyw-3T for v6ops-data@psg.com; Tue, 12 Feb 2008 04:46:52 +0000 Received: from [66.249.82.228] (helo=wx-out-0506.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOn2f-000CyU-4C for v6ops@ops.ietf.org; Tue, 12 Feb 2008 04:46:50 +0000 Received: by wx-out-0506.google.com with SMTP id s9so4939676wxc.32 for ; Mon, 11 Feb 2008 20:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=j5UwhkSdLaLC3xWLYiF/8ZT6hyvX7rvIuwBPiCWdx+k=; b=iCeTxf82ebmVrKo6rE5H9wbcJOQS8c05hv5wPU+aNnqskX7vENg/i2DMu6yDHE2+wK/d6tF147/ndC/1/19aQJAv3K6l2VXqa6pleqS1CNyDSXFSykvDELs3gEMIgPlQMvEnk1X80Ropn+x6UNWX/HI30sWE5wCPq6ZQc/DVIV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XlU4pJd1kzWioBJUMOVI5KW4rpeJsLt4WDvMQdhwELjqSUekQGWv/2onuHlMF0/hq/+uB+hA98qlYSaJ///NEfrAKEf/g20X4rujspfzuZ0Tb1VxuloP+xrXQlX1+JjBKeMkmv6D0YKl1/9eRSODeNO2XNQKrJ0O7Aif6ECsMpY= Received: by 10.142.99.21 with SMTP id w21mr674724wfb.108.1202791605540; Mon, 11 Feb 2008 20:46:45 -0800 (PST) Received: by 10.142.102.19 with HTTP; Mon, 11 Feb 2008 20:46:45 -0800 (PST) Message-ID: <77ead0ec0802112046l7f0598cbj5b0ec4b727e1f2b7@mail.gmail.com> Date: Mon, 11 Feb 2008 20:46:45 -0800 From: "Vishwas Manral" To: "Fred Baker" Subject: Re: Initial agenda for IETF 71 Cc: v6ops@ops.ietf.org, "Samita Chakrabarti" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080209085845.682F53A8176@core3.amsl.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, I have a draft which I would want to be presented. It is the 6PE-Alt draft which was recently discussed on this list. http://www.ietf.org/internet-drafts/draft-manral-idr-mpls-explicit-null-00.txt One of my colleague Samita will be there in the IETF and she will be able to present it. Is there a way I can get a slot for the same. Thanks, Vishwas On Feb 11, 2008 10:04 AM, Fred Baker wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI. I asked for two sessions, one of 2.5 and one of 2 hours, and got > two 2-hour sessions. > > > V6OPS Session 1 (2.5 hours) > > Tuesday, Afternoon Session I 1300-1500 > > Room Name: Breakout Room > > ---------------------------------------------- > > V6OPS Session 2 (2 hours) > > Wednesday, Morning Session I 0900-1130 > > Room Name: Breakout Room > > ---------------------------------------------- > > > The agenda items include the following. Note that I include a couple > of drafts for which I have been promised updates (this week for -00, > by next week otherwise). I would recommend reading these in advance, > so that the discussion is fruitful. > > Tuesday: transition session > Key objective: nail down transition expectations/requirements > draft-jcurran-v6transitionplan > draft-bagnulo-v6ops-6man-nat64-pb-statement > draft-stenberg-v6ops-pd-route-maintenance > > draft-durand-v6ops-natv4v6v4 > draft-despres-v6ops-6rd-ipv6-rapid-deployment > Iljitsch and Brian's merged proposal > draft-miyata-v6ops-snatpt > draft-miyata-v6ops-trans-approach > > Wednesday: general session > Brian Dickson's suggestions > draft-dickson-v6ops-aggregation > draft-dickson-v6ops-assignment > > The RA discussion > draft-chown-v6ops-rogue-ra if Tim updates it > draft-vandevelde-v6ops-ra-guard > > CPE question > Gunter's not-yet-submitted CPE-default-route-detection > draft-ietf-v6ops-cpe-simple-security > > > - ----------------------------------------------------- > I did not include the two Teredo updates: > draft-ietf-v6ops-teredo-security-concerns > draft-krishnan-v6ops-teredo-update > > Since we are discussing these in v6ops, I am waiting for an update to > the security-concerns document, and then will ask for last call > comments on both. The "Teredo Update" may be sponsored by Mark > Townsley, who sponsored Teredo. > -----BEGIN PGP SIGNATURE----- > > iD8DBQFHsI4TbjEdbHIsm0MRAg+uAKCoXkdaqE5zCFApX9QowDLLidiVwQCg3PiR > dwuHvAyePEzRKrCUpy8zRvA= > =rD1x > -----END PGP SIGNATURE----- > > From owner-v6ops@ops.ietf.org Tue Feb 12 02:37:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC24528C18A for ; Tue, 12 Feb 2008 02:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[AWL=1.682, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbq5iHc80WAo for ; Tue, 12 Feb 2008 02:37:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1F9FA28C118 for ; Tue, 12 Feb 2008 02:37:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOsOF-000CbJ-9Y for v6ops-data@psg.com; Tue, 12 Feb 2008 10:29:27 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOsOC-000Caq-NP for v6ops@ops.ietf.org; Tue, 12 Feb 2008 10:29:25 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 79ADD3EA109 for ; Tue, 12 Feb 2008 11:29:23 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id EC11D3EA0C9 for ; Tue, 12 Feb 2008 11:29:20 +0100 (CET) Message-ID: <47B174FF.10505@free.fr> Date: Tue, 12 Feb 2008 11:29:19 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> In-Reply-To: <47AC577E.8060109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk The I-D is available at: http://www.ietf.org/internet-drafts/draft-despres-v6ops-6rd-ipv6-rapid-deployment-00.txt (A previous file name had to be replaced by this one, more compatible with recommended practices, and including the now selected WG reference) Rémi From owner-v6ops@ops.ietf.org Tue Feb 12 07:01:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F2028CC3F for ; Tue, 12 Feb 2008 07:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrqFJXkIuY6j for ; Tue, 12 Feb 2008 07:01:41 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B212B28C222 for ; Tue, 12 Feb 2008 06:59:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOwUE-000EFo-Ui for v6ops-data@psg.com; Tue, 12 Feb 2008 14:51:54 +0000 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOwU8-000ED7-A3 for v6ops@ops.ietf.org; Tue, 12 Feb 2008 14:51:50 +0000 X-ECS-MailScanner-Watermark: 1203432697.84344@v7pYLK/m3DPsLOEZaJf38g Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe78:67b5]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m1CEpbDb011192 for ; Tue, 12 Feb 2008 14:51:37 GMT X-ECS-MailScanner-Watermark: 1203432361.55357@0oRjbKTyF+21atzcwSDkxQ Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m1CEjuch006425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 14:45:58 GMT Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m1CEpKTc012648 for ; Tue, 12 Feb 2008 14:51:21 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m1CEpKBI012647 for v6ops@ops.ietf.org; Tue, 12 Feb 2008 14:51:20 GMT Date: Tue, 12 Feb 2008 14:51:20 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: rogue RA problem statement Message-ID: <20080212145120.GL30232@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20080209085845.682F53A8176@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk (subject line updated) On Mon, Feb 11, 2008 at 10:04:03AM -0800, Fred Baker wrote: > > The RA discussion > draft-chown-v6ops-rogue-ra if Tim updates it > draft-vandevelde-v6ops-ra-guard Hi, On the rogue RA problem statement, Stig and I don't feel there is much point in an update at this stage, and also that presenting the same issue for a 3rd time would be beneficial. Looking back on IETF70 minutes (I wasn't there) they say: http://tools.ietf.org/wg/v6ops/minutes which boils down to 'use SEND' on one hand, and some support from Iljitsch and Francis on the other. We're seeing more instances of the problem being reported, e.g. on the Internet2 list yesterday as a result of the Joint Techs meeting. We're seeing the problem resurface on our own network (some 1500 dual-stack hosts on wired and wireless access). The most recent last week was a Vista machine that somehow didn't pick up the real online RA, and chose to become a 6to4 router as a result (apparently... we'll try to recreate this one). I think there's various underlying issues here. 1) Not everyone will deploy SEND, in fact maybe very few networks will. It would be useful for some SEND fud to perhaps be wiped away, since at present it seems 'up there' with Authenticated DHCP for deployment as far as the people I ask reply. 2) Rogue RAs can happen for various accidental or malicious reasons, so monitoring your link for 'bad' RAs is prudent regardless. We've looked at rafixd and are working on some improvements to that as a monitoring and possibly corrective tool. This can be rolled into monitoring as per ndpmon, perhaps. So these are new things that should be detectable. 3) There are 'simple' fixes that could be made available today, e.g. a switch option to en/disable RAs inbound per switch/stack or per port, which would help just as MLD snooping can do, or DHCP blocking today. 4) The issues with RAs are why people seem keen to use DHCPv6, and the same people do ask about DHCPv6 default router options (regardless of the (lack of) security with DHCPv6 itself). Now, I think (4) is contentious but there could be progress on (1)-(3). Anyway, perhaps the list could guide on updates to the problem statement, and what it says (loosely) about solution spaces. Obviously Gunter is working a little separately on RA Guard as one possible solution. -- Tim From owner-v6ops@ops.ietf.org Tue Feb 12 08:01:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C8B28C1FF for ; Tue, 12 Feb 2008 08:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB4WEhTJqUkC for ; Tue, 12 Feb 2008 08:01:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5043528C2FE for ; Tue, 12 Feb 2008 07:59:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxTG-000LaF-NH for v6ops-data@psg.com; Tue, 12 Feb 2008 15:54:58 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxT9-000LZH-K4 for v6ops@ops.ietf.org; Tue, 12 Feb 2008 15:54:53 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id E62D084A85; Tue, 12 Feb 2008 16:54:49 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ynq+h1nx24kv; Tue, 12 Feb 2008 16:54:43 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id EE0D08480A; Tue, 12 Feb 2008 16:54:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id ECD47845D5; Tue, 12 Feb 2008 16:54:43 +0100 (CET) Date: Tue, 12 Feb 2008 16:54:43 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: rogue RA problem statement In-Reply-To: <20080212145120.GL30232@login.ecs.soton.ac.uk> Message-ID: <20080212163720.B473@mignon.ki.iif.hu> References: <20080209085845.682F53A8176@core3.amsl.com> <20080212145120.GL30232@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 12 Feb 2008, Tim Chown wrote: > (subject line updated) > > On Mon, Feb 11, 2008 at 10:04:03AM -0800, Fred Baker wrote: >> >> The RA discussion >> draft-chown-v6ops-rogue-ra if Tim updates it >> draft-vandevelde-v6ops-ra-guard > > Hi, > > On the rogue RA problem statement, Stig and I don't feel there is much > point in an update at this stage, and also that presenting the same > issue for a 3rd time would be beneficial. > > Looking back on IETF70 minutes (I wasn't there) they say: > http://tools.ietf.org/wg/v6ops/minutes > > which boils down to 'use SEND' on one hand, and some support from > Iljitsch and Francis on the other. > > We're seeing more instances of the problem being reported, e.g. on the > Internet2 list yesterday as a result of the Joint Techs meeting. > > We're seeing the problem resurface on our own network (some 1500 dual-stack > hosts on wired and wireless access). The most recent last week was a > Vista machine that somehow didn't pick up the real online RA, and chose > to become a 6to4 router as a result (apparently... we'll try to recreate > this one). > > I think there's various underlying issues here. > > 1) Not everyone will deploy SEND, in fact maybe very few networks will. > It would be useful for some SEND fud to perhaps be wiped away, since at > present it seems 'up there' with Authenticated DHCP for deployment as > far as the people I ask reply. > > 2) Rogue RAs can happen for various accidental or malicious reasons, so > monitoring your link for 'bad' RAs is prudent regardless. We've looked > at rafixd and are working on some improvements to that as a monitoring > and possibly corrective tool. This can be rolled into monitoring as > per ndpmon, perhaps. So these are new things that should be detectable. > > 3) There are 'simple' fixes that could be made available today, e.g. a > switch option to en/disable RAs inbound per switch/stack or per port, > which would help just as MLD snooping can do, or DHCP blocking today. For this one we proposed with Gunter in draft-vandevelde-v6ops-ra-guard. > > 4) The issues with RAs are why people seem keen to use DHCPv6, and the > same people do ask about DHCPv6 default router options (regardless of > the (lack of) security with DHCPv6 itself). Currently the DHCPv6 is rather loosely integrated in most of the operating systems.... Maybe one option would be combining the two drafts.... Best Regards, Janos From owner-v6ops@ops.ietf.org Tue Feb 12 08:23:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493743A6E65 for ; Tue, 12 Feb 2008 08:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNCFzPUTrYMh for ; Tue, 12 Feb 2008 08:23:15 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6D4E93A6E61 for ; Tue, 12 Feb 2008 08:23:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxt5-000OmC-1X for v6ops-data@psg.com; Tue, 12 Feb 2008 16:21:39 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxt2-000Olk-Fz for v6ops@ops.ietf.org; Tue, 12 Feb 2008 16:21:37 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2008 17:21:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1CGLZDl014742; Tue, 12 Feb 2008 17:21:35 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1CGLZW9018240; Tue, 12 Feb 2008 16:21:35 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 17:21:34 +0100 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 17:21:34 +0100 In-Reply-To: <20080212145120.GL30232@login.ecs.soton.ac.uk> References: <20080209085845.682F53A8176@core3.amsl.com> <20080212145120.GL30232@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: rogue RA problem statement Date: Tue, 12 Feb 2008 08:21:27 -0800 To: Tim Chown X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 12 Feb 2008 16:21:34.0367 (UTC) FILETIME=[55977AF0:01C86D93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=202; t=1202833295; x=1203697295; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20rogue=20RA=20problem=20statement |Sender:=20; bh=e0l36S89FCMpjDw/nVGR47kv1JmmhziLF7xmh2cRliM=; b=f4xZa+5dq/CHjxyyqWKTUFhEwty7n2TVv/6mou0Kri9ZiIlkWq11/FULSH c89VDHwqeQlF9JkZ0VoywCclFEEE6OIAbRmcyt7u8/lTR/6YCjs2NNTTJ3Wd 11HwViTU6F; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Feb 12, 2008, at 6:51 AM, Tim Chown wrote: > Anyway, perhaps the list could guide on updates to the problem > statement, > and what it says (loosely) about solution spaces. wfm. thanks. From owner-v6ops@ops.ietf.org Tue Feb 12 09:25:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950143A6C55 for ; Tue, 12 Feb 2008 09:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IOr3tK+5SzI for ; Tue, 12 Feb 2008 09:25:44 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D201428C2EF for ; Tue, 12 Feb 2008 09:25:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOyl8-00050g-0U for v6ops-data@psg.com; Tue, 12 Feb 2008 17:17:30 +0000 Received: from [131.107.115.212] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOyl5-000501-Mw for v6ops@ops.ietf.org; Tue, 12 Feb 2008 17:17:28 +0000 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 12 Feb 2008 09:17:27 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.1.240.5; Tue, 12 Feb 2008 09:17:26 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Tue, 12 Feb 2008 09:17:41 -0800 From: Christian Huitema To: Mohacsi Janos , Tim Chown CC: "v6ops@ops.ietf.org" Date: Tue, 12 Feb 2008 09:17:23 -0800 Subject: RE: rogue RA problem statement Thread-Topic: rogue RA problem statement Thread-Index: AchtkY+1rJycHqM5SuOs4w6gV2gjdAACUeDg Message-ID: References: <20080209085845.682F53A8176@core3.amsl.com> <20080212145120.GL30232@login.ecs.soton.ac.uk> <20080212163720.B473@mignon.ki.iif.hu> In-Reply-To: <20080212163720.B473@mignon.ki.iif.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > 4) The issues with RAs are why people seem keen to use DHCPv6, and the > > same people do ask about DHCPv6 default router options (regardless of > > the (lack of) security with DHCPv6 itself). > > Currently the DHCPv6 is rather loosely integrated in most of the > operating systems.... It would be interesting to compare practical solutions to "Rogue RA" and "D= HCPv6 spoofing". Is one harder than the other, and why? -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Feb 12 10:41:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3F628C289 for ; Tue, 12 Feb 2008 10:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.477 X-Spam-Level: X-Spam-Status: No, score=-4.477 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NilG5rjKbBxv for ; Tue, 12 Feb 2008 10:41:21 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B4AB228C377 for ; Tue, 12 Feb 2008 10:41:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOzuh-000EgS-Cq for v6ops-data@psg.com; Tue, 12 Feb 2008 18:31:27 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOzub-000Efx-PU for v6ops@ops.ietf.org; Tue, 12 Feb 2008 18:31:22 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 855AF3EA0CA; Tue, 12 Feb 2008 19:31:20 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id EE7B83EA0E0; Tue, 12 Feb 2008 19:31:13 +0100 (CET) Message-ID: <47B1E5F0.5080801@free.fr> Date: Tue, 12 Feb 2008 19:31:12 +0100 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Anand Kumria CC: v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <971f65790802120930h3484344ep1dbf13593b081475@mail.gmail.com> In-Reply-To: <971f65790802120930h3484344ep1dbf13593b081475@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Anand Kumria wrote : > Hi Rémi, > > On 2/12/08, Rémi Després wrote: >> The I-D is available at: >> http://www.ietf.org/internet-d​rafts/draft-despres-v6ops-6rd-i​pv6-rapid-deployment-00.txt > > Perhaps I am being very dense but how does this work, considering: > > - you (free.fr) have a /32 from RIPE-NCC > - you have a IPv4 address (for the CPE) encoded in 32 bits > > The network portion of your 64 bits is now gone. Yes. Until Free a shorter prefix than /32 frpm the RIPE, their customer sites have only one IPv6 link (but this is sufficient to most). Now that Free has received a shorter prefix they can change their 6rd ISP prefix and will be able to permit multiple subnets in their customer sites. > You've lost the ability to specify your IPv6 6rd prefix? > > I realise that you've set aside a portion your the address space > contained with the (i.e. RIPE-NCC+110/36) to be what you use for > "Pure" IPv6 so, what do you specify to your CPEs as the 6rd ISP > prefix? The whole /32 allocation? The 6rd ISP prefix is the /32 itself. Since none of the v4 addresses they assign starts with 1110 there is no confusion. Rémi From owner-v6ops@ops.ietf.org Tue Feb 12 11:32:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D5228C3C9 for ; Tue, 12 Feb 2008 11:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DM4N4293QSg for ; Tue, 12 Feb 2008 11:32:18 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D6E1F28C208 for ; Tue, 12 Feb 2008 11:32:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP0ne-000LH2-NQ for v6ops-data@psg.com; Tue, 12 Feb 2008 19:28:14 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP0nb-000LGn-Sq for v6ops@ops.ietf.org; Tue, 12 Feb 2008 19:28:13 +0000 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 12 Feb 2008 11:28:11 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.1.240.5; Tue, 12 Feb 2008 11:28:11 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Tue, 12 Feb 2008 11:28:06 -0800 From: "Deepak Bansal (NETWORKING)" To: Mohacsi Janos , Tim Chown CC: "v6ops@ops.ietf.org" Date: Tue, 12 Feb 2008 11:27:50 -0800 Subject: RE: rogue RA problem statement Thread-Topic: rogue RA problem statement Thread-Index: AchtkY+1rJycHqM5SuOs4w6gV2gjdAAFgPFA Message-ID: <6607C4545FAB804B97733F82D20E0D085435FA54A2@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> References: <20080209085845.682F53A8176@core3.amsl.com> <20080212145120.GL30232@login.ecs.soton.ac.uk> <20080212163720.B473@mignon.ki.iif.hu> In-Reply-To: <20080212163720.B473@mignon.ki.iif.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >The most recent last week was a > Vista machine that somehow didn't pick up the real online RA, and chose > to become a 6to4 router as a result (apparently... we'll try to recreate > this one). Vista will not become a 6to4 router unless ICS is enabled on it. Hence, I s= uspect that the Vista machine in discussion here somehow had ICS enabled on= it. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of Mohacsi Janos Sent: Tuesday, February 12, 2008 7:55 AM To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: rogue RA problem statement On Tue, 12 Feb 2008, Tim Chown wrote: > (subject line updated) > > On Mon, Feb 11, 2008 at 10:04:03AM -0800, Fred Baker wrote: >> >> The RA discussion >> draft-chown-v6ops-rogue-ra if Tim updates it >> draft-vandevelde-v6ops-ra-guard > > Hi, > > On the rogue RA problem statement, Stig and I don't feel there is much > point in an update at this stage, and also that presenting the same > issue for a 3rd time would be beneficial. > > Looking back on IETF70 minutes (I wasn't there) they say: > http://tools.ietf.org/wg/v6ops/minutes > > which boils down to 'use SEND' on one hand, and some support from > Iljitsch and Francis on the other. > > We're seeing more instances of the problem being reported, e.g. on the > Internet2 list yesterday as a result of the Joint Techs meeting. > > We're seeing the problem resurface on our own network (some 1500 dual-sta= ck > hosts on wired and wireless access). The most recent last week was a > Vista machine that somehow didn't pick up the real online RA, and chose > to become a 6to4 router as a result (apparently... we'll try to recreate > this one). > > I think there's various underlying issues here. > > 1) Not everyone will deploy SEND, in fact maybe very few networks will. > It would be useful for some SEND fud to perhaps be wiped away, since at > present it seems 'up there' with Authenticated DHCP for deployment as > far as the people I ask reply. > > 2) Rogue RAs can happen for various accidental or malicious reasons, so > monitoring your link for 'bad' RAs is prudent regardless. We've looked > at rafixd and are working on some improvements to that as a monitoring > and possibly corrective tool. This can be rolled into monitoring as > per ndpmon, perhaps. So these are new things that should be detectable. > > 3) There are 'simple' fixes that could be made available today, e.g. a > switch option to en/disable RAs inbound per switch/stack or per port, > which would help just as MLD snooping can do, or DHCP blocking today. For this one we proposed with Gunter in draft-vandevelde-v6ops-ra-guard. > > 4) The issues with RAs are why people seem keen to use DHCPv6, and the > same people do ask about DHCPv6 default router options (regardless of > the (lack of) security with DHCPv6 itself). Currently the DHCPv6 is rather loosely integrated in most of the operating systems.... Maybe one option would be combining the two drafts.... Best Regards, Janos From owner-v6ops@ops.ietf.org Tue Feb 12 12:27:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6A228C48D for ; Tue, 12 Feb 2008 12:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aZCRLvjEtmq for ; Tue, 12 Feb 2008 12:27:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BE6B728C46E for ; Tue, 12 Feb 2008 12:27:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP1bd-00015k-KP for v6ops-data@psg.com; Tue, 12 Feb 2008 20:19:53 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP1ba-000157-C5 for v6ops@ops.ietf.org; Tue, 12 Feb 2008 20:19:51 +0000 Received: from basile.remlab.net (unknown [IPv6:2002:3e4e:969c:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 70E836A6; Tue, 12 Feb 2008 21:21:20 +0100 (CET) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: "Deepak Bansal (NETWORKING)" Subject: Re: rogue RA problem statement Date: Tue, 12 Feb 2008 22:19:16 +0200 User-Agent: KMail/1.9.7 Cc: Mohacsi Janos , Tim Chown , "v6ops@ops.ietf.org" References: <20080209085845.682F53A8176@core3.amsl.com> <20080212163720.B473@mignon.ki.iif.hu> <6607C4545FAB804B97733F82D20E0D085435FA54A2@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6607C4545FAB804B97733F82D20E0D085435FA54A2@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802122219.16723.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Le Tuesday 12 February 2008 21:27:50 Deepak Bansal (NETWORKING), vous avez= =20 =E9crit=A0: > >The most recent last week was a > > Vista machine that somehow didn't pick up the real online RA, and chose > > to become a 6to4 router as a result (apparently... we'll try to recreate > > this one). > > Vista will not become a 6to4 router unless ICS is enabled on it. Hence, I > suspect that the Vista machine in discussion here somehow had ICS enabled > on it. I don't know how easy or difficult or manually or automatically enabling IC= S=20 is, but on a sizable (1000+) university with public IPv4 addresses, that ha= s=20 been a recurrent problem ever since we've provided IPv6 (4 years from now o= r=20 so). Vista "IPv6-on-by-default" did not really help since then. Still, XP S= P2=20 is the by far the worst, has the built-in firewall blocks incoming RA while= =20 booting up. Then the PC decides there is no IPv6 router (even though there= =20 *is*), and turns on 6to4 gatewaying. Anyway, upgrading the switches to do some filtering is not an option. Using= =20 SEND is not an option, especially as it's currently not supported by anythi= ng=20 on the market. So it looks like, for the foreseeable future, reactive "0=20 lifetime" RA fixups will remain the only solution. As long as none of the=20 automatic 6to4 gateways are doing UNICAST Router Advertisement, it works,=20 even though it's an ugly hack. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Tue Feb 12 12:30:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D7028C50D for ; Tue, 12 Feb 2008 12:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OugnbNDE3kvh for ; Tue, 12 Feb 2008 12:30:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6D05C28C517 for ; Tue, 12 Feb 2008 12:30:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP1jt-0001vm-0W for v6ops-data@psg.com; Tue, 12 Feb 2008 20:28:25 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP1jq-0001vB-5d for v6ops@ops.ietf.org; Tue, 12 Feb 2008 20:28:23 +0000 Received: from basile.remlab.net (unknown [IPv6:2002:3e4e:969c:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 8907E6A6 for ; Tue, 12 Feb 2008 21:29:52 +0100 (CET) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: v6ops@ops.ietf.org Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Tue, 12 Feb 2008 22:27:46 +0200 User-Agent: KMail/1.9.7 References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> In-Reply-To: <47B174FF.10505@free.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1646425.GnqqLtSmFX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802122227.49344.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk --nextPart1646425.GnqqLtSmFX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le Tuesday 12 February 2008 12:29:19 R=E9mi Despr=E9s, vous avez =E9crit=A0: > The I-D is available at: > http://www.ietf.org/internet-drafts/draft-despres-v6ops-6rd-ipv6-rapid-de= pl >oyment-00.txt > > (A previous file name had to be replaced by this one, more compatible > with recommended practices, and including the now selected WG reference) Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly. Next thing is IPv6 NAT, when people try to "cascade" access points/routers= =20 within their home network. Like it or not, CPEs MUST get more than /64, and= =20 MUST support downstream prefix delegation. Last time I checked, Free was not assigned the whole IPv4 address space. I= =20 assume they don't want to provide the Rapid Deployment service to customers= =20 of *other* ISPs. So while they do only have a /32 IPv6 prefix, they don't=20 need to burn 32 further bits to keep track of each of the IPv4 address of=20 each of their customers. Storing the 24 lower order bits should be=20 sufficient. And this leaves 64-32-24=3D8 rouable bits per customer. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart1646425.GnqqLtSmFX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iEYEABECAAYFAkeyAUUACgkQw+xtvt1tEr0JzgCg1Nnm8V1hkrwHGgVFM3vtC4T9 hfcAoPN2j/YQnnjiz0wDiJh8chrsGb26 =HjXD -----END PGP SIGNATURE----- --nextPart1646425.GnqqLtSmFX-- From owner-v6ops@ops.ietf.org Tue Feb 12 14:59:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3CA3A6E65 for ; Tue, 12 Feb 2008 14:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QHxzk3CNxOy for ; Tue, 12 Feb 2008 14:59:21 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AA2143A6E87 for ; Tue, 12 Feb 2008 14:59:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP3z4-000JB3-79 for v6ops-data@psg.com; Tue, 12 Feb 2008 22:52:14 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP3z1-000JAb-EF for v6ops@ops.ietf.org; Tue, 12 Feb 2008 22:52:12 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id ADBB93EA0EF; Tue, 12 Feb 2008 23:52:10 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 675DB3EA0B7; Tue, 12 Feb 2008 23:52:10 +0100 (CET) Message-ID: <47B22317.1060909@free.fr> Date: Tue, 12 Feb 2008 23:52:07 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <200802122227.49344.rdenis@simphalempin.com> In-Reply-To: <200802122227.49344.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Rémi Denis-Courmont wrote : > Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly. WOW! Please note that many users now have real IPv6, without any NAT traversal tricks, thanks to the proposed new technique, and thanks to its first deployment by Free (which for some practical reasons was initially limited to /64 prefixes). On my home LAN, it doesn't suck at all. It just works to my complete satisfaction. Clearly it is desirable to do much better than this /64 first step, but one step after another is sometimes a good way to progress. In view of your strong reaction though, the following sentence will have IMO to be rewritten: "This is expected to be satisfactory initially for the vast majority of residential sites, where the number of hosts is small." > Next thing is IPv6 NAT, when people try to "cascade" access points/routers > within their home network. You are free to believe that IPv6 to IPv6 NATs would be the proposed next step. But not by me, for sure. >Like it or not, CPEs MUST get more than /64, and > MUST support downstream prefix delegation. Where did you get that I might not like shorter than /64 prefixes !!!. I wrote myself that /64 "is a real restriction which would advantageously be avoided with RIRs cooperation" (sec. 3,2). Free has already obtained a shorter than /32 prefix, just to have multiple subnet customer sites. > Last time I checked, Free was not assigned the whole IPv4 address space. I > assume they don't want to provide the Rapid Deployment service to customers > of *other* ISPs. So while they do only have a /32 IPv6 prefix, they don't > need to burn 32 further bits to keep track of each of the IPv4 address of > each of their customers. Storing the 24 lower order bits should be > sufficient. And this leaves 64-32-24=8 rouable bits per customer. You are right, they could have done that. But IMO the additional complexity would not have been justified, especially since it was expected to be only provisional. It would also have made addresses less readable. Section 3.2 says: "In view of the potential of 6rd to facilitate IPv6 availability, RIRs could be advised to consider assigning /24 prefixes to ISPs that deploy 6rd, and to endorse that these ISPs make their first IPv6 deployments with /56s distributed to their customers." May be more flexibility on this point would be appropriate, in particular by relaxing the restriction that 6rd ISP prefixes are multiple of 8 bits. Rémi From owner-v6ops@ops.ietf.org Tue Feb 12 15:08:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4731828C25B for ; Tue, 12 Feb 2008 15:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.232 X-Spam-Level: X-Spam-Status: No, score=-4.232 tagged_above=-999 required=5 tests=[AWL=2.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Udkzk4w0pq21 for ; Tue, 12 Feb 2008 15:08:02 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 99F303A68A5 for ; Tue, 12 Feb 2008 15:08:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4Ck-000Kem-RL for v6ops-data@psg.com; Tue, 12 Feb 2008 23:06:22 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4Ch-000Ke8-MD for v6ops@ops.ietf.org; Tue, 12 Feb 2008 23:06:21 +0000 Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1CN5oxh048170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2008 00:05:51 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: v6ops WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: draft-v6ops-van-beijnum-mnat-pt-00.txt Date: Wed, 13 Feb 2008 00:06:07 +0100 Cc: Christian Vogt , marcelo bagnulo X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is the modified NAT-PT draft that Brian and I have been working on: http://www.muada.com/drafts/draft-v6ops-van-beijnum-mnat-pt-00.txt Due to a bug in the draft submission thingy it will probably be another day or maybe two until it shows up in drafts database. We'll be doing another iteration next week, but feel free to get in on the ground floor with your comments. It has something for everyone: an EDNS0 option, a BGP community, a DHCPv6 option (TBD), anycasting and of course NAT. From owner-v6ops@ops.ietf.org Tue Feb 12 15:15:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D73F3A6E87 for ; Tue, 12 Feb 2008 15:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=2.122, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY88+X2jfv69 for ; Tue, 12 Feb 2008 15:15:36 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2D9283A6E04 for ; Tue, 12 Feb 2008 15:15:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4K3-000LO1-B7 for v6ops-data@psg.com; Tue, 12 Feb 2008 23:13:55 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4K0-000LNP-Bc for v6ops@ops.ietf.org; Tue, 12 Feb 2008 23:13:53 +0000 Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1CNDLLe048274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2008 00:13:25 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200802122227.49344.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Wed, 13 Feb 2008 00:13:38 +0100 References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <200802122227.49344.rdenis@simphalempin.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi R=E9mis, On 12 feb 2008, at 21:27, R=E9mi Denis-Courmont wrote: > Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly. > Next thing is IPv6 NAT, when people try to "cascade" access points/=20 > routers > within their home network. Like it or not, CPEs MUST get more than /=20= > 64, and > MUST support downstream prefix delegation. > Last time I checked, Free was not assigned the whole IPv4 address =20 > space. I > assume they don't want to provide the Rapid Deployment service to =20 > customers > of *other* ISPs. So while they do only have a /32 IPv6 prefix, they =20= > don't > need to burn 32 further bits to keep track of each of the IPv4 =20 > address of > each of their customers. Storing the 24 lower order bits should be > sufficient. And this leaves 64-32-24=3D8 rouable bits per customer. No, /24 is still too much (only two or three ISPs have that much IPv4 =20= space) and too little (fills up an entire IPv6 /32) at the same time. =20= What should happen here is that the actual allocation size is used. So =20= if an ISP has a /19, they use up /56 - /19 =3D /37 for the customers in =20= that /19.= From owner-v6ops@ops.ietf.org Tue Feb 12 15:46:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D703A6EBA for ; Tue, 12 Feb 2008 15:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbNwMYMKX2kS for ; Tue, 12 Feb 2008 15:46:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 42EE728C51A for ; Tue, 12 Feb 2008 15:44:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4jc-000ODR-OE for v6ops-data@psg.com; Tue, 12 Feb 2008 23:40:20 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP4ja-000OCz-4P for v6ops@ops.ietf.org; Tue, 12 Feb 2008 23:40:19 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Feb 2008 15:40:17 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1CNeGXX017129; Tue, 12 Feb 2008 15:40:16 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1CNe865013463; Tue, 12 Feb 2008 23:40:09 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 18:40:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: rogue RA problem statement Date: Tue, 12 Feb 2008 18:40:52 -0500 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F404C73E93@xmb-rtp-213.amer.cisco.com> In-Reply-To: <20080212163720.B473@mignon.ki.iif.hu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rogue RA problem statement Thread-Index: AchtkGCl1tyytPzwSiaZT2qAHjR+sQAP5QkQ From: "Chip Popoviciu (cpopovic)" To: "Mohacsi Janos" , "Tim Chown" Cc: X-OriginalArrivalTime: 12 Feb 2008 23:40:08.0334 (UTC) FILETIME=[99F032E0:01C86DD0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3309; t=1202859616; x=1203723616; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=20=22Chip=20Popoviciu=20(cpopovic)=22=20 |Subject:=20RE=3A=20rogue=20RA=20problem=20statement |Sender:=20; bh=KRMac6CYmm8g4qntUh3FVJ2UPwSwiDOFdo493Pzmmxc=; b=FVq+lXlCMCNVhe0HAnn3qWcAxJMoomhYTQLMooXlB8nLyNsAGYfitBXP1o IM1soEUYznnfdUmqrdDgvp3WDsBvayRemSfpVOKt85zNPyC6yrKIWxn1AJ3S 4u7Xs68GC6; Authentication-Results: sj-dkim-4; header.From=cpopovic@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Adding a few points to those mentioned by Janos ... =20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mohacsi Janos Sent: Tuesday, February 12, 2008 10:55 AM To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: rogue RA problem statement On Tue, 12 Feb 2008, Tim Chown wrote: > (subject line updated) > > On Mon, Feb 11, 2008 at 10:04:03AM -0800, Fred Baker wrote: >> >> The RA discussion >> draft-chown-v6ops-rogue-ra if Tim updates it >> draft-vandevelde-v6ops-ra-guard > > Hi, > > On the rogue RA problem statement, Stig and I don't feel there is much > point in an update at this stage, and also that presenting the same=20 > issue for a 3rd time would be beneficial. > > Looking back on IETF70 minutes (I wasn't there) they say: > http://tools.ietf.org/wg/v6ops/minutes > > which boils down to 'use SEND' on one hand, and some support from=20 > Iljitsch and Francis on the other. > > We're seeing more instances of the problem being reported, e.g. on the > Internet2 list yesterday as a result of the Joint Techs meeting. > > We're seeing the problem resurface on our own network (some 1500 dual-stack > hosts on wired and wireless access). The most recent last week was a > Vista machine that somehow didn't pick up the real online RA, and=20 > chose to become a 6to4 router as a result (apparently... we'll try to=20 > recreate this one). > > I think there's various underlying issues here. > > 1) Not everyone will deploy SEND, in fact maybe very few networks will. > It would be useful for some SEND fud to perhaps be wiped away, since=20 > at present it seems 'up there' with Authenticated DHCP for deployment=20 > as far as the people I ask reply. > The solutions proposed are not intended to replace SEND but rather complement it wherever possible. I think that, if nothing else, the RA-guard options would help SEND in securing a varied set of environments and deployments. > 2) Rogue RAs can happen for various accidental or malicious reasons, so > monitoring your link for 'bad' RAs is prudent regardless. We've looked > at rafixd and are working on some improvements to that as a monitoring > and possibly corrective tool. This can be rolled into monitoring as > per ndpmon, perhaps. So these are new things that should be detectable. > This is part of some of the solutions proposed by Gunter's draft. It could however be extended to have devices just monitor and report rather than take action. Best Regards, Chip > 3) There are 'simple' fixes that could be made available today, e.g. a > switch option to en/disable RAs inbound per switch/stack or per port,=20 > which would help just as MLD snooping can do, or DHCP blocking today. For this one we proposed with Gunter in draft-vandevelde-v6ops-ra-guard. > > 4) The issues with RAs are why people seem keen to use DHCPv6, and the > same people do ask about DHCPv6 default router options (regardless of=20 > the (lack of) security with DHCPv6 itself). Currently the DHCPv6 is rather loosely integrated in most of the operating systems.... Maybe one option would be combining the two drafts.... Best Regards, Janos From owner-v6ops@ops.ietf.org Tue Feb 12 16:04:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9A228C15C for ; Tue, 12 Feb 2008 16:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhY9s1NaGvRK for ; Tue, 12 Feb 2008 16:04:51 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id F3AF628C10D for ; Tue, 12 Feb 2008 16:04:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP51f-0000Hg-7o for v6ops-data@psg.com; Tue, 12 Feb 2008 23:58:59 +0000 Received: from [205.158.62.78] (helo=smtp1.us4.outblaze.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JP51c-0000G8-J6 for v6ops@ops.ietf.org; Tue, 12 Feb 2008 23:58:57 +0000 Received: (qmail 31128 invoked from network); 12 Feb 2008 23:58:56 -0000 Received: from unknown (HELO ?192.168.3.76?) (jcurran:mail.com?mail.com@69.255.34.88) by smtp1.us4.outblaze.com with SMTP; 12 Feb 2008 23:58:55 -0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080209085845.682F53A8176@core3.amsl.com> Date: Tue, 12 Feb 2008 18:58:51 -0500 To: Fred Baker From: John Curran Subject: Re: Initial agenda for IETF 71 Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 10:04 AM -0800 2/11/08, Fred Baker wrote: > >Tuesday: transition session > Key objective: nail down transition expectations/requirements > draft-jcurran-v6transitionplan > draft-bagnulo-v6ops-6man-nat64-pb-statement > draft-stenberg-v6ops-pd-route-maintenance Fred - I'm in town through Tuesday evening, so if you can spare 10 minutes or so on the Tuesday agenda, I'd be quite happy to present the impetus behind the draft. /John From owner-v6ops@ops.ietf.org Wed Feb 13 01:58:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D42428C3FE for ; Wed, 13 Feb 2008 01:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKnJWZxtiUnl for ; Wed, 13 Feb 2008 01:58:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 45DFA28C6DD for ; Wed, 13 Feb 2008 01:58:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPEGQ-0008cZ-2P for v6ops-data@psg.com; Wed, 13 Feb 2008 09:50:50 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPEGN-0008cG-44 for v6ops@ops.ietf.org; Wed, 13 Feb 2008 09:50:48 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 2605BC95; Wed, 13 Feb 2008 10:52:49 +0100 (CET) To: v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a newapproach MIME-Version: 1.0 Date: Wed, 13 Feb 2008 10:52:49 +0100 From: Remi Denis-Courmont Organization: Remlab.net In-Reply-To: <47B22317.1060909@free.fr> References: <47B22317.1060909@free.fr> Message-ID: <20c70d4dc402a688d63d38fdd18bfee5@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 12 Feb 2008 23:52:07 +0100, Rémi Després wrote: > On my home LAN, it doesn't suck at all. It just works to my complete > satisfaction. > Clearly it is desirable to do much better than this /64 first step, but > one step after another is sometimes a good way to progress. The IETF has a long history of doing "provisional" "for a short time" protocols that eventually last much much longer than intended. NATs are one. And 6to4... it was standardized over 5 years ago, and we are only now realizing that it does not work as well as intended. When we know that something is wrong or broken to begin with, we definitely should not standardize it in the first place, IMHO. That will not prevent Free from using it anyway. > In view of your strong reaction though, the following sentence will have > IMO to be rewritten: > "This is expected to be satisfactory initially for the vast majority of > residential sites, where the number of hosts is small." The number of hosts is totally irrelevant. I have been on switched IPv6 subnets with hundreds of boxes without any problem. The issue is with *cascading* routers. With no bits to do routing within a site, if bridging is not possible, there is no choice but to use NAT. > You are free to believe that IPv6 to IPv6 NATs would be the proposed > next step. > But not by me, for sure. So what if I plug a cheap SOHO router behind my CPE? > You are right, they could have done that. > But IMO the additional complexity would not have been justified, Where is the complexity in shifting some bits? > especially since it was expected to be only provisional. > It would also have made addresses less readable. That assumes humans can convert decimal IPv4 address to hexadecimal fast enough to "read" them. Also, this only works for /32+32 and /16+32 prefixes, neither of which look like a good compromise. I'd happily preserve statelessness, and get saner prefixes size at the expense of readability. IPv6 addresses are pretty much unreadable anyhow. -- Rémi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Wed Feb 13 05:06:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF01528C7B9 for ; Wed, 13 Feb 2008 05:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=1, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkEpXjgnZdiA for ; Wed, 13 Feb 2008 05:06:42 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1857928C770 for ; Wed, 13 Feb 2008 05:06:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPHBr-000O36-La for v6ops-data@psg.com; Wed, 13 Feb 2008 12:58:19 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPHBo-000O2Q-Ug for v6ops@ops.ietf.org; Wed, 13 Feb 2008 12:58:18 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 5224C3EA0EE; Wed, 13 Feb 2008 13:58:16 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id E51933EA0F9; Wed, 13 Feb 2008 13:58:15 +0100 (CET) Message-ID: <47B2E95C.6060208@free.fr> Date: Wed, 13 Feb 2008 13:58:04 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <200802122227.49344.rdenis@simphalempin.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Iljitsch van Beijnum wrote :

> So if an ISP has a /19, they use up /56 - /19 = /37 for the customers
> in that /19.
>
If an ISP has a /19 and assigns  /56s  with 6rd to its customers,  the computation is as follows:

Let XXXX:e000::/19 be the ISP prefix.
Let XXXX:e000::/24 be its chosen 6rd ISP prefix.

Then, 6rd  site prefixes are :
      XXXX:e0AA:AAAA:AA00::/56,
       where Y is "e" or "f",
       the first A is not e
       AAAAAAAA is the site v4 address

Prefixes left for pure v6 sites are then:
(a full /19  -  (a full /24 - (a full /28)))

In other words, *less than  1/32th* of the space has been used for 6rd.
( 1/32 = 1 / 2 ^ [24 - 19] )

With that practically negligible consumption, what has been bought is the capability to rapidly assign /56s to all v4 sites of ISPs .
Note also that, once v4 addresses are no longer necessary for customer sites, this 1/32 of the space can be reused for pure v6 sites.

Rémi
From owner-v6ops@ops.ietf.org Wed Feb 13 05:30:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8A63A6F62 for ; Wed, 13 Feb 2008 05:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=1, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsu7v2ZW0lpS for ; Wed, 13 Feb 2008 05:29:58 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 800A128C83A for ; Wed, 13 Feb 2008 05:29:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPHZ7-0000Fx-9C for v6ops-data@psg.com; Wed, 13 Feb 2008 13:22:21 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPHYs-0000El-Kh for v6ops@ops.ietf.org; Wed, 13 Feb 2008 13:22:07 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 0AF4B3EA114; Wed, 13 Feb 2008 14:22:06 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id C4FE53EA0C3; Wed, 13 Feb 2008 14:22:05 +0100 (CET) Message-ID: <47B2EEF9.1010804@free.fr> Date: Wed, 13 Feb 2008 14:22:01 +0100 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Remi Denis-Courmont CC: v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a newapproach References: <47B22317.1060909@free.fr> <20c70d4dc402a688d63d38fdd18bfee5@chewa.net> In-Reply-To: <20c70d4dc402a688d63d38fdd18bfee5@chewa.net> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Remi Denis-Courmont wrote :
> The issue is with *cascading*routers. With no bits to do routing
> within a site, if bridging is not possible, there is no choice but to
>  use NAT.
There is IMHO a better alternative:  where no IPv6 prefix is available,
like behind a cascading router in a /64 site, use another available tool.
(Teredo, tunnel broker etc, are IMU availble precisely for this).

> Where is the complexity in shifting some bits?
Right, "shifting bits" is simple.
It works if each ISP hasonly one RIR-provided prefix for all its customers,
but *only in this case*.
Personally I don't know how many v4 prefixes Free has, and plans to use.
But, as you know,  ISPs tend to get their v4 address space piece by piece.
The complexity starts.

Rémi



From owner-v6ops@ops.ietf.org Wed Feb 13 05:57:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDC828C83D for ; Wed, 13 Feb 2008 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEaDXKHHeyYD for ; Wed, 13 Feb 2008 05:57:40 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B9BF628C838 for ; Wed, 13 Feb 2008 05:57:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPI2g-00030m-1u for v6ops-data@psg.com; Wed, 13 Feb 2008 13:52:54 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPI2d-00030I-1q for v6ops@ops.ietf.org; Wed, 13 Feb 2008 13:52:52 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2008 14:52:50 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1DDqoFF003434; Wed, 13 Feb 2008 14:52:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1DDqYf1012864; Wed, 13 Feb 2008 13:52:41 GMT Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 14:52:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] Date: Wed, 13 Feb 2008 14:52:34 +0100 Message-ID: <70672088D7D2CE409FB05DDD7B73D3810123F14F@xmb-ams-33c.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] Thread-Index: AchtzE1pk+CSrR98SqivgtlndPcgfAAeo7Fg From: "Gunter Van de Velde (gvandeve)" To: "Iljitsch van Beijnum" , "v6ops WG" Cc: "Shin Miyakawa" , "John Jason Brzozowski" X-OriginalArrivalTime: 13 Feb 2008 13:52:29.0982 (UTC) FILETIME=[ACBC63E0:01C86E47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1153; t=1202910770; x=1203774770; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20 |Subject:=20Draft=20submit=20tool=20still=20down?=20=20[WAS =3A=20RE=3A=20draft-v6ops-van-beijnum-mnat-pt-00.txt] |Sender:=20; bh=hpDHCow9L+DWC+47/OHXeGcaCOUIMiERkucpGwobLPA=; b=bXpYs5DOQDcxmYyLUKusxH/uCKf9AM2BsbFqX+Im+AllLj24PtxiPmMFuF ta86kSLbFHhgVBEbveXusCnfM0ghaBtuPzbum81zypPS6GCoeXYkaqESntwd +5u0RCTqrz; Authentication-Results: ams-dkim-1; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm wondering... Is the submit tool running/working again? We just tried to submit "draft-vandevelde-v6ops-CPE-Default-Route-Detection-00.txt" and the tool complains that there are non-alphanumerics in the title where there are none?=20 Does any have a clue/idea on what could be the reason? (manual posting is closed already at this moment) Thnaks, G/ -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Wednesday, February 13, 2008 12:06 AM To: v6ops WG Cc: Christian Vogt; marcelo bagnulo Subject: draft-v6ops-van-beijnum-mnat-pt-00.txt This is the modified NAT-PT draft that Brian and I have been working on: http://www.muada.com/drafts/draft-v6ops-van-beijnum-mnat-pt-00.txt Due to a bug in the draft submission thingy it will probably be another day or maybe two until it shows up in drafts database. We'll be doing another iteration next week, but feel free to get in on the ground floor with your comments. It has something for everyone: an EDNS0 option, a BGP community, a DHCPv6 option (TBD), anycasting and of course NAT. From owner-v6ops@ops.ietf.org Wed Feb 13 06:02:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B967628C20B for ; Wed, 13 Feb 2008 06:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.763 X-Spam-Level: X-Spam-Status: No, score=-4.763 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQYG65-wdC9P for ; Wed, 13 Feb 2008 06:02:29 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E8D923A6A24 for ; Wed, 13 Feb 2008 06:02:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPI8K-0003SN-O8 for v6ops-data@psg.com; Wed, 13 Feb 2008 13:58:44 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPI8I-0003S4-EK for v6ops@ops.ietf.org; Wed, 13 Feb 2008 13:58:43 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id C070C3EA0FB; Wed, 13 Feb 2008 14:58:41 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 77B963EA0B0; Wed, 13 Feb 2008 14:58:41 +0100 (CET) Message-ID: <47B2F78E.2030808@free.fr> Date: Wed, 13 Feb 2008 14:58:38 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Iljitsch van Beijnum , Brian Carpenter CC: v6ops WG Subject: Re: draft-v6ops-van-beijnum-mnat-pt-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Iljiitsch and Brian, Thanks for the early information, and for the thorough analysis detailed in the document. 1. Full agreement, and support, on the importance of IPv6 to IPv4 connections (I argued about it in v6 ops as early as March 2005, but alone at that time!). 2. On several points, I believe that simplifications are possible. I would really like to have a in depth discussion with you in Philadelphia. One of the items would be a better understanding of why mapped addresses have been avoided in your proposal. (So far, I believe they have real advantages and, in the NAT-PT case at hand, no real drawback). Another item would be where checksum adjustment best fits. 3. Another essential transition configuration is that of a v4 host in a site which has a v6 prefix but no v4 public address. This is the NATv4v6v4 of Alain Durand in http://tools.ietf.org/id/draft-durand-v6ops-natv4v6v4-00.txt). I have a proposal in the pipe for this , but very little time to finalize an I-D. Still hope to have it before the deadline. It has various relationships with MNAT-PT and SHANTI. Rémi From owner-v6ops@ops.ietf.org Wed Feb 13 06:16:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEF428C82A for ; Wed, 13 Feb 2008 06:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.403 X-Spam-Level: X-Spam-Status: No, score=-4.403 tagged_above=-999 required=5 tests=[AWL=4.196, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzr+44WzxOTO for ; Wed, 13 Feb 2008 06:16:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 86A4A28C7E8 for ; Wed, 13 Feb 2008 06:16:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPIIk-0004b7-Rt for v6ops-data@psg.com; Wed, 13 Feb 2008 14:09:30 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPIIh-0004a0-M5 for v6ops@ops.ietf.org; Wed, 13 Feb 2008 14:09:29 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1DE7hoJ008221; Wed, 13 Feb 2008 16:07:43 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1DE7gQb008217; Wed, 13 Feb 2008 16:07:43 +0200 Date: Wed, 13 Feb 2008 16:07:42 +0200 (EET) From: Pekka Savola To: "Gunter Van de Velde (gvandeve)" cc: Iljitsch van Beijnum , v6ops WG , Shin Miyakawa , John Jason Brzozowski Subject: Re: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] In-Reply-To: <70672088D7D2CE409FB05DDD7B73D3810123F14F@xmb-ams-33c.emea.cisco.com> Message-ID: References: <70672088D7D2CE409FB05DDD7B73D3810123F14F@xmb-ams-33c.emea.cisco.com> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.92/5777/Mon Feb 11 20:04:11 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 13 Feb 2008, Gunter Van de Velde (gvandeve) wrote: > I'm wondering... Is the submit tool running/working again? > > We just tried to submit > "draft-vandevelde-v6ops-CPE-Default-Route-Detection-00.txt" > and the tool complains that there are non-alphanumerics in the title > where there are none? > > Does any have a clue/idea on what could be the reason? > (manual posting is closed already at this moment) Try making the letters all-lowercase. -- 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 Wed Feb 13 07:00:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB0C3A6F70 for ; Wed, 13 Feb 2008 07:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnzewBe4yESD for ; Wed, 13 Feb 2008 07:00:34 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 55E193A6F6F for ; Wed, 13 Feb 2008 07:00:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPJ3H-000A0A-IA for v6ops-data@psg.com; Wed, 13 Feb 2008 14:57:35 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPJ36-0009x8-T9 for v6ops@ops.ietf.org; Wed, 13 Feb 2008 14:57:30 +0000 Received: from [IPv6:::1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1DEtUEY061952; Wed, 13 Feb 2008 15:55:30 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: "v6ops WG" , "Shin Miyakawa" , "John Jason Brzozowski" Message-Id: <7E1BC895-1C07-4882-9352-F20E64CD7ED9@muada.com> From: Iljitsch van Beijnum To: Gunter Van de Velde (gvandeve) In-Reply-To: <70672088D7D2CE409FB05DDD7B73D3810123F14F@xmb-ams-33c.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] Date: Wed, 13 Feb 2008 15:55:52 +0100 References: <70672088D7D2CE409FB05DDD7B73D3810123F14F@xmb-ams-33c.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 13 feb 2008, at 14:52, Gunter Van de Velde (gvandeve) wrote: > I'm wondering... Is the submit tool running/working again? I tried to post a draft yesterday evening and this morning and got the "edit metadata" response even though there were no problems indicated with the metadata... Sent mail, waiting for morning to arrive in the US. > We just tried to submit > "draft-vandevelde-v6ops-CPE-Default-Route-Detection-00.txt" > and the tool complains that there are non-alphanumerics in the title > where there are none? Could be that the issue is the capitals... A better error message would be in order, though. From owner-v6ops@ops.ietf.org Wed Feb 13 07:32:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A2C3A6F8A for ; Wed, 13 Feb 2008 07:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b1-EnYL25Dg for ; Wed, 13 Feb 2008 07:32:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 539E33A6F8E for ; Wed, 13 Feb 2008 07:32:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPJX3-000GMo-Lu for v6ops-data@psg.com; Wed, 13 Feb 2008 15:28:21 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPJX1-000GMJ-1w for v6ops@ops.ietf.org; Wed, 13 Feb 2008 15:28:20 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2008 16:28:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1DFSIxr009984; Wed, 13 Feb 2008 16:28:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1DFSBep027916; Wed, 13 Feb 2008 15:28:13 GMT Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 16:28:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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 submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] Date: Wed, 13 Feb 2008 16:28:06 +0100 Message-ID: <70672088D7D2CE409FB05DDD7B73D3810123F243@xmb-ams-33c.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] Thread-Index: AchuShdcMMtE2UMfQsa1w8amjr351QACnPvg From: "Gunter Van de Velde (gvandeve)" To: "Pekka Savola" Cc: "Iljitsch van Beijnum" , "v6ops WG" , "Shin Miyakawa" , "John Jason Brzozowski" X-OriginalArrivalTime: 13 Feb 2008 15:28:05.0964 (UTC) FILETIME=[07A5C8C0:01C86E55] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1433; t=1202916498; x=1203780498; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20 |Subject:=20RE=3A=20Draft=20submit=20tool=20still=20down?=2 0=20[WAS=3A=20RE=3A=20draft-v6ops-van-beijnum-mnat-pt-00.txt ] |Sender:=20; bh=ODEqyxstRwIy/ZMDjOudGyOdTT750nOmLkG1zt4emEk=; b=Jp0KlQwpavShPTuHO5U0aAv4jKHTQ2UuASU+X6AnpYfWhtqn/B93wZTf0a 4wJ2EFMveUHQrrQVB4eV0ikG6FOqPUebEP4oyEM6huaP7HQgi6A6Ls+6rkwr EDlRfZJ6B1; Authentication-Results: ams-dkim-2; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk 'lower-case' was indeed the solution. I did try that already for the actual file name though. it didn't work. Hence, I just changed the title in the xml to lower case: "> and that did indeed do the trick :-) So, my lesson learned is that not just the .txt file must be lower case, but also the title embedded into the draft. G/ -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Wednesday, February 13, 2008 3:08 PM To: Gunter Van de Velde (gvandeve) Cc: Iljitsch van Beijnum; v6ops WG; Shin Miyakawa; John Jason Brzozowski Subject: Re: Draft submit tool still down? [WAS: RE: draft-v6ops-van-beijnum-mnat-pt-00.txt] On Wed, 13 Feb 2008, Gunter Van de Velde (gvandeve) wrote: > I'm wondering... Is the submit tool running/working again? > > We just tried to submit > "draft-vandevelde-v6ops-CPE-Default-Route-Detection-00.txt" > and the tool complains that there are non-alphanumerics in the title=20 > where there are none? > > Does any have a clue/idea on what could be the reason? > (manual posting is closed already at this moment) Try making the letters all-lowercase. --=20 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 Wed Feb 13 12:36:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A863A683B for ; Wed, 13 Feb 2008 12:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFPUVjao2VWq for ; Wed, 13 Feb 2008 12:36:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 39F7D3A67B1 for ; Wed, 13 Feb 2008 12:36:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOFO-0003cW-Oe for v6ops-data@psg.com; Wed, 13 Feb 2008 20:30:26 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOFL-0003by-MH for v6ops@ops.ietf.org; Wed, 13 Feb 2008 20:30:25 +0000 Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1DKTM9Z067607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2008 21:29:23 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Message-Id: <71EF66FA-F6E5-4219-97B0-C4C23131E579@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <47B2E95C.6060208@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Wed, 13 Feb 2008 21:29:40 +0100 References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <200802122227.49344.rdenis@simphalempin.com> <47B2E95C.6060208@free.fr> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 13 feb 2008, at 13:58, R=E9mi Despr=E9s wrote: > If an ISP has a /19 and assigns /56s with 6rd to its customers, =20 > the computation is as follows: > Let XXXX:e000::/19 be the ISP prefix. > Let XXXX:e000::/24 be its chosen 6rd ISP prefix. I'm not sure what you are trying to say here... Can you explain a bit =20= more what the message I'm replying to is about? Are you agreeing with =20= me, suggesting something new or clarifying something old? From owner-v6ops@ops.ietf.org Wed Feb 13 12:39:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D190C3A67B1 for ; Wed, 13 Feb 2008 12:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hld7KIp4Mdu for ; Wed, 13 Feb 2008 12:39:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6416828C89D for ; Wed, 13 Feb 2008 12:39:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOMR-0004XE-CZ for v6ops-data@psg.com; Wed, 13 Feb 2008 20:37:43 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPOMK-0004WG-Ty for v6ops@ops.ietf.org; Wed, 13 Feb 2008 20:37:41 +0000 Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1DKa3oE067779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2008 21:36:07 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: Brian Carpenter , v6ops WG Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <47B2F78E.2030808@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: draft-v6ops-van-beijnum-mnat-pt-00.txt Date: Wed, 13 Feb 2008 21:36:21 +0100 References: <47B2F78E.2030808@free.fr> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 13 feb 2008, at 14:58, R=E9mi Despr=E9s wrote: > 2. On several points, I believe that simplifications are possible. > I would really like to have a in depth discussion with you in =20 > Philadelphia. I'll be there the whole week, let me know when you want to sit down =20 for a more detailed discussion. I have no idea about Brian's =20 availability, though. :-) > One of the items would be a better understanding of why mapped =20 > addresses have been avoided in your proposal. Because some people REALLY don't want to see them on the wire and also =20= because it could be confusing to have the same address block used for =20= two different purposes depending on the presence of native IPv4 =20 connetivity. I'm not even sure anycasting is going to fly, anyway, =20 though. > Another item would be where checksum adjustment best fits. Let me know if you have any ideas about that. > 3. Another essential transition configuration is that of a v4 host =20 > in a site which has a v6 prefix but no v4 public address. > This is the NATv4v6v4 of Alain Durand in = http://tools.ietf.org/id/draft-durand-v6ops-natv4v6v4-00.txt)=20 > . > I have a proposal in the pipe for this , but very little time to =20 > finalize an I-D. > Still hope to have it before the deadline. > It has various relationships with MNAT-PT and SHANTI. I had stuff for this in the previous version of the draft: http://www.muada.com/drafts/draft-van-beijnum-modified-nat-pt-02.txt However, I removed it, because it makes the whole draft longer and =20 this mechanism can be added later without any changes to MNAT-PT =20 translators so there's no real need to specify it now.= From owner-v6ops@ops.ietf.org Wed Feb 13 13:47:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973833A6B51 for ; Wed, 13 Feb 2008 13:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik0-dHLF8Heu for ; Wed, 13 Feb 2008 13:47:02 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E5BA73A6856 for ; Wed, 13 Feb 2008 13:47:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPPKO-000Byl-Uq for v6ops-data@psg.com; Wed, 13 Feb 2008 21:39:40 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPPKM-000ByS-Fw for v6ops@ops.ietf.org; Wed, 13 Feb 2008 21:39:39 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id CFCFB3EA0F3; Wed, 13 Feb 2008 22:39:37 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7EE893EA0F5; Wed, 13 Feb 2008 22:39:37 +0100 (CET) Message-ID: <47B3638D.1080108@free.fr> Date: Wed, 13 Feb 2008 22:39:25 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: v6ops@ops.ietf.org Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <200802122227.49344.rdenis@simphalempin.com> <47B2E95C.6060208@free.fr> <71EF66FA-F6E5-4219-97B0-C4C23131E579@muada.com> In-Reply-To: <71EF66FA-F6E5-4219-97B0-C4C23131E579@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Iljitsch van Beijnum a écrit : > On 13 feb 2008, at 13:58, Rémi Després wrote: > >> If an ISP has a /19 and assigns /56s with 6rd to its customers, the >> computation is as follows: > >> Let XXXX:e000::/19 be the ISP prefix. >> Let XXXX:e000::/24 be its chosen 6rd ISP prefix. > > I'm not sure what you are trying to say here... Can you explain a bit > more what the message I'm replying to is about? Are you agreeing with > me, suggesting something new or clarifying something old? You wrote "if an ISP has a /19, they use up /56 - /19 = /37 for the customers in that /19." I am not sure myself what was your point. I was then trying to clarify how much of the ISP /19 prefix is used for 6rd (with a longer answer than the quotation above). Unless you see a need to discuss this further, we probably can leave it now. Rémi From owner-v6ops@ops.ietf.org Wed Feb 13 14:00:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD2828C389 for ; Wed, 13 Feb 2008 14:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaTAQ11ITn9k for ; Wed, 13 Feb 2008 14:00:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E6F3828C2B1 for ; Wed, 13 Feb 2008 14:00:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPPaT-000Dj5-EP for v6ops-data@psg.com; Wed, 13 Feb 2008 21:56:17 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPPaO-000DiL-1r for v6ops@ops.ietf.org; Wed, 13 Feb 2008 21:56:13 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 3EDFE3EA141; Wed, 13 Feb 2008 22:56:11 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id E8D403EA12D; Wed, 13 Feb 2008 22:56:10 +0100 (CET) Message-ID: <47B36776.7030009@free.fr> Date: Wed, 13 Feb 2008 22:56:06 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Brian Carpenter , v6ops WG Subject: Re: draft-v6ops-van-beijnum-mnat-pt-00.txt References: <47B2F78E.2030808@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Iljitsch van Beijnum a écrit : > On 13 feb 2008, at 14:58, Rémi Després wrote: > >> 2. On several points, I believe that simplifications are possible. >> I would really like to have a in depth discussion with you in >> Philadelphia. > > I'll be there the whole week, let me know when you want to sit down for > a more detailed discussion. I have no idea about Brian's availability, > though. :-) I will contact you when the detailed program is available. >> One of the items would be a better understanding of why mapped >> addresses have been avoided in your proposal. > > Because some people REALLY don't want to see them on the wire Technical reasons should be known for the debate to progress. > because it could be confusing to have the same address block used for > two different purposes depending on the presence of native IPv4 > connetivity. Unclear to me wo far. >> Another item would be where checksum adjustment best fits. > > Let me know if you have any ideas about that. When a address is replaced by another, adjusting the checksum is simple. Using ad hoc values in prefixes in order to keep the checksum change to zero seems to me more complex than needed. It may prevent other uses of prefix fields, that may be more useful. Rémi From owner-v6ops@ops.ietf.org Wed Feb 13 15:06:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152FF3A67D5 for ; Wed, 13 Feb 2008 15:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=2.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP0CAw3Sc2r8 for ; Wed, 13 Feb 2008 15:06:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3FAB13A68D4 for ; Wed, 13 Feb 2008 15:06:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQbY-000KeV-PR for v6ops-data@psg.com; Wed, 13 Feb 2008 23:01:28 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQbV-000Ke9-UL for v6ops@ops.ietf.org; Wed, 13 Feb 2008 23:01:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id F12FB3A6873; Wed, 13 Feb 2008 15:00:01 -0800 (PST) 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-cpe-simple-security-02.txt Message-Id: <20080213230001.F12FB3A6873@core3.amsl.com> Date: Wed, 13 Feb 2008 15:00:01 -0800 (PST) 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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-02.txt Pages : 25 Date : 2008-02-13 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-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-cpe-simple-security-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-cpe-simple-security-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: <2008-02-13145955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-cpe-simple-security-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-cpe-simple-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-13145955.I-D\@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 13 17:54:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2843A6FDF for ; Wed, 13 Feb 2008 17:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqF0E0f9knzI for ; Wed, 13 Feb 2008 17:54:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1B1493A68FC for ; Wed, 13 Feb 2008 17:54:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPTCJ-000CJe-BQ for v6ops-data@psg.com; Thu, 14 Feb 2008 01:47:35 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPTCG-000CJL-Ru for v6ops@ops.ietf.org; Thu, 14 Feb 2008 01:47:34 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2008 02:47:31 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1E1lVdS002241; Thu, 14 Feb 2008 02:47:31 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1E1lQen017598; Thu, 14 Feb 2008 01:47:31 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 02:47:26 +0100 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 02:47:26 +0100 In-Reply-To: References: <20080209085845.682F53A8176@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37001A3B-9F00-44AF-AF34-53DCDFE7F63C@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Initial agenda for IETF 71 Date: Wed, 13 Feb 2008 17:47:12 -0800 To: John Curran X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 14 Feb 2008 01:47:26.0455 (UTC) FILETIME=[8D06B870:01C86EAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=736; t=1202953651; x=1203817651; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Initial=20agenda=20for=20IETF=2071 |Sender:=20; bh=aALvihrWuxAAKl4FWvDO6+WkWZWer5CuDuZcvRUu5jI=; b=Nl8Dtfdngtfj2hfoJSAwTNGtJNw/ezmHwhQ4k7popbxuzM1FlrtWMqqcZj PXFC0X3HGiAK144ILA0kp/W3mRBGkGXlbYesn2YvdnKUhr0NvhF08CON1YPC RbxaCt4RB1; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Outstanding. Thanks. On Feb 12, 2008, at 3:58 PM, John Curran wrote: > At 10:04 AM -0800 2/11/08, Fred Baker wrote: >> >> Tuesday: transition session >> Key objective: nail down transition expectations/requirements >> draft-jcurran-v6transitionplan >> draft-bagnulo-v6ops-6man-nat64-pb-statement >> draft-stenberg-v6ops-pd-route-maintenance > > Fred - I'm in town through Tuesday evening, so if you can > spare 10 minutes or so on the Tuesday agenda, I'd be quite > happy to present the impetus behind the draft. > > /John -----BEGIN PGP SIGNATURE----- iD8DBQFHs52gbjEdbHIsm0MRAqdXAJ9IsshCkZRvI2WnkN2Kglh7JO/X4QCgtPpI IPxGQAUxu/wAuzq7r0DTK14= =HuKI -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Feb 14 04:02:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA7528C66E for ; Thu, 14 Feb 2008 04:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9HSE6+3gcrv for ; Thu, 14 Feb 2008 04:02:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 311C128CEC0 for ; Thu, 14 Feb 2008 04:02:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPcf8-000Jlt-5L for v6ops-data@psg.com; Thu, 14 Feb 2008 11:53:58 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPcf5-000Jlc-NP for v6ops@ops.ietf.org; Thu, 14 Feb 2008 11:53:56 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2008 12:53:54 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1EBrsDk011260; Thu, 14 Feb 2008 12:53:54 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1EBrqen007865; Thu, 14 Feb 2008 11:53:52 GMT Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 12:53:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: rogue RA problem statement Date: Thu, 14 Feb 2008 12:49:21 +0100 Message-ID: <70672088D7D2CE409FB05DDD7B73D3810123F746@xmb-ams-33c.emea.cisco.com> In-Reply-To: <200802122219.16723.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rogue RA problem statement Thread-Index: AchttWoyjkAmjHejSzGyFqTGQmDJAABR4ixw From: "Gunter Van de Velde (gvandeve)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Deepak Bansal (NETWORKING)" Cc: "Mohacsi Janos" , "Tim Chown" , X-OriginalArrivalTime: 14 Feb 2008 11:53:52.0078 (UTC) FILETIME=[448C2EE0:01C86F00] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2727; t=1202990034; x=1203854034; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20 |Subject:=20RE=3A=20rogue=20RA=20problem=20statement |Sender:=20; bh=vt8YbAbpBE4xetCMtiV1TbP01ZZVpIazLHHPRaBBLbU=; b=XDx/JzdmUi7HyU1jqEF7vp1OcNqriKIXU53nz90TG1bdlZ2K4BITgnO0IA duCCsMU0eX9bEngxqKwGNtoVL9hbOlk4+OL9j9zAfZwg6Aowu8bWk5NCo18r g7SxEy88lF; Authentication-Results: ams-dkim-2; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline: GV> > Le Tuesday 12 February 2008 21:27:50 Deepak Bansal (NETWORKING), vous = avez =E9crit=A0: > > >The most recent last week was a > > > Vista machine that somehow didn't pick up the real online RA, and=20 > > >chose to become a 6to4 router as a result (apparently... we'll try = > > >to recreate this one). > > > > Vista will not become a 6to4 router unless ICS is enabled on it.=20 > > Hence, I suspect that the Vista machine in discussion here somehow = had=20 > > ICS enabled on it. > I don't know how easy or difficult or manually or automatically = enabling ICS is, but on a sizable (1000+) university > > with public = IPv4 addresses, that has been a recurrent problem ever since we've = provided IPv6 (4 years from now or so). > Vista "IPv6-on-by-default" did = not really help since then. Still, XP SP2 is the by far the worst, has = the built-in=20 > firewall blocks incoming RA while booting up. Then the PC decides = there is no IPv6 router (even though there *is*), and=20 > turns on 6to4 gatewaying. > Anyway, upgrading the switches to do some filtering is not an option.=20 GV> this statement could be correct for the problem that XP SP2 = experienced.=20 GV> In other cases however filtering RA will however be a simple = solution=20 GV> for devices that behave according specification, as for example CPE = routers attached to an access network of an ISP. GV> I have real SP asking for RA-Guard like capability in their access = networks for IPv6. GV> SeND will not be deployed their for a long time for many reasons and = hence RA-Guard behaviour=20 GV> at local access-network switches is an elegant solution.=20 GV> (I just don't buy the statement that SeND will solve their needs any = time soon, if ever) GV> Rogue-RA's is something that we should not avoid. It is a reality = NOW, and will be for next=20 GV> few years when v6 gets deployed further. We better understand the = issue, so correct action=20 GV> can be taken. Simply claiming SeND will solve 'all' is a bit = academic I suspect. It can solve=20 GV> certain aspects, but 'not all rogue-RA' issues in 'all = environments'. > Using SEND is not an option, especially as it's currently not = supported by anything on the market.=20 GV> this is next to the question of solving the root issue. Root issue = is not related to SeND. > So it looks like,=20 > for the foreseeable future, reactive "0 lifetime" RA fixups will = remain the only solution. As long as none of the >=20 > automatic 6to4 gateways are doing UNICAST Router Advertisement, it = works, even though it's an ugly hack. GV> yes, but it is the practical consequence of a host implementation G/ From oajcompany9979@acm.org Thu Feb 14 10:42:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4160428D12F for ; Thu, 14 Feb 2008 10:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.293 X-Spam-Level: X-Spam-Status: No, score=-86.293 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_96_XX=1.439, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlSyogLV0C6D for ; Thu, 14 Feb 2008 10:42:29 -0800 (PST) Received: from computer.lists.ietf.org (unknown [85.107.156.6]) by core3.amsl.com (Postfix) with SMTP id E8E7428D101 for ; Thu, 14 Feb 2008 10:40:48 -0800 (PST) Message-ID: <001101c86f4a$1077aa40$01912558@computer> From: "Loraine Cassidy" To: v6ops-archive@lists.ietf.org Subject: essay Date: Thu, 14 Mar 2008 20:42:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Hello, v6ops-archive From owner-v6ops@ops.ietf.org Fri Feb 15 00:48:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19CA3A6A55 for ; Fri, 15 Feb 2008 00:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiHUYvAveaUY for ; Fri, 15 Feb 2008 00:48:19 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BA0EE3A68AC for ; Fri, 15 Feb 2008 00:48:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPw8S-000ClK-PY for v6ops-data@psg.com; Fri, 15 Feb 2008 08:41:32 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPw8I-000CiW-2I for v6ops@ops.ietf.org; Fri, 15 Feb 2008 08:41:23 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 614D5C95; Fri, 15 Feb 2008 09:42:57 +0100 (CET) To: v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a newapproach MIME-Version: 1.0 Date: Fri, 15 Feb 2008 09:42:57 +0100 From: Remi Denis-Courmont Organization: Remlab.net In-Reply-To: <47B2EEF9.1010804@free.fr> References: <47B2EEF9.1010804@free.fr> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 13 Feb 2008 14:22:01 +0100, Rémi Després wrote: > > The issue is with *cascading* routers. With no bits to do > > routing within a site, if bridging is not possible, there > > is no choice but to use NAT. > There is IMHO a better alternative:  where no IPv6 prefix is > available, like behind a cascading router in a /64 site, use > another available tool. > (Teredo, tunnel broker etc, are IMU availble precisely for this). Neither Teredo nor TSP are suited in that case. You'd have to go to the Internet to reach hosts from the same site, but within different subnets. There is a reason why native IPv6 access and normal 6to4 are giving more than 64-bits. It's precisely because the solution to this problem is Prefix-Delegation. > > Where is the complexity in shifting some bits? > Right, "shifting bits" is simple. > It works if each ISP hasonly one RIR-provided prefix for all > its customers, but *only in this case*. Makes no difference how many prefixes the ISP has. In any case, the ISP-side endpoint needs to know the prefixes so that it cannot be abused by external users from other ISPs. Moving this issue away from the 64rd ISP endpoint and its addressing scheme to yet another box (a firewall, right) is arguably even more complicated, in fact. > Personally I don't know how many v4 prefixes Free has, > and plans to use. But, as you know,  ISPs tend to get > their v4 address space piece by piece. So? 64rd cannot avoid the problem anyway. -- Rémi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Fri Feb 15 17:31:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0893A6877 for ; Fri, 15 Feb 2008 17:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoHl7GhOM4kM for ; Fri, 15 Feb 2008 17:31:43 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 586C03A6BD3 for ; Fri, 15 Feb 2008 17:31:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQBk8-000NdD-Jb for v6ops-data@psg.com; Sat, 16 Feb 2008 01:21:28 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQBk5-000Ncu-Ro for v6ops@ops.ietf.org; Sat, 16 Feb 2008 01:21:27 +0000 Received: from eagle (192.168.123.10:1422) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Feb 2008 17:21:19 -0800 Reply-To: From: "Tony Hain" To: =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= , References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> In-Reply-To: <47B174FF.10505@free.fr> Subject: RE: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Fri, 15 Feb 2008 17:21:12 -0800 Message-ID: <02cc01c8703a$37abd000$a7037000$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AchtY2jyIfODkd6iQXOPH8ToQ4DW8QCx5JDA Content-Language: en-us Sender: owner-v6ops@ops.ietf.org Precedence: bulk Disclaimer: for several days others have been telling me I am = mis-reading this draft. That said, my interpretation is that this is broken, despite a quick = hack deployment. In any case, I don't believe the proposed fixes would be difficult changes for the existing deployment and will result in a = cleaner solution. Despite the elaborate Intro & Principles discussion, to clarify what I = think the goals are: 1) automate ISP controlled tunnels over IPv4-only aggregation equipment. 2) assign customer prefixes within ISP's delegated RIR prefix to contain = the size of the IPv6 DFZ Discussion: This general approach actually works well in the downstream direction as = a tool to automate PE to CPE tunneling. The PE already has to be = provisioned with the aggregating prefix for its downstream customers, so this is = really just an automated neighbor resolution process on the back end across the IPv4-only aggregation equipment. A BCP describing how to align an IPv6 aggregating prefix for automated PE tunneling would be a good thing, independent of this draft. The upstream direction is another story = though. Problems: 1) 'pure' tag makes a questionable assumption in light of unresolved and continuing RIR discussions about changing the status of 240/4. 2) causes ISPs to allocate unnaturally large prefixes to pops to = accommodate a mostly unused 32-bit field 3) the 3.5 discussion about accepting prefixes from other ISPs that = might contain a 6rd anycast is just wrong. First there is no way for an ISP to know which prefix its peer is using for a 6rd relay. Second, there is no reason to preclude it since the IPv6 6rd prefix would not match for = their sites, and the local CPE would not be configured for the other ISP's anycast, so the local CPE would never be attempting to send to the other ISP's 6rd anycast relays even if there is a route.=20 Fixes: Option 1) provide the IPv4 prefix & length:4 (really only need length:4 since CPE already has addr), as well as IPv6 prefix & length:6. Extract = bits (32-length:4) following IPv6 prefix/length:6, then append to IPv4 prefix = to create IPv4 next-hop. Pro: PE allocation size is the same for both versions =20 Con: CPE can only directly see its containing IPv4 aggregate=20 Resolution: DHCP option includes list of IPv4 prefixes & lengths that = are directly reachable Alternate Resolution: PE sends redirect for any other prefix in the IPv4 = IGP Con: CPE can't tell if a neighbor is tunneled or native Resolution: all CPE attached to a PE must move at the same time to a = prefix shorter than the ISP-wide 6rd one, or PE must host its portion of the shorter native prefix as well as the 6rd one. (much cleaner than assuming 224/3 is never a valid IPv4 dst) Option 2) CPE always initially sends to PE, PE sends redirect for = anything the CPE should be able to reach as indicated by the IPv4 IGP Pro: CPE defers routing decision to PE Pro: CPE configuration is just a 4213 manual tunnel Con: CPE router may ignore redirect Resolution: Requires spec so CPE will accept redirect from the upstream router Con: increases load on PE to generate redirects Resolution: CPE caches redirects for the lifetime of its DHCP lease (if redirect included length:4, the CPE could figure out the rest of that aggregate) Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of R=E9mi Despr=E9s > Sent: Tuesday, February 12, 2008 2:29 AM > To: v6ops@ops.ietf.org > Subject: 6rd - Rapid Deployment on existing IPv4 infrastructures - a > new approach >=20 > The I-D is available at: > = http://www.ietf.org/internet-drafts/draft-despres-v6ops-6rd-ipv6-rapid- > deployment-00.txt >=20 > (A previous file name had to be replaced by this one, more compatible > with recommended practices, and including the now selected WG > reference) >=20 > R=E9mi From owner-v6ops@ops.ietf.org Sun Feb 17 14:44:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776063A6A24 for ; Sun, 17 Feb 2008 14:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-1.956, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMK2mYT2peaF for ; Sun, 17 Feb 2008 14:44:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86E4C3A68EF for ; Sun, 17 Feb 2008 14:44:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQnLq-0000Kq-JM for v6ops-data@psg.com; Sun, 17 Feb 2008 17:30:54 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQnLm-0000KL-A2 for v6ops@ops.ietf.org; Sun, 17 Feb 2008 17:30:53 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm8d47b8b317; Mon, 18 Feb 2008 01:44:37 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1247b39c7b; Thr, 14 Feb 2008 07:43:57 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 14 Feb 2008 07:43:57 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9613828C964; Wed, 13 Feb 2008 15:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk4ZKCgQ1WdN; Wed, 13 Feb 2008 15:00:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B8C3A6F29; Wed, 13 Feb 2008 15:00:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F12FB3A6873; Wed, 13 Feb 2008 15:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-02.txt Message-Id: <20080213230001.F12FB3A6873@core3.amsl.com> Date: Wed, 13 Feb 2008 15:00:01 -0800 (PST) Cc: v6ops@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-02.txt Pages : 25 Date : 2008-02-13 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-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-cpe-simple-security-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-cpe-simple-security-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: <2008-02-13145955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-cpe-simple-security-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-cpe-simple-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-13145955.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-v6ops@ops.ietf.org Sun Feb 17 19:59:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F893A6853 for ; Sun, 17 Feb 2008 19:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwhBM8tA2S1 for ; Sun, 17 Feb 2008 19:59:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD5383A67A2 for ; Sun, 17 Feb 2008 19:59:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQx0f-0000va-74 for v6ops-data@psg.com; Mon, 18 Feb 2008 03:49:41 +0000 Received: from [209.85.198.187] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQx0c-0000vL-RD for v6ops@ops.ietf.org; Mon, 18 Feb 2008 03:49:39 +0000 Received: by rv-out-0910.google.com with SMTP id b22so1396681rvf.41 for ; Sun, 17 Feb 2008 19:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=pYSFArzG6tMN/QONSsK8cEqMOS4XqQUOU3rbLoXgxis=; b=jmj1vk8mc9oz7B2kL2uOoXjhTr2xhLv8sz+yXrBKFYFkiWwB50OP/gGU7uDPyY6ZlhuS7UWJSAVlAM1Wo38bejVVeakhNmN6AQ7rxJDf4MM0qL7csDHuNP2OsDyBzrIRIp4IL6D5/Wae8XmUBNW3jtARGZW6nADmsseSBSom3zI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=xML0AeSdf6eqGmhZU30d6s8prRQxouDOLbWcoRqfj2lLauVn3jbxPcNuUMcOOpTEDEYiEdkCAuluC7qJ52emETjWkBIfHDGhtEN106vQCv3kJ7eGjNlIxpkxgMZ2re1rvXRpvDP4q0VCAxcJIfYYu4RN+2DBH+NSrJYxBozugxw= Received: by 10.140.136.6 with SMTP id j6mr3512641rvd.50.1203306575830; Sun, 17 Feb 2008 19:49:35 -0800 (PST) Received: from ?10.1.1.4? ( [118.92.4.102]) by mx.google.com with ESMTPS id l17sm8205500rvb.21.2008.02.17.19.49.33 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Feb 2008 19:49:34 -0800 (PST) Message-ID: <47B9004A.30600@gmail.com> Date: Mon, 18 Feb 2008 16:49:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Remi Denis-Courmont CC: v6ops Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a newapproach References: <47B22317.1060909@free.fr> <20c70d4dc402a688d63d38fdd18bfee5@chewa.net> In-Reply-To: <20c70d4dc402a688d63d38fdd18bfee5@chewa.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-02-13 22:52, Remi Denis-Courmont wrote: > On Tue, 12 Feb 2008 23:52:07 +0100, R=C3=A9mi Despr=C3=A9s > wrote: >> On my home LAN, it doesn't suck at all. It just works to my complete >> satisfaction. >> Clearly it is desirable to do much better than this /64 first step, bu= t >> one step after another is sometimes a good way to progress. As long as any ISP deploying /64 to SOHO customers also has a way to provide a /48 to any customer who wants to subnet their network, at negligible extra cost, this could be OK. But customers who need /48 (or /56) must not be blocked. >=20 > The IETF has a long history of doing "provisional" "for a short time" > protocols that eventually last much much longer than intended. NATs are= > one. And 6to4... it was standardized over 5 years ago, and we are only = now > realizing that it does not work as well as intended.=20 As far as I know, nobody has deployed it as intended by RFC 3056. Brian From owner-v6ops@ops.ietf.org Mon Feb 18 00:58:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F80B3A6CB0 for ; Mon, 18 Feb 2008 00:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO9FtCE0HoO3 for ; Mon, 18 Feb 2008 00:58:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F0403A6BD5 for ; Mon, 18 Feb 2008 00:58:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR1jK-0009R4-Jp for v6ops-data@psg.com; Mon, 18 Feb 2008 08:52:06 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR1jG-0009QV-P7 for v6ops@ops.ietf.org; Mon, 18 Feb 2008 08:52:05 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1I8psZl072356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 09:51:56 +0100 (CET) (envelope-from iljitsch@muada.com) Cc: "=?ISO-8859-1?Q?=22'R=E9mi_Despr=E9s'=22?=" , Message-Id: <2D3B683A-9651-4E15-A0E7-2DDFA5AADFDC@muada.com> From: Iljitsch van Beijnum To: In-Reply-To: <02cc01c8703a$37abd000$a7037000$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Mon, 18 Feb 2008 09:51:51 +0100 References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <02cc01c8703a$37abd000$a7037000$@net> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 16 feb 2008, at 2:21, Tony Hain wrote: > 3) the 3.5 discussion about accepting prefixes from other ISPs that > might > contain a 6rd anycast is just wrong. First there is no way for an > ISP to > know which prefix its peer is using for a 6rd relay. Second, there > is no > reason to preclude it since the IPv6 6rd prefix would not match for > their > sites, and the local CPE would not be configured for the other ISP's > anycast, so the local CPE would never be attempting to send to the > other > ISP's 6rd anycast relays even if there is a route. What is a "6rd anycast address", anyway? I couldn't figure it out from the draft. The definition certainly isn't helpful: 6rd ISP anycast address: IPv4 anycast address chosen by a 6rd ISP From what you're saying it sounds an awful lot like what happens with 6to4, but that doesn't make any sense because we already have 6to4 and although that's certainly useful, it has the downside that it's impossible to improve the quality of the 6to4 experience. So the basic idea of something that is as simple to set up as 6to4 but where the routing is under control of an ISP is very attractive. From owner-v6ops@ops.ietf.org Mon Feb 18 05:47:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F76528C39A for ; Mon, 18 Feb 2008 05:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=-2.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZmlT-PiJpne for ; Mon, 18 Feb 2008 05:47:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C67428C3A9 for ; Mon, 18 Feb 2008 05:45:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR6Cv-000LnG-GF for v6ops-data@psg.com; Mon, 18 Feb 2008 13:38:57 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR6Cs-000Lmk-Oy for v6ops@ops.ietf.org; Mon, 18 Feb 2008 13:38:56 +0000 Received: (qmail 65191 invoked by uid 1007); 18 Feb 2008 13:38:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=a11cumSHu5D1TKbauUecWmlMcFruF1JbIKC6SCxx45UOQp2ywHMzmDA9o3/iV8sf ; Date: Mon, 18 Feb 2008 14:38:51 +0100 From: Gert Doering To: Iljitsch van Beijnum Cc: alh-ietf@tndh.net, =?iso-8859-1?Q?=22'R=E9mi_Despr=E9s'=22?= , v6ops@ops.ietf.org Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Message-ID: <20080218133851.GX69215@Space.Net> References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <02cc01c8703a$37abd000$a7037000$@net> <2D3B683A-9651-4E15-A0E7-2DDFA5AADFDC@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D3B683A-9651-4E15-A0E7-2DDFA5AADFDC@muada.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Feb 18, 2008 at 09:51:51AM +0100, Iljitsch van Beijnum wrote: > What is a "6rd anycast address", anyway? I couldn't figure it out from > the draft. The definition certainly isn't helpful: > > 6rd ISP anycast address: IPv4 anycast address chosen by a 6rd ISP > > From what you're saying it sounds an awful lot like what happens with > 6to4, Basically it's a locally-contained 6to4 cloud using IPv6 addresses delegated to the provider, instead of 2002::/16. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Feb 18 06:04:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D64E28C35A for ; Mon, 18 Feb 2008 06:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-2.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRFVoe7ZV2Jd for ; Mon, 18 Feb 2008 06:04:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85AD028C300 for ; Mon, 18 Feb 2008 06:04:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR6Zx-000P2y-BK for v6ops-data@psg.com; Mon, 18 Feb 2008 14:02:45 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR6Zu-000P1S-Ah for v6ops@ops.ietf.org; Mon, 18 Feb 2008 14:02:43 +0000 Received: (qmail 87383 invoked by uid 1007); 18 Feb 2008 14:02:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=Ff8hxnAAYmC3TdzWzz2jkGPcmru7ub3pyK4zd7kSQuXiDNiAsJhzZzmu2wVRO/Rd ; Date: Mon, 18 Feb 2008 15:02:41 +0100 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: Alexandru Petrescu , v6ops@ops.ietf.org Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt Message-ID: <20080218140241.GA69215@Space.Net> References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47AC8379.2070305@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47AC8379.2070305@free.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Feb 08, 2008 at 05:29:45PM +0100, Rémi Després wrote: > /64 is clearly not ideal, but is guaranteed to be possible for ISPs that > get only /32 from their RIR's. Using a more intelligent mapping function than "always use full 32 bit" for the mapping IPv4-Address <-> IPv6-Prefix would solve this. For example, if an ISP only has a /16 IPv4 address space, they could map this to a /48 IPv6 per end user, inside their IPv6 space: ::/48 - as the upper 16 bits are the same for all subscribers anyway. Tony Hain has brought up some approaches how to get the mapping table to the CPEs. Another thing could be to just statically provision the mapping tables (" range is 6rd, use point-to-point 6to4 tunnels - and all the rest is native, send to PE") in the CPEs at roll-out - as most ISPs do not get new IPv4 blocks *that* often. Or provision them at "automated centrally managed software update" time. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Feb 18 06:40:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B8B3A6C80 for ; Mon, 18 Feb 2008 06:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i79FQ+TtxPQ0 for ; Mon, 18 Feb 2008 06:40:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 495E13A67F7 for ; Mon, 18 Feb 2008 06:40:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR78K-0004o7-V6 for v6ops-data@psg.com; Mon, 18 Feb 2008 14:38:16 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR78I-0004nd-59 for v6ops@ops.ietf.org; Mon, 18 Feb 2008 14:38:15 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 3FFD53EA130; Mon, 18 Feb 2008 15:38:13 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id E924A3EA11A; Mon, 18 Feb 2008 15:38:12 +0100 (CET) Message-ID: <47B9984C.1040902@free.fr> Date: Mon, 18 Feb 2008 15:38:04 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gert Doering CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47AC8379.2070305@free.fr> <20080218140241.GA69215@Space.Net> In-Reply-To: <20080218140241.GA69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk The point being discussed is IMU simplicity vs functional richness. IMO, the "normal" 6rd is with a /24 ISP prefix, allowing for /58s site prefixes. Yet, to start quickly, as Free did it, /64s are nice to have instead of nothing. Note that if a site has a shorter than /32 IPv4 prefix, say a /28, then it has with 6rd the desired multi-subnet capability with 6rd. (Free happens to only assign /32s in IPv4). Note also that ISPs typically have their IPv4 prefixes coming one by one, with different lengths. Free's IPv4 prefixes, for example, are of lengths /16, /15, /14, two /11s, /10. he simple solution of your example couldn't apply. The code to deal with this, instead of being trivial, and with fixed length parameters, would bacome significantly more complex. The DHCP option also would be substantially lesss simple RD Gert Doering a écrit : > Hi, > > On Fri, Feb 08, 2008 at 05:29:45PM +0100, Rémi Després wrote: >> /64 is clearly not ideal, but is guaranteed to be possible for ISPs that >> get only /32 from their RIR's. > > Using a more intelligent mapping function than "always use full 32 bit" > for the mapping IPv4-Address <-> IPv6-Prefix would solve this. > > For example, if an ISP only has a /16 IPv4 address space, they could > map this to a /48 IPv6 per end user, inside their IPv6 space: > > ::/48 > > - as the upper 16 bits are the same for all subscribers anyway. > > > Tony Hain has brought up some approaches how to get the mapping table > to the CPEs. > > Another thing could be to just statically provision the mapping tables > (" range is 6rd, use point-to-point 6to4 tunnels - and all the rest > is native, send to PE") in the CPEs at roll-out - as most ISPs do not get > new IPv4 blocks *that* often. > > Or provision them at "automated centrally managed software update" time. > > Gert Doering > -- NetMaster From owner-v6ops@ops.ietf.org Mon Feb 18 07:16:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4DE28C440 for ; Mon, 18 Feb 2008 07:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-1.709, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za1p+XTa72Vf for ; Mon, 18 Feb 2008 07:16:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3472828C3FB for ; Mon, 18 Feb 2008 07:16:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR7gY-0009jo-RK for v6ops-data@psg.com; Mon, 18 Feb 2008 15:13:38 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR7gW-0009jU-7S for v6ops@ops.ietf.org; Mon, 18 Feb 2008 15:13:37 +0000 Received: (qmail 49944 invoked by uid 1007); 18 Feb 2008 15:13:34 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=HisYtZu+Hy7aMy43QG5gt2T620xTeRevDY53quiPiXlTw+gD8MdexUlvEsL3ZXlp ; Date: Mon, 18 Feb 2008 16:13:34 +0100 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: Gert Doering , v6ops@ops.ietf.org Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt Message-ID: <20080218151334.GE69215@Space.Net> References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47AC8379.2070305@free.fr> <20080218140241.GA69215@Space.Net> <47B9984C.1040902@free.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vCxiPl2gOWdyO0lm" Content-Disposition: inline In-Reply-To: <47B9984C.1040902@free.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk --vCxiPl2gOWdyO0lm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 18, 2008 at 03:38:04PM +0100, R=E9mi Despr=E9s wrote: > Note also that ISPs typically have their IPv4 prefixes coming one by=20 > one, with different lengths. > Free's IPv4 prefixes, for example, are of lengths /16, /15, /14, two=20 > /11s, /10. > he simple solution of your example couldn't apply. It would work just fine. The tables would be a bit less trivial, but to map 6 prefixes of maximum length /10 into 24 bits worth of IPv6 prefixes is well possible. > The code to deal with this, instead of being trivial, and with fixed=20 > length parameters, would bacome significantly more complex. The code would need to consult a mapping table, indeed. Which is not very advanced magic. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --vCxiPl2gOWdyO0lm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBR7mgnqkuBuNlUUl1AQJYGwP/aG0xx0BI8rDqh6nQ9y7OGj+5+AQq0zvY Td9j3SnDpmEdu6bbN8hJk9vlhz2zO8UaGY+2mAzGE+ty9itlPfse9F9MAzieUvT4 lbaMOd7tz1dBkqK1cv+sAScblpeA1xc4PCEg3pMIpa70Zew4bPNQjUlEaNME5oL5 oBy55kEOoR0= =8HPZ -----END PGP SIGNATURE----- --vCxiPl2gOWdyO0lm-- From owner-v6ops@ops.ietf.org Mon Feb 18 07:57:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9708828C479 for ; Mon, 18 Feb 2008 07:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCHUMKqiasWW for ; Mon, 18 Feb 2008 07:57:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78EF428C47A for ; Mon, 18 Feb 2008 07:55:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR8Id-000FG8-D3 for v6ops-data@psg.com; Mon, 18 Feb 2008 15:52:59 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JR8Ia-000FEm-QZ for v6ops@ops.ietf.org; Mon, 18 Feb 2008 15:52:58 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id DC9963EA0BE; Mon, 18 Feb 2008 16:52:55 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 9D4E53EA0D1; Mon, 18 Feb 2008 16:52:55 +0100 (CET) Message-ID: <47B9A9CB.8050104@free.fr> Date: Mon, 18 Feb 2008 16:52:43 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gert Doering CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47AC8379.2070305@free.fr> <20080218140241.GA69215@Space.Net> <47B9984C.1040902@free.fr> <20080218151334.GE69215@Space.Net> In-Reply-To: <20080218151334.GE69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Gert Doering a écrit : > Hi, > > On Mon, Feb 18, 2008 at 03:38:04PM +0100, Rémi Després wrote: >> Note also that ISPs typically have their IPv4 prefixes coming one by >> one, with different lengths. >> Free's IPv4 prefixes, for example, are of lengths /16, /15, /14, two >> /11s, /10. >> he simple solution of your example couldn't apply. > > It would work just fine. The tables would be a bit less trivial, but to > map 6 prefixes of maximum length /10 into 24 bits worth of IPv6 prefixes > is well possible. > >> The code to deal with this, instead of being trivial, and with fixed >> length parameters, would bacome significantly more complex. > > The code would need to consult a mapping table, indeed. > > Which is not very advanced magic. I can only agree, of course. A table IS indeed possible. It can replace of a simple parameter. Its maximum length will be somewhat arbitrary, but I am sure it can also be lived with. It would make operations and maintenance more complex (address readability in particular), but again, you re right, that's clearly possible. But the "Keep It Simple, Stupid" principle was a guide. In this instance, I still believe that keeping a KISS design is preferable. Note also that, if 256 ISPs deploy 6rd as is, and if all of them get /24s for that (so that 256 IPv6 subnets are available per site having an IPv4 address). Then, the address space consumed is less than that used for 6to4 (256 /24s, partially used, vs one /16). If this does facilitate IPv6 rapid deployment, in particular because it follows the KISS rule, this seems to me a reasonable price to be paid. Can we discuss this issue in Philadelphia? RD From owner-v6ops@ops.ietf.org Tue Feb 19 00:29:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9133B3A689C for ; Tue, 19 Feb 2008 00:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ3v-R6Ff-qi for ; Tue, 19 Feb 2008 00:29:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFDB03A6837 for ; Tue, 19 Feb 2008 00:29:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRNik-000A8L-Qv for v6ops-data@psg.com; Tue, 19 Feb 2008 08:20:58 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRNig-000A7c-Ly for v6ops@ops.ietf.org; Tue, 19 Feb 2008 08:20:56 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A72A23EA125; Tue, 19 Feb 2008 09:20:53 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 47ECA3EA0BC; Tue, 19 Feb 2008 09:20:53 +0100 (CET) Message-ID: <47BA915C.7080100@free.fr> Date: Tue, 19 Feb 2008 09:20:44 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: 'Tony Hain' CC: =?ISO-8859-1?Q?=27R=E9mi_Despr=E9s=27?= , v6ops@ops.ietf.org Subject: Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <02cc01c8703a$37abd000$a7037000$@net> In-Reply-To: <02cc01c8703a$37abd000$a7037000$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your detailed comments. Tony Hain wrote: > Problems: > > 1) 'pure' tag makes a questionable assumption in light of unresolved and > continuing RIR discussions about changing the status of 240/4. > OOPS There is a typo: 1110 as most significant bits is 224/4 (not 240/4 as written once). Apologies. > 2) causes ISPs to allocate unnaturally large prefixes to pops to accommodate > a mostly unused 32-bit field > See the answer to Gert Doering: http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00345.html > 3) the 3.5 discussion about accepting prefixes from other ISPs that might > contain a 6rd anycast is just wrong. First there is no way for an ISP to > know which prefix its peer is using for a 6rd relay. Second, there is no > reason to preclude it since the IPv6 6rd prefix would not match for their > sites, and the local CPE would not be configured for the other ISP's > anycast, so the local CPE would never be attempting to send to the other > ISP's 6rd anycast relays even if there is a route. > > There must be a misunderstanding. An ISP never needs to know 6rd anycast addresses of other ISPs. Routes an ISP has to make sure to refuse, if received by accident or malevolence, are routes to their OWN 6rd anycast prefix. It can be made clearer in the next version. RD From owner-v6ops@ops.ietf.org Tue Feb 19 11:09:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80D43A68D3 for ; Tue, 19 Feb 2008 11:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-3.822, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr9s0fo6qu41 for ; Tue, 19 Feb 2008 11:09:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F32C43A6AD8 for ; Tue, 19 Feb 2008 11:09:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRXjw-00058o-SC for v6ops-data@psg.com; Tue, 19 Feb 2008 19:02:52 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRXju-00058J-7V for v6ops@ops.ietf.org; Tue, 19 Feb 2008 19:02:51 +0000 Received: from eagle (192.168.123.10:4376) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 19 Feb 2008 11:01:56 -0800 Reply-To: From: "Tony Hain" To: =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= Cc: References: <20080208100001.D40A83A771E@core3.amsl.com> <47AC577E.8060109@gmail.com> <47B174FF.10505@free.fr> <02cc01c8703a$37abd000$a7037000$@net> <47BA915C.7080100@free.fr> In-Reply-To: <47BA915C.7080100@free.fr> Subject: RE: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach Date: Tue, 19 Feb 2008 11:01:50 -0800 Message-ID: <0c7301c87329$e3bdcfa0$ab396ee0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achy0fhTCKn1q5cZQh+0gqBwU9XkEwAVZ30A Content-Language: en-us Sender: owner-v6ops@ops.ietf.org Precedence: bulk R=E9mi Despr=E9s wrote: > Thanks for your detailed comments. >=20 > Tony Hain wrote: > > Problems: > > > > 1) 'pure' tag makes a questionable assumption in light of unresolved > and > > continuing RIR discussions about changing the status of 240/4. > > > OOPS > There is a typo: 1110 as most significant bits is 224/4 (not 240/4 as > written once). > Apologies. The tag is a waste to begin with, so fixing which block it talks about doesn't really solve the problem. > > 2) causes ISPs to allocate unnaturally large prefixes to pops to > accommodate > > a mostly unused 32-bit field > > > See the answer to Gert Doering: > http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00345.html A quick hack that is deployed does not mean this is a good design. The deployment could also have taken one /38 and handed out /48's to = customers, then put all the native IPv6 sites in a different /38 (note: both fit = well within the /32). Any CPE could find the others within the ISP because = the /38 matches, and anything else would go to the relay. No need for a = magic flag. No need for oversize allocations to deliver undersize prefixes to customers.=20 > > 3) the 3.5 discussion about accepting prefixes from other ISPs that > might > > contain a 6rd anycast is just wrong. First there is no way for an = ISP > to > > know which prefix its peer is using for a 6rd relay. Second, there = is > no > > reason to preclude it since the IPv6 6rd prefix would not match for > their > > sites, and the local CPE would not be configured for the other ISP's > > anycast, so the local CPE would never be attempting to send to the > other > > ISP's 6rd anycast relays even if there is a route. > > > > > There must be a misunderstanding. > An ISP never needs to know 6rd anycast addresses of other ISPs. > Routes an ISP has to make sure to refuse, if received by accident or > malevolence, are routes to their OWN 6rd anycast prefix. > It can be made clearer in the next version. For an ISP to guarantee proper routing of IPv6 packets going from its IPv4 sites to other ISPs, its IPv4 infrastructure SHOULD NOT accept from other ISPs IPv4 routes that include the 6rd ISP anycast address. If this is just saying 'don't accept your prefixes from another = provider', it is not clear that you even need to say that.=20 Tony From owner-v6ops@ops.ietf.org Wed Feb 20 11:00:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BEF28C9BA for ; Wed, 20 Feb 2008 11:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82Wnw8avyDN7 for ; Wed, 20 Feb 2008 11:00:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A66D28C86A for ; Wed, 20 Feb 2008 11:00:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRu0j-000F9E-Rn for v6ops-data@psg.com; Wed, 20 Feb 2008 18:49:41 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRu0g-000F8M-1H for v6ops@ops.ietf.org; Wed, 20 Feb 2008 18:49:40 +0000 Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id EE7BA30E8DFfor ; Wed, 20 Feb 2008 19:49:35 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Fwd: I-D Action:draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt Date: Wed, 20 Feb 2008 19:49:35 +0100 References: <20080220183001.E5E5E3A6A3C@core3.amsl.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.4014 TC:1F TRN:64 TV:5.0.1023(15742.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We have updated the draft including a more general presentation of the trnasition problem and the motivation for translators, and added a first list of requirements for translators. the goal of the draft is to promote discussion and in particular tune the requirements comments are very welcome, in particular, feedback from people exploring solutions would be great Regards, marcelo Inicio del mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 20 de febrero de 2008 19:30:01 GMT+01:00 > Para: i-d-announce@ietf.org > Asunto: I-D Action:draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv4/IPv6 Coexistence and Transition: > Requirements for solutions > Author(s) : M. Bagnulo, F. Baker > Filename : draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt > Pages : 17 > Date : 2008-02-20 > > This note presents the problem statement, analysis and requirements > for solutions to IPv4/IPv6 coexistence and eventual transition in a > scenario in which dual stack operation is not the norm. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-v6ops-6man-nat64-pb-statement-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-bagnulo-v6ops-6man-nat64-pb-statement-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-bagnulo-v6ops-6man-nat64-pb- > statement-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-02-20101536.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce From owner-v6ops@ops.ietf.org Mon Feb 25 05:12:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C1D28C1FA for ; Mon, 25 Feb 2008 05:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GOGlIe5t6-Q for ; Mon, 25 Feb 2008 05:12:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D8B028C23E for ; Mon, 25 Feb 2008 05:11:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTcyv-0007Yq-I8 for v6ops-data@psg.com; Mon, 25 Feb 2008 13:02:57 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTcyn-0007RS-CA for v6ops@ops.ietf.org; Mon, 25 Feb 2008 13:02:51 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 1810528C4B3; Mon, 25 Feb 2008 05:00:01 -0800 (PST) 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-addr-select-ps-04.txt Message-Id: <20080225130002.1810528C4B3@core3.amsl.com> Date: Mon, 25 Feb 2008 05:00:02 -0800 (PST) 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 : Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules Author(s) : A. Matsumoto, et al. Filename : draft-ietf-v6ops-addr-select-ps-04.txt Pages : 15 Date : 2008-02-25 One physical link can carry multiple subnets. Moreover, we can use multiple physical networks at the same time in a host. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. Without an appropriate source/ destination address selection mechanism, the host will experience some trouble in communication. RFC 3484 defines default source and destination address selection algorithms, but the multi-prefix environment considered here needs additional rules beyond those of the default operation. This document describes the possible problems that end hosts could encounter in an environment with multiple subnets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-04.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-addr-select-ps-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-addr-select-ps-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25045739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-addr-select-ps-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-addr-select-ps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25045739.I-D\@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Feb 25 08:54:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE693A6A41 for ; Mon, 25 Feb 2008 08:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPjh4ofOcrkX for ; Mon, 25 Feb 2008 08:54:44 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CA793A6C90 for ; Mon, 25 Feb 2008 08:54:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTgS9-000Edq-34 for v6ops-data@psg.com; Mon, 25 Feb 2008 16:45:21 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTgRl-000EaH-Ds for v6ops@ops.ietf.org; Mon, 25 Feb 2008 16:45:02 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id BB7C93A6A41; Mon, 25 Feb 2008 08:45:01 -0800 (PST) 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-teredo-security-concerns-02.txt Message-Id: <20080225164501.BB7C93A6A41@core3.amsl.com> Date: Mon, 25 Feb 2008 08:45:01 -0800 (PST) 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 : Teredo Security Concerns Author(s) : J. Hoagland, S. Krishnan Filename : draft-ietf-v6ops-teredo-security-concerns-02.txt Pages : 20 Date : 2008-02-25 Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo's security implications. The primary intent of this document is to raise the awareness regarding the security issues in Teredo as deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-teredo-security-concerns-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-teredo-security-concerns-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-teredo-security-concerns-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: <2008-02-25083133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-teredo-security-concerns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-teredo-security-concerns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25083133.I-D\@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Feb 28 09:21:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5773F3A6923 for ; Thu, 28 Feb 2008 09:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFoBArBhTe+z for ; Thu, 28 Feb 2008 09:21:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 786113A6E60 for ; Thu, 28 Feb 2008 09:21:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUmJ7-0000e0-U0 for v6ops-data@psg.com; Thu, 28 Feb 2008 17:12:33 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUmJ4-0000dD-TK for v6ops@ops.ietf.org; Thu, 28 Feb 2008 17:12:32 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1SHCKuD007864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Feb 2008 11:12:25 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1SHCKhu004994 for ; Thu, 28 Feb 2008 09:12:20 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1SHCJQI004923 for ; Thu, 28 Feb 2008 09:12:19 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 09:12:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) Date: Thu, 28 Feb 2008 09:12:16 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEB4@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) thread-index: AchtBlQLjkHj432HT5+LfAhaAW/K4gAAUw0QADUyxPAAJLuXEAJZ8GVQAJRmgUA= From: "Templin, Fred L" To: X-OriginalArrivalTime: 28 Feb 2008 17:12:17.0151 (UTC) FILETIME=[11D778F0:01C87A2D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Forwarding from the int-area list, a new document with v6ops implications is available and titled: "Subnetwork Encapsulation and Adaptation Layer (SEAL)" http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt This specification considers the use case for router-to-router tunneling of IPv6 over IPv4 in enterprise networks, MANETs, and the global Internet routing core. It also addresses many of the tunnel MTU and fragmentation issues raised in RFC4459. Additional background on the proposed approach is given in the forwarded message (below). Please review along with the document itself and send comments. Fred fred.l.templin@boeing.com=20 -----Original Message----- From: Templin, Fred L=20 Sent: Monday, February 25, 2008 9:58 AM To: Internet Area Subject: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) This message is forwared from the Routing Research Group mailing list. A new document with int-area implications is available and titled: "Subnetwork Encapsulation and Adaptation Layer (SEAL)" http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt SEAL in part specifies an MTU determination scheme based on the Report Fragmentation (RF) concept that was first proposed by Charles Lynn on the tcp-ip mailing list in 1987 and re-introduced by Steve Deering on the Path MTU working group mailing list in 1989. Digests from those lists are found at: http://ipvlx.com/tcp_ip.txt http://gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log Based on the list discussions, the Report Fragmentation (RF) method seemed to be the most attractive approach under consideration for IPv4 path MTU discovery, but was abandoned in favor of the (Don't Fragment/Fragmentation Needed) method that eventually became RFC1191. The RF method seems to have been abandoned due in part to difficulty in procuring an "RF" bit in the IPv4 header, difficulty in defining an ICMP Fragmentation Report message and the concern that not all hosts at that time correctly implemented IP reassembly. The SEAL proposal addresses all of these points (as well as others) and shows that a Report Fragmentation-based path MTU discovery capability for router-to-router tunneling in the Internet is still possible and could correct the operational difficulties associated with traditional path MTU discovery approaches. Moreover, the SEAL approach supports true diversity, especially for subnetworks that contain heterogeneous link types with diverse MTUs and/or L2 address formats. Please review and comment, Fred fred.l.templin@boeing.com _______________________________________________ Int-area mailing list Int-area@ietf.org http://www.ietf.org/mailman/listinfo/int-area