From owner-v6ops@ops.ietf.org Fri May 2 05:00:27 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 0D7A23A6BEB for ; Fri, 2 May 2008 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 mPWPpNsm87-R for ; Fri, 2 May 2008 05:00:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6A4328C0F2 for ; Fri, 2 May 2008 04:58:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrtkM-000G0e-UT for v6ops-data@psg.com; Fri, 02 May 2008 11:48:14 +0000 Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrtkB-000FyQ-MA for v6ops@ops.ietf.org; Fri, 02 May 2008 11:48:09 +0000 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2DEE41EF131; Fri, 2 May 2008 14:48:01 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id BEF411EF118; Fri, 2 May 2008 14:48:00 +0300 (EEST) Message-Id: From: Christian Vogt To: gunter@cisco.com, elevyabe@cisco.com, cpopovic@cisco.com, mohacsi@niif.hu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Review of RA Guard, draft-vandevelde-v6ops-ra-guard-01 Date: Fri, 2 May 2008 14:48:00 +0300 Cc: v6ops Mailing List X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk Gunter, Eric, Ciprian, Janos, I read your RA Guard proposal, and I believe this will be a very useful feature. Especially the simple operational mode, in which Router Advertisement messages are allowed only on manually pre-configured ports, would provide a good level of security at low cost. Two comments, nevertheless: (1) The RA Guard currently has two separate state machines, one for the RA Guard device itself, and one on the per-interface level. I do not see a convincing need for having two state machines instead of one. It seems that you want the RA Guard to operate on a per-interface basis, and that it needs "Off", "Learning", and "Validating" modes. Wouldn't one state machine per interface be sufficient? Why do you need the RA-Guard-level state machine in addition. (Of course, having only the interface-level state machines wouldn't prevent an implementation from providing a user interface that lets the administrator toggle the mode simultaneously for all interfaces on the RA Guard device. This would allow the administrator to switch all interfaces to Learning mode, e.g., with a single mouse click.) (2) And one editorial comment: In section 3.2., "RA-Guard state: LEARNING", you say: "A device or interface in the RA-Guard "Learning" state is actively acquiring information about the devices connected to its interfaces. The learning process takes place over a pre-defined period of time by capturing router advertisments or it can be event triggered. The information gathered is compared against pre-defined criteria which qualify the validity of the RAs." Can you elaborate on what "pre-defined criteria" means in the last sentence? Best regards, - Christian From owner-v6ops@ops.ietf.org Fri May 2 13:45: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 9892928C24E for ; Fri, 2 May 2008 13:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 cwDl3K0LAxb2 for ; Fri, 2 May 2008 13:44:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A72493A6A94 for ; Fri, 2 May 2008 13:43:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Js1z6-0006EF-MJ for v6ops-data@psg.com; Fri, 02 May 2008 20:36:00 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Js1yi-0006BL-99 for v6ops@ops.ietf.org; Fri, 02 May 2008 20:35:48 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m42KZQOt003579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 15:35:31 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m42KZQtf017459 for ; Fri, 2 May 2008 13:35:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m42KZO4L017405 for ; Fri, 2 May 2008 13:35:26 -0700 (PDT) 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.3959); Fri, 2 May 2008 13:35:24 -0700 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: isatap updates Date: Fri, 2 May 2008 13:35:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EE05B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: isatap updates Thread-Index: AcisTmJjBbSJsWRPTxyiQjpUrWsz2gARLNog References: From: "Templin, Fred L" To: "v6ops Mailing List" X-OriginalArrivalTime: 02 May 2008 20:35:25.0117 (UTC) FILETIME=[0CDF7ED0:01C8AC94] Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, http://isatap.org has been updated to reflect recent publications of RFC5214 and linux kernel source code. Links to other related initiatives have also been added. From owner-v6ops@ops.ietf.org Mon May 5 05:44: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 C44F23A69DF for ; Mon, 5 May 2008 05:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 mu9fBi0J3o5i for ; Mon, 5 May 2008 05:44:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA5443A6CD8 for ; Mon, 5 May 2008 05:44:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jszsd-0008dB-4P for v6ops-data@psg.com; Mon, 05 May 2008 12:33:19 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JszsP-0008ba-Ru for v6ops@ops.ietf.org; Mon, 05 May 2008 12:33:11 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id B8C073EA128; Mon, 5 May 2008 14:33:04 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id E6A2B3EA0AD; Mon, 5 May 2008 14:33:03 +0200 (CEST) Message-ID: <481EFE86.3060808@free.fr> Date: Mon, 05 May 2008 14:33:10 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops CC: ext Philip Matthews , behave@ietf.org Subject: Re: [BEHAVE] IPv4/IPv6 relayed address allocation References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> In-Reply-To: <200805050923.50429.remi.denis-courmont@nokia.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 a écrit : > Le Friday 02 May 2008 22:16:02 ext Philip Matthews, vous avez écrit : >> TURN-08 will say that a server should copy the flow label, and if this >> cannot be done, then treat the packets to/from each peer as a separate >> flow with separate labels. This is all part of the new concept of a >> Preserving allocation (what I called a "Fully-Compliant allocation" in >> Philly) that I am in the process of adding right now. > > I myself am not sure what the "proper" handling of the flow infos is. If > anyone knows, that would be some 6man and/or v6ops people (not including me). > Flow infos is not just like DSCP. Reflecting this, the Linux(-specific) API > for flow infos is completely different from that of DSCP and TTL... Pending any approved use of flow labels, there is IMU only one consistent behavior, everywhere: the flow label field MUST be ignored when received, and MUST be set to 0 when created . If and when some use is approved, it will be time to decide whether, in TURN in particular, another behavior is more appropriate. Rémi From owner-v6ops@ops.ietf.org Mon May 5 06:24: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 588523A6B2C for ; Mon, 5 May 2008 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, 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 FUrnnBPxwJVb for ; Mon, 5 May 2008 06:24:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6639A3A68D5 for ; Mon, 5 May 2008 06:24:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt0dJ-000DMH-Fd for v6ops-data@psg.com; Mon, 05 May 2008 13:21:33 +0000 Received: from [216.254.141.171] (helo=mail-08.primus.ca) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt0d8-000DL4-PV for v6ops@ops.ietf.org; Mon, 05 May 2008 13:21:28 +0000 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jt0d8-0007wN-03; Mon, 05 May 2008 09:21:22 -0400 Cc: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops , behave@ietf.org Message-Id: <9925D171-E6BA-4490-B9A8-D44419CA221D@magma.ca> From: Philip Matthews To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <481EFE86.3060808@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: IPv6 Flow Label Date: Mon, 5 May 2008 09:21:21 -0400 References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> <481EFE86.3060808@free.fr> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 5-May-08, at 08:33 , R=E9mi Despr=E9s wrote: > R=E9mi Denis-Courmont a =E9crit : >> Le Friday 02 May 2008 22:16:02 ext Philip Matthews, vous avez =E9crit = : > >>> TURN-08 will say that a server should copy the flow label, and if =20= >>> this >>> cannot be done, then treat the packets to/from each peer as a =20 >>> separate >>> flow with separate labels. This is all part of the new concept of a >>> Preserving allocation (what I called a "Fully-Compliant =20 >>> allocation" in >>> Philly) that I am in the process of adding right now. >> I myself am not sure what the "proper" handling of the flow infos =20 >> is. If anyone knows, that would be some 6man and/or v6ops people =20 >> (not including me). Flow infos is not just like DSCP. Reflecting =20 >> this, the Linux(-specific) API for flow infos is completely =20 >> different from that of DSCP and TTL... > > Pending any approved use of flow labels, there is IMU only one =20 > consistent behavior, everywhere: the flow label field MUST be =20 > ignored when received, and MUST be set to 0 when created . > > If and when some use is approved, it will be time to decide whether, =20= > in TURN in particular, another behavior is more appropriate. What about RFC 3697 ?? Are you saying that this does not describe approved behavior? - Philip= From owner-v6ops@ops.ietf.org Mon May 5 09:13:17 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 A1DF33A6817 for ; Mon, 5 May 2008 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 jTWRQ1ry-4G7 for ; Mon, 5 May 2008 09:13:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7D1628C242 for ; Mon, 5 May 2008 09:12:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt3BY-0005w6-Ql for v6ops-data@psg.com; Mon, 05 May 2008 16:05:04 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt3BM-0005tK-Sn for v6ops@ops.ietf.org; Mon, 05 May 2008 16:04:58 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5F3EC84991; Mon, 5 May 2008 18:04:47 +0200 (CEST) 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 Xrdq5fzkXwym; Mon, 5 May 2008 18:04:44 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 327EC84956; Mon, 5 May 2008 18:04:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 31040848F6; Mon, 5 May 2008 18:04:44 +0200 (CEST) Date: Mon, 5 May 2008 18:04:44 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Christian Vogt cc: gunter@cisco.com, elevyabe@cisco.com, cpopovic@cisco.com, v6ops Mailing List Subject: Re: Review of RA Guard, draft-vandevelde-v6ops-ra-guard-01 In-Reply-To: Message-ID: <20080505175115.V42152@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Christian, Thanks for the comments. On Fri, 2 May 2008, Christian Vogt wrote: > Gunter, Eric, Ciprian, Janos, > > I read your RA Guard proposal, and I believe this will be a very > useful feature. Especially the simple operational mode, in which > Router Advertisement messages are allowed only on manually > pre-configured ports, would provide a good level of security at low > cost. Two comments, nevertheless: > > (1) The RA Guard currently has two separate state machines, one for > the RA Guard device itself, and one on the per-interface level. I > do not see a convincing need for having two state machines instead > of one. It seems that you want the RA Guard to operate on a > per-interface basis, and that it needs "Off", "Learning", and > "Validating" modes. Wouldn't one state machine per interface be > sufficient? Why do you need the RA-Guard-level state machine in > addition. > > (Of course, having only the interface-level state machines > wouldn't prevent an implementation from providing a user > interface that lets the administrator toggle the mode > simultaneously for all interfaces on the RA Guard device. This > would allow the administrator to switch all interfaces to > Learning mode, e.g., with a single mouse click.) I think also that interface level state machine is enough + a global configuration options. We will clarify the text on the state machine. We will also discuss among the co-authors. > > (2) And one editorial comment: In section 3.2., "RA-Guard state: > LEARNING", you say: > > "A device or interface in the RA-Guard "Learning" state is > actively acquiring information about the devices connected to its > interfaces. The learning process takes place over a pre-defined > period of time by capturing router advertisments or it can be > event triggered. The information gathered is compared against > pre-defined criteria which qualify the validity of the RAs." > > Can you elaborate on what "pre-defined criteria" means in the > last sentence? This might be some information configured in the switch also - valid mac addresses of the routers (e.g. multiple mac address in case of HA setup), or valid prefixes or valid lifetime or prefered lifetime. I think it is purely optional. I think it should not contain similar configuration parameters as routers have since maintaining consistency is would be difficult. We will clarify on this one also. Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From owner-v6ops@ops.ietf.org Mon May 5 12:44:25 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 3BBCC3A6A11 for ; Mon, 5 May 2008 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Ch+QBGP2Mn+p for ; Mon, 5 May 2008 12:44:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D5033A68D9 for ; Mon, 5 May 2008 12:44:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt6UV-00016i-1l for v6ops-data@psg.com; Mon, 05 May 2008 19:36:51 +0000 Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt6UJ-00014K-8Z for v6ops@ops.ietf.org; Mon, 05 May 2008 19:36:45 +0000 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8DA8A1EF131; Mon, 5 May 2008 22:36:36 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 218AB1EF12E; Mon, 5 May 2008 22:36:36 +0300 (EEST) Cc: gunter@cisco.com, elevyabe@cisco.com, cpopovic@cisco.com, v6ops Mailing List Message-Id: From: Christian Vogt To: Mohacsi Janos In-Reply-To: <20080505175115.V42152@mignon.ki.iif.hu> 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: Review of RA Guard, draft-vandevelde-v6ops-ra-guard-01 Date: Mon, 5 May 2008 22:36:35 +0300 References: <20080505175115.V42152@mignon.ki.iif.hu> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk Janos, thanks for addressing my comments. Good to hear they were useful. - Christian On May 5, 2008, at 19:04, Mohacsi Janos wrote: > Hi Christian, > > Thanks for the comments. > > On Fri, 2 May 2008, Christian Vogt wrote: > >> Gunter, Eric, Ciprian, Janos, >> >> I read your RA Guard proposal, and I believe this will be a very >> useful feature. Especially the simple operational mode, in which >> Router Advertisement messages are allowed only on manually >> pre-configured ports, would provide a good level of security at low >> cost. Two comments, nevertheless: >> >> (1) The RA Guard currently has two separate state machines, one for >> the RA Guard device itself, and one on the per-interface level. I >> do not see a convincing need for having two state machines instead >> of one. It seems that you want the RA Guard to operate on a >> per-interface basis, and that it needs "Off", "Learning", and >> "Validating" modes. Wouldn't one state machine per interface be >> sufficient? Why do you need the RA-Guard-level state machine in >> addition. >> >> (Of course, having only the interface-level state machines >> wouldn't prevent an implementation from providing a user >> interface that lets the administrator toggle the mode >> simultaneously for all interfaces on the RA Guard device. This >> would allow the administrator to switch all interfaces to >> Learning mode, e.g., with a single mouse click.) > > > I think also that interface level state machine is enough + a global > configuration options. We will clarify the text on the state machine. > We will also discuss among the co-authors. > >> >> (2) And one editorial comment: In section 3.2., "RA-Guard state: >> LEARNING", you say: >> >> "A device or interface in the RA-Guard "Learning" state is >> actively acquiring information about the devices connected to its >> interfaces. The learning process takes place over a pre-defined >> period of time by capturing router advertisments or it can be >> event triggered. The information gathered is compared against >> pre-defined criteria which qualify the validity of the RAs." >> >> Can you elaborate on what "pre-defined criteria" means in the >> last sentence? > > This might be some information configured in the switch also - valid > mac addresses of the routers (e.g. multiple mac address in case of > HA setup), or valid prefixes or valid lifetime or prefered lifetime. > I think it is purely optional. I think it should not contain similar > configuration parameters as routers have since maintaining > consistency is would be difficult. We will clarify on this one also. > > > > Best Regards, > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and > Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > > > From owner-v6ops@ops.ietf.org Mon May 5 14:29: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 421AB3A6B88 for ; Mon, 5 May 2008 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 R2BquMwOJOqY for ; Mon, 5 May 2008 14:29:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46BA23A6B70 for ; Mon, 5 May 2008 14:29:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt8AT-000BZF-Bj for v6ops-data@psg.com; Mon, 05 May 2008 21:24:17 +0000 Received: from [209.85.146.178] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt8AI-000BYF-JX for v6ops@ops.ietf.org; Mon, 05 May 2008 21:24:11 +0000 Received: by wa-out-1112.google.com with SMTP id j37so925940waf.23 for ; Mon, 05 May 2008 14:24:06 -0700 (PDT) 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=OayquIl0ElweDhJH587V/oPS8Z92J/K/UM++36fC444=; b=r0zqSnxzG0WLq2LrefbnDpfdSAPbznDG5hR0AZXxiNkk43YUmUIOezShkWOk4e/rlz0qDtMltI+3po4IMV77ACPM+clNg/ZN/TvTM8gZiPG9UiuDVF7q1lel5oeUvCxirv3zjkDkJFt8AwiqlmznU3uegHAFhlnqal3GbAduERI= 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=jAOTdRP6lCZ8cSNPud54ylMKg1lWiOPv626ednrsT/PjrGjozvOZSlJMBBeKze8YzsRCt3Bdazq45d3l9Wl6U/60pxqY+364P+zKCFZM5c6OuS88nXZXzIzli3h8E3VA3CukhOZb1PbvH8ctYZD1GLGEWtjcpvl8MhHKGyMz08k= Received: by 10.115.76.1 with SMTP id d1mr6168693wal.228.1210022646248; Mon, 05 May 2008 14:24:06 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m40sm11491613wag.50.2008.05.05.14.23.59 (version=SSLv3 cipher=RC4-MD5); Mon, 05 May 2008 14:24:01 -0700 (PDT) Message-ID: <481F7AEC.7030209@gmail.com> Date: Tue, 06 May 2008 09:23:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews CC: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= , v6ops , behave@ietf.org Subject: Re: IPv6 Flow Label References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> <481EFE86.3060808@free.fr> <9925D171-E6BA-4490-B9A8-D44419CA221D@magma.ca> In-Reply-To: <9925D171-E6BA-4490-B9A8-D44419CA221D@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-05-06 01:21, Philip Matthews wrote: >=20 > On Mon, 5-May-08, at 08:33 , R=C3=A9mi Despr=C3=A9s wrote: >> R=C3=A9mi Denis-Courmont a =C3=A9crit : >>> Le Friday 02 May 2008 22:16:02 ext Philip Matthews, vous avez =C3=A9c= rit : >> >>>> TURN-08 will say that a server should copy the flow label, and if th= is >>>> cannot be done, then treat the packets to/from each peer as a separa= te >>>> flow with separate labels. This is all part of the new concept of a >>>> Preserving allocation (what I called a "Fully-Compliant allocation" = in >>>> Philly) that I am in the process of adding right now. >>> I myself am not sure what the "proper" handling of the flow infos is.= >>> If anyone knows, that would be some 6man and/or v6ops people (not >>> including me). Flow infos is not just like DSCP. Reflecting this, the= >>> Linux(-specific) API for flow infos is completely different from that= >>> of DSCP and TTL... >> >> Pending any approved use of flow labels, there is IMU only one >> consistent behavior, everywhere: the flow label field MUST be ignored >> when received, and MUST be set to 0 when created . >> >> If and when some use is approved, it will be time to decide whether, >> in TURN in particular, another behavior is more appropriate. >=20 >=20 > What about RFC 3697 ?? > Are you saying that this does not describe approved behavior? It does, of course. So the rule is really only that the flow label must be delivered *exactly* as it was set by the source host (and the default setting is zero). TURN has to obey that rule like any other device that forwards packets. Brian From owner-v6ops@ops.ietf.org Mon May 5 20:28: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 A56533A6CCA for ; Mon, 5 May 2008 20:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 C95NyFqCT9Au for ; Mon, 5 May 2008 20:28:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C76C3A6B58 for ; Mon, 5 May 2008 20:28:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtDjk-000JjY-2e for v6ops-data@psg.com; Tue, 06 May 2008 03:21:04 +0000 Received: from [209.85.198.226] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtDjY-000Jik-TH for v6ops@ops.ietf.org; Tue, 06 May 2008 03:20:58 +0000 Received: by rv-out-0506.google.com with SMTP id b25so328661rvf.41 for ; Mon, 05 May 2008 20:20:52 -0700 (PDT) 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=NAB/lDgyvCQYdQQNwqJrjLL8E3Ncs+jI5UnXD4iMorE=; b=O3DNfQVPT7fInyNKmJDsUSM5fDfAaEhvgHbLBDGluWFLkAUPQfbyDKiE60fmLBBpcV+elNzL0b6JmtusLw897vBgo3Sm3/dwL0blX2pV8frN/OaqUqCyU9LKst5og6I69Ks/c7185MUFOBo+s0SJAeY7IXqGJFIm3BgDCwUYcrQ= 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=UspHjaJu2v84otlHD+fD4kEbgbw2DKZKRTZcU2qXgq8OrOK0d20wAhG7X05uKS1GAm5Dd5/5VEzOvP5V23RCTZ0JWC6DBX6yhhPj0llR7YjiwtYcLwgJC/XWYKHhDSTj01d+0vcq2dWTwoU1dfcO4UmMeIZX/6nAm3nzUE8/ob4= Received: by 10.141.101.15 with SMTP id d15mr101887rvm.249.1210044052462; Mon, 05 May 2008 20:20:52 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k41sm193387rvb.3.2008.05.05.20.20.50 (version=SSLv3 cipher=RC4-MD5); Mon, 05 May 2008 20:20:52 -0700 (PDT) Message-ID: <481FCE95.50006@gmail.com> Date: Tue, 06 May 2008 15:20:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews CC: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= , v6ops , behave@ietf.org Subject: Re: IPv6 Flow Label References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> <481EFE86.3060808@free.fr> <9925D171-E6BA-4490-B9A8-D44419CA221D@magma.ca> <481F7AEC.7030209@gmail.com> <9F366B86-DEDB-4BD1-8D68-F614AB910FD8@magma.ca> In-Reply-To: <9F366B86-DEDB-4BD1-8D68-F614AB910FD8@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-05-06 13:20, Philip Matthews wrote: >=20 > On Mon, 5-May-08, at 17:23 , Brian E Carpenter wrote: >> On 2008-05-06 01:21, Philip Matthews wrote: >>> >>> On Mon, 5-May-08, at 08:33 , R=C3=A9mi Despr=C3=A9s wrote: >>>> R=C3=A9mi Denis-Courmont a =C3=A9crit : >>>>> Le Friday 02 May 2008 22:16:02 ext Philip Matthews, vous avez =C3=A9= crit : >>>> >>>>>> TURN-08 will say that a server should copy the flow label, and if >>>>>> this >>>>>> cannot be done, then treat the packets to/from each peer as a >>>>>> separate >>>>>> flow with separate labels. This is all part of the new concept of = a >>>>>> Preserving allocation (what I called a "Fully-Compliant >>>>>> allocation" in >>>>>> Philly) that I am in the process of adding right now. >>>>> I myself am not sure what the "proper" handling of the flow infos i= s. >>>>> If anyone knows, that would be some 6man and/or v6ops people (not >>>>> including me). Flow infos is not just like DSCP. Reflecting this, t= he >>>>> Linux(-specific) API for flow infos is completely different from th= at >>>>> of DSCP and TTL... >>>> >>>> Pending any approved use of flow labels, there is IMU only one >>>> consistent behavior, everywhere: the flow label field MUST be ignore= d >>>> when received, and MUST be set to 0 when created . >>>> >>>> If and when some use is approved, it will be time to decide whether,= >>>> in TURN in particular, another behavior is more appropriate. >>> >>> >>> What about RFC 3697 ?? >>> Are you saying that this does not describe approved behavior? >> >> It does, of course. So the rule is really only that the flow label >> must be delivered *exactly* as it was set by the source host (and the >> default setting is zero). TURN has to obey that rule like any other >> device that forwards packets. >> >=20 > For the folks in V6OPS, let me describe the situation more precisely. A= > TURN server receives packets from a TURN client and relays them toward = a > TURN peer. In the process, the server changes both the source and > destination address. Packets can also flow in the reverse direction. >=20 > For the IPv6 flow label, the best solution as far as I can see, is to > copy the flow label from the incoming packet to the outgoing packet. > This seems the right thing to do, even though the source and destinatio= n > addresses change. Since the addresses change, it is possible that two > logically distinct flows that originally had distinct 3-tuples (source > IP, dest IP, flow label) before reaching the server get assigned the > same 3-tuple after relaying. However, as far as I can see, having the > same 3-tuple does not means the packets ARE part of the same flow, but > just that they MAY be part of the same flow. >=20 > Copying the flow label and other fields in the IP header requires > special privileges on most modern OSes (e.g. RAW sockets or kernel > access). So TURN also allows a mode where fields in the IP header are > not copied, but are set as best as possible using unprivileged user-lan= d > APIs. I am not sure what the situation is for the flow label, but for > many other IP header fields, it is easy to set these fields on outgoing= > packets, but impossible to read them on incoming packets. So a somewhat= > less desirable but acceptable solution when relaying the flow label, as= > I can see, is to assume all the packets coming from a given client and > going to a given peer constitute a distinct flow and thus assign them a= > unique flow label after relaying the packets. And similarly in the > opposite direction. >=20 > Comments? My comment is that there's never a valid reason to rewrite IPv6 addresses= on the fly, so I don't see why the problem arises. I don't understand the context in which TURN would face this problem, therefore. If you terminate one IPv6 packet flow and originate another one carrying the same application data, that makes two independent flows and they should have independent flow labels. Brian From owner-v6ops@ops.ietf.org Mon May 5 21:32:52 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 056DA3A6AB2 for ; Mon, 5 May 2008 21:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, 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 Cr7yyaq3LAYm for ; Mon, 5 May 2008 21:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C2A93A67CE for ; Mon, 5 May 2008 21:32:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtEmb-000PzX-2j for v6ops-data@psg.com; Tue, 06 May 2008 04:28:05 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtEmQ-000PyH-5u for v6ops@ops.ietf.org; Tue, 06 May 2008 04:27:59 +0000 Received: from [211.27.108.142] (helo=[10.0.0.10]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtEmB-0006Nx-GQ; Tue, 06 May 2008 14:27:40 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 14:27:30 +1000 Subject: Re: IPv6 Flow Label From: Hesham Soliman To: Brian E Carpenter , Philip Matthews CC: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , v6ops , Message-ID: Thread-Topic: IPv6 Flow Label Thread-Index: AcivMX8O3GkPE3FR4ECV0rJM/CqwRg== In-Reply-To: <481FCE95.50006@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> For the folks in V6OPS, let me describe the situation more precisely. A >> TURN server receives packets from a TURN client and relays them toward a >> TURN peer. In the process, the server changes both the source and >> destination address. Packets can also flow in the reverse direction. >> >> For the IPv6 flow label, the best solution as far as I can see, is to >> copy the flow label from the incoming packet to the outgoing packet. >> This seems the right thing to do, even though the source and destination >> addresses change. Since the addresses change, it is possible that two >> logically distinct flows that originally had distinct 3-tuples (source >> IP, dest IP, flow label) before reaching the server get assigned the >> same 3-tuple after relaying. However, as far as I can see, having the >> same 3-tuple does not means the packets ARE part of the same flow, but >> just that they MAY be part of the same flow. >> >> Copying the flow label and other fields in the IP header requires >> special privileges on most modern OSes (e.g. RAW sockets or kernel >> access). So TURN also allows a mode where fields in the IP header are >> not copied, but are set as best as possible using unprivileged user-land >> APIs. I am not sure what the situation is for the flow label, but for >> many other IP header fields, it is easy to set these fields on outgoing >> packets, but impossible to read them on incoming packets. So a somewhat >> less desirable but acceptable solution when relaying the flow label, as >> I can see, is to assume all the packets coming from a given client and >> going to a given peer constitute a distinct flow and thus assign them a >> unique flow label after relaying the packets. And similarly in the >> opposite direction. >> >> Comments? > > My comment is that there's never a valid reason to rewrite IPv6 addresses > on the fly, so I don't see why the problem arises. I don't understand > the context in which TURN would face this problem, therefore. If you > terminate one IPv6 packet flow and originate another one carrying the > same application data, that makes two independent flows and they should > have independent flow labels. => I completely agree. Philip, it might help if you explain why this need arises for IPv6. What is the scenario? Hesham > > Brian > > From owner-v6ops@ops.ietf.org Tue May 6 01:45: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 D682028C19D for ; Tue, 6 May 2008 01:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 1o3Hb6s45HDh for ; Tue, 6 May 2008 01:45:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3B393A6A27 for ; Tue, 6 May 2008 01:45:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtIh0-000ONO-R1 for v6ops-data@psg.com; Tue, 06 May 2008 08:38:34 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtIgj-000OLN-Ra for v6ops@ops.ietf.org; Tue, 06 May 2008 08:38:29 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id BFC2C3EA0CA; Tue, 6 May 2008 10:38:16 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id A2DF83EA0FE; Tue, 6 May 2008 10:38:15 +0200 (CEST) Message-ID: <482018FD.2060208@free.fr> Date: Tue, 06 May 2008 10:38:21 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops , behave@ietf.org Subject: Re: IPv6 Flow Label References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> <481EFE86.3060808@free.fr> <9925D171-E6BA-4490-B9A8-D44419CA221D@magma.ca> <481F7AEC.7030209@gmail.com> In-Reply-To: <481F7AEC.7030209@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Brian E Carpenter wrote : > So the rule is really only that the flow label > must be delivered *exactly* as it was set by the source host (and the > default setting is zero). Right. However, between source and destination hosts *of IPv6 packets*. On an A-TURN-B path, the *destination host* of a packet from A is TURN (not B). > TURN has to obey that rule like any other > device that forwards packets. TURN is in this respect like any other function that operates with different 5-tuples on its upstream and donwstream interfaces (above the IP layer). Following the discusion, this is IMHO the right logic: TURN nodes may freely support or not support RFC 3697 flow labels, as sources on their outgoing interfaces,. Independently, they may freely ignore received flow labels, or process them to optimize their transport flow recognition, on thir incoming interfaces. If RFC 3697 flow labels are implemented by the two end nodes and by an intermediate TURN node, then packet classification can take advantage of flow labels in all traversed routers, be it with changed flow label values across the TURN node. Rémi From owner-v6ops@ops.ietf.org Tue May 6 02:18: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 089A93A67F9 for ; Tue, 6 May 2008 02:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 knlWcug3r+bO for ; Tue, 6 May 2008 02:18:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B6523A67A6 for ; Tue, 6 May 2008 02:18:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtJG8-0002DY-Jt for v6ops-data@psg.com; Tue, 06 May 2008 09:14:52 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtJFf-00028d-Ee for v6ops@ops.ietf.org; Tue, 06 May 2008 09:14:37 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtJFZ-0004ra-5t; Tue, 06 May 2008 19:14:17 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 19:14:05 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Brian E Carpenter CC: v6ops , Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: AcivWYgTpLnz9sbVS0GP0qF8xqUh6w== In-Reply-To: <482018FD.2060208@free.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 6/05/08 6:38 PM, "R=E9mi Despr=E9s" wrote: > Brian E Carpenter wrote : > So the rule is really only that the flow label > > must be delivered *exactly* as it was set by the source host (and the > > default setting is zero). Right. However, between source and destination hosts > *of IPv6 packets*. On an A-TURN-B path, the *destination host* of a packet > from A is TURN (not B). > TURN has to obey that rule like any other > device > that forwards packets. TURN is in this respect like any other function that > operates with different 5-tuples on its upstream and donwstream interfaces > (above the IP layer). Following the discusion, this is IMHO the right > logic: TURN nodes may freely support or not support RFC 3697 flow labels, as > sources on their outgoing interfaces,. Independently, they may freely ignore > received flow labels, or process them to optimize their transport flow > recognition, on thir incoming interfaces. If RFC 3697 flow labels are > implemented by the two end nodes and by an intermediate TURN node, then > packet classification can take advantage of flow labels in all traversed > routers, be it with changed flow label values across the TURN > node. =3D> I don't understand two points: - Why is the IPv6 address/header being re-written? - If there is a good answer for the above question then why would you ignor= e the flow label and not copy it across? It is one thing to terminate the connection and restart it with the remote node, but I don't see any reason for re-writing a header _and_ ignoring the original content of that header. Hesham R=E9mi _______________________________________________ Behave mailing > list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From findlorne@yahoo.com Tue May 6 04:59: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 8BD143A6BA4 for ; Tue, 6 May 2008 04:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.603 X-Spam-Level: X-Spam-Status: No, score=-47.603 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, 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_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 699ssj-uavhR for ; Tue, 6 May 2008 04:59:02 -0700 (PDT) Received: from [88.233.59.213] (unknown [88.233.59.213]) by core3.amsl.com (Postfix) with ESMTP id 126BF3A69DD for ; Tue, 6 May 2008 04:59:01 -0700 (PDT) Received: from [88.233.59.213] by c.mx.mail.yahoo.com; Tue, 6 May 2008 12:58:59 +0100 Message-ID: <01c8af78$f320ab80$d53be958@findlorne> From: "Google-AdWords" To: Subject: Please Update Your Billing Information. Date: Tue, 6 May 2008 12:58:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8AF78.F320AB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8AF78.F320AB80 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= -- Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment info= rmation. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------= ---------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= ---------------- Thank you for chosing Google Adwords for your business ------=_NextPart_000_0007_01C8AF78.F320AB80 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= ------------

Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= ------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= ------
Thank you for chosing Google Adwords ------=_NextPart_000_0007_01C8AF78.F320AB80-- From fmcqueary@yahoo.com Tue May 6 05:00: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 8D2B53A6C03 for ; Tue, 6 May 2008 05:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.929 X-Spam-Level: X-Spam-Status: No, score=-45.929 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 30DO0p7GtbS3 for ; Tue, 6 May 2008 05:00:01 -0700 (PDT) Received: from [93.89.144.5] (unknown [93.89.144.5]) by core3.amsl.com (Postfix) with ESMTP id 8EEA53A69DD for ; Tue, 6 May 2008 05:00:00 -0700 (PDT) Received: from [93.89.144.5] by c.mx.mail.yahoo.com; Tue, 6 May 2008 12:59:58 +0100 From: "Google-AdWords" To: Subject: Your ads are not running. Date: Tue, 6 May 2008 12:59:58 +0100 Message-ID: <01c8af79$164b5b00$0590595d@fmcqueary> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C8AF79.164B5B00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C8AF79.164B5B00 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit ---------------------------------------------------------------------------- Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment information. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. ----------------------------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. ----------------------------------------------------------------------------------------- Thank you for chosing Google Adwords for your business ------=_NextPart_000_000E_01C8AF79.164B5B00 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= ------

Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= ------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= ------
Thank you for chosing Google Adwords ------=_NextPart_000_000E_01C8AF79.164B5B00-- From owner-v6ops@ops.ietf.org Tue May 6 05:48: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 8B0823A6EA4 for ; Tue, 6 May 2008 05:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.468, 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 FSebzIXD5Sz1 for ; Tue, 6 May 2008 05:48:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8BF13A6CD7 for ; Tue, 6 May 2008 05:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMQz-000N6q-Ix for v6ops-data@psg.com; Tue, 06 May 2008 12:38:17 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMQo-000N5n-QO for v6ops@ops.ietf.org; Tue, 06 May 2008 12:38:12 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id B006C3EA10C; Tue, 6 May 2008 14:38:05 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 741E83EA0F6; Tue, 6 May 2008 14:37:50 +0200 (CEST) Message-ID: <4820511F.3060100@free.fr> Date: Tue, 06 May 2008 14:37:51 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Hesham Soliman CC: Brian E Carpenter , v6ops , behave@ietf.org Subject: Re: [BEHAVE] IPv6 Flow Label 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 Hesham Soliman wrote : > On 6/05/08 6:38 PM, "Rémi Després" wrote: >> Following the discusion, this is IMHO the right logic: >> >> TURN nodes may freely support or not support RFC 3697 flow labels, as >> sources on their outgoing interfaces,. Independently, they may >> freely ignore received flow labels, or process them to optimize their >> transport flow recognition, on thir incoming interfaces. > => I don't understand two points: - Why is the IPv6 address/header > being re-written? - If there is a good answer for the above question > then why would you ignore the flow label and not copy it across? The destination address of a packet received by a TURN relay is the address of the relay. That of the packet it forwards, with the same data field, is the address of the next IP layer destination node (the destination host or an itermediate NAT). RFC 3697 has a rule that non zero flow labels that leave a node MUST be all different for current flows having the same source-destination pair. If flow labels received by a TURN relay from two different sources happen to be the same while the next IP destination happens to be the same NAT, copying flow labels will infringe the rule. Therefore, IMU, flow labels *MUST NOT* be copied from upstream flows to downstream flows. Rémi From owner-v6ops@ops.ietf.org Tue May 6 05:48: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 8D71E3A6D42 for ; Tue, 6 May 2008 05:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, 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 rfdpqQprstFD for ; Tue, 6 May 2008 05:48:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E6743A6801 for ; Tue, 6 May 2008 05:48:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMZK-000O4S-33 for v6ops-data@psg.com; Tue, 06 May 2008 12:46:54 +0000 Received: from [216.254.141.170] (helo=mail-02.primus.ca) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMZ9-000O3d-1l for v6ops@ops.ietf.org; Tue, 06 May 2008 12:46:48 +0000 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JtMZ4-0001Cg-1V; Tue, 06 May 2008 08:46:38 -0400 Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops , Behave WG Message-Id: From: Philip Matthews To: Hesham Soliman , Brian E Carpenter 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 v919.2) Subject: Re: IPv6 Flow Label Date: Tue, 6 May 2008 08:46:36 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 6-May-08, at 00:27 , Hesham Soliman wrote: > >>> For the folks in V6OPS, let me describe the situation more >>> precisely. A >>> TURN server receives packets from a TURN client and relays them >>> toward a >>> TURN peer. In the process, the server changes both the source and >>> destination address. Packets can also flow in the reverse direction. >>> >>> For the IPv6 flow label, the best solution as far as I can see, is >>> to >>> copy the flow label from the incoming packet to the outgoing packet. >>> This seems the right thing to do, even though the source and >>> destination >>> addresses change. Since the addresses change, it is possible that >>> two >>> logically distinct flows that originally had distinct 3-tuples >>> (source >>> IP, dest IP, flow label) before reaching the server get assigned the >>> same 3-tuple after relaying. However, as far as I can see, having >>> the >>> same 3-tuple does not means the packets ARE part of the same flow, >>> but >>> just that they MAY be part of the same flow. >>> >>> Copying the flow label and other fields in the IP header requires >>> special privileges on most modern OSes (e.g. RAW sockets or kernel >>> access). So TURN also allows a mode where fields in the IP header >>> are >>> not copied, but are set as best as possible using unprivileged >>> user-land >>> APIs. I am not sure what the situation is for the flow label, but >>> for >>> many other IP header fields, it is easy to set these fields on >>> outgoing >>> packets, but impossible to read them on incoming packets. So a >>> somewhat >>> less desirable but acceptable solution when relaying the flow >>> label, as >>> I can see, is to assume all the packets coming from a given client >>> and >>> going to a given peer constitute a distinct flow and thus assign >>> them a >>> unique flow label after relaying the packets. And similarly in the >>> opposite direction. >>> >>> Comments? >> >> My comment is that there's never a valid reason to rewrite IPv6 >> addresses >> on the fly, so I don't see why the problem arises. I don't understand >> the context in which TURN would face this problem, therefore. If you >> terminate one IPv6 packet flow and originate another one carrying the >> same application data, that makes two independent flows and they >> should >> have independent flow labels. > > => I completely agree. Philip, it might help if you explain why this > need > arises for IPv6. What is the scenario? TURN is a protocol that allows a client to "engage" the services of a relay (= TURN server). The driving motivation for developing TURN is to allow a client located behind a non-BEHAVE-compliant NAT to talk with other nodes. However, there are other less-common v4 NAT (and firewall?) scenarios where TURN is useful. TURN is an integral part of the ICE/STUN/TURN suite of protocols for NAT traversal. I realize that the question of NATs in the IPv6 world is a touchy subject. If there are no NATs in the v6 world, then TURN may never be needed. Perhaps the best answer is to wait and see what develops. However, like all other IETF protocols, the IESG requires us to consider IPv6 support when developing TURN. In same way, ICE and STUN also include IPv6 support. So I am trying to specify something that seems right for IPv6 with TURN. For the other fields in the IPv4 and IPv6 headers, TURN copies the field from the incoming packet to the outgoing packet except when it needs to do something else for relay purposes. That was my motivation for suggesting that the flow label also be copied (if possible). But from Brian's message, perhaps the more appropriate behavior would be to set the outgoing flow label to 0? - Philip From owner-v6ops@ops.ietf.org Tue May 6 05:54:52 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 92E943A6F8B for ; Tue, 6 May 2008 05:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 BBtpFaGAkJN1 for ; Tue, 6 May 2008 05:54:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7F333A6EA4 for ; Tue, 6 May 2008 05:54:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMfS-000OnA-VZ for v6ops-data@psg.com; Tue, 06 May 2008 12:53:14 +0000 Received: from [202.124.241.204] (helo=smtp-2.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMfE-000Okg-6A for v6ops@ops.ietf.org; Tue, 06 May 2008 12:53:08 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtMf8-0006J9-6j; Tue, 06 May 2008 22:52:54 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 22:52:49 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= CC: Brian E Carpenter , v6ops , Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: AciveBaXkrMDWFXocUCgYOvuhls6yg== In-Reply-To: <4820511F.3060100@free.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> => I don't understand two points: - Why is the IPv6 address/header >> being re-written? - If there is a good answer for the above question >> then why would you ignore the flow label and not copy it across? > > The destination address of a packet received by a TURN relay is the > address of the relay. => This suggests to me that you have to distinct connections: Node - relay Relay - someone else That of the packet it forwards, with the same data > field, is the address of the next IP layer destination node (the > destination host or an itermediate NAT). => Did you mean NAT? I thought we're talking about IPv6. > > RFC 3697 has a rule that non zero flow labels that leave a node MUST be > all different for current flows having the same source-destination pair. > > If flow labels received by a TURN relay from two different sources > happen to be the same while the next IP destination happens to be the > same NAT, copying flow labels will infringe the rule. => I don't know why we're talking about NATs and IPv6. It sounds like a flawed assumption from the beginning. There are two situations I can think of that you might be referring to (I haven't read TURN since 2004) 1. Two connections, node - TURN relay and TURN relay - another node. I have a feeling this is not the case you have in mind. 2. Node - intermediate strange relay that overwrites headers - end node There is no need for scenario 2 in IPv6. If this is in effort to do something for Ipv6 NATs I think it's a waste of time and adds confusion for the Internet as a whole. Hesham From owner-v6ops@ops.ietf.org Tue May 6 06:02: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 5DBB93A6E55 for ; Tue, 6 May 2008 06:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 XvU0LoW6VEsW for ; Tue, 6 May 2008 06:02:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C25373A6FBE for ; Tue, 6 May 2008 06:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMlb-000Psm-Rt for v6ops-data@psg.com; Tue, 06 May 2008 12:59:35 +0000 Received: from [202.124.241.204] (helo=smtp-2.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtMl2-000PlW-5i for v6ops@ops.ietf.org; Tue, 06 May 2008 12:59:14 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtMkw-0006Nt-E1; Tue, 06 May 2008 22:58:54 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 22:58:51 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: Philip Matthews , Brian E Carpenter CC: v6ops , Behave WG Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: AciveO5bFKSmpskDcUi1FKnilqrnbA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the detail Philip, I haven't read TURN for a long time. >> => I completely agree. Philip, it might help if you explain why this >> need >> arises for IPv6. What is the scenario? > > > TURN is a protocol that allows a client to "engage" the services of a > relay (= TURN server). The driving motivation for developing TURN is > to allow a client located behind a non-BEHAVE-compliant NAT to talk > with other nodes. However, there are other less-common v4 NAT (and > firewall?) scenarios where TURN is useful. TURN is an integral part > of the ICE/STUN/TURN suite of protocols for NAT traversal. > > I realize that the question of NATs in the IPv6 world is a touchy > subject. If there are no NATs in the v6 world, then TURN may never be > needed. Perhaps the best answer is to wait and see what develops. > However, like all other IETF protocols, the IESG requires us to > consider IPv6 support when developing TURN. In same way, ICE and STUN > also include IPv6 support. So I am trying to specify something that > seems right for IPv6 with TURN. => I think that a perfectly useful answer to the IESG is to say that since there is no _need_ for NATs in IPv6, we don't have to consider it. There are many NAT traversal mechanisms that don't consider IPv6. There are a few that do consider IPv6 in the context of allowing IPv4-encapsulated IPv6 traffic to traverse NATs. But in those scenarios, I don't think the question of the flow label or the IPv6 header in general needs to be addressed. > > For the other fields in the IPv4 and IPv6 headers, TURN copies the > field from the incoming packet to the outgoing packet except when it > needs to do something else for relay purposes. That was my motivation > for suggesting that the flow label also be copied (if possible). But > from Brian's message, perhaps the more appropriate behavior would be > to set the outgoing flow label to 0? => Personally, I think the appropriate behaviour is not to do anything for IPv6 and NATs. Hesham > > - Philip > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From owner-v6ops@ops.ietf.org Tue May 6 06:20:15 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 63B473A694F for ; Tue, 6 May 2008 06:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, 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 vLXQK24B9gtJ for ; Tue, 6 May 2008 06:20:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97C013A69C9 for ; Tue, 6 May 2008 06:20:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtN3q-0002wU-4d for v6ops-data@psg.com; Tue, 06 May 2008 13:18:26 +0000 Received: from [202.124.241.204] (helo=smtp-2.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtN3f-0002te-CL for v6ops@ops.ietf.org; Tue, 06 May 2008 13:18:20 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtN3Y-0006XY-HF; Tue, 06 May 2008 23:18:08 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 23:17:58 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: Simon Perreault , CC: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , v6ops , Brian E Carpenter Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: Acive5oGKBCvkdS8tU+3Zw+x6wqKkg== In-Reply-To: <200805060900.32340.simon.perreault@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 6/05/08 11:00 PM, "Simon Perreault" wrote: > On Tuesday 06 May 2008 08:52:49 Hesham Soliman wrote: >> => I don't know why we're talking about NATs and IPv6. It sounds like a >> flawed assumption from the beginning. > > I thought the use case for TURNv6 was to allow interoperability between > v4-only and v6-only devices, but now I'm not so sure we're all on the same > wavelength. => Well, in that case the flow label is a moot point. Also, there are requirements and solutions being worked on in v6ops to do this using NAT-PT. Hesham From owner-v6ops@ops.ietf.org Tue May 6 06:21: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 EC37C3A6963 for ; Tue, 6 May 2008 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.371 X-Spam-Level: X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[AWL=-1.488, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 YR5cq63KP0Vg for ; Tue, 6 May 2008 06:21:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 136653A6A22 for ; Tue, 6 May 2008 06:21:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtN6B-0003Gl-Tm for v6ops-data@psg.com; Tue, 06 May 2008 13:20:51 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtN5v-0003Ei-Vs for v6ops@ops.ietf.org; Tue, 06 May 2008 13:20:46 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtN5n-0007eG-Le; Tue, 06 May 2008 23:20:27 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 06 May 2008 23:20:18 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , ext Philip Matthews CC: v6ops , Brian E Carpenter Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: Acive+14nAMH/cIgqESvWNAJ5L0wXw== In-Reply-To: <200805061616.16698.remi.denis-courmont@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 6/05/08 11:16 PM, "R=E9mi Denis-Courmont" wrote: > Le Tuesday 06 May 2008 15:52:49 ext Hesham Soliman, vous avez =E9crit=A0: >> =3D> I don't know why we're talking about NATs and IPv6. It sounds like a >> flawed assumption from the beginning. >> There are two situations I can think of that you might be referring to (= I >> haven't read TURN since 2004) >> 1. Two connections, node - TURN relay and TURN relay - another node. I h= ave >> a feeling this is not the case you have in mind. >> 2. Node - intermediate strange relay that overwrites headers - end node >>=20 >> There is no need for scenario 2 in IPv6. >>=20 >> If this is in effort to do something for Ipv6 NATs I think it's a waste = of >> time and adds confusion for the Internet as a whole. >=20 > You are assuming that scenario 2 implies NAT. >=20 > I believe SOCKS (RFC1928) supports IPv6-IPv6 gatewaying, pretty much the = same > as TURN would. One obvious reason is firewalls. Last time I checked the V= 6CPE > discussion, it did not seem like IPv6 would deprecate firewalls. =3D> Again, this implies having two different connections and there should no= t be an issue with flow labels. >=20 > One can nevertheless question the usefulness of IPv6-IPv6 gateways. After= all > SOCKS is quite old. And the main driver for TURN is NAT traversal, which = is > not an issue in IPv6-IPv6. Assuming that IPv6 firewalls are well BEHAVE'd= , > then TURN will never be needed in pure IPv6 cases. That seems like an > optimistic assumption to me, but fine with me. >=20 >=20 > Then TURN should only support, IPv4-IPv4, IPv6-IPv4 and IPv4-IPv6 cases. = And > then, the issue of flow infos preservation is moot, as flow infos don't e= xist > in IPv4. Also then, we're back to my point on that TURN should provide an > IPv4 mapped address to _IPv6_ TURN clients by default. =3D> Right. I don't know about your point for mapped addresses, but I agree with the rest.=20 Hesham From owner-v6ops@ops.ietf.org Tue May 6 07:17:52 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 1F1493A6E4B for ; Tue, 6 May 2008 07:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Ot5kIPvyGxlS for ; Tue, 6 May 2008 07:17:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35E4D3A6FD4 for ; Tue, 6 May 2008 07:17:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtNvW-0009xA-3p for v6ops-data@psg.com; Tue, 06 May 2008 14:13:54 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtNvL-0009w2-8S for v6ops@ops.ietf.org; Tue, 06 May 2008 14:13:48 +0000 Received: from [10.0.1.197] (c-24-6-157-180.hsd1.ca.comcast.net [24.6.157.180]) by virtualized.org (Postfix) with ESMTP id BC2A51EEBD3; Tue, 6 May 2008 07:13:42 -0700 (PDT) Cc: Philip Matthews , Brian E Carpenter , v6ops , Behave WG Message-Id: <54C11BC4-76CC-44AC-BBD5-8EEA7ADD6909@virtualized.org> From: David Conrad To: Hesham Soliman 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 v919.2) Subject: Re: [BEHAVE] IPv6 Flow Label Date: Tue, 6 May 2008 07:13:42 -0700 References: X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hesham, On May 6, 2008, at 5:58 AM, Hesham Soliman wrote: > I think that a perfectly useful answer to the IESG is to say that > since > there is no _need_ for NATs in IPv6, we don't have to consider it. The fact that IPv6 has the same routing technology as IPv4 guarantees there will be a market for NATv6 (assuming IPv6 gets deployed), if for no other reason than people not wanting to be tied to their ISP. > Personally, I think the appropriate behaviour is not to do anything > for > IPv6 and NATs. It would be sad if the IETF did not learn from past mistakes. Regards, -drc From owner-v6ops@ops.ietf.org Tue May 6 07:27: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 8C2443A6C59 for ; Tue, 6 May 2008 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, 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 SP5PFz3c6oqK for ; Tue, 6 May 2008 07:27:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDFA63A6FF5 for ; Tue, 6 May 2008 07:26:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtO6B-000BFU-UI for v6ops-data@psg.com; Tue, 06 May 2008 14:24:55 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtO61-000BEC-19 for v6ops@ops.ietf.org; Tue, 06 May 2008 14:24:50 +0000 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m46EOilx010665 for ; Tue, 6 May 2008 14:24:44 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0G00301865RV00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for v6ops@ops.ietf.org; Tue, 06 May 2008 08:24:44 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0G00F0GAP6UM70@mail-amer.sun.com>; Tue, 06 May 2008 08:24:42 -0600 (MDT) Date: Tue, 06 May 2008 10:24:41 -0400 From: Sebastien Roy Subject: Re: [BEHAVE] IPv6 Flow Label In-reply-to: To: Hesham Soliman Cc: Philip Matthews , Brian E Carpenter , v6ops , Behave WG Message-id: <1210083881.19601.22.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hesham, On Tue, 2008-05-06 at 22:58 +1000, Hesham Soliman wrote: > => I think that a perfectly useful answer to the IESG is to say that since > there is no _need_ for NATs in IPv6, we don't have to consider it. This is intended merely as a data-point, and not to fuel any NAT-related fires: I'm aware of IPv4 deployments using NAT in order to easily implement transparent proxies. Specifically, they use a NAT to transparently redirect packets to a local address and port, and a user-space proxy receives those packets, processes them, and retransmits them. The use of NAT here has nothing to do with preserving address space, but as a hack to transparently redirect all packets to a local address and port in order to have a local application receive them. I'm also aware of deployments implementing this same hack for IPv6, so to issue a blanket statement that there is no need for NATs with IPv6 may be ignoring some weird use cases like the one above. That said, I don't know whether this particular use of NAT needs to be considered here, I'm merely stating that there is IPv6 NAT out there (much to my chagrin) that might need to be considered. -Seb From owner-v6ops@ops.ietf.org Tue May 6 16:29: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 271E428C50F for ; Tue, 6 May 2008 16:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 N1P6a14KyQQv for ; Tue, 6 May 2008 16:29:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AF8028C563 for ; Tue, 6 May 2008 16:25:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtWQb-000Flg-4y for v6ops-data@psg.com; Tue, 06 May 2008 23:18:33 +0000 Received: from [202.124.241.204] (helo=smtp-2.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtWQP-000FjW-Vg for v6ops@ops.ietf.org; Tue, 06 May 2008 23:18:27 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtWQJ-0006Go-Dc; Wed, 07 May 2008 09:18:15 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Wed, 07 May 2008 09:17:51 +1000 Subject: Re: [BEHAVE] IPv6 Flow Label From: Hesham Soliman To: Sebastien Roy CC: Philip Matthews , Brian E Carpenter , v6ops , Behave WG Message-ID: Thread-Topic: [BEHAVE] IPv6 Flow Label Thread-Index: Acivz2eG+zCPU1h7HkGftijoPZ+8OQ== In-Reply-To: <1210083881.19601.22.camel@strat> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 7/05/08 12:24 AM, "Sebastien Roy" wrote: > Hesham, > > On Tue, 2008-05-06 at 22:58 +1000, Hesham Soliman wrote: >> => I think that a perfectly useful answer to the IESG is to say that since >> there is no _need_ for NATs in IPv6, we don't have to consider it. > > This is intended merely as a data-point, and not to fuel any NAT-related > fires: > > I'm aware of IPv4 deployments using NAT in order to easily implement > transparent proxies. Specifically, they use a NAT to transparently > redirect packets to a local address and port, and a user-space proxy > receives those packets, processes them, and retransmits them. The use > of NAT here has nothing to do with preserving address space, but as a > hack to transparently redirect all packets to a local address and port > in order to have a local application receive them. > > I'm also aware of deployments implementing this same hack for IPv6, so > to issue a blanket statement that there is no need for NATs with IPv6 > may be ignoring some weird use cases like the one above. => As you acknowledge, those are hacks and weird cases. The above doesn't imply a _technical need_. We don't develop standards for everyone who comes along with the hack of the day. If we did that, we'd be in trouble IMHO. Hesham > > That said, I don't know whether this particular use of NAT needs to be > considered here, I'm merely stating that there is IPv6 NAT out there > (much to my chagrin) that might need to be considered. > > -Seb > > From owner-v6ops@ops.ietf.org Tue May 6 16:29: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 E920A28C52C for ; Tue, 6 May 2008 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.387, 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 70KYhMJs+329 for ; Tue, 6 May 2008 16:29:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 250C028C55B for ; Tue, 6 May 2008 16:25:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtWUq-000GAb-QU for v6ops-data@psg.com; Tue, 06 May 2008 23:22:56 +0000 Received: from [202.124.241.204] (helo=smtp-2.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtWUf-000G9b-D2 for v6ops@ops.ietf.org; Tue, 06 May 2008 23:22:50 +0000 Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtWUW-0006Ra-Ha; Wed, 07 May 2008 09:22:40 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Wed, 07 May 2008 09:22:26 +1000 Subject: Re: IPv6 Flow Label From: Hesham Soliman To: Philip Matthews , v6ops , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont CC: Behave WG Message-ID: Thread-Topic: IPv6 Flow Label Thread-Index: Aciv0Atv3LrEExMHnkmL6HhYRz8dPA== In-Reply-To: <7D18EE08-2516-46F8-B9B4-1CE1A4E48459@magma.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Philip, > I would prefer that this thread not dissolve into a debate on whether > or not there will be NATs in IPv6 networks. I would also prefer that > this thread not discuss scenarios in which TURN might or might not be > used in IPv6 scenarios. If you wish, let's discuss these on other > threads. > > In this thread, I would like to start with the assumption that TURN > _is_ being used to relay IPv6 to IPv6. IF this is done, then what is > the appropriate treatment for the flow label field? => I think it is perfectly valid to question the scenario since you're asking us about what needs to be done in that scenario. Bottom line, if you're overwriting IPv6 addresses, it doesn't matter what you do with the flow label because you already broke it. > > Right now, I see two alternatives: > > 1) Copy the flow label from the incoming packet to the outgoing packet > if possible. If not possible (because the appropriate APIs do not > exist on the OS on which the TURN server runs to allow the incoming > flow label to be read), then treat each (client, peer) combination as > defining a flow and assign unique flow labels correspondingly. > > 2) Always set the outgoing flow label to 0. => If the addresses are being overwritten then 1) makes no sense and 2) implies breaking the glow label use anyway. Hesham > > (See previous messages in this thread for more details). > > If it helps the discussion, think about replacing the TURN server with > any middleware box that modifies addresses (for example, an SIP > Session Border Controller). I think the question is the same. > > I would greatly appreciate help for folks familiar with the IPv6 flow > label in making a decision between the two alternatives. > > - Philip > > From owner-v6ops@ops.ietf.org Tue May 6 18:47: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 5269D3A68D3 for ; Tue, 6 May 2008 18:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 FDb4NdYLNeME for ; Tue, 6 May 2008 18:47:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DECC3A6919 for ; Tue, 6 May 2008 18:47:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtYfZ-0003If-6g for v6ops-data@psg.com; Wed, 07 May 2008 01:42:09 +0000 Received: from [209.85.146.176] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtYfN-0003H1-9j for v6ops@ops.ietf.org; Wed, 07 May 2008 01:42:03 +0000 Received: by wa-out-1112.google.com with SMTP id j37so115029waf.23 for ; Tue, 06 May 2008 18:41:56 -0700 (PDT) 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=iEd+xb/5knBHbAjWgXTqLjFRJSjZraSzIGhr46IKeVI=; b=qphgnlcuFEeE2b5Yl6eiUtiLp+UEFZEfQTSSiEUK3kpN8kbSX0zUOayfrEO5fUO6vR0P8Sxs9vxm8FFOFrZqMDEO9x1wgb+mU9DzQkvF+T8HTJQoulDRYw5vS8X0bimMNMS1jCPpaUkeOMNyMnclCabK0wRp0dPQho1vYrSP91U= 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=W+rcIXUUVEhhah1BkYm++Ln8qg1chKtzBgy+HTkRWrw9cMRYsl4tQFujbuK0Ik+KcIdhby8pDgWKHJv0c+wIIB2g8RtnepZ4sD9bkT+jheh5bpIg8XLqQtI410l7Wvjzo8VjIu7r32FTkLPYTiYk8hswe8+BmxeHCzbSfb9O/8s= Received: by 10.114.76.1 with SMTP id y1mr1376092waa.38.1210124516790; Tue, 06 May 2008 18:41:56 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j21sm3059034wah.6.2008.05.06.18.41.54 (version=SSLv3 cipher=RC4-MD5); Tue, 06 May 2008 18:41:56 -0700 (PDT) Message-ID: <482108DF.4020800@gmail.com> Date: Wed, 07 May 2008 13:41:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews CC: v6ops , Hesham Soliman , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , =?UTF-8?B?UsOpbQ==?= =?UTF-8?B?aSBEZW5pcy1Db3VybW9udA==?= , Behave WG Subject: Re: IPv6 Flow Label References: <7D18EE08-2516-46F8-B9B4-1CE1A4E48459@magma.ca> In-Reply-To: <7D18EE08-2516-46F8-B9B4-1CE1A4E48459@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-05-07 06:35, Philip Matthews wrote: > I would prefer that this thread not dissolve into a debate on whether or > not there will be NATs in IPv6 networks. I would also prefer that this > thread not discuss scenarios in which TURN might or might not be used in > IPv6 scenarios. If you wish, let's discuss these on other threads. > > In this thread, I would like to start with the assumption that TURN _is_ > being used to relay IPv6 to IPv6. IF this is done, then what is the > appropriate treatment for the flow label field? > > Right now, I see two alternatives: > > 1) Copy the flow label from the incoming packet to the outgoing packet > if possible. If not possible (because the appropriate APIs do not exist > on the OS on which the TURN server runs to allow the incoming flow label > to be read), then treat each (client, peer) combination as defining a > flow and assign unique flow labels correspondingly. I'm disturbed by the idea of copying the label. The rules were designed in such a way that the 3tuple {DA, SA, flow label} is bound to be unique, without any signaling, so that flows can always be identified by any router they happen to go through. So I think that any relay device that is not a simple packet forwarder should assign a new flow label, to guarantee that uniqueness. > > 2) Always set the outgoing flow label to 0. This is a subset of "assign a new flow label". Zero is always allowed. The rules in RFC3697 were intended to make the flow label's semantics robust even when there are different use cases operating simultaneously. It could be the case (I'm making this up) that the originating host wants to use flow labels to support load-spreading, and the TURN relay wants to use flow labels to support some future QOS mechanism. "Assign a new flow label" works well in that case. So, I'd say that the default behavior for a relayed packet should be "Assign 0", and "Assign a new flow label according to RFC3697" should be optional (just as the whole of RFC3697 is optional). And this is entirely independent of whether or not the incoming packet has a non-zero flow label. (The same is not true of the DSCP. There's every reason that should be copied as-is. But I expect you know that.) Brian > > (See previous messages in this thread for more details). > > If it helps the discussion, think about replacing the TURN server with > any middleware box that modifies addresses (for example, an SIP Session > Border Controller). I think the question is the same. > > I would greatly appreciate help for folks familiar with the IPv6 flow > label in making a decision between the two alternatives. > > - Philip > > > From owner-v6ops@ops.ietf.org Tue May 6 20:48: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 1C9C23A6843 for ; Tue, 6 May 2008 20:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, 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 XxwunAI2E89R for ; Tue, 6 May 2008 20:48:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2ACB23A67AA for ; Tue, 6 May 2008 20:48:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtaWu-000F0N-GF for v6ops-data@psg.com; Wed, 07 May 2008 03:41:20 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtaWj-000Ez5-N8 for v6ops@ops.ietf.org; Wed, 07 May 2008 03:41:15 +0000 Received: from [211.27.108.142] (helo=[10.0.0.10]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JtaWZ-0000VI-28; Wed, 07 May 2008 13:40:59 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Wed, 07 May 2008 13:40:43 +1000 Subject: Re: IPv6 Flow Label From: Hesham Soliman To: Philip Matthews CC: v6ops , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , Behave WG Message-ID: Thread-Topic: IPv6 Flow Label Thread-Index: Aciv9CBerG3fsS/nu0Ka1PiAXnUEKw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Hesham: > > If I understand you correctly, you are arguing that we should not > consider this question, because TURN should never be used with IPv6. => No I was only referring to the IPv6-IPv6 relay scenario. > > My take on this is as follows. It may be that TURN will never get used > as an IPv6-to-IPv6 relay. If so, then this discussion is > unnecessary. However, v6OPS is currently discussing the possibility > of NATing between IPv4 and IPv6, so there is the chance that TURN > might be useful in a v6 context. => That's fine with me. In that scenario the question of the flow label would not come up though. Furthermore, the IESG requires that > all protocols consider IPv6, so it is easier and faster for me (as > TURN editor) to simply add the small extra text to cover the v6 case > than to fight for a special exception to the rule. => I think you could think of analogous situations where the requirement would not apply and therefore the IESG would not hold you responsible. For instance, suppose we're updating the NAT RFC or RFC 1918. I'm pretty sure the IESG would not require you to reserve a block of IPv6 addresses for IPv6-IPv6 NATs. This is a similar case. > > Does this make sense? Do I correctly understand your position? => I was only referring to IPv6-IPv6 scenarios, clearly there is merit in the IPv4-IPv6 cases. Hesham > > - Philip > From owner-v6ops@ops.ietf.org Tue May 6 20:51: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 17ECF3A67B2 for ; Tue, 6 May 2008 20:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.508, 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 zPjmXBV8cUCD for ; Tue, 6 May 2008 20:51:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EADF3A696C for ; Tue, 6 May 2008 20:51:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jtafd-000Ftf-Nu for v6ops-data@psg.com; Wed, 07 May 2008 03:50:21 +0000 Received: from [209.85.198.225] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtafP-000FsG-TQ for v6ops@ops.ietf.org; Wed, 07 May 2008 03:50:13 +0000 Received: by rv-out-0506.google.com with SMTP id b25so168921rvf.41 for ; Tue, 06 May 2008 20:50:07 -0700 (PDT) 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=MElcPhDt61oZ+4bktv6Wis1knDZU4EFXMIVafSBmijQ=; b=Q9nha5POK1yDUIuxiQ9DL/fhG5s0PcuElGrwkuW5xVj0XYsMkvrTqAoHDfjFNVrUzR4wa5cFQ9hN1Oe4G6brGmIgDcHw+rbviu+xplv0Ua3q3Ab6UtM/b08Ve3gjndDo0If1VnDebqN4pgs9Pby6mDJFPE6ehWRcjfWoN7pxYzA= 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=UMJDqApdmz8rb7kkIKI64Vx0IUCYS4DovTY5bvW1ob+uD0Qz3IB2LepOv5+2qP/HamvYBAVhuqroPQo/GE/gCEmo6eBm3ZU9JqTiZ9NrGhKzaRJsZIFvwoMT8vxBPrnLbyZBNlCGI7ioBXgyFgXna+TUfrkpKqrpnvZ1I0cMZFY= Received: by 10.114.58.6 with SMTP id g6mr1457596waa.68.1210132207288; Tue, 06 May 2008 20:50:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k39sm3313897wah.3.2008.05.06.20.50.05 (version=SSLv3 cipher=RC4-MD5); Tue, 06 May 2008 20:50:07 -0700 (PDT) Message-ID: <482126E9.9070106@gmail.com> Date: Wed, 07 May 2008 15:50:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews CC: v6ops , Hesham Soliman , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , =?UTF-8?B?UsOpbQ==?= =?UTF-8?B?aSBEZW5pcy1Db3VybW9udA==?= , Behave WG Subject: Re: IPv6 Flow Label References: <7D18EE08-2516-46F8-B9B4-1CE1A4E48459@magma.ca> <482108DF.4020800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk In line.. On 2008-05-07 15:34, Philip Matthews wrote: > > On Tue, 6-May-08, at 21:41 , Brian E Carpenter wrote: >> On 2008-05-07 06:35, Philip Matthews wrote: >>> I would prefer that this thread not dissolve into a debate on whether or >>> not there will be NATs in IPv6 networks. I would also prefer that this >>> thread not discuss scenarios in which TURN might or might not be used in >>> IPv6 scenarios. If you wish, let's discuss these on other threads. >>> >>> In this thread, I would like to start with the assumption that TURN _is_ >>> being used to relay IPv6 to IPv6. IF this is done, then what is the >>> appropriate treatment for the flow label field? >>> >>> Right now, I see two alternatives: >>> >>> 1) Copy the flow label from the incoming packet to the outgoing packet >>> if possible. If not possible (because the appropriate APIs do not exist >>> on the OS on which the TURN server runs to allow the incoming flow label >>> to be read), then treat each (client, peer) combination as defining a >>> flow and assign unique flow labels correspondingly. >> >> I'm disturbed by the idea of copying the label. The rules >> were designed in such a way that the 3tuple {DA, SA, flow label} >> is bound to be unique, without any signaling, so that flows can >> always be identified by any router they happen to go through. >> So I think that any relay device that is not a simple packet >> forwarder should assign a new flow label, to guarantee that >> uniqueness. >>> >>> 2) Always set the outgoing flow label to 0. >> >> This is a subset of "assign a new flow label". Zero is always >> allowed. >> >> The rules in RFC3697 were intended to make the flow label's >> semantics robust even when there are different use cases >> operating simultaneously. It could be the case (I'm making >> this up) that the originating host wants to use flow labels >> to support load-spreading, and the TURN relay wants to use >> flow labels to support some future QOS mechanism. "Assign >> a new flow label" works well in that case. >> >> So, I'd say that the default behavior for a relayed packet >> should be "Assign 0", and "Assign a new flow label according to >> RFC3697" should be optional (just as the whole of RFC3697 is optional). >> And this is entirely independent of whether or not the incoming >> packet has a non-zero flow label. > > I have no technical problem with doing with you suggest. > > My only question is: if many devices adopt this approach, then won't > this mean that the flow label will often be zero, and thus useless for > things like load-balancing in equal-cost multi-path scenarios? That is today's situation - there was no consensus for assuming that load-balancing is the primary use case, so no consensus for making setting the label a SHOULD. I don't think that TURN is special in this regard. > >> >> >> (The same is not true of the DSCP. There's every reason that should >> be copied as-is. But I expect you know that.) > > The proposed DSCP text says that the DSCP should be copied unless the > relay believes, through unspecified means, that another value for the > outgoing DSCP is appropriate. However, if the incoming value cannot be > read, then set the outgoing value to Best Effort (again, unless the > relay believes another value is more appropriate). OK, although I would be a bit more specific: unless the relay includes a diffserv classifier (and associated policy). That's how it obtains such a 'belief' in the diffserv model. > Believe me, the v4 cases have had much discussion (including the > involvement of three current ADs). I don't doubt it ;-) Brian From owner-v6ops@ops.ietf.org Tue May 6 23:54: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 8F9983A67AD for ; Tue, 6 May 2008 23:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 ggi1rMMaTxXa for ; Tue, 6 May 2008 23:54:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57B223A6D2D for ; Tue, 6 May 2008 23:54:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtdQU-000A9d-EJ for v6ops-data@psg.com; Wed, 07 May 2008 06:46:54 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtdQ1-000A4B-BO for v6ops@ops.ietf.org; Wed, 07 May 2008 06:46:39 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 5A4203EA0E0; Wed, 7 May 2008 08:46:24 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 40B243EA0DD; Wed, 7 May 2008 08:46:22 +0200 (CEST) Message-ID: <48215043.10803@free.fr> Date: Wed, 07 May 2008 08:46:27 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter CC: Philip Matthews , v6ops , Hesham Soliman , =?UTF-8?B?UsOpbWkgRGVuaXMtQ291?= =?UTF-8?B?cm1vbnQ=?= , Behave WG Subject: Re: IPv6 Flow Label References: <7D18EE08-2516-46F8-B9B4-1CE1A4E48459@magma.ca> <482108DF.4020800@gmail.com> In-Reply-To: <482108DF.4020800@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Brian E Carpenter wrote : > So, I'd say that the default behavior for a relayed packet should be > "Assign 0", and "Assign a new flow label according to RFC3697" should > be optional (just as the whole of RFC3697 is optional). And this is > entirely independent of whether or not the incoming packet has a > non-zero flow label. This is IMU the right behavior I had essentially the same conclusion (see for example http://www.ietf.org/mail-archive/web/behave/current/msg03789.html). A slightly different wording could however, IMO, be preferable. "Assign 0" and "RFC3697" should be placed on an equal footing, no one being more "default" than the other: a source may have either behavior; a destination or an intermediate node may not assume any of the two behaviors in particular. Rémi From owner-v6ops@ops.ietf.org Wed May 7 13:47: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 18F3328C25F for ; Wed, 7 May 2008 13:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LzzFQUsKvxb1 for ; Wed, 7 May 2008 13:47:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 220863A67F5 for ; Wed, 7 May 2008 13:47:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtqP1-0007Ba-Rp for v6ops-data@psg.com; Wed, 07 May 2008 20:38:15 +0000 Received: from [216.254.141.173] (helo=mail-03.primus.ca) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtqOY-00078Q-SF for v6ops@ops.ietf.org; Wed, 07 May 2008 20:38:01 +0000 Received: from webmail-05.web.primus.ca ([10.201.132.16] helo=localhost) by mail-03.primus.ca with esmtp (Exim 4.63) (envelope-from ) id 1JtqOY-0002Ij-0y for v6ops@ops.ietf.org; Wed, 07 May 2008 16:37:46 -0400 MIME-Version: 1.0 X-Mailer: AtMail PHP 5.2 Message-ID: <.1210192666@magma.ca> To: Reply-To: philip_matthews@magma.ca Content-Type: text/plain; charset="utf-8" X-Origin: 216.13.42.68 Date: Wed, 7 May 2008 16:37:46 -0400 Subject: Re: IPv6 Flow Label From: Philip Matthews Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 7-May-08, at 02:46 , R=C3=A9mi Despr=C3=A9s wrote: >Brian E Carpenter wrote : >>So, I'd say that the default behavior for a relayed packet should be >>"Assign 0", and "Assign a new flow label according to RFC3697" should >>be optional (just as the whole of RFC3697 is optional). And this is >>entirely independent of whether or not the incoming packet has a >>non-zero flow label. >This is IMU the right behavior >I had essentially the same conclusion (see for example >http://www.ietf.org/mail-archive/web/behave/current/msg03789.html). >A slightly different wording could however, IMO, be preferable. >"Assign 0" and "RFC3697" should be placed on an equal footing, no one >being more "default" than the other: a source may have either behavior; >a destination or an intermediate node may not assume any of the two >behaviors in particular. If no one has any objections, I will adopt this behavior. - Philip From owner-v6ops@ops.ietf.org Thu May 8 08:48:27 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 2385A28CC20 for ; Thu, 8 May 2008 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[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 7uU84P+LWXpq for ; Thu, 8 May 2008 08:48:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D59728D4CD for ; Thu, 8 May 2008 07:05:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju2tQ-000ARH-5i for v6ops-data@psg.com; Thu, 08 May 2008 09:58:28 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju2tF-000APq-Bq for v6ops@ops.ietf.org; Thu, 08 May 2008 09:58:22 +0000 Received: from [192.168.0.51] (118-92-113-200.dsl.dyn.ihug.co.nz [118.92.113.200]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id E13A82753A for ; Thu, 8 May 2008 21:58:14 +1200 (NZST) Message-Id: From: Nathan Ward To: v6ops WG 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 v919.2) Subject: Re: Automatic selection of transition mechanism? Date: Thu, 8 May 2008 21:58:13 +1200 References: X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 26/03/2008, at 1:41 AM, = wrote: > Hi, > > As we now have a set of mechanisms to transport IPv6 over IPv4 =20 > standardized, and as it seems we will probably end up having a set =20 > of mechanisms to access IPv4 destinations over IPv6-only access =20 > (MNAT-PT, SNAT, NATv4v6v4=85), has there been discussion already how a = =20 > host that implements multiple transition technologies should =20 > efficiently and automatically discover which mechanisms to use in =20 > access networks it happens to attach (and move between)? > > Is the current state of the art just: trial & error, provisioning by =20= > non-IETF means, or as defined by other SDOs for their systems? > There hasn't been a reply to this yet, so I'll fill the void. I haven't kept up to date on the new stuff that people are talking =20 about, SHANTI, (M)NAT-PT and so on. Windows does a fairly reasonable job, by doing roughly: - Look for ISATAP.. If it exists use ISATAP. - If we have a non-RFC1918 address use 6to4. - Last resort use Teredo. That seems to be a reasonable approach. The one big bug is if the non-=20= RFC1918 address is filtered, NATed, etc. 6to4 will generally fail to =20 operate. -- Nathan Ward From owner-v6ops@ops.ietf.org Thu May 8 14:08: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 0B8C628C2C4 for ; Thu, 8 May 2008 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 pa3yOPg3bkBi for ; Thu, 8 May 2008 14:08:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 503303A6E61 for ; Thu, 8 May 2008 14:06:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuDBV-000PRP-9F for v6ops-data@psg.com; Thu, 08 May 2008 20:57:49 +0000 Received: from [64.233.170.190] (helo=rn-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuDB2-000POd-8M for v6ops@ops.ietf.org; Thu, 08 May 2008 20:57:34 +0000 Received: by rn-out-0910.google.com with SMTP id i50so378009rne.11 for ; Thu, 08 May 2008 13:57:19 -0700 (PDT) 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=9n1fkqfH/cjMi1Wgrc1v+B2flxn+pYqax94qQ9tDtvI=; b=M4/XMZwWV+Fe2TukyvfgsNfn+zwB64sR608TaOh57wHzfHeiMRmsoG9qTeYfnSpuaN+O0MlbOA3a3CHtZeTvvaRzb5GvuyljL+9a2tZgWEpGyKf0A2+DZm5Z6zfzFztDzMxH1Om+C675iZI+cHacNzx5teDxLBVatsCdcppWiqU= 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=RMrZN/HWy80cAy3+nUhxVb6kgQ4eQ9EpqCOSdHznh1Qo01XSWZimCj8BgUci/NlQ3Wq6sNFVpBNnhY7lX5gzEItjtlbRWB8pA1x8AA7ZAw7HDJp565Wu63jdS2ZuglO4u4+aPTUv9UHt8ZH2RttoSgLA49nbNujAt2clF0+wEvY= Received: by 10.142.203.13 with SMTP id a13mr1594240wfg.224.1210280239111; Thu, 08 May 2008 13:57:19 -0700 (PDT) Received: from ?10.1.1.4? ( [118.92.252.49]) by mx.google.com with ESMTPS id 32sm8610728wfa.18.2008.05.08.13.57.16 (version=SSLv3 cipher=RC4-MD5); Thu, 08 May 2008 13:57:18 -0700 (PDT) Message-ID: <48236928.7080709@gmail.com> Date: Fri, 09 May 2008 08:57:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: philip_matthews@magma.ca CC: v6ops@ops.ietf.org Subject: Re: IPv6 Flow Label References: <.1210192666@magma.ca> In-Reply-To: <.1210192666@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-05-08 08:37, Philip Matthews wrote: > On Wed, 7-May-08, at 02:46 , R=C3=A9mi Despr=C3=A9s wrote: >> Brian E Carpenter wrote : >>> So, I'd say that the default behavior for a relayed packet should be >>> "Assign 0", and "Assign a new flow label according to RFC3697" should= >>> be optional (just as the whole of RFC3697 is optional). And this is >>> entirely independent of whether or not the incoming packet has a >>> non-zero flow label. >=20 >> This is IMU the right behavior >=20 >=20 >> I had essentially the same conclusion (see for example >> http://www.ietf.org/mail-archive/web/behave/current/msg03789.html). >=20 >> A slightly different wording could however, IMO, be preferable. >> "Assign 0" and "RFC3697" should be placed on an equal footing, no one >> being more "default" than the other: a source may have either behavior= ; >> a destination or an intermediate node may not assume any of the two >> behaviors in particular. >=20 > If no one has any objections, I will adopt this behavior. Sure. The main point is that a TURN relay should behave like any other IPv6 speaker in this respect - no special rules. Brian From owner-v6ops@ops.ietf.org Thu May 8 14:08: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 4A5623A6E8E for ; Thu, 8 May 2008 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 E2-twchGLRud for ; Thu, 8 May 2008 14:07:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA96528C333 for ; Thu, 8 May 2008 14:06:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuDGK-000Pu3-Oy for v6ops-data@psg.com; Thu, 08 May 2008 21:02:48 +0000 Received: from [209.85.200.168] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuDG5-000PsR-Mg for v6ops@ops.ietf.org; Thu, 08 May 2008 21:02:43 +0000 Received: by wf-out-1314.google.com with SMTP id 26so873223wfd.32 for ; Thu, 08 May 2008 14:02:33 -0700 (PDT) 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=29jDIbaUclpp2naR1cHkRR0zJ4GOPKCtzSwhyKzaSvw=; b=Gt39Us+o2QXNlNSxuMpDBUpJo9emKvKgeGiPQ6qQzL/4MTvVtOxmQSGOqs4RQqVnLk3yPTBs0k4YVKHIN/zgbgcFE7SwaAEkT/7YhSKbbsJsrRgh+wDOWb1jke+WbhOwYslKRigpEtaIcC/DzSxYP9fMbiYqU9kAW7s4LSvUuHs= 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=Y5cLzTS/locvSsY4oAYcXbP32zfu/jzdqrrlw3X7VTehJsJqmoWh532yE62On1ESxmzjUao+I1zcXKl48UujTfEJfwxlrnOEt0geORS2KmUSMXxlHRqZzvz7eVygLt9J/O644j8RLM3hT4ZhDfqMciXHevzJEbspvThKgEeKJxU= Received: by 10.143.33.19 with SMTP id l19mr1609503wfj.18.1210280553087; Thu, 08 May 2008 14:02:33 -0700 (PDT) Received: from ?10.1.1.4? ( [118.92.252.49]) by mx.google.com with ESMTPS id 29sm8408777wfg.0.2008.05.08.14.02.31 (version=SSLv3 cipher=RC4-MD5); Thu, 08 May 2008 14:02:32 -0700 (PDT) Message-ID: <48236A63.5060209@gmail.com> Date: Fri, 09 May 2008 09:02:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward CC: v6ops WG Subject: Re: Automatic selection of transition mechanism? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2008-05-08 21:58, Nathan Ward wrote: > On 26/03/2008, at 1:41 AM, > wrote: >=20 >> Hi, >> >> As we now have a set of mechanisms to transport IPv6 over IPv4 >> standardized, and as it seems we will probably end up having a set of >> mechanisms to access IPv4 destinations over IPv6-only access (MNAT-PT,= >> SNAT, NATv4v6v4=E2=80=A6), has there been discussion already how a hos= t that >> implements multiple transition technologies should efficiently and >> automatically discover which mechanisms to use in access networks it >> happens to attach (and move between)? >> >> Is the current state of the art just: trial & error, provisioning by >> non-IETF means, or as defined by other SDOs for their systems? >> > There hasn't been a reply to this yet, so I'll fill the void. >=20 > I haven't kept up to date on the new stuff that people are talking > about, SHANTI, (M)NAT-PT and so on. >=20 > Windows does a fairly reasonable job, by doing roughly: > - Look for ISATAP.. If it exists use ISATAP. > - If we have a non-RFC1918 address use 6to4. > - Last resort use Teredo. >=20 > That seems to be a reasonable approach. The one big bug is if the > non-RFC1918 address is filtered, NATed, etc. 6to4 will generally fail t= o > operate. Right, which suggests a need to encourage reachability checking so that black holes are detected. I think it's too soon to think about operational pragmas for IPv4-via-IPv= 6 until the various solutions settle down. Brian From owner-v6ops@ops.ietf.org Fri May 9 09:24: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 2D01F3A67CE for ; Fri, 9 May 2008 09:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[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 BDUnUB6aFmcm for ; Fri, 9 May 2008 09:24:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 198963A67C1 for ; Fri, 9 May 2008 09:24:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuVHW-0006Qy-Oi for v6ops-data@psg.com; Fri, 09 May 2008 16:17:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuVH5-0006Lm-KN for v6ops@ops.ietf.org; Fri, 09 May 2008 16:17:00 +0000 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1210349566; x=1210954366; i=miguelangel.diaz@consulintel.es; q=dns; h=DomainKey-Signature:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding: Thread-Index:Reply-To; b=DsHri92dcEyEn0bXkwlmjDwMVs3RqrQzCyex0+IS QY37wsYJJVl9dG5fWXrhusad9ZtkmY2Qcwg3+VG0rO/nDMBIL5mgRAUi3HBDB2Gx QvZCjF/ejETRypKKkO2cRh5E2XQr4zckfimSYqio1FpSptus7Abel0ALDCriZgfC s2Q= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=jKeWAgSMs9uPIN4996Gmm3syhdUcgjJDLvNmyWOxauaknWJQOULVuoEviKOoblUbGMHipcCSpoq8CpGHszl+dX4dEiuliPisk8ACx7XFXeuHCvb5Gm/FZacF8WcUxwLE2WWct73eC52oS2b2ozex5QwigQ0hiZxAwMzuLr4LK3U=; Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002907291.msg for ; Fri, 09 May 2008 18:12:42 +0200 From: "Miguel A. Diaz" To: Subject: Re: Automatic selection of transition mechanism? Date: Fri, 9 May 2008 18:16:22 +0200 Message-ID: <007c01c8b1f0$065c2a70$1100a80a@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acix8AWpBV1iT8YERtiq27D7jPeqmA== X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-HashCash: 1:20:080509:v6ops@ops.ietf.org::rWL1oKZ+QB3ySm66:00000000000000000000000000000000000000000004D8j X-MDRemoteIP: 85.48.160.211 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: miguelangel.diaz@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 09 May 2008 18:12:46 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 26/03/2008, at 1:41 AM, wrote: > Hi, > > As we now have a set of mechanisms to transport IPv6 over IPv4 > standardized, and as it seems we will probably end up having a set of > mechanisms to access IPv4 destinations over IPv6-only access (MNAT-PT, > SNAT, NATv4v6v4.), has there been discussion already how a host that > implements multiple transition technologies should efficiently and > automatically discover which mechanisms to use in access networks it > happens to attach (and move between)? > > Is the current state of the art just: trial & error, provisioning by > non-IETF means, or as defined by other SDOs for their systems? > There is some work in the IETF done time ago regarding this topic. It can be found at http://tools.ietf.org/html/draft-palet-v6ops-auto-trans-02 It explains how an auto-transition mechanism should work. Regards Miguel ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon May 12 02:01: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 9BF6E3A684C for ; Mon, 12 May 2008 02:01:53 -0700 (PDT) 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 Xuj2m-GkCidq for ; Mon, 12 May 2008 02:01:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6FD43A67AA for ; Mon, 12 May 2008 02:01:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvRmy-000LQP-75 for v6ops-data@psg.com; Mon, 12 May 2008 06:45:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvRmT-000LMd-8W for v6ops@ops.ietf.org; Mon, 12 May 2008 06:45:21 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3E3C83A6A2E; Sun, 11 May 2008 23:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-addr-select-req-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512064505.3E3C83A6A2E@core3.amsl.com> Date: Sun, 11 May 2008 23:45:04 -0700 (PDT) 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 : Requirements for address selection mechanisms Author(s) : A. Matsumoto, et al. Filename : draft-ietf-v6ops-addr-select-req-07.txt Pages : 9 Date : 2008-05-11 There are some problematic cases when using the default address selection mechanism which RFC 3484 defines. This document describes additional requirements co-working with RFC 3484 to solve the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-addr-select-req-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-11234247.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon May 12 09:45:25 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 3B3503A68F3 for ; Mon, 12 May 2008 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.478, 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 6BBOyj+mkteQ for ; Mon, 12 May 2008 09:45:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B261E3A6B12 for ; Mon, 12 May 2008 09:45:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jvb1x-000CSo-M5 for v6ops-data@psg.com; Mon, 12 May 2008 16:37:41 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jvb1U-000CPW-NF for v6ops@ops.ietf.org; Mon, 12 May 2008 16:37:27 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A242D3EA0FB for ; Mon, 12 May 2008 18:37:11 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 79BF63EA0C6 for ; Mon, 12 May 2008 18:37:11 +0200 (CEST) Message-ID: <48287238.3050307@free.fr> Date: Mon, 12 May 2008 18:37:12 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: v6ops Subject: 6rd (IPv6 Rapid Deployment on IPv4 infrastructures) Draft-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk The second edition of the I-D on 6rd is available at: http://www3.tools.ietf.org/html/draft-despres-v6ops-6rd-ipv6-rapid-deployment-01 It takes care of remarks made before and during IETF 71. In particular it allows for shorter IPv6 site prefixes in zones where there is a common IPv4 prefix. Remarks welcome. Rémi From owner-v6ops@ops.ietf.org Mon May 12 11:06:58 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 C62773A6882 for ; Mon, 12 May 2008 11:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 7KH9zTISQt7t for ; Mon, 12 May 2008 11:06:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA90D3A67C1 for ; Mon, 12 May 2008 11:06:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvcLJ-000O7L-O1 for v6ops-data@psg.com; Mon, 12 May 2008 18:01:45 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvcL3-000O4B-TV for v6ops@ops.ietf.org; Mon, 12 May 2008 18:01:35 +0000 Received: (qmail 574 invoked by uid 417); 12 May 2008 18:00:55 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 12 May 2008 18:00:55 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 12 May 2008 12:00:55 -0600 From: EricLKlein@softhome.net To: v6ops@ops.ietf.org Subject: Status of NAT-PT solution Date: Mon, 12 May 2008 12:00:55 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.107.188] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Now that NAT-PT has move to historical, is there a consensus or direction on how NAT-PT like services are going to be implemented? What is the status and the correct work to reference for future implementation documentation? Eric From owner-v6ops@ops.ietf.org Mon May 12 12:59:17 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 AA05C28C299 for ; Mon, 12 May 2008 12:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 5sSuiAc2ntsc for ; Mon, 12 May 2008 12:59:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB4683A68C3 for ; Mon, 12 May 2008 12:59:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jve4C-000Bir-4j for v6ops-data@psg.com; Mon, 12 May 2008 19:52:12 +0000 Received: from [209.85.162.178] (helo=el-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jve41-000BhC-57 for v6ops@ops.ietf.org; Mon, 12 May 2008 19:52:06 +0000 Received: by el-out-1112.google.com with SMTP id m34so589405ele.8 for ; Mon, 12 May 2008 12:52:00 -0700 (PDT) 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=0jFz2gflIbaWmwlQo4jSrzxTGzRnSp4bGenRW74ln4s=; b=LWqdxGBXkzQ99VvdDRt8WuudxrjVC+zl1d+pHgaLcnQUAVu1AZonqbre8THfHWPsuEwfjlPJYXDKOljD+QsbOWDmPfUMo4O2xhhcuZfE83vEcLM4syZf33MOpMkIZ2Uogyd0JthTAS7m3v1VJ+FS9YI8OnhIdPegFRFT6Q1Dyzc= 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=ikt3IdNOVejjDXj0C7mLuysf5TizL+dzQapQv3JvEMAOGQPjQLBUfOzRL4MD6a+WgzJSVqA2OQuct4r/ab696wB0C/V6r+aegNP3YoMlQKMd/wJI3JEKYOAiDL+JDovUIHsNWqO2bz6KVh5Ql6UV8A9cmTscgFSHv6ExR4WkHCk= Received: by 10.142.207.8 with SMTP id e8mr3424982wfg.243.1210621919745; Mon, 12 May 2008 12:51:59 -0700 (PDT) Received: from ?10.1.1.4? ( [118.92.205.246]) by mx.google.com with ESMTPS id 20sm340894wfi.11.2008.05.12.12.51.58 (version=SSLv3 cipher=RC4-MD5); Mon, 12 May 2008 12:51:59 -0700 (PDT) Message-ID: <48289FDA.1090808@gmail.com> Date: Tue, 13 May 2008 07:51:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: EricLKlein@softhome.net CC: v6ops@ops.ietf.org Subject: Re: Status of NAT-PT solution References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Eric, This is still work in progress, so there is no "correct" reference right now. I think there will be some more drafts before Dublin. Brian On 2008-05-13 06:00, EricLKlein@softhome.net wrote: > > Now that NAT-PT has move to historical, is there a consensus or > direction on how NAT-PT like services are going to be implemented? > What is the status and the correct work to reference for future > implementation documentation? > Eric > > From owner-v6ops@ops.ietf.org Tue May 13 01:13: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 D10993A6875 for ; Tue, 13 May 2008 01:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=1.839, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, 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 sV3tdzV1XxFG for ; Tue, 13 May 2008 01:13:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B36213A6859 for ; Tue, 13 May 2008 01:13:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpV4-0007eY-Fz for v6ops-data@psg.com; Tue, 13 May 2008 08:04:42 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpU4-0007WD-8Y for v6ops@ops.ietf.org; Tue, 13 May 2008 08:03:46 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1382720AF7; Tue, 13 May 2008 10:02:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EEAE7209A1; Tue, 13 May 2008 10:02:54 +0200 (CEST) Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 10:02:54 +0200 Received: from mail pickup service by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC; Tue, 13 May 2008 10:02:54 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 09:37:57 +0200 Received: from mailgw1.ericsson.se ([193.180.251.45]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 22:10:11 +0200 Received: from mailgw1.ericsson.se (unknown [127.0.0.1]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id BCFB358C002; Mon, 12 May 2008 22:10:11 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-1b-48294b2e716c Received: from psg.com (psg.com [147.28.0.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id 6AAD950001E; Mon, 12 May 2008 22:10:11 +0200 (CEST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jve4C-000Bir-4j for v6ops-data@psg.com; Mon, 12 May 2008 19:52:12 +0000 Received: from [209.85.162.178] (helo=el-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jve41-000BhC-57 for v6ops@ops.ietf.org; Mon, 12 May 2008 19:52:06 +0000 Received: by el-out-1112.google.com with SMTP id m34so589405ele.8 for ; Mon, 12 May 2008 12:52:00 -0700 (PDT) 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=0jFz2gflIbaWmwlQo4jSrzxTGzRnSp4bGenRW74ln4s=; b=LWqdxGBXkzQ99VvdDRt8WuudxrjVC+zl1d+pHgaLcnQUAVu1AZonqbre8THfHWPsuEwfjlPJYXDKOljD+QsbOWDmPfUMo4O2xhhcuZfE83vEcLM4syZf33MOpMkIZ2Uogyd0JthTAS7m3v1VJ+FS9YI8OnhIdPegFRFT6Q1Dyzc= 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=ikt3IdNOVejjDXj0C7mLuysf5TizL+dzQapQv3JvEMAOGQPjQLBUfOzRL4MD6a+WgzJSVqA2OQuct4r/ab696wB0C/V6r+aegNP3YoMlQKMd/wJI3JEKYOAiDL+JDovUIHsNWqO2bz6KVh5Ql6UV8A9cmTscgFSHv6ExR4WkHCk= Received: by 10.142.207.8 with SMTP id e8mr3424982wfg.243.1210621919745; Mon, 12 May 2008 12:51:59 -0700 (PDT) Received: from ?10.1.1.4? ( [118.92.205.246]) by mx.google.com with ESMTPS id 20sm340894wfi.11.2008.05.12.12.51.58 (version=SSLv3 cipher=RC4-MD5); Mon, 12 May 2008 12:51:59 -0700 (PDT) Message-ID: <48289FDA.1090808@gmail.com> Date: Tue, 13 May 2008 07:51:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: EricLKlein@softhome.net CC: v6ops@ops.ietf.org Subject: Re: Status of NAT-PT solution References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 12 May 2008 20:10:11.0900 (UTC) FILETIME=[2F0E67C0:01C8B46C] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Eric, This is still work in progress, so there is no "correct" reference right now. I think there will be some more drafts before Dublin. Brian On 2008-05-13 06:00, EricLKlein@softhome.net wrote: > > Now that NAT-PT has move to historical, is there a consensus or > direction on how NAT-PT like services are going to be implemented? > What is the status and the correct work to reference for future > implementation documentation? > Eric > > From owner-v6ops@ops.ietf.org Tue May 13 01:14:08 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 708523A6875 for ; Tue, 13 May 2008 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Ai2g3ZvTERNJ for ; Tue, 13 May 2008 01:14:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 838533A6859 for ; Tue, 13 May 2008 01:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpVw-0007km-3k for v6ops-data@psg.com; Tue, 13 May 2008 08:05:36 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpUI-0007Ye-J3 for v6ops@ops.ietf.org; Tue, 13 May 2008 08:04:09 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 61FDA20135 for ; Tue, 13 May 2008 10:02:40 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 543D0213B0 for ; Tue, 13 May 2008 10:02:40 +0200 (CEST) Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 10:02:34 +0200 Received: from mail pickup service by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC; Tue, 13 May 2008 10:02:34 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 09:37:48 +0200 Received: from mailgw8.ericsson.se ([193.180.251.59]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 19:06:31 +0200 Received: from mailgw8.ericsson.se (unknown [127.0.0.1]) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id 81A45520002; Mon, 12 May 2008 19:06:31 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-b8-48294b205b64 Received: from psg.com (psg.com [147.28.0.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id 30C74498045; Mon, 12 May 2008 19:06:31 +0200 (CEST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jvb1x-000CSo-M5 for v6ops-data@psg.com; Mon, 12 May 2008 16:37:41 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jvb1U-000CPW-NF for v6ops@ops.ietf.org; Mon, 12 May 2008 16:37:27 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A242D3EA0FB for ; Mon, 12 May 2008 18:37:11 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 79BF63EA0C6 for ; Mon, 12 May 2008 18:37:11 +0200 (CEST) Message-ID: <48287238.3050307@free.fr> Date: Mon, 12 May 2008 18:37:12 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: v6ops Subject: 6rd (IPv6 Rapid Deployment on IPv4 infrastructures) Draft-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 12 May 2008 17:06:31.0522 (UTC) FILETIME=[86662C20:01C8B452] Sender: owner-v6ops@ops.ietf.org Precedence: bulk The second edition of the I-D on 6rd is available at: http://www3.tools.ietf.org/html/draft-despres-v6ops-6rd-ipv6-rapid-deployment-01 It takes care of remarks made before and during IETF 71. In particular it allows for shorter IPv6 site prefixes in zones where there is a common IPv4 prefix. Remarks welcome. Rémi From owner-v6ops@ops.ietf.org Tue May 13 16:38: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 A57BC3A6922 for ; Tue, 13 May 2008 16:38:53 -0700 (PDT) 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 fHgmXs3fU4or for ; Tue, 13 May 2008 16:38:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAA113A67AF for ; Tue, 13 May 2008 16:38:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jw3x2-0008Cs-Kl for v6ops-data@psg.com; Tue, 13 May 2008 23:30:32 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jw3wY-0008AE-HF for v6ops@ops.ietf.org; Tue, 13 May 2008 23:30:17 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 301873A6854; Tue, 13 May 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080513233001.301873A6854@core3.amsl.com> Date: Tue, 13 May 2008 16:30:01 -0700 (PDT) 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 : IPv4/IPv6 Coexistence and Transition: Requirements for solutions Author(s) : M. Bagnulo, et al. Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt Pages : 17 Date : 2008-05-13 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-ietf-v6ops-nat64-pb-statement-req-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-nat64-pb-statement-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-13162035.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Wed May 14 00:24: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 4C11C3A69D6 for ; Wed, 14 May 2008 00:24:21 -0700 (PDT) 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 LQP3oQe2-jqW for ; Wed, 14 May 2008 00:24:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 528723A69C9 for ; Wed, 14 May 2008 00:24:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwBD4-000Hud-42 for v6ops-data@psg.com; Wed, 14 May 2008 07:15:34 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwBCZ-000Hqk-P7 for v6ops@ops.ietf.org; Wed, 14 May 2008 07:15:18 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 6DDA23A685A; Wed, 14 May 2008 00:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-addr-select-ps-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514071501.6DDA23A685A@core3.amsl.com> Date: Wed, 14 May 2008 00:15:01 -0700 (PDT) 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-06.txt Pages : 17 Date : 2008-05-14 A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OS's. But, it has been too difficult to use operationally for several reasons, In some environment where multiple prefixes are assigned on a single physical link, the host with the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-addr-select-ps-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-14000847.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Wed May 14 09:11: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 DCC613A682A for ; Wed, 14 May 2008 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 PPF+OUQb+VnZ for ; Wed, 14 May 2008 09:11:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34DB328C0D6 for ; Wed, 14 May 2008 09:11:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwJPi-000IU5-V2 for v6ops-data@psg.com; Wed, 14 May 2008 16:01:10 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwJOh-000IK7-8J for v6ops@ops.ietf.org; Wed, 14 May 2008 16:00:40 +0000 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EFsdxX014655; Wed, 14 May 2008 10:54:55 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:54:39 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:54:39 +0300 Received: from es-nira-64-48.europe.nokia.com (es-nira-64-48.europe.nokia.com [10.162.64.48]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m4EFsabh031616; Wed, 14 May 2008 18:54:37 +0300 Message-Id: <913678E6-D723-419B-B19D-7430D9DF4641@nokia.com> From: Bob Hinden To: IETF IPv6 Mailing List , IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Reply-To: bob.hinden@nokia.com Subject: Fwd: [Int-area] RSVP for IPv6 implementors: your use of RAO value 3 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 14 May 2008 17:54:35 +0200 References: X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 14 May 2008 15:54:39.0157 (UTC) FILETIME=[D0DAFE50:01C8B5DA] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI Begin forwarded message: > From: "Jukka MJ Manner" > Date: May 14, 2008 3:51:08 PM GMT+02:00 > To: Transport Area WG , Internet Area > > Subject: [Int-area] RSVP for IPv6 implementors: your use of RAO > value 3 > > > Hi, > > We are in the middle of fixing the IP Router Alert Option registry and > allocations, and one issue affects the current RSVP implementations. > > There are two values that indicate end-to-end RSVP: > "1" Datagram contains RSVP message [RFC2711] > "3" RSVP Aggregation Level 0 [RFC3175] > > We are currently proposing that value "3" should be removed from > use, and > reserved (not to be allocated to any protocol). Thus, value "1" > should be > used to indicate end-to-end RSVP. > > The question is: who have RSVP implementations for IPv6, and would > this > change break something? > > Regards, > Jukka > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From owner-v6ops@ops.ietf.org Wed May 14 14:58: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 AD2B63A6780 for ; Wed, 14 May 2008 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.918 X-Spam-Level: X-Spam-Status: No, score=-4.918 tagged_above=-999 required=5 tests=[AWL=0.131, 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 sxNHn4ahzptm for ; Wed, 14 May 2008 14:58:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FEEF3A63D3 for ; Wed, 14 May 2008 14:58:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwOrT-000AzF-3b for v6ops-data@psg.com; Wed, 14 May 2008 21:50:11 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwOqA-000Ak1-Sc for v6ops@ops.ietf.org; Wed, 14 May 2008 21:49:35 +0000 Received: from marcelo-bagnulos-macbook-pro.local (118.44.217.87.dynamic.jazztel.es [87.217.44.118])by smtp02.uc3m.es (Postfix) with ESMTP id 93C4539CC32for ; Wed, 14 May 2008 23:48:44 +0200 (CEST) Message-ID: <482B5E3C.5000302@it.uc3m.es> Date: Wed, 14 May 2008 23:48:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> In-Reply-To: <20080513233001.301873A6854@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.0135 TC:1F TRN:37 TV:5.5.1026(15910.002) 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 submitted the new version of the requirements for translators AFAICT one issue that needs to be decided is whether we need solutions both for v4 initiated solution and v6 initiated solution or it is enough to hav solutions for v6 initiated solutions, especially without requiring modifications to the v4 nodes. During some of the discussion, for instance during the one on DNSSec, people have expressed that they don't feel that we need to require DNSSec support for v4 initiated communications cause these where not relevant. So, i guess we need to define this comments? Regards, marcelo Internet-Drafts@ietf.org escribió: > 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 : IPv4/IPv6 Coexistence and Transition: Requirements for solutions > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt > Pages : 17 > Date : 2008-05-13 > > 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-ietf-v6ops-nat64-pb-statement-req-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-v6ops@ops.ietf.org Wed May 14 23:36: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 E509B3A67F3 for ; Wed, 14 May 2008 23:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 OaB3kV7D+ydX for ; Wed, 14 May 2008 23:36:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCB943A63D3 for ; Wed, 14 May 2008 23:36:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwWvd-000Feu-TX for v6ops-data@psg.com; Thu, 15 May 2008 06:27:01 +0000 Received: from [209.85.200.170] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwWvA-000Fbx-V7 for v6ops@ops.ietf.org; Thu, 15 May 2008 06:26:47 +0000 Received: by wf-out-1314.google.com with SMTP id 26so260818wfd.32 for ; Wed, 14 May 2008 23:26:32 -0700 (PDT) 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=eIqgPTj5PQOu4oTgbg9qjrX3go1JqqKdpgWd6nmmda0=; b=Iml7DJZs4rmnmthvbAR65jlrLYDcHD48iJjUAOnO4X6k2fSNM7vLCVcD/GMQyErhILhteT7sDhu4netfipzkrF9vORh46bw0FisQF6H2skRB9GHMGId9BAyNNMmQfx7mGtbPRqx3te45lbv2Wsj1otPxFgOpUAjqbdCa66yjGVw= 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=cyaxHFmgrtiQTjd9NJDGpGehNlQ7gSm17ZRboX8Y9OlsrZdfKhpi/Mhtu1XXuVC4JpB1OFGnbBwkmoJ6uqNCMv2IePnPZC9rXFnGW8DrJNSaZQBS76oOOtE77UZ7iNxQIYxA9cOPpWyOLIrFpEZTz2/wnts4VQUMSme98kz0oDA= Received: by 10.142.125.5 with SMTP id x5mr798598wfc.191.1210832792601; Wed, 14 May 2008 23:26:32 -0700 (PDT) Received: by 10.143.164.14 with HTTP; Wed, 14 May 2008 23:26:32 -0700 (PDT) Message-ID: <77ead0ec0805142326n77ce1692vaf57d35378f5fe27@mail.gmail.com> Date: Thu, 15 May 2008 11:56:32 +0530 From: "Vishwas Manral" To: bob.hinden@nokia.com, jmanner@cs.Helsinki.FI Subject: Re: [Int-area] RSVP for IPv6 implementors: your use of RAO value 3 Cc: "IETF IPv6 Mailing List" , "IPv6 Operations" In-Reply-To: <913678E6-D723-419B-B19D-7430D9DF4641@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <913678E6-D723-419B-B19D-7430D9DF4641@nokia.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Bob/ Jukka, We at IPInfusion support RSVP for IPv6. Our implementation will however not be affected by the fix mentioned below. Thanks, Vishwas On Wed, May 14, 2008 at 9:24 PM, Bob Hinden wrote: > FYI > > Begin forwarded message: > >> From: "Jukka MJ Manner" >> Date: May 14, 2008 3:51:08 PM GMT+02:00 >> To: Transport Area WG , Internet Area > > >> Subject: [Int-area] RSVP for IPv6 implementors: your use of RAO >> value 3 >> >> >> Hi, >> >> We are in the middle of fixing the IP Router Alert Option registry and >> allocations, and one issue affects the current RSVP implementations. >> >> There are two values that indicate end-to-end RSVP: >> "1" Datagram contains RSVP message [RFC2711] >> "3" RSVP Aggregation Level 0 [RFC3175] >> >> We are currently proposing that value "3" should be removed from >> use, and >> reserved (not to be allocated to any protocol). Thus, value "1" >> should be >> used to indicate end-to-end RSVP. >> >> The question is: who have RSVP implementations for IPv6, and would >> this >> change break something? >> >> Regards, >> Jukka >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From owner-v6ops@ops.ietf.org Thu May 15 01:37: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 18A743A6A57 for ; Thu, 15 May 2008 01:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 5KdP-vl6bD3p for ; Thu, 15 May 2008 01:37:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A69D3A6A56 for ; Thu, 15 May 2008 01:36:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwYrL-0004gj-Be for v6ops-data@psg.com; Thu, 15 May 2008 08:30:43 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwYqw-0004dw-KF for v6ops@ops.ietf.org; Thu, 15 May 2008 08:30:33 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4F8U4sC007181; Thu, 15 May 2008 11:30:08 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 11:30:01 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 11:30:00 +0300 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: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Thu, 15 May 2008 11:29:58 +0300 Message-ID: In-Reply-To: <482B5E3C.5000302@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: Aci2DoJWKR2wtrw6Rmu5d9KuaT05rQATVHCQ References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> From: To: , X-OriginalArrivalTime: 15 May 2008 08:30:00.0385 (UTC) FILETIME=[DD7B3310:01C8B665] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I agree with the document, with following comments: In cellular environments it can actually be the mobile phone that is = provided IPv6-only connectivity by the network, and the mobile needs to = act the role of CPE (to be more exact, the mobile with IPv6-only = connectivity may be running IPv4-only apps and it may have IPv4 LAN = behind it, for which mobile needs to provide (NATted) addresses). These = devices are not manually configurable (provisionable they are, though) = and often not easily software upgradable. These devices are also very = many and thus transition solutions must be scalable especially on the = core network side (imagine operator with 100 million devices connected = with IPv6-only and simultaneously asking for IPv4 translation services = for high speed data sessions). The cellular terminals are often on the move - the transition mechanism = discovery and setup ought to be very quick process (i.e. during movement = users are not happy to wait as long as in system startup and initial = connection creation phase). This is also essential in network selection = phase - if there are multiple networks available (e.g. WLAN hot-spots) = the availability of transition mechanisms might have impact on network = selection, and if possible the unavailability should be quickly = detectable for fast failures & fallbacks. In my opinion the modifications should be done only for new/upgradable = IPv6-enabled nodes and only for IP-layer, as IPv6 is not widely used yet = and as legacy IPv4 applications (running on IPv6-capable nodes) need to = be supported as well.=20 One aspect on these transition mechanisms is placement of NAT(s) (4-4, = 4-6, 6-4) and required ALGs, i.e. whether those are on client itself, on = gateway, or nowhere (APBP kind of approach). Different approaches have = different pros and cons, which should be studied more. The placement = likely affects at least on scalability of the solution. Thus for chapter 2.2/4.1. I propose additions of: - Translation architectures SHOULD be scalable for large numbers of = hosts and high data speeds - Availability of translation mechanism service SHOULD be quickly = discoverable=20 - Legacy IPv4-only applications on IPv6-nodes MUST continue working I say SHOULD instead of MUST, as there surely are deployment scenarios = where scalability is not an issue or where discovery process can be = slow. For chapter 3.5 I'd like to add Symbian as one well-known and widely = used OS. There are also great volumes of vendor proprietary OS'es.=20 It should be acknowledged (if its not) that quite likely not a single = transition solution will be suitable for everybody: - operator/organization with relatively large IPv4 address pool might = prefer IPv4-over-IPv6 tunneling (static or dynamic) - i.e. long term = lease of full IPv4 address to clients - operator/organization with relatively small IPv4 address pool might = prefer translation or DSTM/APBP kinds of approaches - i.e. short term = lease of IPv4 address(&port) to clients - operator/organization who deploys DSMIP or VPNs might want to use = those as transition mechanism - operator/organization with large subscriber base (100s of millions ) = might need more scalable solutions than operator with small subscriber = base (e.g. smaller than RFC1918 address space) - .... Best regards, Teemu =20 >-----Original Message----- >From: owner-v6ops@ops.ietf.org=20 >[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext marcelo=20 >bagnulo braun >Sent: 15 May, 2008 00:49 >To: v6ops@ops.ietf.org >Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt > >Hi, > >we have submitted the new version of the requirements for translators > >AFAICT one issue that needs to be decided is whether we need=20 >solutions both for v4 initiated solution and v6 initiated=20 >solution or it is enough to hav solutions for v6 initiated=20 >solutions, especially without requiring modifications to the v4 nodes. > >During some of the discussion, for instance during the one on=20 >DNSSec, people have expressed that they don't feel that we=20 >need to require DNSSec support for v4 initiated communications=20 >cause these where not relevant. > >So, i guess we need to define this > >comments? > > >Regards, marcelo > >Internet-Drafts@ietf.org escribi=F3: >> A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working=20 >Group of the IETF. >> >> >> Title : IPv4/IPv6 Coexistence and Transition:=20 >Requirements for solutions >> Author(s) : M. Bagnulo, et al. >> Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt >> Pages : 17 >> Date : 2008-05-13 >> >> This note presents the problem statement, analysis and requirements=20 >> for solutions to IPv4/IPv6 coexistence and eventual transition in a=20 >> scenario in which dual stack operation is not the norm. >> >> A URL for this Internet-Draft is: >>=20 >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statemen >> t-req-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >> =20 > > > From owner-v6ops@ops.ietf.org Thu May 15 02:50: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 9D1153A6A35 for ; Thu, 15 May 2008 02:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-2.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_22=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 FJ+TYE-i+V7v for ; Thu, 15 May 2008 02:50:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADECC3A6824 for ; Thu, 15 May 2008 02:50:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwZzz-000Di4-0b for v6ops-data@psg.com; Thu, 15 May 2008 09:43:43 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwZzR-000DeG-0w for v6ops@ops.ietf.org; Thu, 15 May 2008 09:43:24 +0000 Received: from marcelo-bagnulos-macbook-pro.local (118.44.217.87.dynamic.jazztel.es [87.217.44.118])by smtp01.uc3m.es (Postfix) with ESMTP id 0C235603990;Thu, 15 May 2008 11:43:03 +0200 (CEST) Message-ID: <482C05A6.4070404@it.uc3m.es> Date: Thu, 15 May 2008 11:43:02 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: teemu.savolainen@nokia.com CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-20.4205 TC:1F TRN:74 TV:5.5.1026(15910.005) 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 Teemu thanks for the comments see comments below... teemu.savolainen@nokia.com escribió: I undrsatnd that the changes you are proposing are: > Thus for chapter 2.2/4.1. I propose additions of: > - Translation architectures SHOULD be scalable for large numbers of hosts and high data speeds > that certainly makes sense to me, would you include it in the basic requirements (MUST) or in the SHOULD? (i mean you phrase it as a should but you propose to include it 4.1) > - Availability of translation mechanism service SHOULD be quickly discoverable > I also agree with this one, probably in section 4.2? > - Legacy IPv4-only applications on IPv6-nodes MUST continue working > > I am not sure this has to do with the translation mechanisms that we are considering at this point... I mean, what we are considering here AFAIU, is a new box that you include in between the v4 world and the v6 world, so that they can communicate. There may require some modifications to the v6 host. For that it seems to me that this is somehow different transition tool, that fits in a different scenario? So, i don't see this clear... > I say SHOULD instead of MUST, as there surely are deployment scenarios where scalability is not an issue or where discovery process can be slow. > > For chapter 3.5 I'd like to add Symbian as one well-known and widely used OS. There are also great volumes of vendor proprietary OS'es. > > makes sense to me > It should be acknowledged (if its not) that quite likely not a single transition solution will be suitable for everybody: > - operator/organization with relatively large IPv4 address pool might prefer IPv4-over-IPv6 tunneling (static or dynamic) - i.e. long term lease of full IPv4 address to clients > - operator/organization with relatively small IPv4 address pool might prefer translation or DSTM/APBP kinds of approaches - i.e. short term lease of IPv4 address(&port) to clients > - operator/organization who deploys DSMIP or VPNs might want to use those as transition mechanism > - operator/organization with large subscriber base (100s of millions ) might need more scalable solutions than operator with small subscriber base (e.g. smaller than RFC1918 address space) > - .... > > could you provide text of where and what you propose to include as you did in the previous items? Thanks, marcelo > Best regards, > > Teemu > > > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext marcelo >> bagnulo braun >> Sent: 15 May, 2008 00:49 >> To: v6ops@ops.ietf.org >> Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt >> >> Hi, >> >> we have submitted the new version of the requirements for translators >> >> AFAICT one issue that needs to be decided is whether we need >> solutions both for v4 initiated solution and v6 initiated >> solution or it is enough to hav solutions for v6 initiated >> solutions, especially without requiring modifications to the v4 nodes. >> >> During some of the discussion, for instance during the one on >> DNSSec, people have expressed that they don't feel that we >> need to require DNSSec support for v4 initiated communications >> cause these where not relevant. >> >> So, i guess we need to define this >> >> comments? >> >> >> Regards, marcelo >> >> Internet-Drafts@ietf.org escribió: >> >>> 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 : IPv4/IPv6 Coexistence and Transition: >>> >> Requirements for solutions >> >>> Author(s) : M. Bagnulo, et al. >>> Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt >>> Pages : 17 >>> Date : 2008-05-13 >>> >>> 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-ietf-v6ops-nat64-pb-statemen >> >>> t-req-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >> >> > > From owner-v6ops@ops.ietf.org Thu May 15 07:16: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 D89323A6A80 for ; Thu, 15 May 2008 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 MaC+K5e1QW-9 for ; Thu, 15 May 2008 07:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 886943A6A70 for ; Thu, 15 May 2008 07:16:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jwe8f-000Muk-SC for v6ops-data@psg.com; Thu, 15 May 2008 14:08:57 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jwe8R-000Msw-Jn for v6ops@ops.ietf.org; Thu, 15 May 2008 14:08:52 +0000 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4FE8LEe016500; Thu, 15 May 2008 09:08:35 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 17:08:23 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 17:08:23 +0300 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: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Thu, 15 May 2008 17:08:20 +0300 Message-ID: In-Reply-To: <482C05A6.4070404@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: Aci2cBghp3oXUNsYRZ6/dRzc6TKGlAAC3JVA References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> <482C05A6.4070404@it.uc3m.es> From: To: Cc: X-OriginalArrivalTime: 15 May 2008 14:08:23.0386 (UTC) FILETIME=[23034BA0:01C8B695] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Marcelo, Inline, >I undrsatnd that the changes you are proposing are: >> Thus for chapter 2.2/4.1. I propose additions of: >> - Translation architectures SHOULD be scalable for large numbers of=20 >> hosts and high data speeds >> =20 >that certainly makes sense to me, >would you include it in the basic requirements (MUST) or in=20 >the SHOULD?=20 >(i mean you phrase it as a should but you propose to include it 4.1) I originally though it to be MUST, but then I started thinking that in some environments other properties than scalability may be of priority, and as scalability is somewhat subjective concept, I ended up with SHOULD. It is very hard to be exact on scalability requirements, but I believe we will nevertheless be able to compare different proposals from that point of view. See below for proposal. >> - Availability of translation mechanism service SHOULD be quickly=20 >> discoverable >> =20 >I also agree with this one, probably in section 4.2? Yes, for same reasons. I added requirement of one RTT. See below for proposal. >> - Legacy IPv4-only applications on IPv6-nodes MUST continue working >> >I am not sure this has to do with the translation mechanisms=20 >that we are considering at this point... I mean, what we are=20 >considering here AFAIU, is a new box that you include in=20 >between the v4 world and the v6 world, so that they can=20 >communicate. There may require some modifications to the v6 host. >For that it seems to me that this is somehow different=20 >transition tool, that fits in a different scenario? Excluding RFC2766 NAT-PT kind of single box solutions (is there others than RFC2766?), all actually implement two (or more) logical boxes - one near/on the v6 host and one further away with IPv4 interface (all tunneling solutions, and also NATv4v6v4 and MNAT-PT), right? The "I2: operational flexibility" says that "It should be possible to locate the translation device at an arbitrary point in the network (i.e. not at fixed points such as a site exit), so that there is full operational flexibility.". I would read that sentence so that if the "translation device" is actually two logical functions, then the other end can locate inside the v6 host as well (i.e. between the small internal v4 world and v6 world), if seen useful from operational flexibility point of view. The other end of course is located in some other device which has global IPv4 interface.=20 From solution side at least DSTM/TSP/APBP utilize the possibility to have great deal of the functionality in the v6 hosts themselves for achieving scalability benefits (less load for single infrastructure components, NAT/ALG avoidance). I added this to 4.3 below as MAY. I was considering SHOULD, but as IPv4 world is so used to live with NATs and my understanding is that current level of IPv4 support does not need to be improved here, I ended up with MAY (this can be debated, surely:-) >could you provide text of where and what you propose to=20 >include as you did in the previous items? Here are the proposed additions (old+some new): 2. Problem statement It may be that a single transition mechanism is not able to address all transition scenarios at optimal way. The transition mechanism should be clear for which scenarios it has been designed for. 2.1. Transition scenarios Not every organization has the same starting point and resources available for IPv6 transition. Namely availability of public IPv4 addresses and number of simultaneously served hosts differs. At least following general scenarios can be identified, in which different organizations can be at different moments of time: o Enough public IPv4 addresses to uniquely number each host in the network o Enough private IPv4 addresses to uniquely number each host in the network=20 o Not enough public and private IPv4 addresses to uniquely number each host in the network without using parallel RFC1918 address spaces It can be assumed that organizations have access to as many public IPv4 address and port combinations as there are simultaneously active IPv4 data connections. 2.1.2. Transition scenarios that do not require translation Organizations that have enough public or private IPv4 addresses can use "start-time" tunnels, but for those lacking public and private IPv4 addresses "dynamic tunneling" is more favorable, as it does not consume IPv4 addresses for IPv4-idle hosts. 2.1.3. Transition scenarios that require translation Translation is a potential solution for organizations facing shortage of IPv4 addresses or who do not wish to provide IPv4 access network, but who still need to provide IPv4 connectivity for legacy IPv4-only applications running on IPv6 hosts or for hosts that are IPv6-only and need to connect to IPv4-only services. 2.2. Requirements for the overall transition strategy 8. Transition architectures should be scalable for large number of hosts and high data speeds. 9. Availability of transition solutions on an access network should be quickly discoverable. 4.2. Important things that SHOULD be supported I9: Scalability The translation mechanism SHOULD support very large number of hosts and high data speeds with reasonable infrastructure requirements considering equipment available at the transition timeframe. I10: Discovery The translation mechanism SHOULD be quickly discoverable, preferably in one RTT, to help moving hosts better assess capabilities of available access networks and to provide good user experience. 4.3. Important things that MAY be supported M1: No NATs or ALGs The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid need for ALGs.=20 Best regards, Teemu From kian-tat@fujitsu.com Sun May 18 07:29: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 7E4E03A6919 for ; Sun, 18 May 2008 07:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.399 X-Spam-Level: X-Spam-Status: No, score=-24.399 tagged_above=-999 required=5 tests=[DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FM_FAKE_HELO_VERIZON=1.229, HELO_DYNAMIC_IPADDR=2.935, HELO_EQ_DSL=1.129, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, JM_REACTOR_MAILER=1, MANGLED_CIALIS=2.5, 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_XBL=2.896, RDNS_NONE=0.1, SUBJECT_DRUG_GAP_C=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=0.901, URIBL_SBL=20, 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 KAVH13kBUEKp for ; Sun, 18 May 2008 07:29:25 -0700 (PDT) Received: from static-66-13-85-148.bdsl.verizon.net (unknown [66.13.85.148]) by core3.amsl.com (Postfix) with ESMTP id E3DC73A68E2 for ; Sun, 18 May 2008 07:29:24 -0700 (PDT) Message-ID: <000a01c8b8f3$061a54cf$c7ab09a5@owbnckt> From: "cornell isel" To: Subject: CIAALIS. Huge Discount Today! Date: Sun, 18 May 2008 12:42:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8B8F3.06151668" 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_01C8B8F3.06151668 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable chest pain or irregular heartbeats; dizziness, nausea, or angina (pain, = tightness, discomfort, numbness, or tingling in the chest, arms, neck, = or jaw); CIALLIS. Huge Discount Today! want cheap it, get cheap it from India! ------=_NextPart_000_0007_01C8B8F3.06151668 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

chest pain or irregular heartbeats; dizziness, nausea, = or angina (pain, tightness, discomfort, numbness, or tingling in the = chest, arms, neck, or jaw);

CIALLIS. Huge Discount Today! want cheap it, get cheap it = from India!

------=_NextPart_000_0007_01C8B8F3.06151668-- From c6852@mail.tsit.com.tw Sun May 18 13:01:15 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 D88373A6992; Sun, 18 May 2008 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.902 X-Spam-Level: X-Spam-Status: No, score=-53.902 tagged_above=-999 required=5 tests=[FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=4.199, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_NUMERIC_HELO=2.599, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.617, 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 Eb7lwabqN9Mp; Sun, 18 May 2008 13:01:15 -0700 (PDT) Received: from 82.159.123.0.dyn.user.ono.com (82.159.123.0.dyn.user.ono.com [82.159.123.0]) by core3.amsl.com (Postfix) with SMTP id 297A428C55F; Sun, 18 May 2008 13:01:05 -0700 (PDT) X-Originating-IP: 253.190.112.32 by smtp.82.159.123.0; Sun, 18 May 2008 16:01:05 -0500 Message-ID: From: "Doyle Duffy" Reply-To: "Doyle Duffy" To: tools-discuss@ietf.org Subject: Superior replica watches for you Date: Sun, 18 May 2008 16:01:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://kotowydi77321.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://kotowydi77321.blogspot.com/ From ca@equipaindustria.com.br Sun May 18 13:27: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 927363A6BFD; Sun, 18 May 2008 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.114 X-Spam-Level: X-Spam-Status: No, score=-85.114 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 VpZkyJvOFWFg; Sun, 18 May 2008 13:27:21 -0700 (PDT) Received: from cliente-10702.iberbanda.es (unknown [82.198.105.204]) by core3.amsl.com (Postfix) with SMTP id B993A3A6800; Sun, 18 May 2008 13:27:09 -0700 (PDT) X-Originating-IP: 240.68.48.182 by smtp.82.198.105.204; Sun, 18 May 2008 16:27:10 -0500 Message-ID: From: "Terra Crum" Reply-To: "Terra Crum" To: provreg-archive@megatron.ietf.org Subject: Get 15% off these watches Date: Sun, 18 May 2008 16:27:10 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://rynozuhi83273.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://rynozuhi83273.blogspot.com/ From c.kaelin@rkmarketing.ch Mon May 19 04:49: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 7B0D428C619; Mon, 19 May 2008 04:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, 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, 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 qKupGQcxzaks; Mon, 19 May 2008 04:49:08 -0700 (PDT) Received: from 190-172-186-45.speedy.com.ar (unknown [190.172.186.45]) by core3.amsl.com (Postfix) with SMTP id CAB1128C606; Mon, 19 May 2008 04:47:30 -0700 (PDT) X-Originating-IP: 90.60.10.161 by smtp.190.172.186.45; Mon, 19 May 2008 07:47:28 -0500 Message-ID: From: "Janelle Bynum" Reply-To: "Janelle Bynum" To: tools-discuss@ietf.org Subject: The affordable watch alternative Date: Mon, 19 May 2008 07:47:28 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://suzicagy68735.shheus.com/ From owner-v6ops@ops.ietf.org Mon May 19 16:11: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 051593A6B5D for ; Mon, 19 May 2008 16:11:33 -0700 (PDT) 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 KOSc10Ftk8EM for ; Mon, 19 May 2008 16:11:30 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BE5403A6978 for ; Mon, 19 May 2008 16:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JyEMS-00058e-96 for v6ops-data@psg.com; Mon, 19 May 2008 23:01:44 +0000 Received: from [205.158.62.78] (helo=smtp1.us4.outblaze.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JyEMH-00057V-Gc for v6ops@ops.ietf.org; Mon, 19 May 2008 23:01:38 +0000 Received: (qmail 29103 invoked from network); 19 May 2008 23:01:32 -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; 19 May 2008 23:01:31 -0000 Mime-Version: 1.0 Message-Id: Date: Mon, 19 May 2008 19:01:21 -0400 To: v6ops@ops.ietf.org From: John Curran Subject: New Version Notification for draft-jcurran-v6transitionplan-03 Content-Type: text/plain; charset="us-ascii" Sender: owner-v6ops@ops.ietf.org Precedence: bulk In preparation for RFC submission, an updated version of this Internet-Draft was submitted to the IETF repository. The Change History from -02 to -03 is as follows: o Revise Introduction to provide additional motivation language. o Revise Introduction and requirements language preface to better clarify use of RFC 2119 style terminology. o Clarify need for IPv6-capable infrastructure rather than simply servers in final phase. o Correct misc typos and capitalization errors. o Updated Acknowledgements section appropriately. FYI, /John === >From: IETF I-D Submission Tool >To: jcurran@istaff.org >Subject: New Version Notification for draft-jcurran-v6transitionplan-03 >Date: Sun, 18 May 2008 20:44:59 -0700 (PDT) > >A new version of I-D, draft-jcurran-v6transitionplan-03.txt has been successfuly submitted by John Curran and posted to the IETF repository. > >Filename: draft-jcurran-v6transitionplan >Revision: 03 >Title: An Internet Transition Plan >Creation_date: 2008-05-19 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >This memo provides one possible plan for transitioning the Internet > from a predominantly IPv4-based connectivity model to a predominantly > IPv6-based connectivity model. > >The IETF Secretariat. From c56c@c56c.com Mon May 19 16: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 22A313A67ED; Mon, 19 May 2008 16:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.733 X-Spam-Level: X-Spam-Status: No, score=-52.733 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HELO_MISMATCH_NET=0.611, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SPEC_ROLEX_SEL=2.222, TVD_RCVD_IP=1.931, 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 nNscQnyxAkR4; Mon, 19 May 2008 16:56:25 -0700 (PDT) Received: from 200.79.152.27.dial.dyn.telnor.net (unknown [200.79.152.27]) by core3.amsl.com (Postfix) with SMTP id C576D3A6B24; Mon, 19 May 2008 16:55:58 -0700 (PDT) X-Originating-IP: 240.168.240.128 by smtp.200.79.152.27; Mon, 19 May 2008 19:55:57 -0500 Message-ID: From: "Lucy Macdonald" Reply-To: "Lucy Macdonald" To: tools-discuss@ietf.org Subject: Inexpensive IWC watches Date: Mon, 19 May 2008 19:55:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking for superior quality replica watches? Then welcome to the newly redesigned Prestige Replicas, home of the best reproduction Rolex Sportmodel watches on the whole web! Prestige Replicas offers a tremendous selection of Rolex replica timepieces for both men and women, all of them featuring the original manufacturer markings along with a myriad of details that make these watches look so much like the brand new Rolexes that even the experts are having a hard time differentiating them! http://mocybofivor40.blogspot.com/ So, come visit Prestige Replicas and enjoy not only the most beautiful Rolex Sportmodel replica watches at unbelievable prices, but also get an extra 15% off when you buy two! http://mocybofivor40.blogspot.com/ From c.gebhart@wastema.de Mon May 19 17:42:39 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 DE97A3A6B51; Mon, 19 May 2008 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.772 X-Spam-Level: X-Spam-Status: No, score=-78.772 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, 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, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 9h1GUto80hqA; Mon, 19 May 2008 17:42:38 -0700 (PDT) Received: from 201-255-10-157.mrse.com.ar (unknown [201.255.10.157]) by core3.amsl.com (Postfix) with SMTP id D157F3A6B80; Mon, 19 May 2008 17:42:28 -0700 (PDT) X-Originating-IP: 122.170.12.31 by smtp.201.255.10.157; Mon, 19 May 2008 20:42:30 -0500 Message-ID: From: "Drew Lay" Reply-To: "Drew Lay" To: provreg-archive@megatron.ietf.org Subject: One of a kind replicas Date: Mon, 19 May 2008 20:42:30 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://myguwysecok03.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://myguwysecok03.blogspot.com/ From c.lemmens@isec.heldb.be Tue May 20 03:41: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 0D0B528C1B3; Tue, 20 May 2008 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.695 X-Spam-Level: X-Spam-Status: No, score=-6.695 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, 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, SARE_RECV_VIRTUACOMBR=1.193, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 bWd8kuQybHPo; Tue, 20 May 2008 03:41:27 -0700 (PDT) Received: from c935ba04.virtua.com.br (unknown [201.53.186.4]) by core3.amsl.com (Postfix) with SMTP id AAA513A69ED; Tue, 20 May 2008 03:41:09 -0700 (PDT) X-Originating-IP: 187.50.88.59 by smtp.201.53.186.4; Tue, 20 May 2008 06:41:09 -0500 Message-ID: From: "Socorro Pearson" Reply-To: "Socorro Pearson" To: ut.sale@ietf.org Subject: New replica watches delivered fast Date: Tue, 20 May 2008 06:41:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://www.acoskke.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://www.acoskke.com/ From c.vandervoort@actus.be Tue May 20 21:22: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 4D06F3A67B2; Tue, 20 May 2008 21:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_EQ_MODEMCABLE=0.768, 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_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 Fi35lxdIIBOQ; Tue, 20 May 2008 21:22:20 -0700 (PDT) Received: from Dynamic-IP-1908411957.cable.net.co (unknown [190.84.119.57]) by core3.amsl.com (Postfix) with SMTP id C898A3A67A1; Tue, 20 May 2008 21:22:15 -0700 (PDT) X-Originating-IP: 0.48.38.88 by smtp.190.84.119.57; Wed, 21 May 2008 00:22:18 -0500 Message-ID: From: "Katherine Bingham" Reply-To: "Katherine Bingham" To: provreg-archive@megatron.ietf.org Subject: You and a Rolex watch Date: Wed, 21 May 2008 00:22:18 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080520-1, 20/05/2008), Outbound message X-Antivirus-Status: Clean Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://www.adieks.com/ From owner-v6ops@ops.ietf.org Wed May 21 07:25: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 9C7A93A69B0 for ; Wed, 21 May 2008 07:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, 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 gYHh4-GLVOe8 for ; Wed, 21 May 2008 07:25:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C23E28C0F8 for ; Wed, 21 May 2008 07:25:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jyp6S-000OgA-2m for v6ops-data@psg.com; Wed, 21 May 2008 14:15:40 +0000 Received: from [216.254.141.179] (helo=mail-09.primus.ca) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jyp5s-000OZV-O5 for v6ops@ops.ietf.org; Wed, 21 May 2008 14:15:21 +0000 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jyp5r-0001rg-2P for v6ops@ops.ietf.org; Wed, 21 May 2008 10:15:03 -0400 Message-Id: <09E3E900-0058-4D5D-BC43-2B6CB244CE9E@magma.ca> From: Philip Matthews To: v6ops In-Reply-To: <20080513233001.301873A6854@core3.amsl.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: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Wed, 21 May 2008 10:15:00 -0400 References: <20080513233001.301873A6854@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some comments on this draft, from the perspective of someone familiar with the various BEHAVE documents. * R6 lists TCP, UDP, ICMP, and TLS as protocols to be supported. I am surprised that TLS is listed in addition to TCP, since full TCP support would imply TLS. I am also surprised that DTLS is not listed, if listing TLS is seen as necessary. Any explanation for this? * R7 lists the BEHAVE requirement documents for TCP and UDP. Is there some reason for not listing the BEHAVE requirement document for ICMP? * R8 talks about fragmented packets. Is there some reason to include this specifically, given that the BEHAVE requirements cover fragmentation in some detail? The BEHAVE requirements do not mention the 5 second stuff, but they talk about out-of-order fragments which R8 does not mention. * I6 and I7 talk about SCTP and DCCP support. Is it acceptable to support these by transporting them over UDP? * I8 talks about multicast. Should multicast support comply with the BEHAVE requirement document for multicast? * A (long) comment on R2. There is a class of applications that work today through NAT44s. As a general rule, these are applications that do not carry addresses embedded inside protocol messages, and have communication initiated by the host behind the NAT. Is this the same class of applications that should be supported by the proposed translation mechanism? Code in a NAT that recognizes packets of a specific application protocol and does special processing of that packet is known as an ALG (Application Level Gateway). The BEHAVE group considers an FTP ALG to be acceptable, because FTP was there before NATs, but other ALGs are discouraged (= default off). Is this rule consistent with the proposed transition mechanism? This rule is given in RFC 4787, which R7 says the mechanism must comply with. If so, is R2 an attempt to formalize all this in different words? - Philip On Tue, 13-May-08, at 19:30 , Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of > the IETF. > > > Title : IPv4/IPv6 Coexistence and Transition: > Requirements for solutions > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt > Pages : 17 > Date : 2008-05-13 > > 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-ietf-v6ops-nat64-pb-statement-req-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-v6ops@ops.ietf.org Wed May 21 07:38: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 A460E3A6AB2 for ; Wed, 21 May 2008 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.475, 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 MEsRV3rt-kud for ; Wed, 21 May 2008 07:38:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8A433A6A88 for ; Wed, 21 May 2008 07:38:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JypQR-0001ga-IW for v6ops-data@psg.com; Wed, 21 May 2008 14:36:19 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JypQG-0001fE-S0 for v6ops@ops.ietf.org; Wed, 21 May 2008 14:36:14 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 2A4D23EA0E5; Wed, 21 May 2008 16:36:08 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id D429F3EA0B6; Wed, 21 May 2008 16:36:07 +0200 (CEST) Message-ID: <48343360.1090505@free.fr> Date: Wed, 21 May 2008 16:36:16 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> In-Reply-To: <482B5E3C.5000302@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk marcelo bagnulo braun wrote : > During some of the discussion, for instance during the one on DNSSec, > people have expressed that they don't feel that we need to require > DNSSec support for v4 initiated communications cause these where not > relevant. > > So, i guess we need to define this > > comments? IMO, trying to propose solutions for v4 initiated communications at the same time as those for v6 initiated ones, would result into counterproductive delays. Rationale: - Dual stack hosts that have v6 connectivity and no public v4 address, and that have to reach legacy v4-only servers, should have a better solution than through cascaded v4-to-v4 NATs. - Dual stack hosts that have v4 addresses will most probably get also v6 connectivity (possibly trough tunnels) well before v4 to v6 NATs can be specified, implemented and deployed. Regards. Rémi From c76410ac@nijiyamarket.com Wed May 21 11:00: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 AF8A128C216; Wed, 21 May 2008 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, 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 xhHUqPL7tzfa; Wed, 21 May 2008 11:00:34 -0700 (PDT) Received: from cable201-233-159-41.epm.net.co (cable201-233-159-41.epm.net.co [201.233.159.41]) by core3.amsl.com (Postfix) with SMTP id 6983328C210; Wed, 21 May 2008 11:00:27 -0700 (PDT) X-Originating-IP: 228.84.233.85 by smtp.201.233.159.41; Wed, 21 May 2008 14:00:33 -0500 Message-ID: From: "Verna Maynard" Reply-To: "Verna Maynard" To: provreg-archive@megatron.ietf.org Subject: Take a look at the latest replica watches Date: Wed, 21 May 2008 14:00:33 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www.adieks.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www.adieks.com/ From c.kovar@stamberg.at Wed May 21 19:37: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 662CF3A688B; Wed, 21 May 2008 19:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, 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_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 oO4HvEDAV3sE; Wed, 21 May 2008 19:37:43 -0700 (PDT) Received: from adsl190-25124050.dyn.etb.net.co (unknown [190.25.124.50]) by core3.amsl.com (Postfix) with SMTP id 31F293A6A17; Wed, 21 May 2008 19:37:26 -0700 (PDT) X-Originating-IP: 92.148.254.229 by smtp.190.25.124.50; Wed, 21 May 2008 22:37:26 -0500 Message-ID: From: "Rex Aldridge" Reply-To: "Rex Aldridge" To: tools-discuss@ietf.org Subject: Save thousands... no one will know Date: Wed, 21 May 2008 22:37:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www.oidoido.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www.oidoido.com/ From owner-v6ops@ops.ietf.org Wed May 21 20:04: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 F2BDA3A6882 for ; Wed, 21 May 2008 20:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.987, 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 FxFvpRN9602L for ; Wed, 21 May 2008 20:04:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 001933A684E for ; Wed, 21 May 2008 20:04:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jz0z5-0007ZT-Qz for v6ops-data@psg.com; Thu, 22 May 2008 02:56:51 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jz0yv-0007YB-3m for v6ops@ops.ietf.org; Thu, 22 May 2008 02:56:46 +0000 Received: by wa-out-1112.google.com with SMTP id j37so3277322waf.23 for ; Wed, 21 May 2008 19:56:40 -0700 (PDT) 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=vW8KWYw73Lu+P06rbkW4gdGexbF3nVtoPOcaIJQA+UM=; b=PL+PTsjHKxSeoBIW7ltLYP1vUlyo7Z10tLaf2xXBqUmWLy0Ewo3+FVlT0u6Kq9kMbG2hERwMEhlQfSG1Go05ZTV50KJVhPgR2dzysOAQbVWA4PCV1egtu/xo6KtTHzNjJxoZiN84zmfNZFd/EdA/QAJ+SCASeYpfkH79SF5dEt0= 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=m01xqGCvWQ+BTK+lyOVMPwck+7I+LYyKZvYaGiUG+ZfBQGffiszc7RrnxK5MjWLfsjguggm06nBoQ1fYNxAlByt/11bQU9UKDmwzHIJ3KnI+ZKdV8rbm80ZrdtwWzjh1VxLg9yXkM4L7wM3BCE+MlWREpryhXAVaH6LUnpcj+W4= Received: by 10.114.94.1 with SMTP id r1mr11473715wab.31.1211424999244; Wed, 21 May 2008 19:56:39 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l36sm7046556waf.45.2008.05.21.19.56.38 (version=SSLv3 cipher=RC4-MD5); Wed, 21 May 2008 19:56:38 -0700 (PDT) Message-ID: <4834E0E3.9030507@gmail.com> Date: Thu, 22 May 2008 14:56:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com CC: marcelo@it.uc3m.es, v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> <482C05A6.4070404@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Teemu, On 2008-05-16 02:08, teemu.savolainen@nokia.com wrote: ... > > Excluding RFC2766 NAT-PT kind of single box solutions (is there others > than RFC2766?), all actually implement two (or more) logical boxes - one > near/on the v6 host and one further away with IPv4 interface (all > tunneling solutions, and also NATv4v6v4 and MNAT-PT), right? > > The "I2: operational flexibility" says that "It should be possible to > locate the translation device at an arbitrary point in the network (i.e. > not at fixed points such as a site exit), so that there is full > operational flexibility.". I would read that sentence so that if the > "translation device" is actually two logical functions, then the other > end can locate inside the v6 host as well (i.e. between the small > internal v4 world and v6 world), if seen useful from operational > flexibility point of view. The other end of course is located in some > other device which has global IPv4 interface. If you are still thinking of a mobile device that is acting as an interworking unit between a local IPv4 network and an IPv6 world, it seems to me you are loading it up with CPU and memory and battery power needs that are unreasonable. I agree that we shouldn't restrict where the various functions can be placed, but it seems desirable to minimise what is needed in mobile devices. Brian From owner-v6ops@ops.ietf.org Thu May 22 01:05: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 E2E113A6AD3 for ; Thu, 22 May 2008 01:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.877 X-Spam-Level: X-Spam-Status: No, score=-3.877 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 bOdiPLPRhtRw for ; Thu, 22 May 2008 01:05:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F26383A6AD9 for ; Thu, 22 May 2008 01:05:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jz5fH-000MGC-UX for v6ops-data@psg.com; Thu, 22 May 2008 07:56:43 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jz5ea-000M8O-Ve for v6ops@ops.ietf.org; Thu, 22 May 2008 07:56:23 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4M7tSA0016766; Thu, 22 May 2008 02:55:50 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 May 2008 10:55:48 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 May 2008 10:55:47 +0300 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: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Thu, 22 May 2008 10:55:46 +0300 Message-ID: In-Reply-To: <4834E0E3.9030507@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: Aci7t3u5JHJPFXBEQTqtGH88R3uIVgAG7JjA References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> <482C05A6.4070404@it.uc3m.es> <4834E0E3.9030507@gmail.com> From: To: Cc: , X-OriginalArrivalTime: 22 May 2008 07:55:47.0412 (UTC) FILETIME=[3EB4A140:01C8BBE1] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk =20 >If you are still thinking of a mobile device that is acting as=20 >an interworking unit between a local IPv4 network and an IPv6=20 >world, it seems to me you are loading it up with CPU and=20 >memory and battery power needs that are unreasonable. I agree=20 On mobile the resource needs for NATting/translating are not very significant when compared to resources needed to transmit data (e.g. video) on WLAN/HSPA/EVDO/LTE/WiMAX speeds at the first place (or having a VPN for encryption for those speeds, which is a supported feature on some products). There are already cellular phones on market that come with DHCP server and NAT for IPv4->IPv4 case (Bluetooth PAN->cellular). There are also companies implementing software for cellular WLAN hot-spot kind of features, see e.g.: - JoikuSpot http://www.joikuspot.com/ (free) - Walkinghotspot http://www.walkinghotspot.com/ Generally the power consumption with high data rates is a significant factor and an area of constant research/optimization. However, if people have to choose between not to have a high speed data access at all, or have a high speed data access for half a day or so when running on battery and indefinitely when near mains, they choose to have the feature. The keep-alives are the biggest problem as they eat the standby time without giving clear benefits for users. I also tend to believe that people do most of the data transmission when they are rather still and near mains - e.g. at visited office, at home, at summer cottage, or e.g. in train (in Finland the better trains have power available on certain seats).=20 Furthermore, the mobile device does not necessarily have to be handheld, it can be an USB-stick which gets power from PC, or it can be a fixed device e.g. in a car/bus/table that acts as WLAN AP for nearby devices and uses cellular network as WAN.=20 An alternative is to make mobile devices IPv6-only, but that would introduce flag-day kind of problems: - convince people that they should upgrade their old IPv4-only applications/devices (is this really a possibility?) - place the burden of doing IPv4-over-IPv6 to other devices (e.g. laptops) =3D> this solution has the problem of not-providing-so-nice-transition-experience and also that for some software there might not be IPv6-support available (in time) - an important example is Java MIDP 2.0 runtime environment, which is IPv4-only. MIDP 3 is bringing IPv6 support (optional), but that is not yet approved standard. I.e. if transition would happen by large next year, we probably would have to provide support for IPv4-only devices, applications and run-time environments, but maybe 5 years from now different approach would be possible. >that we shouldn't restrict where the various functions can be=20 >placed, but it seems desirable to minimise what is needed in=20 >mobile devices. True, but if IPv6-only is not practical option (see above), is native dual-stack (for mobile device, for last-mile) always the most cost-efficient solution?=20 Consider a cellular operator with 100 million customers needing simultaneous network connectivity. Which is the cheapest architecture for them (I don't know the right answer): 1) provide native dual-stack air interface ("last mile")=20 2) provide translator box (e.g. NAT-PT, MNAT-PT, NATv4v6v4) 3) provide static tunneling (e.g. configured tunnels (via provisioning), SNAT, VPN, DSMIP) 4) provide dynamic tunneling (e.g. TSP) 1) requires resources for transmitting both address families over the air interface/last mile. These resources include at least IPv4 address, plus in some technologies also more resources from the first hop router (in 3GPP this requires two parallel PDP contexts and thus more powerful/costly GGSN). The IPv4 address could be conserved by on-demand reservation, but if the on-demand reservation requries closing/opening link-layers (e.g. PDP contexts) and thus brings in latencies, does that provide good user experience? 2) Don't these require ALG support for either NAT-PT box, or also on the mobile host in case MNAT-PT/NATv4v6v4 is implemented there? E.g. even if application uses synthetic IPv4 source address and thus knows there is a NAT on the path, the "client-side" of MNAT-PT/NATv4v6v4 needs to implement IPv4->IPv6 ALG? (in the original NAT-PT this ALG would be only on the NAT-PT box). ALG implementation burden to all mobile devices does not sound very attractive. 3) Has the biggest header overhead and also requires IPv4 address. I believe these solutions also introduce biggest requirements for tunnel endpoint performance?=20 4) Aren't these kind of solutions performance-wise most optimal? No NAT, no ALG, and the tunnel-endpoint load is the lowest? I would be happy if we would end up with just a single solution, but I think we may need several for different deployment scenarios (which are the used access technologies, how many simultaneous customers need to be served, how heavily IPv4 addresses need to be conserved) and for different moments of time (what is the level of IPv6-support in softwares/hardwares/services).=20 E.g.=20 1) dual-stack could be a solution for home deployments (DSL/hotspot-style, from CPE box to LAN) 2) translators for further in the future when IPv6 is widely supported by applications/devices 3) static tunneling for more demanding use-cases such as where public IPv4 address is required, for enterprises VPN uses, where mobility is required, or for infrastructure (e.g. used to provide IPv4 connectivity to that CPE box/WLAN hot-post) 4) dynamic tunneling for cases where subscriber base is very large and IPv4 applications/devices that need to be supported are many? Best regards, Teemu From owner-v6ops@ops.ietf.org Thu May 22 06:14:08 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 D0C5A28C285 for ; Thu, 22 May 2008 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.417, 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 ZwZ2buAwX0CB for ; Thu, 22 May 2008 06:14:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2C6C28C259 for ; Thu, 22 May 2008 06:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JzAVB-000CxP-Fc for v6ops-data@psg.com; Thu, 22 May 2008 13:06:37 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JzAUi-000CtE-1a for v6ops@ops.ietf.org; Thu, 22 May 2008 13:06:22 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7E6A43EA0DD; Thu, 22 May 2008 15:06:06 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id B06F13EA0E3; Thu, 22 May 2008 15:06:05 +0200 (CEST) Message-ID: <48356FC6.6030901@free.fr> Date: Thu, 22 May 2008 15:06:14 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marcelo Bagnulo CC: v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> In-Reply-To: <20080513233001.301873A6854@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Marcelo, The scope of the draft being (quite rightly) comprehensive, a mention of scenarios based on APBP should IMU be included. These scenarios fit in: - the 3rd scenario of section 2.1 (an IPv4 system connecting to an IPv4 system across an IPv6 network), - the 6th scenario (IPv6 system connecting to an IPv4 system), Their raison d'être is that, unlike those described in section 2.1.3, they DO NOT require any NAT64. (Explanations on APBP, address-port-borrowing-protocol, are in http://www.ietf.org/internet-drafts/draft-despres-v6ops-apbp-00.txt.) This complement could be inserted, for example, as follows: (A) Title 2.1.2 becomes: "2.1.2 Transition scenarios that do not require NAT64 2.1.2.1 Tunnel scenarios" (B) Title 2.1.3 becomes: "2.1.2.2 Address-port-borrowing-protocol scenarios 2.1.3 Transition scenarios that do not require NAT64" If the principle has some support, I can work on a text for the new section 2.1.2.2. Regards Rémi From c.wisse@carlas-dance-studio.nl Thu May 22 12:05: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 F38383A6BC9; Thu, 22 May 2008 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.626 X-Spam-Level: X-Spam-Status: No, score=-72.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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_DSL=1.129, 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, 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 S+Os9bSMhRoD; Thu, 22 May 2008 12:05:25 -0700 (PDT) Received: from 39-141-223-201.adsl.terra.cl (39-141-223-201.adsl.terra.cl [201.223.141.39]) by core3.amsl.com (Postfix) with SMTP id 4835728C1C8; Thu, 22 May 2008 12:02:46 -0700 (PDT) X-Originating-IP: 252.116.10.245 by smtp.201.223.141.39; Thu, 22 May 2008 15:02:47 -0500 Message-ID: From: "Marcella Camp" Reply-To: "Marcella Camp" To: provreg-archive@megatron.ietf.org Subject: Watches for him, her and you Date: Thu, 22 May 2008 15:02:47 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://gisoxugihyd16.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://gisoxugihyd16.blogspot.com/ From cab@nic.txnet.de Fri May 23 00:14: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 C0C573A6C75; Fri, 23 May 2008 00:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.439 X-Spam-Level: X-Spam-Status: No, score=-78.439 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, 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 j6WUmikAQYYH; Fri, 23 May 2008 00:14:36 -0700 (PDT) Received: from 201-255-187-152.mrse.com.ar (unknown [201.255.187.152]) by core3.amsl.com (Postfix) with SMTP id 33AC528C235; Fri, 23 May 2008 00:13:28 -0700 (PDT) X-Originating-IP: 178.234.218.120 by smtp.201.255.187.152; Fri, 23 May 2008 03:13:21 -0500 Message-ID: From: "Houston Golden" Reply-To: "Houston Golden" To: tools-discuss@ietf.org Subject: Inexpensive IWC watches Date: Fri, 23 May 2008 03:13:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://doneroxalew66.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://doneroxalew66.blogspot.com/ From cacton@afscmecouncil92.org Fri May 23 03:24: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 5AF6A3A6BB0; Fri, 23 May 2008 03:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.67 X-Spam-Level: * X-Spam-Status: No, score=1.67 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, 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_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, 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, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, 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 WaCvqDXTq97s; Fri, 23 May 2008 03:24:24 -0700 (PDT) Received: from ppp-124-121-200-158.revip2.asianet.co.th (ppp-124-121-200-158.revip2.asianet.co.th [124.121.200.158]) by core3.amsl.com (Postfix) with SMTP id 57B7B3A6C7A; Fri, 23 May 2008 03:24:12 -0700 (PDT) X-Originating-IP: 105.184.2.74 by smtp.124.121.200.158; Fri, 23 May 2008 06:24:12 -0500 Message-ID: From: "Russel Wooten" Reply-To: "Russel Wooten" To: provreg-archive@megatron.ietf.org Subject: Watches for him, her and you Date: Fri, 23 May 2008 06:24:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://www.oidoido.com/ From owner-v6ops@ops.ietf.org Sat May 24 15:55: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 B5B063A68C3 for ; Sat, 24 May 2008 15:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 K9c6J9TDEIxz for ; Sat, 24 May 2008 15:55:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B137B3A68B4 for ; Sat, 24 May 2008 15:55:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K02Ut-000761-GX for v6ops-data@psg.com; Sat, 24 May 2008 22:45:55 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K02Ue-00074I-Pn for v6ops@ops.ietf.org; Sat, 24 May 2008 22:45:49 +0000 Received: from [192.168.2.13] (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 m4OMhwFd012118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 May 2008 00:44:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: IPv6 Operations Message-Id: From: Iljitsch van Beijnum To: "" 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 v919.2) Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Sun, 25 May 2008 00:44:06 +0200 References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> X-Mailer: Apple Mail (2.919.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 15 mei 2008, at 10:29, wrote: > > In cellular environments it can actually be the mobile phone that is > provided IPv6-only connectivity by the network, and the mobile needs > to act the role of CPE (to be more exact, the mobile with IPv6-only > connectivity may be running IPv4-only apps and it may have IPv4 LAN > behind it, for which mobile needs to provide (NATted) addresses). [...] > - Availability of translation mechanism service SHOULD be quickly > discoverable > - Legacy IPv4-only applications on IPv6-nodes MUST continue working The problem with IPv4-only applications in an IPv6 world is that there is no way to encode all possible IPv6 destinations into an IPv4 header. However, the case where the ultimate destination is also IPv4 and it's just the network in the middle that's IPv4 is much easier. In a previous modified-nat-pt draft I wrote about the v4-v6-v4 case where IPv4 clients sit behind a CPE or layer in the stack that translates their IPv4 packets into IPv6 packets using SIIT (= stateless) and then the resulting IPv6 packets flow through the same NAT64 translators that IPv6 hosts that want to talk to the IPv4 world also use. Expect to see a new or updated draft on this topic before Dublin. I'm currently looking at defining a new DHCPv6 option that would allow NAT464 devices/layers to discover the 96 upper bits used by the NAT64 translator. Would DHCPv6 be fast enough for your use case? In a mobile environment, a NAT464 could obtain a new /96 for a new translator when it moves and send new sessions through the new translator while existing sessions keep using the previous translator. This is not ideal from a BEHAVE viewpoint but it would allow for a reasonable amount of route optimization without breaking too much stuff. From cactus@cactushealth.com Sun May 25 05:22: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 685B33A6A2C; Sun, 25 May 2008 05:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, 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_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTTP_ESCAPED_HOST=0.134, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 IrygahiBfmPa; Sun, 25 May 2008 05:22:43 -0700 (PDT) Received: from cm-85-152-181-205.telecable.es (cm-85-152-181-205.telecable.es [85.152.181.205]) by core3.amsl.com (Postfix) with SMTP id 9CD193A6A99; Sun, 25 May 2008 05:22:35 -0700 (PDT) X-Originating-IP: 78.193.8.144 by smtp.85.152.181.205; Sun, 25 May 2008 08:22:39 -0500 Message-ID: From: "Ora Leon" Reply-To: "Ora Leon" To: tools-discuss@ietf.org Subject: Watches made to impress Date: Sun, 25 May 2008 08:22:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit How about making your friends jealous and saving a lot of money doing it? Forget about spending thousands of dollars on a new Rolex watch! Instead, visit the newly redesigned Prestige Replicas and buy yourself a beautiful, one of a kind Rolex Datejust watch! http://www%2Esuppoenn%2Ecom/ Of course, we're talking about replica watches, not the overpriced originals... After all, our Rolex Datejusts offer the same precise functionality and exact look than their costly counterparts, but you can buy yours for just a couple of hundred bucks. So, come aboard Prestige Replicas and take advantage of our extensive collection of replica Rolex watches, our superb customer service and our super low prices! http://www%2Esuppoenn%2Ecom/ From c.knight@ds-redesign.co.uk Sun May 25 12:52: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 E79AD3A67AA; Sun, 25 May 2008 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.359 X-Spam-Level: X-Spam-Status: No, score=-11.359 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 fbWzmDveIvwH; Sun, 25 May 2008 12:52:39 -0700 (PDT) Received: from r190-135-10-220.dialup.adsl.anteldata.net.uy (r190-135-10-220.dialup.adsl.anteldata.net.uy [190.135.10.220]) by core3.amsl.com (Postfix) with SMTP id AB40C3A676A; Sun, 25 May 2008 12:52:25 -0700 (PDT) X-Originating-IP: 159.116.19.234 by smtp.190.135.10.220; Sun, 25 May 2008 15:52:38 -0500 Message-ID: From: "Elisabeth Aldrich" Reply-To: "Elisabeth Aldrich" To: provreg-archive@megatron.ietf.org Subject: Get one of these awesome replicas Date: Sun, 25 May 2008 15:52:38 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www%2Esuppoenn%2Ecom/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www%2Esuppoenn%2Ecom/ From c.ryan@aquatecinc.com Sun May 25 17:02: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 6471D3A6989; Sun, 25 May 2008 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.044 X-Spam-Level: X-Spam-Status: No, score=-7.044 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 9F3hRs-VNBkj; Sun, 25 May 2008 17:02:08 -0700 (PDT) Received: from 190-48-137-165.speedy.com.ar (unknown [190.48.137.165]) by core3.amsl.com (Postfix) with SMTP id F21933A6A05; Sun, 25 May 2008 17:01:56 -0700 (PDT) X-Originating-IP: 52.142.66.87 by smtp.190.48.137.165; Sun, 25 May 2008 20:02:07 -0500 Message-ID: From: "Belinda Blanco" Reply-To: "Belinda Blanco" To: tools-discuss@ietf.org Subject: Hot replica watches from 2008 Date: Sun, 25 May 2008 20:02:07 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Esuppoenn%2Ecom/ From cabas@flaviomoccia.com Sun May 25 22:53: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 D928B3A68BE; Sun, 25 May 2008 22:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.814 X-Spam-Level: X-Spam-Status: No, score=-3.814 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 d+lXdQiG6Jdy; Sun, 25 May 2008 22:53:23 -0700 (PDT) Received: from dup-148-221-123-5.prodigy.net.mx (dup-148-221-123-5.prodigy.net.mx [148.221.123.5]) by core3.amsl.com (Postfix) with SMTP id 4BB7D3A6895; Sun, 25 May 2008 22:51:50 -0700 (PDT) X-Originating-IP: 168.216.222.106 by smtp.148.221.123.5; Mon, 26 May 2008 01:51:55 -0500 Message-ID: From: "Nina Mcclendon" Reply-To: "Nina Mcclendon" To: ut.sale@ietf.org Subject: Looking for a replica watch? Date: Mon, 26 May 2008 01:51:55 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://www%2Eacoskke%2Ecom/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://www%2Eacoskke%2Ecom/ From rt{rtida1989@IBD.TRAVELOCITY.COM Mon May 26 03:24: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 673253A6B7A for ; Mon, 26 May 2008 03:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.978 X-Spam-Level: X-Spam-Status: No, score=-38.978 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FM_SEX_HELODDDD=10.357, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.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, 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 YkRAHT2WF32z for ; Mon, 26 May 2008 03:24:48 -0700 (PDT) Received: from host-92-5-25-199.as43234.net (unknown [92.5.25.199]) by core3.amsl.com (Postfix) with ESMTP id 155993A683E for ; Mon, 26 May 2008 03:24:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 26 May 2008 11:24:46 +0100 Subject: Give her your best shot From: Jovan To: "v6ops-archive@megatron.ietf.org" Message-ID: Thread-Topic: Give her your best shot Thread-Index: Aci/IxpaYBMeJ2hjQxGnExds/4Vkuw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_1810638218_75071" --B_1810638218_75071 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit They just cannot get enough and won't stop moaning during sex now http://www.stavent.com/ --B_1810638218_75071 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Give her your best shot They just cannot get enough and won't stop = moaning during sex now http://www.stavent.com/
 --B_1810638218_75071-- From ruhezust_1974@IBD.TRAVELOCITY.COM Mon May 26 03:25:27 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 BE8AD3A6A37 for ; Mon, 26 May 2008 03:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.978 X-Spam-Level: X-Spam-Status: No, score=-38.978 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FM_SEX_HELODDDD=10.357, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.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, 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 vdxTxrotwepF for ; Mon, 26 May 2008 03:25:27 -0700 (PDT) Received: from host-92-5-25-199.as43234.net (unknown [92.5.25.199]) by core3.amsl.com (Postfix) with ESMTP id 87D383A683E for ; Mon, 26 May 2008 03:25:26 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 26 May 2008 11:25:25 +0100 Subject: Give her your best shot From: Quinlan To: "v6ops-archive@ietf.org" Message-ID: Thread-Topic: Give her your best shot Thread-Index: Aci/IzFdYWnUyZSWQx+FzHJevdezHw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_6230590322_90025" --B_6230590322_90025 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit They just cannot get enough and won't stop moaning during sex now http://www.craempp.com/ --B_6230590322_90025 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Give her your best shot They just cannot get enough and won't stop = moaning during sex now http://www.craempp.com/
 --B_6230590322_90025-- From Muir-rucidasi@IBD.TRAVELOCITY.COM Mon May 26 03:28: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 6ECA228C103 for ; Mon, 26 May 2008 03:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -49.335 X-Spam-Level: X-Spam-Status: No, score=-49.335 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.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_SC_SURBL=10, 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 5F-F+km35k09 for ; Mon, 26 May 2008 03:28:37 -0700 (PDT) Received: from host-92-5-25-199.as43234.net (unknown [92.5.25.199]) by core3.amsl.com (Postfix) with ESMTP id 33C0428C110 for ; Mon, 26 May 2008 03:28:37 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 26 May 2008 11:28:35 +0100 Subject: guaranteed growth for all customers From: Muir To: "v6ops-archive@lists.ietf.org" Message-ID: <76B9B0DD.5%Muir-rucidasi@IBD.TRAVELOCITY.COM> Thread-Topic: guaranteed growth for all customers Thread-Index: Aci/I6MFfQBlRw1gR9mZrB90ZdvtdA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3907625043_99076" --B_3907625043_99076 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Medical research has shown that just taking our herbal forumlations will cause an increase in size http://www.Dracaye.com/ --B_3907625043_99076 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable guaranteed growth for all customers Medical research has shown that just taking our = herbal forumlations will cause an increase in size http://www.Dracaye.com/
 --B_3907625043_99076-- From c21nea@mail.maine.rr.com Mon May 26 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 530B53A6BF6; Mon, 26 May 2008 12:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.648 X-Spam-Level: X-Spam-Status: No, score=-25.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_ESCAPED_HOST=0.134, 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_SPEC_REPLICA_OBFU=1.812, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 FGUfcSQgaxty; Mon, 26 May 2008 12:24:20 -0700 (PDT) Received: from host51-133-dynamic.7-87-r.retail.telecomitalia.it (host51-133-dynamic.7-87-r.retail.telecomitalia.it [87.7.133.51]) by core3.amsl.com (Postfix) with SMTP id 583213A6BF1; Mon, 26 May 2008 12:24:14 -0700 (PDT) X-Originating-IP: 149.238.172.126 by smtp.87.7.133.51; Mon, 26 May 2008 15:24:29 -0500 Message-ID: From: "Allan Tackett" Reply-To: "Allan Tackett" To: provreg-archive@megatron.ietf.org Subject: 15% off on two watches Date: Mon, 26 May 2008 15:24:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080526-0, 26/05/2008), Outbound message X-Antivirus-Status: Clean Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eselissia%2Ecom/ From c.stadler@stadler-willi.de Mon May 26 21:54: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 132F93A6AEC; Mon, 26 May 2008 21:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.581 X-Spam-Level: X-Spam-Status: No, score=-9.581 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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_IPADDR=2.426, HTTP_ESCAPED_HOST=0.134, 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_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 It76Leilyktf; Mon, 26 May 2008 21:54:30 -0700 (PDT) Received: from pc-195-145-47-190.cm.vtr.net (pc-195-145-47-190.cm.vtr.net [190.47.145.195]) by core3.amsl.com (Postfix) with SMTP id D157F3A68D1; Mon, 26 May 2008 21:53:32 -0700 (PDT) X-Originating-IP: 97.208.148.224 by smtp.190.47.145.195; Tue, 27 May 2008 00:53:45 -0500 Message-ID: From: "Janine Kinney" Reply-To: "Janine Kinney" To: tools-discuss@ietf.org Subject: 15% off on two watches Date: Tue, 27 May 2008 00:53:45 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://www%2Essedkke%2Ecom/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://www%2Essedkke%2Ecom/ From c.serriere@serriere-deco.com Tue May 27 01:47:58 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 095AC3A67A1; Tue, 27 May 2008 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.875 X-Spam-Level: *** X-Spam-Status: No, score=3.875 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, 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_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_FR=0.35, HTTP_ESCAPED_HOST=0.134, 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, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 rlkojlwzyqzy; Tue, 27 May 2008 01:47:47 -0700 (PDT) Received: from LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr (LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr [193.251.191.146]) by core3.amsl.com (Postfix) with SMTP id A17DA28C236; Tue, 27 May 2008 01:47:27 -0700 (PDT) X-Originating-IP: 185.169.96.205 by smtp.193.251.191.146; Tue, 27 May 2008 04:47:42 -0500 Message-ID: From: "Jeanine Bragg" Reply-To: "Jeanine Bragg" To: provreg-archive@megatron.ietf.org Subject: Save thousands... no one will know Date: Tue, 27 May 2008 04:47:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www%2Enunubsyy%2Ecom/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www%2Enunubsyy%2Ecom/ From c.mayer@sswkampfkuenste.ch Tue May 27 11:54: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 8B9533A690D; Tue, 27 May 2008 11:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.473 X-Spam-Level: X-Spam-Status: No, score=-23.473 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HTTP_ESCAPED_HOST=0.134, 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, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 HTKwl0bHRz7g; Tue, 27 May 2008 11:54:20 -0700 (PDT) Received: from adsl201-244111041.dyn.etb.net.co (unknown [201.244.111.41]) by core3.amsl.com (Postfix) with SMTP id 315913A6C47; Tue, 27 May 2008 11:53:25 -0700 (PDT) X-Originating-IP: 52.202.108.18 by smtp.201.244.111.41; Tue, 27 May 2008 14:53:39 -0500 Message-ID: From: "Genaro Mckinney" Reply-To: "Genaro Mckinney" To: tools-discuss@ietf.org Subject: Why get an original watch? Date: Tue, 27 May 2008 14:53:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://www%2Emiracuole%2Ecom/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://www%2Emiracuole%2Ecom/