From owner-v6ops@ops.ietf.org Mon May 01 12:19:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fab7U-0006nr-JU for v6ops-archive@lists.ietf.org; Mon, 01 May 2006 12:19:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fab7T-0001MD-9e for v6ops-archive@lists.ietf.org; Mon, 01 May 2006 12:19:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fab3B-0001Z7-Sd for v6ops-data@psg.com; Mon, 01 May 2006 16:15:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.78] (helo=test-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fab39-0001YU-VK for v6ops@ops.ietf.org; Mon, 01 May 2006 16:15:03 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 09:15:03 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k41GF3h0005484; Mon, 1 May 2006 09:15:03 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k41GDXlK020289; Mon, 1 May 2006 09:13:33 -0700 In-Reply-To: <4456283A.5030603@isoc.org> References: <4456283A.5030603@isoc.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EADD691-5B22-4FBD-A7C5-8D7A4944D9EB@cisco.com> Cc: Ray Pelletier Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: IETF Meeting Survey Date: Mon, 1 May 2006 09:15:01 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.749.3) DKIM-Signature: a=rsa-sha1; q=dns; l=880; t=1146500013; x=1147364013; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20IETF=20Meeting=20Survey |To:v6ops@ops.ietf.org; X=v=3Dcisco.com=3B=20h=3DO32Nn52FihIckUveA94SILp5ZMU=3D; b=jtK9OVnJJkcc4iHSKCeMI/nxp3mxZB+byUNrjclYMSGUuPUvAAD0RSFFOueyoQYBLuDuGT86 darlsp0NPTz7K9fdo+eBdJ6hrTcWSuTGyg/azBIuwsCb1tn8pOCEu/aj; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Folks: we have been asked for our opinions on the recent IETF meeting. Would you kindly take a look at the survey? On May 1, 2006, at 8:24 AM, Ray Pelletier wrote: > All; > It has been suggested that if I really wanted to get feedback on > the Meeting Survey (and I do) I should have it forwarded by the WG > Chairs to the working groups - so this is a request that you ask > members of the working groups to complete a short survey that > focuses primarily, but not exclusively, on their meeting experience > in Dallas. > I truly want the info to make the changes members of the community > want, if possible and greatly appreciate your assistance in this > regard. > > Those interested in taking the survey can find it at: > http://www.surveymonkey.com/s.asp?u=649182049947 > > Thanks > Ray Pelletier > IETF Admininstrative Director > From owner-v6ops@ops.ietf.org Wed May 03 06:46:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEsP-0007mT-TT for v6ops-archive@lists.ietf.org; Wed, 03 May 2006 06:46:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbEsO-0001Zy-Kf for v6ops-archive@lists.ietf.org; Wed, 03 May 2006 06:46:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbEou-0002fN-Ck for v6ops-data@psg.com; Wed, 03 May 2006 10:43:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbEor-0002f5-GF for v6ops@ops.ietf.org; Wed, 03 May 2006 10:42:57 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k43AgqAt008426 for ; Wed, 3 May 2006 11:42:52 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k43Aghl6015410 for ; Wed, 3 May 2006 11:42:44 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k43Agewf008031 for v6ops@ops.ietf.org; Wed, 3 May 2006 11:42:40 +0100 Date: Wed, 3 May 2006 11:42:40 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: European IPv6 Convergence Event, Vienna, 1st/2nd June Message-ID: <20060503104240.GW2508@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, I'm a bit nervous about sending what may be considered spam to this list, but I feel this is probably the European Commission's biggest IPv6 event of the year, and it has a deployment focus on convergence of services on IPv6, so is relevent to what people are discussing in v6ops. It's in Vienna and free to register/attend, with speakers from all over the world. People on list particularly in Europe may be interested in coming along, if so then there's info and registration details here: http://www.ipv6-convergence-vienna.net/ Cheers, -- Tim/::1 From owner-v6ops@ops.ietf.org Wed May 03 11:29:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJHu-0004Yx-MN for v6ops-archive@lists.ietf.org; Wed, 03 May 2006 11:29:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbJHt-0004hf-8M for v6ops-archive@lists.ietf.org; Wed, 03 May 2006 11:29:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbJEZ-000J1w-Ou for v6ops-data@psg.com; Wed, 03 May 2006 15:25:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbJEY-000J1a-Ml for v6ops@ops.ietf.org; Wed, 03 May 2006 15:25:46 +0000 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 3 May 2006 16:25:44 +0100 (BST) Date: Wed, 3 May 2006 16:25:44 +0100 From: David Malone To: v6ops@ops.ietf.org Subject: Re: European IPv6 Convergence Event, Vienna, 1st/2nd June Message-ID: <20060503152544.GA60387@walton.maths.tcd.ie> References: <20060503104240.GW2508@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060503104240.GW2508@login.ecs.soton.ac.uk> User-Agent: Mutt/1.5.6i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote: > It's in Vienna and free to register/attend, with speakers from all > over the world. I also note that the conference is being streamed, so if you can't make it to Vienna you're not out of luck. David. From owner-v6ops@ops.ietf.org Sun May 07 15:29:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcowg-00086f-GS for v6ops-archive@lists.ietf.org; Sun, 07 May 2006 15:29:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcowf-0004Hy-6o for v6ops-archive@lists.ietf.org; Sun, 07 May 2006 15:29:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FcosA-000Ec9-No for v6ops-data@psg.com; Sun, 07 May 2006 19:24:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fcos9-000Ebj-VX for v6ops@ops.ietf.org; Sun, 07 May 2006 19:24:54 +0000 Received: from dhcp-222-250.ws.afnog.org ([196.200.222.250]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Fcos6-000CTd-NW; Sun, 07 May 2006 19:24:51 +0000 In-Reply-To: <20060503152544.GA60387@walton.maths.tcd.ie> References: <20060503104240.GW2508@login.ecs.soton.ac.uk> <20060503152544.GA60387@walton.maths.tcd.ie> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8093D63A-BF57-4A6F-98D1-6074180308EC@ca.afilias.info> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: European IPv6 Convergence Event, Vienna, 1st/2nd June Date: Sun, 7 May 2006 22:24:41 +0300 To: David Malone X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 3-May-2006, at 18:25 , David Malone wrote: > On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote: >> It's in Vienna and free to register/attend, with speakers from all >> over the world. > > I also note that the conference is being streamed, so if you can't > make it to Vienna you're not out of luck. Is it being streamed over IPv6? From owner-v6ops@ops.ietf.org Mon May 08 06:22:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2sj-0001UM-QZ for v6ops-archive@lists.ietf.org; Mon, 08 May 2006 06:22:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd2sh-0004pN-Ev for v6ops-archive@lists.ietf.org; Mon, 08 May 2006 06:22:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd2pL-00033g-Ix for v6ops-data@psg.com; Mon, 08 May 2006 10:18:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd2pK-00033P-B5 for v6ops@ops.ietf.org; Mon, 08 May 2006 10:18:54 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k48AIowm001428 for ; Mon, 8 May 2006 11:18:50 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k48AIi69024777 for ; Mon, 8 May 2006 11:18:44 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k48AIcBT021799 for v6ops@ops.ietf.org; Mon, 8 May 2006 11:18:38 +0100 Date: Mon, 8 May 2006 11:18:38 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: European IPv6 Convergence Event, Vienna, 1st/2nd June Message-ID: <20060508101838.GO18468@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20060503104240.GW2508@login.ecs.soton.ac.uk> <20060503152544.GA60387@walton.maths.tcd.ie> <8093D63A-BF57-4A6F-98D1-6074180308EC@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8093D63A-BF57-4A6F-98D1-6074180308EC@ca.afilias.info> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Sun, May 07, 2006 at 10:24:41PM +0300, Joe Abley wrote: > > On 3-May-2006, at 18:25 , David Malone wrote: > > >On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote: > >>It's in Vienna and free to register/attend, with speakers from all > >>over the world. > > > >I also note that the conference is being streamed, so if you can't > >make it to Vienna you're not out of luck. > > Is it being streamed over IPv6? At present I believe the Austria Telekom streaming service is v4 only but a v6 facility is being investigated. -- Tim/::1 From owner-v6ops@ops.ietf.org Mon May 08 18:52:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEaw-0000gY-40 for v6ops-archive@lists.ietf.org; Mon, 08 May 2006 18:52:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdEav-0006Fv-Nu for v6ops-archive@lists.ietf.org; Mon, 08 May 2006 18:52:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdEYG-0007mh-D3 for v6ops-data@psg.com; Mon, 08 May 2006 22:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdEYF-0007m6-Fa for v6ops@ops.ietf.org; Mon, 08 May 2006 22:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k48Mo167029463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FdEYD-0006a5-Gl; Mon, 08 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-05.txt Message-Id: Date: Mon, 08 May 2006 18:50:01 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-05.txt Pages : 38 Date : 2006-5-8 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-analysis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-8152106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-8152106.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue May 09 10:30:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdTEC-0003JV-Jg for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 10:30:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdTEB-0003T5-Aw for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 10:30:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdTBa-000Bjr-Er for v6ops-data@psg.com; Tue, 09 May 2006 14:27:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdTBZ-000BjW-81 for v6ops@ops.ietf.org; Tue, 09 May 2006 14:27:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k49ERGu5024874; Tue, 9 May 2006 17:27:16 +0300 Date: Tue, 9 May 2006 17:27:16 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org, v6ops@ops.ietf.org cc: David Woodhouse Subject: RFC3484 problem: scoping with site-locals/ULAs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1451/Tue May 9 02:27:49 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi, I was alerted to a practical deployment problem. As a result Linux glibc has started prefering IPv4 by default... so, I believe we need to find a better solution. 1) v6 site-local address selection problems A site has deployed IPv6 site-local addresses (alongside with NATed v4). They do not have global IPv6 reachability yet, but want to test IPv6 alongside IPv4 internally. As a result, RFC 3484 address selection breaks: when trying to connect to a hostname with a public IPv4 and IPv6 address, the host will first try v6 fails (incurring about 3 min TCP timeout if ICMP error is not sent), and after that connects to the v4 address. I.e., 'prefer matching scope' has v6 globals and site-locals, while v4 has globals and private v4 addresses, and v6 wins, with bad results. An easy fix could be that v4 is preferable to v6 if both have mismatching scope as v4 is likely to be NATed while v6 isn't. Has anyone else run into this problem? Is there something I'm missing? What has been the implementation (or deployment) approach here? (I don't believe using RFC 4191 to advertise only the site-local prefix instead of a default route is a feasible solution here. Likewise, requiring that routers will always send back an ICMP error and the host gets it and honors it seems unfeasible in general.) 2) v6 ULA address selection problems Deploying ULAs doesn't help here, it just makes the problem worse as you couldn't even use the 'matching scope' tweak. Do we need to specify that v6 ULAs should be treated as "site scope" for the purposes of default address selection, or something else? Note that I do not believe it's sufficient to require that each site (and each host within the site) deploys non-default RFC3484 policies. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue May 09 11:42:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUMH-00006Q-VN for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 11:42:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUMG-00077R-KW for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 11:42:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdUKa-000Jzi-D4 for v6ops-data@psg.com; Tue, 09 May 2006 15:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.186.42.179] (helo=26.mail-out.ovh.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdUKW-000Jz0-Jy for v6ops@ops.ietf.org; Tue, 09 May 2006 15:40:56 +0000 Received: (qmail 6611 invoked by uid 503); 9 May 2006 15:41:01 -0000 Received: (QMFILT: 1.0); 09 May 2006 15:41:01 -0000 Received: from b6.ovh.net (HELO mail12.ha.ovh.net) (213.186.33.56) by 26.mail-out.ovh.net with SMTP; 9 May 2006 15:41:01 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 9 May 2006 15:40:52 -0000 Received: from mail12.ha.ovh.net (10.0.50.12) by mail12.ha.ovh.net with SMTP; 9 May 2006 15:40:36 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 9 May 2006 15:32:27 -0000 Received: from st3-1-3.tky.hut.fi (postmaster%simphalempin.com@130.233.27.57) by ns0.ovh.net with SMTP; 9 May 2006 15:32:27 -0000 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: SimPhalempin.Com To: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: RFC3484 problem: scoping with site-locals/ULAs Date: Tue, 9 May 2006 18:32:15 +0300 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2485556.PM8dk6dLAU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605091832.23221@auguste.remlab.net> X-Ovh-Remote: 130.233.27.57 (st3-1-3.tky.hut.fi) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --nextPart2485556.PM8dk6dLAU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le Mardi 9 Mai 2006 17:27, Pekka Savola a =C3=A9crit : > 1) v6 site-local address selection problems I assume you refer to the deprecated but Linux kernel-supported=20 site-local fec0::/12 address space (not sure if it is /12 - but=20 anyway). > A site has deployed IPv6 site-local addresses (alongside with NATed > v4). They do not have global IPv6 reachability yet, but want to test > IPv6 alongside IPv4 internally. > As a result, RFC 3484 address selection breaks: when trying to > connect to a hostname with a public IPv4 and IPv6 address, the host > will first try v6 fails (incurring about 3 min TCP timeout if ICMP > error is not sent), and after that connects to the v4 address. I am pretty sure it used to work =E2=80=9Cproperly=E2=80=9D... when trying = to connect()=20 to some public IPv6 address while the host only had link-local and=20 site-local addresses, the stack would immediatly (non-blocking) address=20 unreachable. Then software using the getaddrinfo() paradigm would=20 fallback to IPv4 without the user noticing any delay. But then indeed,=20 it seems to be now broken. > 2) v6 ULA address selection problems > > Deploying ULAs doesn't help here, it just makes the problem worse as > you couldn't even use the 'matching scope' tweak. Yes, I definitely have had these issues. Since ULA have global scope,=20 there is no way to detect the issue there. Another (Linux-specific) issue is that source address selection is=20 completely broken, so if you have both public addresses and ULAs on the=20 host, the stack might be an ULA (non-routable!) address as source when=20 sending packets toward a public address. But that, I guess, it because=20 Linux does not implement source address selection properly. That said I don't think defaulting to IPv4 in libc is wise, and it will=20 actually break in other case. Linux users should probably rather=20 refrain from using ULAs until their OS supports them properly. I'm actually pretty sure some apps rely on getaddrinfo() returning=20 AF_INET6 entries before AF_INET. Inverting the ordering might cause=20 serious troubles there. This is ***definitely*** going to break listening TCP socket=20 applications that relied on IPv6-mapped IPv4 addresses to catch both IP=20 protocol versions with a single socket. This includes noteworthy Apache=20 httpd 2 and OpenSSH, and probably a bunch of other server apps. This=20 could, to a lesser extent also affect the UDP and =E2=80=9Coutgoing=E2=80= =9D TCP=20 cases... in fact, whenever one uses IPv6-mapped IPv4 addresses. =2D-=20 R=C3=A9mi Denis-Courmont http://www.simphalempin.com/home/ --nextPart2485556.PM8dk6dLAU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEYLYHw+xtvt1tEr0RAgXOAKDAZ+jIoMuXhQ5Jh4jasGkHKwdtHgCfVuSu IeI5yo2weMCc3ulrU9vh/CM= =uf0w -----END PGP SIGNATURE----- --nextPart2485556.PM8dk6dLAU-- From owner-v6ops@ops.ietf.org Tue May 09 16:24:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYl4-0002P2-9T for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 16:24:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYl1-0003uY-VK for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 16:24:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdYit-000Ir3-RL for v6ops-data@psg.com; Tue, 09 May 2006 20:22:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [204.127.192.83] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdYis-000Iqk-UR for v6ops@ops.ietf.org; Tue, 09 May 2006 20:22:22 +0000 Received: from waltxp (c-69-255-22-217.hsd1.va.comcast.net[69.255.22.217]) by comcast.net (rwcrmhc13) with SMTP id <20060509202219m1300plp1ke>; Tue, 9 May 2006 20:22:21 +0000 From: "Walt Lazear" To: , Subject: Re: RFC3484 problem: scoping with site-locals/ULAs Date: Tue, 9 May 2006 16:22:03 -0400 Message-ID: <01fb01c673a6$434f1760$5100a8c0@WaltXP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Eliot makes a good point about DNS. This sounds like a perfect case for split DNS, to maintain isolation of both the (private) inside of the NAT point and the site local addresses from the public Internet. What people see on DNS inside should be reachable from the inside, but what they see on DNS outside should be nothing(?). It sounds like the site in question has a single DNS and it's telling outsiders about private stuff that should not be allowed to escape. Walt Lazear From owner-v6ops@ops.ietf.org Tue May 09 16:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZ3o-0004N5-L8 for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 16:44:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZ3n-0005CI-6k for v6ops-archive@lists.ietf.org; Tue, 09 May 2006 16:44:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdZ3A-000KGL-8B for v6ops-data@psg.com; Tue, 09 May 2006 20:43:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdZ39-000KFS-AT for v6ops@ops.ietf.org; Tue, 09 May 2006 20:43:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k49KhDpv007633; Tue, 9 May 2006 23:43:13 +0300 Date: Tue, 9 May 2006 23:43:13 +0300 (EEST) From: Pekka Savola To: Walt Lazear cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: RFC3484 problem: scoping with site-locals/ULAs In-Reply-To: <01fb01c673a6$434f1760$5100a8c0@WaltXP> Message-ID: References: <01fb01c673a6$434f1760$5100a8c0@WaltXP> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1451/Tue May 9 02:27:49 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Tue, 9 May 2006, Walt Lazear wrote: > It sounds like the site in question has a single DNS and it's > telling outsiders about private stuff that should not be allowed to > escape. Exactly the opposite. To solve this problem using split DNS, the DNS resolvers at the site would need to BLOCK any global IPv6 addresses from being received (in DNS packets) from _outside_ the site. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed May 10 11:50:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqxF-0004Pi-Kx for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 11:50:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqxF-00037K-6u for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 11:50:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqwH-0007mD-VY for v6ops-data@psg.com; Wed, 10 May 2006 15:49:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [208.17.33.59] (helo=pacdcoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqwH-0007kl-0P for v6ops@ops.ietf.org; Wed, 10 May 2006 15:49:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3484 problem: scoping with site-locals/ULAs Date: Wed, 10 May 2006 11:49:03 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D961A3A4F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3484 problem: scoping with site-locals/ULAs Thread-Index: AcZ0R2Jyuv9IoxfERvGbKTBMP7jrxgAARBTA From: "Durand, Alain" To: "Fred Baker" , "Pekka Savola" Cc: , "David Woodhouse" , X-OriginalArrivalTime: 10 May 2006 15:49:05.0091 (UTC) FILETIME=[441E5130:01C67449] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 In my previous live, we were all using a large server for many things. That server had 17 physical interfaces. Each interface had one IPv4 address and 2 IPv6 addressses. Each client had also one IPv4 address and two IPv6 addresses. That makes the total combination: 17*2*2 for IPv6 plus 17*1*1 for IPv4, that is 85. Trying them all at the same time for potentially hundreds of clients, many of them on different subnets than any of the 17 interfaces, is overkill. - Alain. =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Wednesday, May 10, 2006 11:31 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org; David Woodhouse; ipv6@ietf.org > Subject: Re: RFC3484 problem: scoping with site-locals/ULAs >=20 > So I have a dumb question. >=20 > Why not: > - use a DNS lookup that asks for all records (including=20 > A, MX, and > AAAA) > - open both a v4 and a v6 connection simultaneously > - accept the first to successfully open and shut down all others >=20 > Down sides: It gets all of the DNS data, which may be more=20 > than it wanted to know, and it issues a second=20 > SYN-or-whatever, and in the worst case one to each address.=20 > But it deterministically finds a solution that works and=20 > gives the system the service it is looking for. >=20 > I the big picture, the problem with that behavior is what? >=20 > On May 9, 2006, at 7:27 AM, Pekka Savola wrote: >=20 > > Hi, > > > > I was alerted to a practical deployment problem. As a result Linux=20 > > glibc has started prefering IPv4 by default... so, I=20 > believe we need=20 > > to find a better solution. > > > > 1) v6 site-local address selection problems > > > > A site has deployed IPv6 site-local addresses (alongside with NATed=20 > > v4). They do not have global IPv6 reachability yet, but=20 > want to test=20 > > IPv6 alongside IPv4 internally. > > > > As a result, RFC 3484 address selection breaks: when trying=20 > to connect=20 > > to a hostname with a public IPv4 and IPv6 address, the host=20 > will first=20 > > try v6 fails (incurring about 3 min TCP timeout if ICMP=20 > error is not=20 > > sent), and after that connects to the v4 address. > > > > I.e., 'prefer matching scope' has v6 globals and site-locals, while > > v4 has globals and private v4 addresses, and v6 wins, with bad=20 > > results. > > > > An easy fix could be that v4 is preferable to v6 if both have=20 > > mismatching scope as v4 is likely to be NATed while v6 isn't. > > > > Has anyone else run into this problem? Is there something I'm=20 > > missing? What has been the implementation (or deployment) approach=20 > > here? > > > > (I don't believe using RFC 4191 to advertise only the site-local=20 > > prefix instead of a default route is a feasible solution here. > > Likewise, requiring that routers will always send back an=20 > ICMP error=20 > > and the host gets it and honors it seems unfeasible in general.) > > > > 2) v6 ULA address selection problems > > > > Deploying ULAs doesn't help here, it just makes the problem=20 > worse as=20 > > you couldn't even use the 'matching scope' tweak. > > > > Do we need to specify that v6 ULAs should be treated as=20 > "site scope"=20 > > for the purposes of default address selection, or something else? > > > > Note that I do not believe it's sufficient to require that=20 > each site=20 > > (and each host within the site) deploys non-default RFC3484=20 > policies. > > > > --=20 > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From owner-v6ops@ops.ietf.org Wed May 10 11:51:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqyT-00055V-PT for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 11:51:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqyT-00039g-O6 for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 11:51:41 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdqhR-0005kZ-Q2 for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 11:34:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqeO-0006JB-Df for v6ops-data@psg.com; Wed, 10 May 2006 15:30:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqeN-0006Iz-RV for v6ops@ops.ietf.org; Wed, 10 May 2006 15:30:55 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 May 2006 08:30:44 -0700 X-IronPort-AV: i="4.05,110,1146466800"; d="scan'208"; a="426991726:sNHT33067696568" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4AFUhKC013873; Wed, 10 May 2006 08:30:43 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4AFUhB7007663; Wed, 10 May 2006 08:30:43 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4AFSdHv009689; Wed, 10 May 2006 08:28:39 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <769A3F79-9DA1-422E-8707-D7562680AA95@cisco.com> Cc: ipv6@ietf.org, v6ops@ops.ietf.org, David Woodhouse Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: RFC3484 problem: scoping with site-locals/ULAs Date: Wed, 10 May 2006 08:30:41 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2751; t=1147275043; x=1148139043; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20RFC3484=20problem=3A=20scoping=20with=20site-locals/ULAs; X=v=3Dcisco.com=3B=20h=3DzjqlMh1cECIC8o0YTPfZUlXHXNE=3D; b=Xvzer5qUedi+jPdgpevUvQxZNn4NwXAO6UnOedDucGKsv+ez0v/kLEgfOl58lEiXcDSAjoZa pofm5AULOkG570EAq8rmFVy6jif0o5b9nlZg1sJgJsXM5vsGnyxGqboJ; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 So I have a dumb question. Why not: - use a DNS lookup that asks for all records (including A, MX, and AAAA) - open both a v4 and a v6 connection simultaneously - accept the first to successfully open and shut down all others Down sides: It gets all of the DNS data, which may be more than it wanted to know, and it issues a second SYN-or-whatever, and in the worst case one to each address. But it deterministically finds a solution that works and gives the system the service it is looking for. I the big picture, the problem with that behavior is what? On May 9, 2006, at 7:27 AM, Pekka Savola wrote: > Hi, > > I was alerted to a practical deployment problem. As a result Linux > glibc has started prefering IPv4 by default... so, I believe we > need to find a better solution. > > 1) v6 site-local address selection problems > > A site has deployed IPv6 site-local addresses (alongside with NATed > v4). They do not have global IPv6 reachability yet, but want to > test IPv6 alongside IPv4 internally. > > As a result, RFC 3484 address selection breaks: when trying to > connect to a hostname with a public IPv4 and IPv6 address, the host > will first try v6 fails (incurring about 3 min TCP timeout if ICMP > error is not sent), and after that connects to the v4 address. > > I.e., 'prefer matching scope' has v6 globals and site-locals, while > v4 has globals and private v4 addresses, and v6 wins, with bad > results. > > An easy fix could be that v4 is preferable to v6 if both have > mismatching scope as v4 is likely to be NATed while v6 isn't. > > Has anyone else run into this problem? Is there something I'm > missing? What has been the implementation (or deployment) approach > here? > > (I don't believe using RFC 4191 to advertise only the site-local > prefix instead of a default route is a feasible solution here. > Likewise, requiring that routers will always send back an ICMP > error and the host gets it and honors it seems unfeasible in general.) > > 2) v6 ULA address selection problems > > Deploying ULAs doesn't help here, it just makes the problem worse > as you couldn't even use the 'matching scope' tweak. > > Do we need to specify that v6 ULAs should be treated as "site > scope" for the purposes of default address selection, or something > else? > > Note that I do not believe it's sufficient to require that each > site (and each host within the site) deploys non-default RFC3484 > policies. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed May 10 12:04:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrAy-00051D-US for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 12:04:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrAy-0003lz-SV for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 12:04:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdrAx-00062n-Dj for v6ops-archive@lists.ietf.org; Wed, 10 May 2006 12:04:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdrAQ-000950-Af for v6ops-data@psg.com; Wed, 10 May 2006 16:04:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=test-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdrAP-00094n-GV for v6ops@ops.ietf.org; Wed, 10 May 2006 16:04:01 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by test-iport-1.cisco.com with ESMTP; 10 May 2006 09:04:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4AG41oG000989; Wed, 10 May 2006 09:04:01 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4AG40B9006940; Wed, 10 May 2006 09:04:00 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4AG1v5v010680; Wed, 10 May 2006 09:01:57 -0700 In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D961A3A4F@PACDCEXCMB03.cable.comcast.com> References: <4884CD6C1DF0A8429DD8DAD942BF9D961A3A4F@PACDCEXCMB03.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7430F547-B18E-4630-8450-C73D25ACDD79@cisco.com> Cc: "Pekka Savola" , , "David Woodhouse" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: RFC3484 problem: scoping with site-locals/ULAs Date: Wed, 10 May 2006 09:03:58 -0700 To: "Durand, Alain" X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=574; t=1147277041; x=1148141041; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20RFC3484=20problem=3A=20scoping=20with=20site-locals/ULAs; X=v=3Dcisco.com=3B=20h=3DzjqlMh1cECIC8o0YTPfZUlXHXNE=3D; b=SU+UH1Qxq5akxRwHckuMJ/GcHvYB5BiVCSI0mG7Z60sJKuW4DG/BwEYDmYZwF4kqWwscav2L vSzI9jvANpF1qNDbB8+drnadFDD6v16ouy4wdTM8cArEeFYJ9qavYysl; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On May 10, 2006, at 8:49 AM, Durand, Alain wrote: > Trying them all at the same time for potentially hundreds of > clients, many of them on different subnets than any of the 17 > interfaces, is overkill. Of course it is. But the discussion here is of the fact that we are trying very hard to pick one, and the one doesn't work. I'm thinking that there must be a way to pick enough of them that one of the ones picked in fact works. And starting out by getting both the IPv4 and IPv6 addresses in the same step seems like a rational starting place. From owner-v6ops@ops.ietf.org Thu May 11 04:21:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6QC-000153-Ah for v6ops-archive@lists.ietf.org; Thu, 11 May 2006 04:21:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6QA-0004NB-Uc for v6ops-archive@lists.ietf.org; Thu, 11 May 2006 04:21:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fe6Mk-000MUU-8F for v6ops-data@psg.com; Thu, 11 May 2006 08:17:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fe6Mi-000MUG-QF for v6ops@ops.ietf.org; Thu, 11 May 2006 08:17:45 +0000 Received: from localhost (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id F404921DC40; Thu, 11 May 2006 10:17:42 +0200 (CEST) Date: Thu, 11 May 2006 10:17:42 +0200 (CEST) Message-Id: <20060511.101742.59653143.he@uninett.no> To: fred@cisco.com Cc: pekkas@netcore.fi, ipv6@ietf.org, v6ops@ops.ietf.org, dwmw2@infradead.org Subject: Re: RFC3484 problem: scoping with site-locals/ULAs From: Havard Eidnes In-Reply-To: <769A3F79-9DA1-422E-8707-D7562680AA95@cisco.com> References: <769A3F79-9DA1-422E-8707-D7562680AA95@cisco.com> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > So I have a dumb question. > > Why not: > - use a DNS lookup that asks for all records (including A, MX, and = > AAAA) Because you can't do this with a single DNS query. The "ANY" query type will return all the records/record types cached for a given name, but there is no guarantee that the cache has been filled with all the information available on the authoritative name servers for the given name. Individual RRsets (name+type) can have different TTLs, so even if the cache was filled with all the information initially, a caching name server can't guarantee that will always be the case at a later time. That's a minor detail, though -- one or two DNS queries doesn't make much of a difference. > - open both a v4 and a v6 connection simultaneously > - accept the first to successfully open and shut down all others I think that the TCP connect operations are typically synchronous at the user/kernel interface. Doing several connection attempts in parallel is therefore at best problematical. Using pthreads could possibly be a workaround, but mandating use of pthreads for all applications for using the C library is, I think, not acceptable. Regards, - H=E5vard From owner-v6ops@ops.ietf.org Fri May 12 17:10:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feetd-0002BD-5V for v6ops-archive@lists.ietf.org; Fri, 12 May 2006 17:10:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feeer-0002Rw-8I for v6ops-archive@lists.ietf.org; Fri, 12 May 2006 16:54:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeebU-0004VT-Ld for v6ops-data@psg.com; Fri, 12 May 2006 20:51:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeebS-0004VE-1C for v6ops@ops.ietf.org; Fri, 12 May 2006 20:51:14 +0000 Received: from jurassic.eng.sun.com ([129.146.56.144]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4CKorxW021448; Fri, 12 May 2006 14:50:53 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4CKoo8a242051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 May 2006 13:50:53 -0700 (PDT) Message-ID: <4464F52A.8080707@sun.com> Date: Fri, 12 May 2006 13:50:50 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Fred Baker CC: Pekka Savola , v6ops@ops.ietf.org, David Woodhouse , ipv6@ietf.org Subject: Re: RFC3484 problem: scoping with site-locals/ULAs References: <769A3F79-9DA1-422E-8707-D7562680AA95@cisco.com> In-Reply-To: <769A3F79-9DA1-422E-8707-D7562680AA95@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Fred Baker wrote: > So I have a dumb question. > > Why not: > - use a DNS lookup that asks for all records (including A, MX, and > AAAA) > - open both a v4 and a v6 connection simultaneously > - accept the first to successfully open and shut down all others > > Down sides: It gets all of the DNS data, which may be more than it > wanted to know, and it issues a second SYN-or-whatever, and in the worst > case one to each address. But it deterministically finds a solution that > works and gives the system the service it is looking for. > > I the big picture, the problem with that behavior is what? In the big picture, I think that's the direction we need to move. But I don't think we want to have every application have that logic, since the logic might need to evolve over time (and needs to take into account Alain's example of umpteen different IP addresses - might want to stagger the attempts when there are lots of IP addresses to try.) So instead I think we want to raise the abstraction layer for the applications by introducing a connect-by-name socket API so that the application just hands in the FQDN and the port number to which it wants to connect. It isn't hard to come up with an initial cut of a connect-by-name implementation entirely as a library routine (using non-blocking sockets for the connect() system calls so that multiple can be outstanding and the same time.) Erik From owner-v6ops@ops.ietf.org Tue May 16 00:09:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffqs4-0001ZS-Gp for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 00:09:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffqs4-0005UR-18 for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 00:09:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ffqo5-000LT5-L9 for v6ops-data@psg.com; Tue, 16 May 2006 04:05:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ffqo4-000LSs-Oa for v6ops@ops.ietf.org; Tue, 16 May 2006 04:05:12 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 15 May 2006 21:05:12 -0700 X-IronPort-AV: i="4.05,131,1146466800"; d="scan'208"; a="1806828891:sNHT36804832" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4G45Ckb012216; Mon, 15 May 2006 21:05:12 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4G45BJj001393; Mon, 15 May 2006 21:05:11 -0700 (PDT) Received: from [192.168.2.198] (rtp-vpn1-74.cisco.com [10.82.224.74]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4G42l9L003599; Mon, 15 May 2006 21:02:47 -0700 In-Reply-To: <200603202041.k2KKfrR16518@irp-view7.cisco.com> References: <200603202041.k2KKfrR16518@irp-view7.cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00C68A2E-0769-4658-ACC6-573755422C97@cisco.com> Cc: v6ops@ops.ietf.org, iesg-secretary@ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: draft-ietf-v6ops-ent-analysis-05.txt to Informational Date: Tue, 16 May 2006 00:05:07 -0400 To: David Kessens X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-5.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4844; t=1147752312; x=1148616312; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:draft-ietf-v6ops-ent-analysis-05.txt=20to=20Informational; X=v=3Dcisco.com=3B=20h=3D6R5e06B1RLD8uTEuwc+Hd5j2t7k=3D; b=1mPFLLhPPvEhEuMHgNi9HoGoNFbQD83MFcgsEPHwsjqC82gfBbwsXqzOm5z2GgcTs6FyH4sd TVQ1Zx3OYxnIQZNscZjX2B44JC9XSl6CtNzosdzK0rL/2OkQ1Hi7JC7a; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e v6ops begs your indulgence to send this document off in an Informational status. > 1.a) Have the chairs personally reviewed this version of the > Internet Draft (ID), and in particular, do they believe this ID is > ready to forward to the IESG for publication? Which chair is the > WG Chair Shepherd for this document? Yes, I believe that it is ready for publication. I will be the proto- shepherd. > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? Do you have any concerns about the depth > or breadth of the reviews that have been performed? This document has had significant and at times contentious review in the working group. I believe that the recommendations it makes are sound and have been accepted by the working group. > 1.c) Do you have concerns that the document needs more review from > a particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, internationalization, XML, > etc.)? I could imagine interest in the Internet area. It is essentially operational, so issues that the security area or others might come up with are more comments on IPv6 than they are on these points. > 1.d) Do you have any specific concerns/issues with this document > that you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain parts of the > document, or have concerns whether there really is a need for it. > In any event, if your issues have been discussed in the WG and the > WG has indicated it that it still wishes to advance the document, > detail those concerns in the write-up There has been significant discussion in the WG regarding the document. At this point, I believe that the document is appropriate and makes appropriate statements. > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? One could describe v6ops as a set of groups of people intimately worried about specific topics among a crowd of people who mostly want to stay in touch with what happens. As such, it is a pretty quiet group. However, consensus exists behind this document to the extent it can be measured. > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. (It should be > separate email because this questionnaire will be entered into the > tracker). not to my knowledge. > 1.g) Have the chairs verified that the document checks out against > all the ID nits? (see http://www.ietf.org/ID-Checklist.html). > Boilerplate checks are not enough; this check needs to be thorough. Yes. > 1.h) Has the document split its references into normative and > informative? Yes. > Are there normative references to IDs, where the IDs are not also > ready for advancement or are otherwise in an unclear state? There are several references to internet drafts. All are non-normative. > The RFC Editor will not publish an RFC with normative references to > IDs (will delay the publication until all such IDs are also ready > for RFC publicatioin). If the normative references are behind, > what is the strategy for their completion? On a related matter, > are there normative references that are downward references, as > described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these > supports the Area Director in the Last Call downref procedure > specified in RFC 3967. This has been addressed. > 1.i) For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following sections: > > * Technical Summary This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. > * Working Group Summary This has been discussed in detail in the working group. > * Protocol Quality This does not specify a protocol. From owner-v6ops@ops.ietf.org Tue May 16 09:21:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzUE-00035y-4q for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 09:21:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzUC-00066M-DQ for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 09:21:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfzRH-000PtX-WF for v6ops-data@psg.com; Tue, 16 May 2006 13:18:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfzRG-000PtD-G4 for v6ops@ops.ietf.org; Tue, 16 May 2006 13:18:14 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZD0043G1CGQX@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Tue, 16 May 2006 21:26:40 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZD00LCO1CG99@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Tue, 16 May 2006 21:26:40 +0800 (CST) Received: from z52447 ([10.164.5.19]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZD00GNT1MGBQ@szxml02-in.huawei.com>; Tue, 16 May 2006 21:32:49 +0800 (CST) Date: Tue, 16 May 2006 21:17:56 +0800 From: Lawrence Zou Subject: RFC3697 question,can anybody explain it ? To: ipv6@ietf.org, v6ops@ops.ietf.org Message-id: <000f01c678eb$28ca44b0$1305a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db what the definition of the "flow state" is? I am not very clear about the content of "flow state" and there is no definition in the RFC3697. From owner-v6ops@ops.ietf.org Tue May 16 10:44:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0mY-0001Xi-Nf for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 10:44:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0mX-0001iP-7K for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 10:44:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fg0lC-0005PO-4Q for v6ops-data@psg.com; Tue, 16 May 2006 14:42:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fg0l9-0005Op-7M for v6ops@ops.ietf.org; Tue, 16 May 2006 14:42:51 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k4GEgiUh133434 for ; Tue, 16 May 2006 14:42:44 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4GEhfBi130730 for ; Tue, 16 May 2006 15:43:41 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k4GEghCi002875 for ; Tue, 16 May 2006 15:42:43 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k4GEghgC002854; Tue, 16 May 2006 15:42:43 +0100 Received: from zurich.ibm.com (sig-9-145-250-42.de.ibm.com [9.145.250.42]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA46118; Tue, 16 May 2006 16:42:42 +0200 Message-ID: <4469E4E0.8080402@zurich.ibm.com> Date: Tue, 16 May 2006 16:42:40 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Lawrence Zou CC: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: RFC3697 question,can anybody explain it ? References: <000f01c678eb$28ca44b0$1305a40a@china.huawei.com> In-Reply-To: <000f01c678eb$28ca44b0$1305a40a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Lawrence, Lawrence Zou wrote: > what the definition of the "flow state" is? I am not very clear about > the content of "flow state" and there is no definition in the RFC3697. I assume you have read the definition of "flow" at the beginning of section 1. "State" or "state information" in the IETF usually means the set of data held by a node to describe a communications session. So in this case, a possible definition of flow state would be: The set of data held by a node to describe a flow as defined in section 1. I'm sorry we didn't include a definition in the RFC. As the RFC says, it doesn't describe any mechanisms for establishing flow state, and therefore it doesn't need to describe the data either. But I would assume that the flow state will always include at least Flow label value Source address Destination address with the rest depending on the way the flow label is being used. Hope this helps. Brian From owner-v6ops@ops.ietf.org Tue May 16 21:04:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgASn-00020o-KB for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 21:04:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgASn-0004Yl-Bf for v6ops-archive@lists.ietf.org; Tue, 16 May 2006 21:04:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgAPM-000Lwp-QJ for v6ops-data@psg.com; Wed, 17 May 2006 01:01:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgAPJ-000LwE-Se for v6ops@ops.ietf.org; Wed, 17 May 2006 01:00:58 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZD00ARHXVK9N@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Wed, 17 May 2006 09:09:21 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZD00IHGXVK5R@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Wed, 17 May 2006 09:09:20 +0800 (CST) Received: from z52447 ([10.164.5.19]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZD00BB4Y5LMM@szxml02-in.huawei.com>; Wed, 17 May 2006 09:15:29 +0800 (CST) Date: Wed, 17 May 2006 09:01:24 +0800 From: Lawrence Zou Subject: RE: RFC3697 question,can anybody explain it ? In-reply-to: <4469E4E0.8080402@zurich.ibm.com> To: 'Brian E Carpenter' Cc: ipv6@ietf.org, v6ops@ops.ietf.org Message-id: <000a01c6794d$6e723920$1305a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab >As the RFC says, it doesn't describe any mechanisms for establishing flow state, and therefore it doesn't need to describe the data either. But I would assume that the flow state will >always include at least > Flow label value > Source address > Destination address >with the rest depending on the way the flow label is being used. Brian: thanks, it helps me a lot,but i assume that except that 3- tuple you mentioned,the flow state will at least also include the liftetime of the flow label. -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Tuesday, May 16, 2006 10:43 PM To: Lawrence Zou Cc: ipv6@ietf.org; v6ops@ops.ietf.org Subject: Re: RFC3697 question,can anybody explain it ? Lawrence, Lawrence Zou wrote: > what the definition of the "flow state" is? I am not very clear about > the content of "flow state" and there is no definition in the > RFC3697. I assume you have read the definition of "flow" at the beginning of section 1. "State" or "state information" in the IETF usually means the set of data held by a node to describe a communications session. So in this case, a possible definition of flow state would be: The set of data held by a node to describe a flow as defined in section 1. I'm sorry we didn't include a definition in the RFC. As the RFC says, it doesn't describe any mechanisms for establishing flow state, and therefore it doesn't need to describe the data either. But I would assume that the flow state will always include at least Flow label value Source address Destination address with the rest depending on the way the flow label is being used. Hope this helps. Brian From owner-v6ops@ops.ietf.org Wed May 17 09:14:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLqt-0005DQ-6O for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 09:14:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLqr-0008M0-PV for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 09:14:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgLmI-00095d-18 for v6ops-data@psg.com; Wed, 17 May 2006 13:09:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.65.76.7] (helo=ns2.teleware.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgLmF-000955-2m for v6ops@ops.ietf.org; Wed, 17 May 2006 13:09:23 +0000 Received: from teleware.fi (unknown [10.204.2.29]) by ns2.teleware.fi (Postfix) with ESMTP id BA6DD1C8018 for ; Wed, 17 May 2006 16:09:24 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: Teredo routing status? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 May 2006 16:09:10 +0300 Message-ID: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Teredo routing status? Thread-Index: AcZ5sxY+4KorKnLyTpOu04Cvro6tnw== From: "Anssi Porttikivi" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I found in the Wikipedia Teredo article that http://www.sixxs.net/tools/grh/lg/?find=3D2001::/32 can be used to verify that the new Teredo prefix is indeed widely available as an anycast route. There was also a reference to this list and a hint by David Thaler from Micorosoft that the prefix can be configured to Windows: http://psg.com/lists/v6ops/v6ops.2006/msg00064.html=20 Done that, and my Teredo does not work. Windows Teredo says "secondary server address unreachable". What is this configuration changed supposed to affect, exactly? Does the MS Teredo server accept a client request for address with this prefix? Is the global routing for it really working? Is Teredo reliably and universally working with ANY configuration? I have fond memories of those few times last year when a South Korean public relay actually advertised the old prefix in global BGP, and Teredo actually worked globally. Anssi.Porttikivi@teleware.fi skype: gatestone=20 From owner-v6ops@ops.ietf.org Wed May 17 09:28:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgM4R-000135-SP for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 09:28:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgM4M-0000cY-Dy for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 09:28:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgM3k-000ARu-Uf for v6ops-data@psg.com; Wed, 17 May 2006 13:27:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgM3j-000ARV-4n for v6ops@ops.ietf.org; Wed, 17 May 2006 13:27:27 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id A1BD76773F; Wed, 17 May 2006 15:27:21 +0200 (CEST) Subject: Re: Teredo routing status? From: Jeroen Massar To: Anssi Porttikivi Cc: v6ops@ops.ietf.org In-Reply-To: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lFrINel4XsAUKlMmSv8q" Organization: Unfix Date: Wed, 17 May 2006 15:27:17 +0200 Message-Id: <1147872437.20557.6.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --=-lFrINel4XsAUKlMmSv8q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-05-17 at 16:09 +0300, Anssi Porttikivi wrote: > I found in the Wikipedia Teredo article that > http://www.sixxs.net/tools/grh/lg/?find=3D2001::/32 > can be used to verify that the new Teredo prefix is indeed widely > available as an anycast route. There was also a reference to this list > and a hint by David Thaler from Micorosoft that the prefix can be > configured to Windows: >=20 > http://psg.com/lists/v6ops/v6ops.2006/msg00064.html=20 >=20 > Done that, and my Teredo does not work. Windows Teredo says "secondary > server address unreachable". Because you are most likely still using the old servers which only support (afaik) the old 6bone prefix and not yet the 2001::/32 one. Also, did you reboot? :) > What is this configuration changed supposed to affect, exactly? Does the > MS Teredo server accept a client request for address with this prefix? > Is the global routing for it really working? The v6 path is there, that is what GRH shows, though that still depends on the viewpoint and if the route is actually made visible globally or only for a limitted set of networks (eg using no-export or filters). The v4 path is the other question and you will have to configure it to use a server which supports the RIR prefix. That said, you will want to contact the operator of your Teredo server you are using, though you might some of them here, if you really want operational people and not standards folks, try: http://lists.cluenet.de/mailman/listinfo/ipv6-ops Though I have to note that that is not a help-me list either. > Is Teredo reliably and universally working with ANY configuration? According to the people who tested it it seems to work except for the cone-nat situation (or was it the other one, see wikipedia ;) > I have fond memories of those few times last year when a South Korean > public relay actually advertised the old prefix in global BGP, and > Teredo actually worked globally. Which was most likely quite useless latency wise when your packets had to travel twice around the world; it also makes debugging a lot of 'fun'. Greets, Jeroen --=-lFrINel4XsAUKlMmSv8q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkRrJLUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I5WvAJwPmIj6m9B3RQDVWE3+PXocoCyh tgCaAuEj8jFzQIsSk9HW7rNEp6vMhC0= =9iLu -----END PGP SIGNATURE----- --=-lFrINel4XsAUKlMmSv8q-- From owner-v6ops@ops.ietf.org Wed May 17 10:30:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN2J-0001Ti-EL for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 10:30:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgN2F-0003gH-Ve for v6ops-archive@lists.ietf.org; Wed, 17 May 2006 10:30:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgN0W-000FZV-GP for v6ops-data@psg.com; Wed, 17 May 2006 14:28:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.186.38.137] (helo=27.mail-out.ovh.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgN0U-000FZF-Ii for v6ops@ops.ietf.org; Wed, 17 May 2006 14:28:10 +0000 Received: (qmail 19663 invoked by uid 503); 17 May 2006 14:28:54 -0000 Received: from b7.ovh.net (HELO mail150.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 17 May 2006 14:28:54 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 17 May 2006 14:27:13 -0000 Received: from mail150.ha.ovh.net (10.0.50.150) by mail150.ha.ovh.net with SMTP; 17 May 2006 14:27:07 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 17 May 2006 14:26:58 -0000 Received: from st3-1-3.tky.hut.fi (postmaster%simphalempin.com@130.233.27.57) by ns0.ovh.net with SMTP; 17 May 2006 14:26:57 -0000 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: SimPhalempin.Com To: v6ops@ops.ietf.org Subject: Re: Teredo routing status? Date: Wed, 17 May 2006 17:27:05 +0300 User-Agent: KMail/1.9.1 References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> In-Reply-To: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> Cc: "Anssi Porttikivi" MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart24961628.oedkOygagT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605171727.08808@auguste.remlab.net> X-Ovh-Remote: 130.233.27.57 (st3-1-3.tky.hut.fi) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --nextPart24961628.oedkOygagT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, Le Mercredi 17 Mai 2006 16:09, vous avez =C3=A9crit : > What is this configuration changed supposed to affect, exactly? It changes which prefix Windows expect from the server. > Does the MS Teredo server accept a client request for address with > this prefix? Not yet, or at least not at teredo.ipv6.microsoft.com. I couldn't get=20 any infos as to whether and when this is going to change. > Is the global routing for it really working? The IANA prefix (2001:0::/32) is working; ITGate is advertising the=20 prefix and running a working relay. The experimental prefix=20 (3ffe:831f::/32) is not (anymore). > Is Teredo reliably and universally working with ANY configuration? No. No tunneling system works universally anyway, with the possible=20 exception of DNS tunneling. Now, if you mean any NAT configuration,=20 assuming there is no firewalling problems as well, then, no, Teredo as=20 it is specified does not support symmetric NATs. There are undocumented-unspecified extensions in Windows Vista that=20 would allow traversal of any NAT, provided either side of the packets=20 exchange is behind no NAT or a friendly NAT. This would imply NAT=20 traversal would at least work properly toward the whole IPv6 Internet=20 (because Teredo relays are *NEVER* behind unfriendly NATs), and toward=20 most Teredo clients behind SOHO NAT routers. Unfortunately, given this is not a specified extension, and that I'm=20 fairly confident it's in explicit contradiction with the current=20 specification, I have some reservations as to whether it's actually=20 going to work as advertised. That is to say, if Teredo relays are=20 running Vista, it might work fine, but not otherwise. I'd be happy to=20 provide support for this in my own implementation, but I can't do so=20 with zero concrete information. Also, the guys behind the NICI-Teredo implementation have seemingly=20 developped their own extensions that, I assume, would allow Teredo to=20 work in all cases. But their results is yet to be released: =E2=80=9CHuang, S.-M., Wu, Q.-C., and Lin, Y.-B. Enhancing Teredo IPv6 Tunn= eling=20 to Traverse the Symmetric NAT, Accepted and to appear in IEEE=20 Communications Letters.=E2=80=9D (quoted from http://liny.csie.nctu.edu.tw/) Regards, =2D-=20 R=C3=A9mi Denis-Courmont http://www.simphalempin.com/home/ --nextPart24961628.oedkOygagT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEazK8w+xtvt1tEr0RArPUAJ47bHUF5DSz2bp1CcsrtIcsNNYJ2ACg06Bm ybmatSJOStiIMUMWUr+ktME= =Wcsw -----END PGP SIGNATURE----- --nextPart24961628.oedkOygagT-- From owner-v6ops@ops.ietf.org Thu May 18 01:44:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgbIx-00026b-PS for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 01:44:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgbIt-0007Dn-6v for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 01:44:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgbGM-000Kx3-6G for v6ops-data@psg.com; Thu, 18 May 2006 05:41:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.203] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgbGL-000Kwp-8e for v6ops@ops.ietf.org; Thu, 18 May 2006 05:41:29 +0000 Received: by wx-out-0102.google.com with SMTP id s8so101606wxc for ; Wed, 17 May 2006 22:41:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=V0XT0SvYzWdqB0x0NXQnZQ4Vplnm+Qw0/NJJo8feqALMcdib2kRaOeEXpYqLppYcIDydyYuZeuRgdTHLEFlP0kAwfU4LAGT693QTsXa++uxvmYPPtEp7SBN04HICy4wcgatVyoLXr6aDeMGrNpq2pt8vKRVk2WMZnd9vyTZRGkE= Received: by 10.70.77.7 with SMTP id z7mr194365wxa; Wed, 17 May 2006 22:41:27 -0700 (PDT) Received: by 10.70.40.18 with HTTP; Wed, 17 May 2006 22:41:27 -0700 (PDT) Message-ID: Date: Thu, 18 May 2006 13:41:27 +0800 From: "haofeng Zhang" To: "Anssi Porttikivi" Subject: Re: Teredo routing status? Cc: v6ops@ops.ietf.org In-Reply-To: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_401_7210443.1147930887532" References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 ------=_Part_401_7210443.1147930887532 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I did the same thing and got the same result. The default teredo server spicified in Windows XP is teredo.ipv6.microsoft.com. So even we have changed the teredo prefix in teredo client, we can never change the prefix advertised by MS teredo server. I think it's why teredo service doesn't work. Also, current implementation of teredo service in MS doesn't work reliably and universally without ANY configuration. Accoriding to the document of Windows Vista, it supports teredo service transparent to ANY kinds of NATs. PS, it's good to see many operators are advertising 2001::/32 teredo prefix to global BGP table. Zhang Haofeng MSN: haofeng0913@msn.com 2006-5-18 2006/5/17, Anssi Porttikivi : > > I found in the Wikipedia Teredo article that > http://www.sixxs.net/tools/grh/lg/?find=3D2001::/32 > can be used to verify that the new Teredo prefix is indeed widely > available as an anycast route. There was also a reference to this list > and a hint by David Thaler from Micorosoft that the prefix can be > configured to Windows: > > http://psg.com/lists/v6ops/v6ops.2006/msg00064.html > > Done that, and my Teredo does not work. Windows Teredo says "secondary > server address unreachable". > > What is this configuration changed supposed to affect, exactly? Does the > MS Teredo server accept a client request for address with this prefix? > Is the global routing for it really working? Is Teredo reliably and > universally working with ANY configuration? > > I have fond memories of those few times last year when a South Korean > public relay actually advertised the old prefix in global BGP, and > Teredo actually worked globally. > > Anssi.Porttikivi@teleware.fi > skype: gatestone > > ------=_Part_401_7210443.1147930887532 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

I did the same thing and got the same result.
The default te= redo server spicified in Windows XP is teredo.ipv6.microsoft.com. So even we have changed the teredo = prefix in teredo client, we can never change the prefix advertised by MS te= redo server.
I think it's why teredo service doesn't work.

Also, current impl= ementation of teredo service in MS doesn't work reliably and universally wi= thout ANY configuration. Accoriding to the document of Windows Vista, it su= pports teredo service transparent to ANY kinds of NATs.

PS, it's good to see many operators are advertising 2001::/32 tered= o prefix to global BGP table.

Zhang Haofeng
MSN: haofeng0913@msn.com
2006-5-18

2006/5/17, Anssi Porttikivi <Anssi@= teleware.fi>:
I found in the Wikipedia Teredo article that
http://www.sixxs.net/tools/grh/lg/?fin= d=3D2001::/32
can be used to verify that the new Teredo prefix is in= deed widely
available as an anycast route. There was also a reference to this list<= br>and a hint by David Thaler from Micorosoft that the prefix can be
con= figured to Windows:

        = http://psg.com/lists/v6ops/v6ops.2006/msg00064.html

Done that, a= nd my Teredo does not work. Windows Teredo says "secondary
server a= ddress unreachable".

What is this configuration changed suppose= d to affect, exactly? Does the
MS Teredo server accept a client request for address with this prefix?<= br>Is the global routing for it really working? Is Teredo reliably and
u= niversally working with ANY configuration?

I have fond memories of t= hose few times last year when a South Korean
public relay actually advertised the old prefix in global BGP, and
T= eredo actually worked globally.

Anssi.Porttikivi@teleware.fi
skype: gatestone


------=_Part_401_7210443.1147930887532-- From owner-v6ops@ops.ietf.org Thu May 18 10:24:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjQu-0007O7-Qn for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 10:24:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjQt-0004h8-HM for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 10:24:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgjQE-000P0U-Jx for v6ops-data@psg.com; Thu, 18 May 2006 14:24:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.186.38.137] (helo=27.mail-out.ovh.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgjQD-000P07-9M for v6ops@ops.ietf.org; Thu, 18 May 2006 14:24:13 +0000 Received: (qmail 611 invoked by uid 503); 18 May 2006 14:25:26 -0000 Received: from b7.ovh.net (HELO mail152.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 18 May 2006 14:25:26 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 18 May 2006 14:24:18 -0000 Received: from mail152.ha.ovh.net (10.0.50.152) by mail152.ha.ovh.net with SMTP; 18 May 2006 14:24:16 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 18 May 2006 14:24:16 -0000 Received: from st3-1-3.tky.hut.fi (postmaster%simphalempin.com@130.233.27.57) by ns0.ovh.net with SMTP; 18 May 2006 14:24:16 -0000 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: SimPhalempin.Com To: Kevin Loch Subject: Re: Teredo routing status? Date: Thu, 18 May 2006 17:23:51 +0300 User-Agent: KMail/1.9.1 References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> <446C79AC.1030005@hotnic.net> In-Reply-To: <446C79AC.1030005@hotnic.net> Cc: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2689956.zKs9XrWT28"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605181723.55095@auguste.remlab.net> X-Ovh-Remote: 130.233.27.57 (st3-1-3.tky.hut.fi) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --nextPart2689956.zKs9XrWT28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le Jeudi 18 Mai 2006 16:42, vous avez =E9crit : > Who is announcing it besides 12779? At large, nobody indeed. > I will add Teredo server/relay > support to our 6to4 relay and announce 2001::/32 as soon as > I get an implementation working on FreeBSD 5.4. =46YI, ng_teredo might work, though it's not clear to me whether it's been= =20 totally ported to FreeBSD 5. Miredo is supposed to work. Regards, =2D-=20 R=E9mi Denis-Courmont http://www.simphalempin.com/home/ --nextPart2689956.zKs9XrWT28 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEbIN7w+xtvt1tEr0RAuHdAJ9i8lL1tPPPJmaWmNgLiX9Kp1faRQCgkC5u R4XnEESbQ0cpxidMOSSDDYI= =Zut8 -----END PGP SIGNATURE----- --nextPart2689956.zKs9XrWT28-- From owner-v6ops@ops.ietf.org Thu May 18 11:45:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkgl-00054T-Bw for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 11:45:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgj0k-0002ib-Jz for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 09:57:54 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgiky-00034b-7c for v6ops-archive@lists.ietf.org; Thu, 18 May 2006 09:41:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgihp-000LJ0-Ao for v6ops-data@psg.com; Thu, 18 May 2006 13:38:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [66.117.32.22] (helo=srv013.carpathiahost.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgihm-000LIW-Ja for v6ops@ops.ietf.org; Thu, 18 May 2006 13:38:18 +0000 Received: from [66.117.52.85] (unknown [66.117.52.85]) by srv013.carpathiahost.net (Postfix) with ESMTP id DEE7093789; Thu, 18 May 2006 09:38:17 -0400 (EDT) Message-ID: <446C79AC.1030005@hotnic.net> Date: Thu, 18 May 2006 09:42:04 -0400 From: Kevin Loch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: haofeng Zhang Cc: Anssi Porttikivi , v6ops@ops.ietf.org Subject: Re: Teredo routing status? References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB87A@hkisrv09.tw.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de haofeng Zhang wrote: > PS, it's good to see many operators are advertising 2001::/32 teredo > prefix to global BGP table. Who is announcing it besides 12779? I will add Teredo server/relay support to our 6to4 relay and announce 2001::/32 as soon as I get an implementation working on FreeBSD 5.4. - Kevin From owner-v6ops@ops.ietf.org Mon May 22 07:35:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8gm-0003qV-Ko for v6ops-archive@lists.ietf.org; Mon, 22 May 2006 07:35:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8gl-00042g-Ag for v6ops-archive@lists.ietf.org; Mon, 22 May 2006 07:35:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi8c8-0000Js-Dz for v6ops-data@psg.com; Mon, 22 May 2006 11:30:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi8c5-0000JZ-CD for v6ops@ops.ietf.org; Mon, 22 May 2006 11:30:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4MBUAXC026729; Mon, 22 May 2006 14:30:10 +0300 Date: Mon, 22 May 2006 14:30:10 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: hannes.tschofenig@siemens.com, rfg@acm.org, Mohan.Parthasarathy@nokia.com Subject: draft-ietf-v6ops-ipsec-tunnels-02 review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-Virus-Scanned: ClamAV 0.88.2/1474/Sun May 21 16:18:22 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 FYI, as a co-author, I solicited one extra IPsec expert review from Pasi Eronen for draft-ietf-v6ops-ipsec-tunnels-02. Unfortanately, the document still needs a bit of work. ---------- Forwarded message ---------- I have three major comments (which I believe require significant further work), and a couple of minor comments (that should be easy to address). The major ones first: 1) I found it very difficult to reconcile the "generic SPD" described in this document with the IPsec architecture in RFC4301. An SPD is an ordered database, so having one SPD contain multiple entries with just "match everything" selectors doesn't seem to make much sense. So it looks like either we have to consider each interface (IPv6-in-IPv4 tunnel) having its own SPD, or the interface is used as a selector in the SPD. There's nothing wrong with this -- and I guess it can be made to work if the IPsec SAs are configured manually -- but it does cause complications with IKE. In particular, when the IKE responder receives a request to create a new IPsec SA, how does it know which interface this corresponds to? For "real" interfaces, an obvious answer would be "the interface where the IKE packets came from" -- but I guess in this case, the IKE packets are sent using the normal IPv4 interface, not the tunnel "pseudo-interface". I guess there are ways how this can be handled, especially if the host/gateway has only a single IPv6-in-IPv4 tunnel. But the document needs much more text about this. 2) Section 8 and Security Considerations: Simply knowing the tunnel endpoint's IP address is not sufficient: the initiator also needs to know how it should authenticate itself to the remote peer, and what kind of authentication to expect from the remote peer. For example, if the responder is authenticated using certificates, the initiator has to know what the right subject name is. In other words: how do we discover the PAD identities and peer authentication data? 3) PAD "Child SA Authorization Data" needs to be described, for all three cases (transport, tunnel with specific SPD, tunnel with SPD). Minor comments: 4) Section 4: "[RFC2401] does not support transport mode SAs between hosts and security gateways." This is a misunderstanding of RFC2401: these IP packets are destined to the "gateway" (they have the gateway's IP address as the destination IP address), so at the point where this SA is relevant, it's acting as a host, and using transport mode is allowed. Decapsulating the IP-in-IP packet happens higher up in the stack (and for this purpose, it doesn't matter whether the tunneling protocol is IP-in-IP or GRE or MIP-over-UDP or SOCKS or something else). 5) Section 7: "IKEv2 can detect the presence of a NAT automatically by sending an Informational exchange with NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec SA." No such functionality is described in RFC4306; the NAT detection notifications are always placed in IKE_SA_INIT exchange, not INFORMATIONAL (MOBIKE adds this functionality, though). 6) Section 7: "The IETF MOBIKE working group is looking into providing a solution for IKEv2 but the work is still in progress". MOBIKE WG has been closed (the document is in RFC editor's queue). 7) I'd suggest using RFC4301's bi-directional SPD notation instead of the separate SPD-in and SPD-out. Best regards, Pasi From owner-v6ops@ops.ietf.org Mon May 22 16:37:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiH9I-0001Vh-A5 for v6ops-archive@lists.ietf.org; Mon, 22 May 2006 16:37:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiH9G-0003dV-Sb for v6ops-archive@lists.ietf.org; Mon, 22 May 2006 16:37:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiH6l-000ApX-Fe for v6ops-data@psg.com; Mon, 22 May 2006 20:34:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiH6k-000ApI-Pp for v6ops@ops.ietf.org; Mon, 22 May 2006 20:34:30 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 13:34:30 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280850631:sNHT33192372" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4MKYUWS015136; Mon, 22 May 2006 13:34:30 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4MKYTHc003524; Mon, 22 May 2006 13:34:30 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4MKVe8U024700; Mon, 22 May 2006 13:31:40 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A8B7147-B200-478D-B9A2-6F9743C92D34@cisco.com> Cc: v6ops@ops.ietf.org, hannes.tschofenig@siemens.com, rfg@acm.org, Mohan.Parthasarathy@nokia.com Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: draft-ietf-v6ops-ipsec-tunnels-02 review Date: Mon, 22 May 2006 13:34:25 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3894; t=1148330070; x=1149194070; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20draft-ietf-v6ops-ipsec-tunnels-02=20review; X=v=3Dcisco.com=3B=20h=3D4TyxKR0pFbHj6knqndYAcjPsm+M=3D; b=M2xEgc2QdvjmKPxZ4cLdSB6rZ9CaJc2e6rG0GHhtI2WssW5jywZhijGQmOvN5tQH1gd1Yump I4oijcc31NtPRXl0mkdBE3hN0xH+GMvqsBzmAmCTAkeAB29+kNgjnFTo; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Thanks for doing that. I take it that we can expect an updated version of the draft? On May 22, 2006, at 4:30 AM, Pekka Savola wrote: > FYI, as a co-author, I solicited one extra IPsec expert review from > Pasi Eronen for draft-ietf-v6ops-ipsec-tunnels-02. Unfortanately, > the document still needs a bit of work. > > ---------- Forwarded message ---------- > > I have three major comments (which I believe require significant > further work), and a couple of minor comments (that should be easy > to address). The major ones first: > > 1) I found it very difficult to reconcile the "generic SPD" described > in this document with the IPsec architecture in RFC4301. > > An SPD is an ordered database, so having one SPD contain multiple > entries with just "match everything" selectors doesn't seem to make > much sense. So it looks like either we have to consider each > interface (IPv6-in-IPv4 tunnel) having its own SPD, or the > interface is used as a selector in the SPD. There's nothing wrong > with this -- and I guess it can be made to work if the IPsec SAs > are configured manually -- but it does cause complications with > IKE. > > In particular, when the IKE responder receives a request to create > a new IPsec SA, how does it know which interface this corresponds > to? For "real" interfaces, an obvious answer would be "the > interface where the IKE packets came from" -- but I guess in this > case, the IKE packets are sent using the normal IPv4 interface, not > the tunnel "pseudo-interface". > > I guess there are ways how this can be handled, especially if the > host/gateway has only a single IPv6-in-IPv4 tunnel. But the > document needs much more text about this. > > 2) Section 8 and Security Considerations: Simply knowing the tunnel > endpoint's IP address is not sufficient: the initiator also needs > to know how it should authenticate itself to the remote peer, and > what kind of authentication to expect from the remote peer. For > example, if the responder is authenticated using certificates, > the initiator has to know what the right subject name is. In > other words: how do we discover the PAD identities and peer > authentication data? > > 3) PAD "Child SA Authorization Data" needs to be described, for > all three cases (transport, tunnel with specific SPD, tunnel > with SPD). > > Minor comments: > > 4) Section 4: "[RFC2401] does not support transport mode SAs > between hosts and security gateways." > > This is a misunderstanding of RFC2401: these IP packets are > destined to the "gateway" (they have the gateway's IP address as > the destination IP address), so at the point where this SA is > relevant, it's acting as a host, and using transport mode is > allowed. Decapsulating the IP-in-IP packet happens higher up in > the stack (and for this purpose, it doesn't matter whether the > tunneling protocol is IP-in-IP or GRE or MIP-over-UDP or SOCKS > or something else). > > 5) Section 7: "IKEv2 can detect the presence of a NAT automatically > by sending an Informational exchange with NAT_DETECTION_SOURCE_IP > and NAT_DETECTION_DESTINATION_IP payloads before establishing an > IPsec SA." > > No such functionality is described in RFC4306; the NAT detection > notifications are always placed in IKE_SA_INIT exchange, not > INFORMATIONAL (MOBIKE adds this functionality, though). > > 6) Section 7: "The IETF MOBIKE working group is looking into providing > a solution for IKEv2 but the work is still in progress". MOBIKE WG > has been closed (the document is in RFC editor's queue). > > 7) I'd suggest using RFC4301's bi-directional SPD notation instead > of the separate SPD-in and SPD-out. > > Best regards, > Pasi From owner-v6ops@ops.ietf.org Tue May 23 13:30:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiai5-0004xP-TJ for v6ops-archive@lists.ietf.org; Tue, 23 May 2006 13:30:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiai4-0001N9-Bs for v6ops-archive@lists.ietf.org; Tue, 23 May 2006 13:30:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiaeP-000Juj-RZ for v6ops-data@psg.com; Tue, 23 May 2006 17:26:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.1.1 Received: from [192.6.111.86] (helo=grerelbas02.bastion.europe.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiaeL-000JuJ-LM for v6ops@ops.ietf.org; Tue, 23 May 2006 17:26:31 +0000 Received: from IDAEXG12.emea.cpqcorp.net (idaexg12.emea.cpqcorp.net [16.16.5.39]) by grerelbas02.bastion.europe.hp.com (Postfix) with ESMTP id 5547E3414E; Tue, 23 May 2006 19:26:20 +0200 (CEST) Received: from mail pickup service by IDAEXG12.emea.cpqcorp.net with Microsoft SMTPSVC; Tue, 23 May 2006 19:26:00 +0200 Received: from grerelbas03.bastion.europe.hp.com ([15.191.5.39]) by IDAEXG12.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 13:35:38 +0200 Received: from ccerelrim01.cce.hp.com (smtp.cce.hp.com [161.114.21.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by grerelbas03.bastion.europe.hp.com (Postfix) with ESMTP id 69D0834053; Mon, 22 May 2006 13:35:38 +0200 (CEST) Received: from ccerelrim01.cce.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 81DB618D398; Mon, 22 May 2006 06:35:14 -0500 (CDT) 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 ccerelrim01.cce.hp.com (Postfix) with ESMTP id 88B3F18D42C; Mon, 22 May 2006 06:35:13 -0500 (CDT) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi8c8-0000Js-Dz for v6ops-data@psg.com; Mon, 22 May 2006 11:30:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi8c5-0000JZ-CD for v6ops@ops.ietf.org; Mon, 22 May 2006 11:30:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4MBUAXC026729; Mon, 22 May 2006 14:30:10 +0300 Date: Mon, 22 May 2006 14:30:10 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: hannes.tschofenig@siemens.com, rfg@acm.org, Mohan.Parthasarathy@nokia.com Subject: draft-ietf-v6ops-ipsec-tunnels-02 review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-Virus-Scanned: ClamAV 0.88.2/1474/Sun May 21 16:18:22 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.1 X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.22.41613 X-OriginalArrivalTime: 22 May 2006 11:35:38.0861 (UTC) FILETIME=[D974C1D0:01C67D93] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 FYI, as a co-author, I solicited one extra IPsec expert review from Pasi Eronen for draft-ietf-v6ops-ipsec-tunnels-02. Unfortanately, the document still needs a bit of work. ---------- Forwarded message ---------- I have three major comments (which I believe require significant further work), and a couple of minor comments (that should be easy to address). The major ones first: 1) I found it very difficult to reconcile the "generic SPD" described in this document with the IPsec architecture in RFC4301. An SPD is an ordered database, so having one SPD contain multiple entries with just "match everything" selectors doesn't seem to make much sense. So it looks like either we have to consider each interface (IPv6-in-IPv4 tunnel) having its own SPD, or the interface is used as a selector in the SPD. There's nothing wrong with this -- and I guess it can be made to work if the IPsec SAs are configured manually -- but it does cause complications with IKE. In particular, when the IKE responder receives a request to create a new IPsec SA, how does it know which interface this corresponds to? For "real" interfaces, an obvious answer would be "the interface where the IKE packets came from" -- but I guess in this case, the IKE packets are sent using the normal IPv4 interface, not the tunnel "pseudo-interface". I guess there are ways how this can be handled, especially if the host/gateway has only a single IPv6-in-IPv4 tunnel. But the document needs much more text about this. 2) Section 8 and Security Considerations: Simply knowing the tunnel endpoint's IP address is not sufficient: the initiator also needs to know how it should authenticate itself to the remote peer, and what kind of authentication to expect from the remote peer. For example, if the responder is authenticated using certificates, the initiator has to know what the right subject name is. In other words: how do we discover the PAD identities and peer authentication data? 3) PAD "Child SA Authorization Data" needs to be described, for all three cases (transport, tunnel with specific SPD, tunnel with SPD). Minor comments: 4) Section 4: "[RFC2401] does not support transport mode SAs between hosts and security gateways." This is a misunderstanding of RFC2401: these IP packets are destined to the "gateway" (they have the gateway's IP address as the destination IP address), so at the point where this SA is relevant, it's acting as a host, and using transport mode is allowed. Decapsulating the IP-in-IP packet happens higher up in the stack (and for this purpose, it doesn't matter whether the tunneling protocol is IP-in-IP or GRE or MIP-over-UDP or SOCKS or something else). 5) Section 7: "IKEv2 can detect the presence of a NAT automatically by sending an Informational exchange with NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec SA." No such functionality is described in RFC4306; the NAT detection notifications are always placed in IKE_SA_INIT exchange, not INFORMATIONAL (MOBIKE adds this functionality, though). 6) Section 7: "The IETF MOBIKE working group is looking into providing a solution for IKEv2 but the work is still in progress". MOBIKE WG has been closed (the document is in RFC editor's queue). 7) I'd suggest using RFC4301's bi-directional SPD notation instead of the separate SPD-in and SPD-out. Best regards, Pasi From owner-v6ops@ops.ietf.org Tue May 23 18:50:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fifi0-00058o-UU for v6ops-archive@lists.ietf.org; Tue, 23 May 2006 18:50:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fifi0-0000kk-S9 for v6ops-archive@lists.ietf.org; Tue, 23 May 2006 18:50:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fife3-0004o5-9a for v6ops-archive@lists.ietf.org; Tue, 23 May 2006 18:46:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FifbV-000Blp-EE for v6ops-data@psg.com; Tue, 23 May 2006 22:43:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FifbU-000Blc-NQ for v6ops@ops.ietf.org; Tue, 23 May 2006 22:43:52 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 May 2006 15:43:52 -0700 X-IronPort-AV: i="4.05,162,1146466800"; d="scan'208"; a="281729036:sNHT32974108" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4NMhqCp020046 for ; Tue, 23 May 2006 15:43:52 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4NMhqJj000178 for ; Tue, 23 May 2006 15:43:52 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4NMexEX027203 for ; Tue, 23 May 2006 15:40:59 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: Status of various documents Date: Tue, 23 May 2006 15:43:50 -0700 X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-5.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2718; t=1148424232; x=1149288232; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Status=20of=20various=20documents; X=v=3Dcisco.com=3B=20h=3DWJdTp4W6693cx1O0rW3GQnvljoQ=3D; b=GU9ArFlvaZZTKU6hwzm0O5Jp8RRZnqqB4Q6elhZcN2TQKCBEdubMdeea/8FlWIRjnf1Wcc1C HGtwWzxB3NatThsu/zf2Ancv2MFz0rRJn1MacZrblTuCFuwMI2hyPrUd; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 So I'm piling through to figure out what the status of the various documents in v6ops are. We have 21 documents with the name "v6ops" in them, many of which are individual submissions and some of which relate to transition mechanisms and are therefore not a category we are supposed to look at. The good news here is that the tools team has put together a web page to show this information, which is at http://tools.ietf.org/wg/v6ops/. At this instant, we have five documents in IESG Processing: draft-ietf-v6ops-natpt-to-exprmntl 2005-10-21 18:30 AD Evaluation draft-ietf-v6ops-bb-deployment-scenarios 2005-10-21 18:38 IESG Evaluation draft-ietf-v6ops-nap 2005-10-25 13:55 IESG Evaluation draft-ietf-v6ops-security-overview 2006-03-08 19:24 IESG Evaluation draft-ietf-v6ops-ent-analysis 2006-05-08 19:20 Publication Requested and two in the RFC Editor's queue draft-ietf-v6ops-onlinkassumption 2006-01-17 15:50 draft-ietf-v6ops-vlan-usage 2006-03-09 16:40 Last call closed with some comments on draft-ietf-v6ops-icmpv6- filtering-recs, so I am waiting for an updated document before sending that to the IESG. There has been a security review of draft-ietf-v6ops-ipsec-tunnels, and I am expecting an updated draft before sending it to David. It may require another WGLC. I am waiting for an updated draft of draft-chown-v6ops-port-scanning- implications to open WGLC. I believe that the following hold: draft-blanchet-v6ops-routing-guidelines-01.txt 2006-03-07 17:27 Looking for an update from Marc draft-blanchet-v6ops-tunnelbroker-tsp-03.txt 2005-10-08 22:00 Out of scope draft-chown-v6ops-campus-transition-02.txt 2006-03-09 18:32 Looking for working group review. Tim to finish sections 4-7 and repost. draft-chown-v6ops-renumber-thinkabout-04.txt 2006-03-09 17:39 At Tim's discretion draft-manral-v6ops-tiny-fragments-issues-02.txt 2006-01-09 17:48 Draft is dead; there was a working group email discussion and it was closed. draft-massar-v6ops-heartbeat-01.txt 2005-10-08 22:00 Out of scope draft-ooms-v6ops-bgp-tunnel-06.txt 2006-01-18 17:09 Publication requested by idr draft-palet-v6ops-6in4-vs-6over4-01.txt 2005-11-16 18:24 Draft is dead draft-palet-v6ops-point2point-00.txt 2006-03-01 13:43 Draft is dead draft-shin-v6ops-802-16-deployment-scenarios-00.txt 2006-03-02 16:46 Being republished as a working group draft Looking for WG review draft-vandevelde-v6ops-addcon-00.txt 2006-02-13 20:10 Looking for working group review From owner-v6ops@ops.ietf.org Wed May 24 03:06:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FinRT-0004Rr-Ia for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 03:06:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FinRR-0006tu-0m for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 03:06:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FinOW-000BVr-SU for v6ops-data@psg.com; Wed, 24 May 2006 07:03:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.197] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FinOV-000BVf-MH for v6ops@ops.ietf.org; Wed, 24 May 2006 07:02:59 +0000 Received: by wx-out-0102.google.com with SMTP id s8so1095927wxc for ; Wed, 24 May 2006 00:02:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bnWWWaOgm7rWHMWqDZbztaoe8BQuLFmaYbdUq+JCIKHJcJcEp1/ecIZoOycIAdQKkH2uc4J90spSzRG4RLq+4t3Z0sq51RH1wqgwAcPK8PrF/pNFbq8AcSHM8Pv3z6hU8zJYZ9ELweFKs+r+Xq1UCVUh7KygMGTbD+CSvaN+3DQ= Received: by 10.70.46.9 with SMTP id t9mr4873313wxt; Wed, 24 May 2006 00:02:58 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Wed, 24 May 2006 00:02:58 -0700 (PDT) Message-ID: <77ead0ec0605240002j121b0f7ar67aacc3c8e661115@mail.gmail.com> Date: Wed, 24 May 2006 12:32:58 +0530 From: "Vishwas Manral" To: "Fred Baker" Subject: Re: Status of various documents Cc: v6ops@ops.ietf.org In-Reply-To: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_54871_8456642.1148454178619" References: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c ------=_Part_54871_8456642.1148454178619 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Fred, One small doubt. Do let me know if I am missing something? I am not sure the draft http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny-fragments-issue= s-02.txt is dead. It still exists in the IETF repository. I am not sure of a discussion which said the draft is not required? The discussion we had was on an initial version of the draft and can be located at http://ops.ietf.org/lists/v6ops/v6ops.2005/msg00693.html Thanks, Vishwas On 5/24/06, Fred Baker wrote: > > So I'm piling through to figure out what the status of the various > documents in v6ops are. We have 21 documents with the name "v6ops" in > them, many of which are individual submissions and some of which > relate to transition mechanisms and are therefore not a category we > are supposed to look at. The good news here is that the tools team > has put together a web page to show this information, which is at > http://tools.ietf.org/wg/v6ops/. > > At this instant, we have five documents in IESG Processing: > draft-ietf-v6ops-natpt-to-exprmntl > 2005-10-21 18:30 > AD Evaluation > > draft-ietf-v6ops-bb-deployment-scenarios > 2005-10-21 18:38 > IESG Evaluation > > draft-ietf-v6ops-nap > 2005-10-25 13:55 > IESG Evaluation > > draft-ietf-v6ops-security-overview > 2006-03-08 19:24 > IESG Evaluation > > draft-ietf-v6ops-ent-analysis > 2006-05-08 19:20 > Publication Requested > > and two in the RFC Editor's queue > draft-ietf-v6ops-onlinkassumption > 2006-01-17 15:50 > > draft-ietf-v6ops-vlan-usage > 2006-03-09 16:40 > > Last call closed with some comments on draft-ietf-v6ops-icmpv6- > filtering-recs, so I am waiting for an updated document before > sending that to the IESG. > > There has been a security review of draft-ietf-v6ops-ipsec-tunnels, > and I am expecting an updated draft before sending it to David. It > may require another WGLC. > > I am waiting for an updated draft of draft-chown-v6ops-port-scanning- > implications to open WGLC. > > I believe that the following hold: > > draft-blanchet-v6ops-routing-guidelines-01.txt 2006-03-07 17:27 > Looking for an update from Marc > > draft-blanchet-v6ops-tunnelbroker-tsp-03.txt 2005-10-08 22:00 > Out of scope > > draft-chown-v6ops-campus-transition-02.txt 2006-03-09 18:32 > Looking for working group review. Tim to finish sections 4-7 and > repost. > > draft-chown-v6ops-renumber-thinkabout-04.txt 2006-03-09 17:39 > At Tim's discretion > > draft-manral-v6ops-tiny-fragments-issues-02.txt 2006-01-09 17:48 > Draft is dead; there was a working group email discussion and it > was > closed. > > draft-massar-v6ops-heartbeat-01.txt 2005-10-08 22:00 > Out of scope > > draft-ooms-v6ops-bgp-tunnel-06.txt 2006-01-18 17:09 > Publication requested by idr > > draft-palet-v6ops-6in4-vs-6over4-01.txt 2005-11-16 18:24 > Draft is dead > > draft-palet-v6ops-point2point-00.txt 2006-03-01 13:43 > Draft is dead > > draft-shin-v6ops-802-16-deployment-scenarios-00.txt 2006-03-02 16:46 > Being republished as a working group draft > Looking for WG review > > draft-vandevelde-v6ops-addcon-00.txt 2006-02-13 20:10 > Looking for working group review > > ------=_Part_54871_8456642.1148454178619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Fred,
 
One small doubt. Do let me know if I am missing something?
 
I am not sure the draft http://www.ietf.org/inter= net-drafts/draft-manral-v6ops-tiny-fragments-issues-02.txt is dead= . It still exists in the IETF repository.
 
I am not sure of a discussion which said the draft is not required? Th= e discussion we had was on an initial version of the draft and can be locat= ed at
 
Thanks,
Vishwas

 
On 5/24/06, = Fred Baker <fred@cisco.com>= wrote:
So I'm piling through to figure = out what the status of the various
documents in v6ops are. We have 21 do= cuments with the name "v6ops" in
them, many of which are individual submissions and some of which
rel= ate to transition mechanisms and are therefore not a category we
are sup= posed to look at. The good news here is that the tools team
has put toge= ther a web page to show this information, which is at
http://tools.ietf.org/wg/v6= ops/.

At this instant, we have five documents in IESG Processing= :
       draft-ietf-v6ops-natpt-to-exprmnt= l
       2005-10-21 18:30
       AD Evaluation

  &= nbsp;    draft-ietf-v6ops-bb-deployment-scenarios
 &= nbsp;     2005-10-21 18:38
    &= nbsp;  IESG Evaluation

       dra= ft-ietf-v6ops-nap
       2005-10-25 13:55<= br>       IESG Evaluation

       draft-ietf-v6ops-security-overview=
       2006-03-08 19:24
  &n= bsp;    IESG Evaluation

     = ;  draft-ietf-v6ops-ent-analysis
     &nbs= p; 2006-05-08 19:20
       Publication Req= uested

and two in the RFC Editor's queue
       draft-ietf-v6ops-onlinkassumption<= br>       2006-01-17 15:50

  = ;     draft-ietf-v6ops-vlan-usage
   =     2006-03-09 16:40

Last call closed with some comme= nts on draft-ietf-v6ops-icmpv6-
filtering-recs, so I am waiting for an u= pdated document before
sending that to the IESG.

There has been a security review of dr= aft-ietf-v6ops-ipsec-tunnels,
and I am expecting an updated draft before= sending it to David. It
may require another WGLC.

I am waiting f= or an updated draft of draft-chown-v6ops-port-scanning-
implications to open WGLC.

I believe that  the followi= ng hold:

draft-blanchet-v6ops-routing-guidelines-01.txt  &= nbsp;    2006-03-07 17:27
     &= nbsp; Looking for an update from Marc

draft-blanchet-v6ops-tunnelbro= ker-tsp-03.txt          2005-10-08 22:00
 =       Out of scope

draft-chown-v6ops-campus= -transition-02.txt         &nb= sp; 2006-03-09 18:32
       Looking for wo= rking group review. Tim to finish sections 4-7 and
repost.

draft-= chown-v6ops-renumber-thinkabout-04.txt          2006-03-09 17:39
 =       At Tim's discretion

draft-manral-v6op= s-tiny-fragments-issues-02.txt      2006-01-0= 9 17:48
       Draft is dead; there was a = working group email discussion and it was
closed.

draft-massar-v6ops-heartbeat-01.txt     &n= bsp;            = ;2005-10-08 22:00
       Out of scope
<= br>draft-ooms-v6ops-bgp-tunnel-06.txt      &n= bsp;            2006= -01-18 17:09
       Publication requested = by idr

draft-palet-v6ops-6in4-vs-6over4-01.txt      =         2005-11-16 18:24
 &= nbsp;     Draft is dead

draft-palet-v6ops-point2= point-00.txt          &nb= sp;      2006-03-01 13:43
   &nb= sp;   Draft is dead

draft-shin-v6ops-802-16-deployment-sce= narios-00.txt   2006-03-02 16:46
       Being = republished as a working group draft
      = ; Looking for WG review

draft-vandevelde-v6ops-addcon-00.txt &n= bsp;            = ;   2006-02-13 20:10
       Look= ing for working group review


------=_Part_54871_8456642.1148454178619-- From owner-v6ops@ops.ietf.org Wed May 24 11:14:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiv4M-00073W-98 for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 11:14:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiv4J-0004Ah-Ve for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 11:14:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fiv0e-000D7E-6R for v6ops-data@psg.com; Wed, 24 May 2006 15:10:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fiv0d-000D71-I7 for v6ops@ops.ietf.org; Wed, 24 May 2006 15:10:51 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 24 May 2006 08:10:51 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="1811999154:sNHT61046096" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4OFAopa017366; Wed, 24 May 2006 08:10:50 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4OFAoHc005591; Wed, 24 May 2006 08:10:50 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4OF7hYf016621; Wed, 24 May 2006 08:07:55 -0700 In-Reply-To: <77ead0ec0605240002j121b0f7ar67aacc3c8e661115@mail.gmail.com> References: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> <77ead0ec0605240002j121b0f7ar67aacc3c8e661115@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <516F5B4E-3893-451D-A23E-E6B9DB549B35@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of various documents Date: Wed, 24 May 2006 08:10:49 -0700 To: "Vishwas Manral" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=446; t=1148483450; x=1149347450; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20various=20documents; X=v=3Dcisco.com=3B=20h=3DAfNULCmqrmjRzzGfrH8DnclSAnE=3D; b=HuhhKiN+WgImVqvzMv78SL5xfJNnkpK6BxlI+jSOAjjZwBDNeYnhyPBE1aG2CmRMuNCC5SJo kLf78eUyT1EeGE7V1cmSoLLlGITpaLcaBeSSK/koqEfjzkj9UodG/3/P; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: > I am not sure the draft http://www.ietf.org/internet-drafts/draft- > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists > in the IETF repository. Yes, it is in the repository; it remains until they flush it out. What I was saying is that discussion seems to be at an end. What would you like to do with it further? Do you plan to continue driving this? From owner-v6ops@ops.ietf.org Wed May 24 11:36:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivPC-0007zw-SX for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 11:36:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivPB-0005Co-J0 for v6ops-archive@lists.ietf.org; Wed, 24 May 2006 11:36:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FivOG-000Emi-SJ for v6ops-data@psg.com; Wed, 24 May 2006 15:35:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FivOE-000EmJ-FR for v6ops@ops.ietf.org; Wed, 24 May 2006 15:35:14 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 May 2006 08:35:05 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="282194810:sNHT5736063446" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4OFZ3Kn020178 for ; Wed, 24 May 2006 08:35:03 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4OFZ3Hc024137 for ; Wed, 24 May 2006 08:35:03 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4OFW8i3017202 for ; Wed, 24 May 2006 08:32:08 -0700 Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <888BBEE0-4481-4A39-914A-2F621E111B44@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: IANA considerations confusion Date: Wed, 24 May 2006 08:35:02 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1430; t=1148484903; x=1149348903; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Fwd=3A=20IANA=20considerations=20confusion; X=v=3Dcisco.com=3B=20h=3DgZo4smdBHFPn6xGNRkPQjntofbg=3D; b=ANM9wrWTh8XFRBlUZfLdZWhhS4g+2q77kfpSYGUEodb9pqhRpnh6QfW33CRLqeDVZArWl14u MsxWuMrIbn1A9loDC14f7DY7IURujeDDfZ136Uy9IoMhb3B9YiAmeCkK; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 FYI. I don't think this is especially relevant in this WG, as we don't do protocols. But if you have issues with IANA considerations, you might read the I-D for guidance. Begin forwarded message: > From: > Date: May 24, 2006 1:30:44 AM PDT > To: > Subject: IANA considerations confusion > > Hi, > > During the past two months alone, I've encountered two different > cases where a document author, even having read RFC2434, believed > that the "IANA Considerations" section has to include only new > registries created in the document, but not values registered in > existing registries. > > In one of these cases, this mistake was not caught until well after > the RFC had been published (the authors had provided "suggested" > values instead of TBD-BY-IANA). Fortunately, IANA had not yet > allocated these values for any other document. > > Thus, I'd recommend pointing your document authors to the much > better instructions in draft-narten-iana-considerations-rfc2434bis, > and checking the documents extra carefully if the IANA Considerations > section does not include any registrations in existing namespaces. > > Or even more strongly: if the document only creates new registries, > I'd suggest including an explicit "This document does not require > IANA to assign any values in existing registries" statement. > > Best regards, > Pasi From owner-v6ops@ops.ietf.org Thu May 25 03:02:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj9q7-0007n1-Ri for v6ops-archive@lists.ietf.org; Thu, 25 May 2006 03:00:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj9pP-0004gr-8v for v6ops-archive@lists.ietf.org; Thu, 25 May 2006 03:00:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj9lv-0009Il-Bj for v6ops-data@psg.com; Thu, 25 May 2006 06:56:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.1 Received: from [64.233.162.197] (helo=nz-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj9lm-0009Ht-Li for v6ops@ops.ietf.org; Thu, 25 May 2006 06:56:30 +0000 Received: by nz-out-0102.google.com with SMTP id x7so1488344nzc for ; Wed, 24 May 2006 23:56:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X1WiU1Y0JeqA2u5uM7cbo83D15IIRWseFFgfmsGlQ2VdB+BHRB60ZgZnF3Xb9ciMq/I7rQWfvLtDjSbZq6JAnq47DbMGSid4dwtCEI7xGWZP0b5H7jsRdX5XJV68uZkhUrin8ZBLxro4gH3HNO30GkkrlvA/vlKAMSPeXBqdTCI= Received: by 10.85.2.4 with SMTP id e4mr3077421aui; Wed, 24 May 2006 23:56:28 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Wed, 24 May 2006 23:56:28 -0700 (PDT) Message-ID: <77ead0ec0605242356q1a38e3a0p4a9bd3ab7a8df485@mail.gmail.com> Date: Thu, 25 May 2006 12:26:28 +0530 From: "Vishwas Manral" To: "Fred Baker" Subject: Re: Status of various documents Cc: v6ops@ops.ietf.org In-Reply-To: <516F5B4E-3893-451D-A23E-E6B9DB549B35@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69994_3235585.1148540188571" References: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> <77ead0ec0605240002j121b0f7ar67aacc3c8e661115@mail.gmail.com> <516F5B4E-3893-451D-A23E-E6B9DB549B35@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_Part_69994_3235585.1148540188571 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Fred, I thought it was an important enough issue to be addressed, from the operational perspective. If possible I would want to drive it further. Would be eager to get your views on the same. Thanks for restarting the discussion, Vishwas On 5/24/06, Fred Baker wrote: > > > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: > > > I am not sure the draft http://www.ietf.org/internet-drafts/draft- > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists > > in the IETF repository. > > Yes, it is in the repository; it remains until they flush it out. > What I was saying is that discussion seems to be at an end. > > What would you like to do with it further? Do you plan to continue > driving this? > ------=_Part_69994_3235585.1148540188571 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Fred,
 
I thought it was an important enough issue to be addressed, from the o= perational perspective.
 
If possible I would want to drive it further. Would be eager= to get your views on the same.
 
Thanks for restarting the discussion,
Vishwas
 
On 5/24/06, = Fred Baker <fred@cisco.com>= wrote:

On May 24, 2006, at 12:02 AM= , Vishwas Manral wrote:

> I am not sure the draft http://www.ietf.org/internet-drafts/draft-
> manral-v6ops-tiny-fr= agments-issues-02.txt is dead. It still exists
> in the IETF reposito= ry.

Yes, it is in the repository; it remains until they flush it out= .
What I was saying is that discussion seems to be at an end.

What= would you like to do with it further? Do you plan to continue
driving t= his?

------=_Part_69994_3235585.1148540188571-- From owner-v6ops@ops.ietf.org Thu May 25 20:59:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQfN-0004Kk-Ui for v6ops-archive@lists.ietf.org; Thu, 25 May 2006 20:59:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjQfM-0004R7-Jl for v6ops-archive@lists.ietf.org; Thu, 25 May 2006 20:59:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjQc8-000AVw-Gq for v6ops-data@psg.com; Fri, 26 May 2006 00:55:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjQc7-000AVY-SI for v6ops@ops.ietf.org; Fri, 26 May 2006 00:55:39 +0000 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 25 May 2006 17:55:40 -0700 X-IronPort-AV: i="4.05,174,1146466800"; d="scan'208"; a="323535479:sNHT31680962" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4Q0tdhP009762 for ; Thu, 25 May 2006 17:55:39 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4Q0tdsF007225 for ; Thu, 25 May 2006 17:55:39 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4Q0qcqu029073 for ; Thu, 25 May 2006 17:52:38 -0700 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <77ead0ec0605242356q1a38e3a0p4a9bd3ab7a8df485@mail.gmail.com> References: <769B92A9-778F-4B30-BBB7-321F77FB9033@cisco.com> <77ead0ec0605240002j121b0f7ar67aacc3c8e661115@mail.gmail.com> <516F5B4E-3893-451D-A23E-E6B9DB549B35@cisco.com> <77ead0ec0605242356q1a38e3a0p4a9bd3ab7a8df485@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of various documents Date: Thu, 25 May 2006 17:55:37 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-8.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2487; t=1148604939; x=1149468939; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20various=20documents; X=v=3Dcisco.com=3B=20h=3DAfNULCmqrmjRzzGfrH8DnclSAnE=3D; b=X4qINFuvHec3ryFSFDYR4yQEM/Uh06MxAqBlygm348nqU+dt+eb57zLJCzWS426f94cl6ytg LyVg37kZDbyCq8N9Sbbbv7GIegtMpdeiAYHEBbr0Ljl+VtIJwwhYLy+S; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 OK, folks. Lets get a review. http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny- fragments-issues-02.txt "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, 9-Jan-06, The principal comment that I noted from our previous discussion was that the problem existed for IPv4 also, and hence was not specifically an IPv6 problem. The working group did not choose to make a recommendation on the topic, and personally I wasn't aware that we were asked to. The key recommendation seems to be that there be a minimum MTU size large enough to contain the IPv6 header (with all of its additional headers) plus the second layer header, and that middleware devices like firewalls discard messages that were a non- last fragment and were smaller than that size. In such a case, this would convert the attack to another kind of attack, one in which the target is bombarded with fragments of messages, but never enabled to reassemble them, and attacking the reassembly tables and associated memory. The solution for that is fortunately trivial - in the event that there is any any overload in this area, discard the oldest fragment in the buffer and any other fragments that are presumptively part of the same message - the same way we protect TCP TCBs. The origin of the discussion was in Mobile IP, where related issues were addressed. What do folks wish the document said? Is this something for the working group to make an effort on? Is there a feeling that it should be a working group draft? On May 24, 2006, at 11:56 PM, Vishwas Manral wrote: > Hi Fred, > > I thought it was an important enough issue to be addressed, from > the operational perspective. > > If possible I would want to drive it further. Would be eager to get > your views on the same. > > Thanks for restarting the discussion, > Vishwas > > On 5/24/06, Fred Baker wrote: > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: > > > I am not sure the draft http://www.ietf.org/internet-drafts/draft- > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists > > in the IETF repository. > > Yes, it is in the repository; it remains until they flush it out. > What I was saying is that discussion seems to be at an end. > > What would you like to do with it further? Do you plan to continue > driving this? > From owner-v6ops@ops.ietf.org Fri May 26 01:10:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjUaI-0005bv-TP for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 01:10:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjUaE-0002jx-F4 for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 01:10:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjUXi-0000t4-Lr for v6ops-data@psg.com; Fri, 26 May 2006 05:07:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.196] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjUXh-0000sr-JT for v6ops@ops.ietf.org; Fri, 26 May 2006 05:07:21 +0000 Received: by wx-out-0102.google.com with SMTP id s8so1426778wxc for ; Thu, 25 May 2006 22:07:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=HFNJbZRLtuqtuIya6fLfJdtMcP5TsEddEypC2aeM+j7YxkMgDwLHRU7vzTqB8kzOcP4f3AIwVV+llbCJC3V/ztcotvgYLDctqRz4hbHPMcJz0OplO0is9ILiq77aAuQlzx06ID1p77IZsWWYmZDjG4ocrI5bVzX3ECOBcPY+1D4= Received: by 10.70.53.10 with SMTP id b10mr302472wxa; Thu, 25 May 2006 22:07:20 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Thu, 25 May 2006 22:07:20 -0700 (PDT) Message-ID: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> Date: Fri, 26 May 2006 10:37:20 +0530 From: "Vishwas Manral" To: "Fred Baker" Subject: Status of Operational issues with Tiny Fragments in IPv6 Cc: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Fred, Thanks a lot for summarizing the issue. I have changed the subject line to more closely reflect the discussion. Just to remind the people the discussion on this topic happened more on the ipv6 list than on the v6ops list. The way I see the problem is that we have middlebox devices, so that we do not have to cram all the functionality in each of the end devices and it also makes the entire thing easier to manage. A lot of basic attacks(example SYN flood) are detected by seeing discrepancies in the header fields. For IPv4 firewalls will drop/ send to slow path packets with IP options and the packet of below 64 bytes is dropped for non-last fragment. In IPv4 this way we solve the problem of having the header fields not broken across fragments. In IPv6 options are now a standard part.of the protocol. We need to state what the non-last fragment size can be because by doing so we do not have a way for the attacker to pass the firewall yet be accepted by an end host. A simple solution recommended by the IPv6 chairs was to drop all such packe= ts. Thanks, Vishwas On 5/26/06, Fred Baker wrote: > OK, folks. Lets get a review. > > http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny- > fragments-issues-02.txt > "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, > 9-Jan-06, > > > The principal comment that I noted from our previous discussion was > that the problem existed for IPv4 also, and hence was not > specifically an IPv6 problem. The working group did not choose to > make a recommendation on the topic, and personally I wasn't aware > that we were asked to. The key recommendation seems to be that there > be a minimum MTU size large enough to contain the IPv6 header (with > all of its additional headers) plus the second layer header, and that > middleware devices like firewalls discard messages that were a non- > last fragment and were smaller than that size. > > In such a case, this would convert the attack to another kind of > attack, one in which the target is bombarded with fragments of > messages, but never enabled to reassemble them, and attacking the > reassembly tables and associated memory. The solution for that is > fortunately trivial - in the event that there is any any overload in > this area, discard the oldest fragment in the buffer and any other > fragments that are presumptively part of the same message - the same > way we protect TCP TCBs. > > The origin of the discussion was in Mobile IP, where related issues > were addressed. > > What do folks wish the document said? Is this something for the > working group to make an effort on? Is there a feeling that it should > be a working group draft? > > > On May 24, 2006, at 11:56 PM, Vishwas Manral wrote: > > > Hi Fred, > > > > I thought it was an important enough issue to be addressed, from > > the operational perspective. > > > > If possible I would want to drive it further. Would be eager to get > > your views on the same. > > > > Thanks for restarting the discussion, > > Vishwas > > > > On 5/24/06, Fred Baker wrote: > > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: > > > > > I am not sure the draft http://www.ietf.org/internet-drafts/draft- > > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists > > > in the IETF repository. > > > > Yes, it is in the repository; it remains until they flush it out. > > What I was saying is that discussion seems to be at an end. > > > > What would you like to do with it further? Do you plan to continue > > driving this? > > > From owner-v6ops@ops.ietf.org Fri May 26 01:37:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjV0a-0004b3-Dg for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 01:37:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjV0W-0004P7-VG for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 01:37:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjUzu-0002St-QV for v6ops-data@psg.com; Fri, 26 May 2006 05:36:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjUzs-0002Se-7b for v6ops@ops.ietf.org; Fri, 26 May 2006 05:36:28 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 25 May 2006 22:36:28 -0700 X-IronPort-AV: i="4.05,175,1146466800"; d="scan'208"; a="1813205712:sNHT31479864" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4Q5aRqI029458 for ; Thu, 25 May 2006 22:36:27 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4Q5aRB9025962 for ; Thu, 25 May 2006 22:36:27 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4Q5XQHo002779 for ; Thu, 25 May 2006 22:33:26 -0700 Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4EE5989C-6235-4A11-A8BE-2E007C4EF498@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Date: Thu, 25 May 2006 22:36:26 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1896; t=1148621787; x=1149485787; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=20the=2066t h=20IETF=20Meeting=20in=20Montreal,=20Quebec,=20Canada=20; X=v=3Dcisco.com=3B=20h=3D28kQSnuMPzXNqubXCxnKFzp/Abk=3D; b=vNvgbQwI80zxxWJ4SwDhvBj93DH+5klQQuGbuZZ62aoWzeSdv9rqmXbBDLGjx0GOgDQSdTX4 PB9b4bPIptZyU2RHsaZq+mPIpRSkpzCiHxZ/lO1naiiBV1l3NSxvhrno; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: May 25, 2006 9:00:01 PM PDT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF > Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 66th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Fri May 26 04:23:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjXbp-0001k9-VM for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 04:23:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjXbo-0002to-D6 for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 04:23:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjXXK-0006id-HJ for v6ops-data@psg.com; Fri, 26 May 2006 08:19:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjXXI-0006iH-Qu for v6ops@ops.ietf.org; Fri, 26 May 2006 08:19:09 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FjXXF-00029B-Ef; Fri, 26 May 2006 09:19:05 +0100 Message-ID: <4476BA9F.1040008@dial.pipex.com> Date: Fri, 26 May 2006 09:21:51 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Vishwas Manral CC: Fred Baker , v6ops@ops.ietf.org Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> In-Reply-To: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 These issues are already discussed in sections 2.1.10 and 2.1.11 of draft-v6ops-security-overview-04. I didn't get involved too much in the discussion of Vishwas' draft because I had already been round the loop of suggesting to the ipv6 wg that the base standard should be modified to recommend - no overlapping fragments and - non-last fragments to be close to the guaranteed minimum MTU. This didn't get much traction. However the concerns are valid. I would suggest that rather than making this into a separate draft we can look at improving the text in the security overview (if necessary) given that we are probably ging to have to do *another* round on this one. Regards, Elwyn Vishwas Manral wrote: > Hi Fred, > > Thanks a lot for summarizing the issue. I have changed the subject > line to more closely reflect the discussion. Just to remind the people > the discussion on this topic happened more on the ipv6 list than on > the v6ops list. > The way I see the problem is that we have middlebox devices, so that > we do not have to cram all the functionality in each of the end > devices and it also makes the entire thing easier to manage. > > A lot of basic attacks(example SYN flood) are detected by seeing > discrepancies in the header fields. For IPv4 firewalls will drop/ send > to slow path packets with IP options and the packet of below 64 bytes > is dropped for non-last fragment. In IPv4 this way we solve the > problem of having the header fields not broken across fragments. > > In IPv6 options are now a standard part.of the protocol. We need to > state what the non-last fragment size can be because by doing so we do > not have a way for the attacker to pass the firewall yet be accepted > by an end host. > A simple solution recommended by the IPv6 chairs was to drop all such > packets. > > Thanks, > Vishwas > On 5/26/06, Fred Baker wrote: >> OK, folks. Lets get a review. >> >> http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny- >> fragments-issues-02.txt >> "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, >> 9-Jan-06, >> >> >> The principal comment that I noted from our previous discussion was >> that the problem existed for IPv4 also, and hence was not >> specifically an IPv6 problem. The working group did not choose to >> make a recommendation on the topic, and personally I wasn't aware >> that we were asked to. The key recommendation seems to be that there >> be a minimum MTU size large enough to contain the IPv6 header (with >> all of its additional headers) plus the second layer header, and that >> middleware devices like firewalls discard messages that were a non- >> last fragment and were smaller than that size. >> >> In such a case, this would convert the attack to another kind of >> attack, one in which the target is bombarded with fragments of >> messages, but never enabled to reassemble them, and attacking the >> reassembly tables and associated memory. The solution for that is >> fortunately trivial - in the event that there is any any overload in >> this area, discard the oldest fragment in the buffer and any other >> fragments that are presumptively part of the same message - the same >> way we protect TCP TCBs. >> >> The origin of the discussion was in Mobile IP, where related issues >> were addressed. >> >> What do folks wish the document said? Is this something for the >> working group to make an effort on? Is there a feeling that it should >> be a working group draft? >> >> >> On May 24, 2006, at 11:56 PM, Vishwas Manral wrote: >> >> > Hi Fred, >> > >> > I thought it was an important enough issue to be addressed, from >> > the operational perspective. >> > >> > If possible I would want to drive it further. Would be eager to get >> > your views on the same. >> > >> > Thanks for restarting the discussion, >> > Vishwas >> > >> > On 5/24/06, Fred Baker wrote: >> > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: >> > >> > > I am not sure the draft http://www.ietf.org/internet-drafts/draft- >> > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists >> > > in the IETF repository. >> > >> > Yes, it is in the repository; it remains until they flush it out. >> > What I was saying is that discussion seems to be at an end. >> > >> > What would you like to do with it further? Do you plan to continue >> > driving this? >> > >> > From owner-v6ops@ops.ietf.org Fri May 26 05:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjYVp-00027A-Gt for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 05:21:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjYVo-0000IB-0P for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 05:21:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjYUb-000AEb-Bm for v6ops-data@psg.com; Fri, 26 May 2006 09:20:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.204] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjYUa-000AE9-5m for v6ops@ops.ietf.org; Fri, 26 May 2006 09:20:24 +0000 Received: by wx-out-0102.google.com with SMTP id s8so20065wxc for ; Fri, 26 May 2006 02:20:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B8ie7MjzJ6tY5J49VfcnjYLm9Z1ctSosgIMQWuxIFTvZedWDeYOl6zYcVrqGbpXeC3wGQCJOdluFmV/k13KdWIAl7xN9l56Xj/Ml9X0fAl0MRawwvJp55URsu65QTRBOWjxlZS8Hrv2h+/JJ9ZrVKxbf/gQWjO0ojn7rvItWH8c= Received: by 10.70.117.9 with SMTP id p9mr45477wxc; Fri, 26 May 2006 02:20:23 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Fri, 26 May 2006 02:20:23 -0700 (PDT) Message-ID: <77ead0ec0605260220y658a5315q194f5eb4f9ba857b@mail.gmail.com> Date: Fri, 26 May 2006 14:50:23 +0530 From: "Vishwas Manral" To: "Elwyn Davies" Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Cc: "Fred Baker" , v6ops@ops.ietf.org In-Reply-To: <4476BA9F.1040008@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi Elwyn, I did notice the issue being raised in the security overview section. Firstly it is not just a security issue but issue for all middle boxes. Also I think security overview probably is not the best place to specify the solution to the problem. The point I bring forward is that we need not just a problem statement but also a solution of how to deal with it. Do let me know if I am off target. Thanks, Vishwas On 5/26/06, Elwyn Davies wrote: > These issues are already discussed in sections 2.1.10 and 2.1.11 of > draft-v6ops-security-overview-04. > > I didn't get involved too much in the discussion of Vishwas' draft > because I had already been round the loop of suggesting to the ipv6 wg > that the base standard should be modified to recommend > - no overlapping fragments and > - non-last fragments to be close to the guaranteed minimum MTU. > > This didn't get much traction. However the concerns are valid. > > I would suggest that rather than making this into a separate draft we > can look at improving the text in the security overview (if necessary) > given that we are probably ging to have to do *another* round on this one= . > > Regards, > Elwyn > > Vishwas Manral wrote: > > Hi Fred, > > > > Thanks a lot for summarizing the issue. I have changed the subject > > line to more closely reflect the discussion. Just to remind the people > > the discussion on this topic happened more on the ipv6 list than on > > the v6ops list. > > The way I see the problem is that we have middlebox devices, so that > > we do not have to cram all the functionality in each of the end > > devices and it also makes the entire thing easier to manage. > > > > A lot of basic attacks(example SYN flood) are detected by seeing > > discrepancies in the header fields. For IPv4 firewalls will drop/ send > > to slow path packets with IP options and the packet of below 64 bytes > > is dropped for non-last fragment. In IPv4 this way we solve the > > problem of having the header fields not broken across fragments. > > > > In IPv6 options are now a standard part.of the protocol. We need to > > state what the non-last fragment size can be because by doing so we do > > not have a way for the attacker to pass the firewall yet be accepted > > by an end host. > > A simple solution recommended by the IPv6 chairs was to drop all such > > packets. > > > > Thanks, > > Vishwas > > On 5/26/06, Fred Baker wrote: > >> OK, folks. Lets get a review. > >> > >> http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny- > >> fragments-issues-02.txt > >> "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, > >> 9-Jan-06, > >> > >> > >> The principal comment that I noted from our previous discussion was > >> that the problem existed for IPv4 also, and hence was not > >> specifically an IPv6 problem. The working group did not choose to > >> make a recommendation on the topic, and personally I wasn't aware > >> that we were asked to. The key recommendation seems to be that there > >> be a minimum MTU size large enough to contain the IPv6 header (with > >> all of its additional headers) plus the second layer header, and that > >> middleware devices like firewalls discard messages that were a non- > >> last fragment and were smaller than that size. > >> > >> In such a case, this would convert the attack to another kind of > >> attack, one in which the target is bombarded with fragments of > >> messages, but never enabled to reassemble them, and attacking the > >> reassembly tables and associated memory. The solution for that is > >> fortunately trivial - in the event that there is any any overload in > >> this area, discard the oldest fragment in the buffer and any other > >> fragments that are presumptively part of the same message - the same > >> way we protect TCP TCBs. > >> > >> The origin of the discussion was in Mobile IP, where related issues > >> were addressed. > >> > >> What do folks wish the document said? Is this something for the > >> working group to make an effort on? Is there a feeling that it should > >> be a working group draft? > >> > >> > >> On May 24, 2006, at 11:56 PM, Vishwas Manral wrote: > >> > >> > Hi Fred, > >> > > >> > I thought it was an important enough issue to be addressed, from > >> > the operational perspective. > >> > > >> > If possible I would want to drive it further. Would be eager to get > >> > your views on the same. > >> > > >> > Thanks for restarting the discussion, > >> > Vishwas > >> > > >> > On 5/24/06, Fred Baker wrote: > >> > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote: > >> > > >> > > I am not sure the draft http://www.ietf.org/internet-drafts/draft- > >> > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists > >> > > in the IETF repository. > >> > > >> > Yes, it is in the repository; it remains until they flush it out. > >> > What I was saying is that discussion seems to be at an end. > >> > > >> > What would you like to do with it further? Do you plan to continue > >> > driving this? > >> > > >> > > > From owner-v6ops@ops.ietf.org Fri May 26 11:08:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdvX-0002MY-Bo for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:08:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdvX-0005Tj-9g for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:08:35 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjdvW-0001JS-4U for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:08:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjdst-000797-Hc for v6ops-data@psg.com; Fri, 26 May 2006 15:05:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjdss-00078m-5f for v6ops@ops.ietf.org; Fri, 26 May 2006 15:05:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4QF5fVp013090; Fri, 26 May 2006 18:05:42 +0300 Date: Fri, 26 May 2006 18:05:41 +0300 (EEST) From: Pekka Savola To: Vishwas Manral cc: Elwyn Davies , Fred Baker , v6ops@ops.ietf.org Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 In-Reply-To: <77ead0ec0605260220y658a5315q194f5eb4f9ba857b@mail.gmail.com> Message-ID: References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <77ead0ec0605260220y658a5315q194f5eb4f9ba857b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1485/Thu May 25 22:29:05 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Fri, 26 May 2006, Vishwas Manral wrote: > I did notice the issue being raised in the security overview section. > > Firstly it is not just a security issue but issue for all middle > boxes. Also I think security overview probably is not the best place > to specify the solution to the problem. The point I bring forward is > that we need not just a problem statement but also a solution of how > to deal with it. FWIW, I agree that we can describe the problem (which is mostly security-related) in the overview, and already do, to some extent. This is our charter items 2 and 3. This WG isn't chartered to specify (in the normative sense, e.g., altering RFC 2460) the solution, it should likely be done by IPv6 WG or an int-area work item. I'd fully support a clean-up of the IPv6 specification (including more than just this issue), but I think folks need to talk to the Internet ADs on whether they feel this is the right thing to do and which way to go about doing it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri May 26 11:32:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeIW-0008Ju-0o for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:32:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeIT-0007HC-EV for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:32:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjeHn-000911-J6 for v6ops-data@psg.com; Fri, 26 May 2006 15:31:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjeHl-00090m-Da for v6ops@ops.ietf.org; Fri, 26 May 2006 15:31:33 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 08:31:33 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="1813514475:sNHT166801670" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4QFVWuw015772; Fri, 26 May 2006 08:31:32 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFVWsF023966; Fri, 26 May 2006 08:31:32 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QFSTqH016060; Fri, 26 May 2006 08:28:29 -0700 In-Reply-To: <4476BA9F.1040008@dial.pipex.com> References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vishwas Manral , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 08:31:30 -0700 To: Elwyn Davies X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-5.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4686; t=1148657492; x=1149521492; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20Operational=20issues=20with=20Tiny=20Fragments=20i n=20IPv6; X=v=3Dcisco.com=3B=20h=3Da5ojuOrTQJc1IP87NJ/vxv/Q9kM=3D; b=StXgTZyWrCddw7tk+h5WTxq9yMMe0FXe7EYz1J5Vy4pl7oYs6vXrP3/hZiY2yDHjoJa5ZTOV 5/5jCTv6eyjpS8fV/2IsTdwy/lsl70rHXo06iCVtjXE6Kr0KloZZvqEl; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 On May 26, 2006, at 1:21 AM, Elwyn Davies wrote: > I would suggest that rather than making this into a separate draft > we can look at improving the text in the security overview (if > necessary) given that we are probably going to have to do *another* > round on this one. That seems rational to me. A quick comment: > - no overlapping fragments and > - non-last fragments to be close to the guaranteed minimum MTU. I think the latter point wants to read "non-last fragments close to the PATH MTU, and therefore at least as large as the largest fragment size less than or equal in size to the minimum MTU." There is a discussion of fragmentation and reassembly in RFC 1812 section 4.2.2.7 that may be useful to reference, or at least learn lessons from. In part, this results from the behavior of NIC cards in the late 1980's that couldn't reliably receive datagrams back to back for very long due to chip or memory issues, and partly this is is due to brain-dead behaviors in early end-station OS's. One issue was that many systems sent packets at the minimum MTU size (then 576 bytes, derived from the memory structure of the Fuzzball and BBN Routers) rather than at the path MTU, which meant that there were greater opportunities for per-datagram errors because there were more of them. There were also various strategies on how to fragment - should the first datagram be the smallest, the last, or should the fragmenting system try to make them all approximately the same size? It makes some specific recommendations: > 4.2.2.7 Fragmentation: RFC 791 Section 3.2 > > Fragmentation, as described in [INTERNET:1], MUST be supported by a > router. > > When a router fragments an IP datagram, it SHOULD minimize the > number > of fragments. When a router fragments an IP datagram, it SHOULD > send > the fragments in order. A fragmentation method that may > generate one > IP fragment that is significantly smaller than the other MAY cause > the first IP fragment to be the smaller one. > > DISCUSSION > There are several fragmentation techniques in common use in the > Internet. One involves splitting the IP datagram into IP > fragments with the first being MTU sized, and the others being > approximately the same size, smaller than the MTU. The > reason for > this is twofold. The first IP fragment in the sequence will be > the effective MTU of the current path between the hosts, and the > following IP fragments are sized to minimize the further > fragmentation of the IP datagram. Another technique is to split > the IP datagram into MTU sized IP fragments, with the last > fragment being the only one smaller, as described in > [INTERNET:1]. > > A common trick used by some implementations of TCP/IP is to > fragment an IP datagram into IP fragments that are no larger > than > 576 bytes when the IP datagram is to travel through a router. > This is intended to allow the resulting IP fragments to pass the > rest of the path without further fragmentation. This would, > though, create more of a load on the destination host, since it > would have a larger number of IP fragments to reassemble into > one > IP datagram. It would also not be efficient on networks > where the > MTU only changes once and stays much larger than 576 bytes. > Examples include LAN networks such as an IEEE 802.5 network > with a > MTU of 2048 or an Ethernet network with an MTU of 1500). > > One other fragmentation technique discussed was splitting the IP > datagram into approximately equal sized IP fragments, with the > size less than or equal to the next hop network's MTU. This is > intended to minimize the number of fragments that would result > from additional fragmentation further down the path, and assure > equal delay for each fragment. > > Routers SHOULD generate the least possible number of IP > fragments. > > Work with slow machines leads us to believe that if it is > necessary to fragment messages, sending the small IP fragment > first maximizes the chance of a host with a slow interface of > receiving all the fragments. I think the NIC card issue (where should the smallest fragment be?) is historical and not to be worried about. But the matter of generating (by whatever algorithm) the least number of fragments that can represent a transport-level message is, I think, important. From owner-v6ops@ops.ietf.org Fri May 26 11:33:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeJa-0000FT-M9 for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:33:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeJY-0007Ju-Cg for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 11:33:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjeJS-000994-Ac for v6ops-data@psg.com; Fri, 26 May 2006 15:33:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjeJR-00098o-T3 for v6ops@ops.ietf.org; Fri, 26 May 2006 15:33:17 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 08:33:18 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="1813516192:sNHT118034216" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4QFXHBl003150; Fri, 26 May 2006 08:33:17 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFXHJj028011; Fri, 26 May 2006 08:33:17 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QFUENE016111; Fri, 26 May 2006 08:30:14 -0700 In-Reply-To: References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <77ead0ec0605260220y658a5315q194f5eb4f9ba857b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DF9957F-9FD5-413D-AB96-5CAE5B74F9C5@cisco.com> Cc: Vishwas Manral , Elwyn Davies , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 08:33:15 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-7.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=318; t=1148657597; x=1149521597; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20Operational=20issues=20with=20Tiny=20Fragments=20i n=20IPv6; X=v=3Dcisco.com=3B=20h=3Da5ojuOrTQJc1IP87NJ/vxv/Q9kM=3D; b=SszDQV1pQs4y51cH8AZhtscs7i/mtYAr+pyTGqwjfkbBnctsIU1VLJaCRT3Gua8NJBPzpC1X 9PZmzfeQUzg7sZ1NEOQFeoLXvBSxQAsOSI3qjQizBU8/OardprdskeGE; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 On May 26, 2006, at 8:05 AM, Pekka Savola wrote: > This WG isn't chartered to specify (in the normative sense, e.g., > altering RFC 2460) the solution, it should likely be done by IPv6 > WG or an int-area work item. Except that IPv6 sent it to us. I believe that they view it as an operational question. From owner-v6ops@ops.ietf.org Fri May 26 12:05:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeoQ-00087J-5C for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:05:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeoQ-0001wk-1x for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:05:18 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjeoP-00025A-7E for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:05:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjeng-000C2Y-V1 for v6ops-data@psg.com; Fri, 26 May 2006 16:04:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HOT_NASTY,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjeng-000C2C-6p for v6ops@ops.ietf.org; Fri, 26 May 2006 16:04:32 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 09:04:31 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="1813546278:sNHT113749592" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4QG4Vt7008420; Fri, 26 May 2006 09:04:31 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4QG4TsF027227; Fri, 26 May 2006 09:04:29 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QG1Pqe016824; Fri, 26 May 2006 09:01:25 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org, Lindqvist Erik Kurt Content-Transfer-Encoding: 7bit From: Fred Baker Subject: FW: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Date: Fri, 26 May 2006 09:04:26 -0700 To: "Adeel Ahmed ((adahmed))" , cpopovic@cisco.com, jordi.palet@consulintel.es, Pekka Savola , "Salman Asadullah ((sasad))" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-5.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=8103; t=1148659471; x=1149523471; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:FW=3A=20Review=20of=20draft-ietf-v6ops-bb-deployment-scenarios-04.txt; X=v=3Dcisco.com=3B=20h=3DoKckvUj6P2SCTFELswJj8R3rqLs=3D; b=Slou41kEbOdlSKH1oxwH60QU6auE8bN4cCto6ozL6xhToYOE4UrfyR5nfvbXGh1Klx2gX+y0 mfJPoRDWEQAE4hrDcTK1ZsgFl+Ld5+vDikFY2PW/bNa9ZJZ5RNxj0hzs; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e FYI. Margaret's original message seems to have not made it to v6ops, or at least through it to me and reportedly several of you. -----Original Message----- From: Margaret Wasserman Sent: Thursday, May 25, 2006 11:16 AM To: 'v6ops@ops.ietf.org'; 'iesg@ietf.org' Subject: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Hi All, While I was in a mood to review v6ops documents, I also reviewed draft-ietf-v6ops-bb-deployment-scenarios-04.txt. IMO, this is a very good document that is full of useful information, and it is nearly suitable for publication. I only found one serious issue in the document, and it non-technical. I think that section 2 should be removed from the document, because I don't think it is appropriate for the IETF to publish documents that indicate how SPs should differentiate their services and/or to comment on SPs specific products and services. I have a couple of other comments (see below), but nothing else that Should block publication of this document, IMO. Margaret --- 1.1. Common Terminology Add "BB" which is used throughout the document to mean Broadband? 2. IPv6 Based BB Services At this point IPv6 based services are seen as a differentiator that enables SPs to take advantage of the large IPv6 address space to the extent that subscribers get up to fixed /48 prefixes versus the single, temporary IPv4 addresses. Such resources allow the SPs to better position themselves against the competition. The IPv6 deployments can be seen as a driver for lower service support costs by eliminating NAT with its negative impact on applications and its complex behavior. Another reason of IPv6 being popular in some countries might be the government driven financial incentives and favorable legislation towards the ISPs who are deploying IPv6. I would remove this entire seciton (section 2) from the document. I don't think that the IETF is qualified to comment on business differentiators in the SP industry, and even if we were qualified to do so, I don't why we would want to do so. I don't think it is appropriate to mention specific companies' products and services, and timely information about what is currently deployed, including the limitations of those deployments, will probably be outdated by the time this document is published. If you don't remove this section, I think it will need a lot of work, as it mentions individual company names and product names without any disclaimers and/or indication of whether those companies have approved of what we are saying about their products, and without including such legal niceties as trademarks, etc. The network is transparent to the Layer 3 protocol. The only possible changes would come with the intent of filtering and monitoring IPv6 traffic based on layer 2 information such as IPv6 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC addresses (3333.xxxx.xxxx). What format of MAC address is this? I have most often seen Ethernet addresses represented at xx:xx:xx:xx:xx:xx, so this would be 33:33:xx:xx:xx:xx, right? But other MAC addresses may be other lengths, such as EUI-64 identifiers. Also, if one filters on an EtherType of 0x86DD, one will see all IPv6 traffic. I am not sure why an additional filter for IPv6-specific multicast addresses would be needed. Can you explain? It is important to note that the customers of a Service Provider can choose to establish tunnels to publicly available and free tunnel services. Even though the quality of such services might not be high, they provide free IPv6 access. In designing their IPv6 services, the SPs should take into considerations such options available to their potential customers. The IPv6 deployment should support services (like multicast, VoIPv6 etc) and a level of quality that would make the access through the SP worthwhile to potential subscribers. This paragraph should be removed, as it mainly provides marketing, not operational, advice to SPs. 6. Broadband Cable Networks This section describes the infrastructure that exists today in cable networks providing BB services to the home. It also describes IPv6 deployment options in these cable networks. DOCSIS standardizes and documents the operation of data over Cable Networks. The current version of DOCSIS has limitations that do not allow for a smooth implementation of native IPv6 transport. Some of these limitations are discussed in this section. For this reason, the IPv6 deployment scenarios discussed in this section for the existent Cable Networks are tunnel based. The tunneling examples presented here could also be applied to the other BB technologies described in sections 7, 8, 9 and 10. You should expand the DOCSIS acronym, add a reference for DOCSIS and state which version is the "current version" that has these limitations. 6.2.4. IPv6 QoS IPv6 will not change or add any queuing/scheduling functionality already existing in DOCSIS specifications. But the QoS mechanisms on the CMTS and CM would need to be IPv6 capable. This includes support for IPv6 classifiers, so that data traffic to/from host devices can be classified appropriately into different service flows and be assigned appropriate priority. Appropriate classification criteria would need to be implemented for unicast and multicast traffic. In order to classify IPv6 traffic the following classifiers would need to be modified in the DOCSIS specification to support the 128- bit IPv6 address: A. IP source address B. IP source mask C. IP destination address D. IP destination mask E. IP traffic class (DSCP) The following classifiers would be new for IPv6: A. IP version B. Flow label (optional) Traffic classification and marking should be done at the CM for upstream traffic and the CMTS/ER for downstream traffic in order to support the various types of services: data, voice, video. The same IPv4 QoS concepts and methodologies should be applied for IPv6 as well. It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes. I am not certain about the purpose of this section... Are we trying to tell DOCSIS what they would need to change in their specifications in order to support IPv6 QoS? If so, I don't think that this belongs in a document that is telling SPs how to support IPv6 in their networks, does it? I think you should make it clearer here and in later sections what will not currently work, rather than just stating that DOCSIS should change things. 7.2.1.2. Addressing The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless auto-configuration or stateful DHCPv6 based configuration to acquire an address via the Edge Router. However, as manual configuration for each customer is a provisioning challenge, implementations are encouraged to develop mechanism(s) which automatically map the PVC (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer- specific prefix to all the customers with minimal configuration. How is this done in IPv4? Why does it need to be different in IPv6? From owner-v6ops@ops.ietf.org Fri May 26 12:06:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjepL-0002jp-DV for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:06:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjepK-000261-1L for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:06:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjep9-000CDw-SG for v6ops-data@psg.com; Fri, 26 May 2006 16:06:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjep8-000CDb-2f for v6ops@ops.ietf.org; Fri, 26 May 2006 16:06:02 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 26 May 2006 09:06:02 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="323581645:sNHT57588046" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4QG61WU004115; Fri, 26 May 2006 09:06:01 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4QG60Hc006232; Fri, 26 May 2006 09:06:00 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QG2s20016870; Fri, 26 May 2006 09:02:54 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D1EF5F6-0D92-46FE-8917-758D75782D6F@cisco.com> Cc: v6ops@ops.ietf.org, Lindqvist Erik Kurt Content-Transfer-Encoding: 7bit From: Fred Baker Subject: FW: Review of draft-ietf-v6ops-nap-02.txt Date: Fri, 26 May 2006 09:05:56 -0700 To: Tony Hain , Brian E Carpenter , EricLKlein , gunter@cisco.com, Ralph Droms X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=30935; t=1148659561; x=1149523561; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:FW=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt; X=v=3Dcisco.com=3B=20h=3DIPFGi5jNJlY01ZSpcetI+GjqjH4=3D; b=sDXeo2KuYS18KfVtasHIdc6dNZ1NqSf8Hu6htEi7NTQNaYDyaL6MXepfB/dGY5Z0QD1udwEK T124iapOMJr4mVBE7PYho64oy0y0QK3F21T7JYftgjd7Z6aCGvS34ISg; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c333e139fa2e0789f26c027c47be6c7f FYI. Margaret's original message seems to have not made it to v6ops, or at least through it to me and reportedly several of you. -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] On Behalf Of Margaret Wasserman Sent: Wednesday, May 24, 2006 7:06 PM To: 'iesg@ietf.org'; 'v6ops@ops.ietf.org' Subject: Review of draft-ietf-v6ops-nap-02.txt Hi All, I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number of serious issues with the document. I realize that the Last Calls have already completed and that this document is on the agenda for this week's IESG telechat, but I consider these issues to be serious enough that they are worth raising as late objections. I think that there is a serious problem with the way this document describes existing NAT technology. There are significant issues with the tone of this document, which is arrogant and argumentative. I also believe that the document contains several factual mistakes and some potentially damaging recommendations. In addition to resolving my review comments, I would suggest that the document shepherd request a technical review from members of the Transport area who focus on NAT-related technologies. While there are some strong technical points in this document, I think that they are severely weakened by the length of the document and the level of IPv6 marketing hype included in a document that is simultaneously bashing NAT providers for exactly this sort of behaviour. Little of this hype, including the entire appendix, is actually operational advice of any kind, and I don't know why the IETF would want to publish it. There are already existing groups that market IPv6, and I think that it is outside the scope of the IETF to do so. The authors also seem to have inserted quite a bit of their own religion, and I think that there are large parts of this document that do not even come close to expressing IETF consensus on various topics like NAT features, the usefulness of firewalls, appropriate use of the IGP routing practices, etc. It seems unlikely that this document has received adequate review from people in these areas. In other words, I think that some of the contents of this document and the current editorial style make it unsuitable for publication as an RFC. Specific comments are included below, along with the document exerpts that they refer to. Margaret --- Abstract Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT. This abstract seems very slanted. I also think that it would be incorrect at this point to say that "amplifying" address space is the primary benefit of NATs, as many companies use them in spite of the fact that they have plenty of address space available. There are at least three other _real_ benefits of NAT boxes. While I hold with this document's position that these benefits can and should be realized in other ways in IPv6, I do not think it is factual or helpful to argue that they don't exist. Those benefits are: (1) Avoiding the reliance of internal network number on externally allocated numbers. AKA not having to renumber when you change ISPs or when ISPs change address allocation strategies. (2) Hiding internal topology from external communicants. (3) Avoiding the establishment of unauthorized inbound connections. While this NAT side effect can also cause problems, it does provide the real benefits of a stateful firewall. 1. Introduction Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. The serious disadvantages of ambiguous "private" address space and of Network Address Translation (NAT) [1][5] have been well documented [4][6]. However, given its wide market acceptance NAT undoubtedly has some perceived benefits. Indeed, in an Internet model based on universal any-to-any connectivity, product marketing departments have driven a perception hat some connectivity and security concerns can only be solved by using a NAT device or by using logically separated Local Area Network (LAN) address spaces. This document describes the reasons for utilizing a NAT device in an IPv4 environment that are regularly cited in marketing pronouncements. It then shows how these needs can be met without using NAT in an IPv6 network. Some of the IPv6 solutions offer advantages beyond the equivalent IPv4 NAT solution. The use of the facilities from IPv6 described in this document avoids the negative impacts of address translation. I don't understand, at all, the mentione of "marketing departments" and "marketing pronouncements" in this section and think it should be reworded to remove them and/or cite specific documents. There are real reasons why people use NATs in IPv4, and there are better ways to do those things with IPv6. That's what we should say. The text in the above paragraph is insulting, incorrect and very likely to get the network administrator to stop reading before you can offer any advice on how to set-up an IPv6 network. 2. Perceived Benefits of NAT and its Impact on IPv4 This section provides insight into the generally perceived benefits of the use of IPv4 NAT as extolled by product marketing. The goal of Again with the "product marketing". Do the authors of this document really believe that these benefits do not exist? Does the IETF as a whole? I think we should be somewhat embarrassed to publish this document as-is, because it seems very naive and one-sided. This continues throughout the document, but I will not continue to mention it. 2.2. Simple Security due to Stateful Filter Implementation A firewall doesn't fully secure a network, because many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows etc. What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary. This is the section where we are describing the benefits of NAT without analyzing them. So, why is this sub-section here? It is clear that the side effects of NAT can be used as one element of a system to protect internal nodes. It is not sufficient to protect them from everything, which doesn't mean that it doesn't protect them against anything. Much of this section could appear to be an argument that firewalls of all kinds are useless because of the existence of Trojan Horse-style attacks, which is obviously false. Have any firewall experts been asked to review this section? If not, I think you should ask someone like Steve Bellovin to do so. 2.3. User/Application tracking Although NATs create temporary state for active sessions, in general they provide limited capabilities for the administrator of the NAT to gather information about who in the private network is requesting access to which Internet location. This could in theory be done by logging the network address translation details of the private and the public addresses from the NAT device's state database. The checking of this database is not always a simple task, especially if Port Address Translation is used. It also has an unstated assumption that the administrative instance has a mapping between an IPv4-address and a network element or user at all times, or the administrator has a time-correlated list of the address/port mappings. I think that this document is arguing that User/Application tracking is not a benefit of NAT? If so, why is it even in this document? 2.4. Privacy and Topology Hiding The goal of 'topology hiding' is to provide devices on the private network with an identifier (IPv4 address) which an entity outside the network can use to communicate with or to reference the private network devices in protocols but prevents the external entity making a correlation between the topological location of the private device and the address on the local network. The above sentence does not parse (editorial). The use of NAT then results in a user behind a NAT gateway actually appearing on the Internet as a user inside the NAT box itself; i.e., the IPv4 address that appears on the Internet is only sufficient to identify the NAT. When concealed behind a NAT it is impossible to tell from the outside which member of a family, which customer of an Internet cafe, or which employee of a company generated or received a particular packet. Thus, although NATs do nothing to provide application level privacy, they do prevent the external tracking and profiling of individual host computers by means of their IP addresses, usually known as 'device profiling'. At the same time a NAT creates a smaller pool of addresses for a much more focused point of attack. What does the last sentence mean? Give some sort of example or take it out, perhaps? 3.4. Untraceable IPv6 Addresses These should be globally routable IPv6 addresses which can be randomly and independently assigned to IPv6 devices. The random assignment is intended to mislead the outside world about the structure of the local network. However the local network needs to maintain a correlation between the location of the device and the untraceable IPv6 address. This correlation could be done by generating IPv6 host route entries or by utilizing an indirection device such as a Mobile IPv6 Home Agent. Is not technically sound to advocate the dissemination of host routes in the IGP for infrastructure hiding. IGPs are not designed to scale well for this sort of use. It would be much more technically sound to advocate the use of L2 switching to avoid exposure of network topology at L3. Besides, I thought the point of network address hiding (or one of them), as outlined above was to avoid the ability to identify different nodes by address for port scanning purposes, not (merely) to avoid the ability to tell what subnets they are on. The proposed technique doesn't seem to address that issue at all. With external connectivity the simple gateway could also use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet will always use the global IPv6 addresses [9] derived from this prefix delegation. It should be noted that the address selection policy table in end-systems needs to be correctly set up so that true global prefixes are distinguished from ULAs and will be used for the source address in preference when the destination is not a ULA. Unless one takes steps to actively screw this up, a globally routable destination address will always have a longest-prefix match with a globally routable source and a ULA will always have a longest-prefix match with a ULA. So, the last sentence is completely unnecessary and somewhat misleading. The tricky part is making sure that the node uses the right _destination_ address -- a ULA for local traffic and global address for non-local traffic. This will generally require the use of some type of split DNS, with ULAs returned internally but not externally. In the very simple case there is no explicit routing protocol and a single default route is used out to the global Internet. A slightly more complex case might involve local routing protocols, but with the entire local network sharing a common global prefix there would still not be a need for an external routing protocol as a default route would continue to be consistent with the connectivity. I don't understand this paragraph at all. What does it have to do with ULAs? Also, the second half of this sentence doesn't make sense. I'm not 100% sure what it means, but if it means what I think it means, it is wrong. 4.2. IPv6 and Simple Security The vulnerability of an IPv6 host is similar to that of an IPv4 host directly connected towards the Internet. The use of firewall and Intrusion Detection Systems (IDS) is recommended. A proxy may be used for certain applications, but with the caveat that the end to end transparancy is broken. However, with IPv6, the following protections are available without the use of NAT while maintaining end-to-end reachability: 1. Short lifetimes on privacy extension suffixes reduce the attack profile since the node will not respond to the address once the address is no longer valid. 2. IPsec is a mandatory service for IPv6 implementations. IPsec functions to prevent session hijacking, prevent content tampering, and optionally masks the packet contents. While IPsec might be available in IPv4 implementations, deployment in NAT environments either breaks the protocol or requires complex helper services with limited functionality or efficiency. IPsec performs exactly the same purposes in IPv4 as IPv6. I don't know of any stacks that implement IPsec for IPv6 and not for IPv4. Also, it is not clear that end-to-end IPsec is fundamentally useful, even without the interference of a NAT box, as I believe that there needs to be some sort of binding to the upper layer protocol in order for IPsec to provide these protections. If you decide to keep this section, you should acknowledge that use of the IPv6 stateful firewall mechanisms advocated in bullet 3 will present similar obstacles to using IPsec. 3. The size of the address space of a typical subnet (64 bits of IID) will make an effective network ping sweep and resulting port-scan virtually impossible due to the number of possible combinations available, provided that IIDs are essentially randomly distributed across the available space. IIDs will not be randomly distributed. They are based on EUI-64 IDs which are certainly not randomly distributed. In fact, on Ethernet 16 of the 64-bits will have a known value. Also, the numbering space for the first three bytes (24-bits) is not completely allocated and there is very clearly an unbalanced distribution in that space. The fact that companies tend to buy somewhat homogenous hardware can make it possible to guess which three-byte combinations are most likely to be present within a given company. So, the length of the IID offers nowhere near the level of protection described above. This protection is nullified if the attacker has no access to a local connection. If an attacker has local access then he could use ND [3] and ping6 to ff02::1 to detect local neighbors. (Of course, a locally connected attacker has many scanning options with IPv4 as well.) It is recommended for site administrators to take [18] into consideration to achieve the expected goal. This protection will also be nullified if IIDs are configured in a group near the start of the IID space. Assuming the network administrator is aware of [18] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. The intention of topology probing is to identify a selection of the available hosts inside an enterprise. This mostly starts with a ping-sweep. Since the IPv6 subnets are 64 bits worth of address space, this means that an attacker has to send out a simply unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it takes over 5000 years to scan a single 64 bit space. See my comments above about why this is not correct. 4.3. User/Application Tracking IPv6 enables the collection of information about data flows. Due to the fact that all addresses used for Internet and intra-/inter-site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. This enhances the capability of data-flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses. Why is this mentioned in this document? Given this paragraph, I think you have perversely stated another benefit of NAT -- that my ISP cannot effectively track this information on a per-machine basis. Also, how is this consistent with the idea that IPv6 will use privacy address for client communications? There are two possible scenarios for the extreme situation when a network manager also wishes to fully conceal the internal IPv6 topology. o One could use explicit host routes and remove the correlation between location and IPv6 address. This solution does however show severe scalability issues. Right. That is why we should not recommend it. o The other technology to fully hide the internal topology would be to use a tunneling mechanism. Mobile IPv6 without route optimization is one example. In this example the public facing addresses are indirected via an edge Home Agent (HA). This indirection method truly masks the internal topology as all nodes with global access appear to share a common prefix. The downside of using this method is that it makes usage of middleware like a Home Agent (HA). This seems awfully complex and may present other problems, such as brittleness and MTU/fragmentation issues. What are the possible benefits of subnet hiding that could justify this type of solution? There are other answers involving L2 bridging with VLANs for limiting broadcast domains that are much more scalable and simpler than either of these approaches. 4.5. Independent Control of Addressing in a Private Network [...] When using IPv6, the need to ask for more address space will become far less likely due to the increased size of the subnets. These subnets typically allow 2^64 addresses per subnet and an enterprise will typically receive a /48 which allows segmentation into at least 2^16 different subnets. The ongoing subnet size maintenance may become simpler when IPv6 technology is utilised. If IPv4 address space is optimised one has to look periodically into the number of hosts on a segment and the subnet size allocated to the segment; an enterprise today may have a mix of /28 - /23 size subnets for example, and may shrink/grow these as their network user base changes. For IPv6 all subnets have /64 prefixes. I am not really sure what any of this has to do with anything, and it isn't entirely correct. The 64-bit IID is a hard limit in IPv6, but there is no hard limit that all sites will be allocated a /48. 4.6. Global Address Pool Conservation IPv6 provides sufficient space to completely avoid the need for overlapping address space, 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total possible addresses. As previously discussed, the serious The naivete of pointing out the number of possible IPv6 addresses actually hurts this argument. Because of the 64-bit IID and the IETF's recommendations to allocate a /48 to home users, the address space will be much less densely used than in IPv4. Many people still feel that there will be enough address space that conservation is not needed, and there are decent documents that you could cite that make that argument. This has little or nothing to do with the number of possible addresses in IPv6, though. disadvantages of ambiguous address space have been well documented, and with sufficient space there is no need to continue the increasingly aggressive conservation practices that are necessary with IPv4. While IPv6 allocation policies and ISP business practice will continue to evolve, the recommendations in RFC 3177 are based on the technical potential of the vast IPv6 address space. That document demonstrates that there is no resource limitation which will require the adoption of the IPv4 workaround of ambiguous space behind a NAT. As an example of the direct contrast, many expansion oriented IPv6 deployment scenarios result in multiple IPv6 addresses per device, as opposed to the constriction of IPv4 scenarios where multiple devices are forced to share a scarce global address. 4.7. Multihoming and Renumbering Multihoming and renumbering remain technically challenging with IPv6 (see the Gap Analysis below). However, IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-like prefixes and thus with several simultaneous ISPs. An address selection mechanism [10] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in this regard therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding and removing active prefixes at a site have been documented [12] and [19]. To be balanced, you should at least say something here about the fact that end-user sites that currently have "swamp space" addresses in IPv4 may need to move ot ISP-provided addresses in IPv6, thus increasing concerns about renumbering and multi-homing. If there is need to mask the internal structure towards the external IPv6 internet, then some form of 'untraceable' addresses may be used. These addresses will be derived from a local pool, and may be assigned to those hosts for which topology masking is required or which want to reach the IPv6 Internet or other external networks. The technology to assign these addresses to the hosts could be based on DHCPv6. To complement the 'Untraceable' addresses it is needed to have at least awareness of the IPv6 address location when routing an IPv6 packet through the internal network. This could be achieved by 'route-injection' in the network infrastructure. This route- injection could be done based on /128 host-routes to each device that wants to connect to the Internet using an untraceable address. This will provide the most dynamic masking, but will have a scalability limitation, as an IGP is typically not designed to carry many thousands of IPv6 prefixes. A large enterprise may have thousands of hosts willing to connect to the Internet. Less flexible masking could be to have time-based IPv6 prefixes per link or subnet. This may reduce the amount of route entries in the IGP by a significant factor, but has as trade-off that masking is time and subnet based. This whole "untraceable" address concept seems to be poorly thought- out. I am concerned that this document, while supposedly an informational document on existing IPv6 features is trying to specify a new IPv6 feature and doing it quite inadequately, IMO. While a full prefix is expected to be the primary deployment model there may be cases where the ISP provides a single IPv6 address for use on a single piece of equipment (PC, PDA, etc.). How does this differ from the "single user connection" case described in 5.3? 6.1. Subnet Topology Masking There really is no functional gap here as a centrally assigned pool of addresses in combination with host routes in the IGP is an effective way to mask topology. You discuss the scaling issues in your own document, so this seems to be misleading. 6.4. Site Multihoming This complex problem has never been completely solved for IPv4, which is exactly why NAT has been used as a partial solution. For IPv6, after several years' work, the IETF has converged on an architectural approach intended with service restoration as initial aim [20]. Again, ULAs may help since they will provide stable addressing for internal communications that are not affected by multihoming. Depending on what benefits are expected from multihoming, the capacity for IPv6 to use more than one prefix per interface may help here, too. Appendix A. Additional Benefits due to Native IPv6 and Universal Unique Addressing I am not really sure that including a "marketing brochure" regarding the general benefits of IPv6 at the end of this document serves to make it any clearer. The users of native IPv6 technology and global unique IPv6 addresses have the potential to make use of the enhanced IPv6 capabilities, in addition to the benefits offered by the IPv4 technology. A.1. Universal Any-to-Any Aonnectivity Connectivity, perhaps? A.4. Increased Security Protection The security protection offered by native IPv6 technology is more advanced than IPv4 technology. There are various transport mechanisms enhanced to allow a network to operate more securely with less performance impact: o IPv6 has the IPsec technology directly embedded into the IPv6 protocol. See note above. IPsec is no more "embedded" in IPv6 than it is in IPv4. This allows for simpler peer-to-peer encryption and authentication, once a simple key/trust management model is developed, while the usage of some other less secure mechanisms is avoided (i.e. md5 password hash for neighbor authentication). o On a local network, any user will have more security awareness. IPv6 will make users more security-aware? What does that even mean? This awareness will motivate the usage of simple firewall applications/devices to be inserted on the border between the external network and the local (or home network) as there is no Address Translater and hance no false safety perception. o All flows on the Internet will be better traceable due to a unique and globally routable source and destination IPv6 address. This may facilitate an easier methodology for back-tracing DoS attacks and avoid illegal access to network resources by simpler traffic filtering. We already can trace these flows inside the NAT just fine. The only place it is now easier to trace is outside my NAT, where the attackers live. o The usage of private address-space in IPv6 is now provided by Unique Local Addresses, which will avoid conflict situations when merging networks and securing the internal communication on a local network infrastructure due to simpler traffic filtering policy. How is this a security benefit? o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source- routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source-route header. Again, how is this a security benefit? A.5. Mobility Anytime, anywhere, universal access requires MIPv6 services in support of mobile nodes. While a Home Agent is required for initial connection establishment in either protocol version, IPv6 mobile nodes are able to optimize the path between them using the MIPv6 option header while IPv4 mobile nodes are required to triangle route all packets. In general terms this will minimize the network resources used and maximize the quality of the communication. Nice plug for MIP6, but why is it here? And, have you run this text by the MIP4 WG to make sure that they agree with it? A.7. Community of interest Although some Internet-enabled devices will function as fully- fledged Internet hosts, it is believed that many will be operated in a highly restricted manner functioning largely or entirely within a Community of Interest. By Community of Interest we mean a collection of hosts that are logically part of a group reflecting their ownership or function. Typically, members of a Community of Interest need to communicate within the community but should not be generally accessible on the Internet. They want the benefits of the connectivity provided by the Internet, but do not want to be exposed to the rest of the world. This functionality will be available through the usage of NAP and native IPv6 dataflows, without any stateful device in the middle. It will also allow to build virtual organization networks on the fly, which is very difficult to do in IPv4+NAT scenarios. Uh... What is this all about? VPNs? Something else? Why is this different in IPv6 than in IPv4? From owner-v6ops@ops.ietf.org Fri May 26 12:48:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfUH-0000IS-H2 for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:48:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfUC-0007p9-JU for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 12:48:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjfSt-000G1W-L1 for v6ops-data@psg.com; Fri, 26 May 2006 16:47:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjfSs-000G1H-UN for v6ops@ops.ietf.org; Fri, 26 May 2006 16:47:06 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA23768; Fri, 26 May 2006 09:47:05 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4QGl5B24833; Fri, 26 May 2006 09:47:05 -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.1830); Fri, 26 May 2006 09:47:03 -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: RE: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 09:46:54 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C64@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Operational issues with Tiny Fragments in IPv6 Thread-Index: AcaA22kTcRfYACbDRJaId4oA2dU5SgABlQQQ From: "Templin, Fred L" To: "Fred Baker" , "Elwyn Davies" Cc: "Vishwas Manral" , X-OriginalArrivalTime: 26 May 2006 16:47:03.0575 (UTC) FILETIME=[0410DA70:01C680E4] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > There is a discussion of fragmentation and reassembly in RFC 1812 =20 > section 4.2.2.7 that may be useful to reference, or at least learn =20 > lessons from. In part, this results from the behavior of NIC cards in > the late 1980's that couldn't reliably receive datagrams back to back > for very long due to chip or memory issues, Digital Equipment Corporation had such NIC cards in the late 1980's. The DEQNA card in particular could go into "qe restart" mode when it received back to back fragments that arrived too quickly for its little legs to carry. This was exacerbated by packetization mechanisms such as NFS that sent 8KB frames as chains of back-to-back IPv4 fragments. The follow-on DELQA card, as well as "faster" VAX processors, improved the situation. =20 > and partly this is is due =20 > to brain-dead behaviors in early end-station OS's. Having authored some of the network drivers in one of those "brain-dead" OSs, there was really nothing that could be done for the DEQNA case. Ethernet of that day and age was supposed to be 10Mb/sec, but SUN was one of the first vendors that could actually achieve that rate. Times have certainly changed. Fred fred.l.templin@boeing.com =20 From owner-v6ops@ops.ietf.org Fri May 26 13:00:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjffl-0001Iv-6T for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 13:00:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjffj-0000RM-PI for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 13:00:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjffJ-000HIl-Io for v6ops-data@psg.com; Fri, 26 May 2006 16:59:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjffJ-000HIZ-0D for v6ops@ops.ietf.org; Fri, 26 May 2006 16:59:57 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 09:59:56 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="1813583903:sNHT32660080" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4QGxu62015446; Fri, 26 May 2006 09:59:56 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4QGxtB7016468; Fri, 26 May 2006 09:59:55 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QGuqlH018113; Fri, 26 May 2006 09:56:53 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C64@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1818C64@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <800A6D98-0294-4C14-8437-07DC0E33CB71@cisco.com> Cc: "Elwyn Davies" , "Vishwas Manral" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 09:59:54 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2324; t=1148662796; x=1149526796; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20Operational=20issues=20with=20Tiny=20Fragments=20i n=20IPv6; X=v=3Dcisco.com=3B=20h=3Da5ojuOrTQJc1IP87NJ/vxv/Q9kM=3D; b=WekJ/nN5dQVwWZEVSZ6FqW32xKV4AvVjzcaOorO9CnwgPi2EdxzOtMIP2J4Nj10X4PI9mrHs IQM6PzrH4gAHnbWCHPIE9sxUNGa+FlK4TWC+RfbT2uUqrkaTWLh0RYxE; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 yes. And DEQNA was in no sense the only one; Cisco routers to this day have a capability in RIP to insert time delays between RIP updates due to issues in Netware, in which some PC NICs had trouble with back to back packets. As I say, those were different days. The matter of minimizing the number of packets required to represent a transport message, however, remains real. Especially in wireless networks, there are a number of issues that result in a per-datagram probability of loss that is to some degree independent of datagram size. Sending less network layer datagrams per transport message improves the probability of delivering the entire transport message. That is the bottom line of the inspecific ruminations people frequently make about "fragmentation problems" and preferring transport-layer fragmentation and reassembly to network-layer fragmentation and reassembly. So it seems like carrying that recommendation forward has value. On May 26, 2006, at 9:46 AM, Templin, Fred L wrote: >> There is a discussion of fragmentation and reassembly in RFC 1812 >> section 4.2.2.7 that may be useful to reference, or at least learn >> lessons from. In part, this results from the behavior of NIC cards >> in the late 1980's that couldn't reliably receive datagrams back >> to back for very long due to chip or memory issues, > > Digital Equipment Corporation had such NIC cards in the late > 1980's. The DEQNA card in particular could go into "qe restart" > mode when it received back to back fragments that arrived too > quickly for its little legs to carry. This was exacerbated by > packetization mechanisms such as NFS that sent 8KB frames as chains > of back-to-back IPv4 fragments. The follow-on DELQA card, as well > as "faster" VAX processors, improved the situation. > >> and partly this is is due to brain-dead behaviors in early end- >> station OS's. > > Having authored some of the network drivers in one of those "brain- > dead" OSs, there was really nothing that could be done for the > DEQNA case. Ethernet of that day and age was supposed to be 10Mb/ > sec, but SUN was one of the first vendors that could actually > achieve that rate. Times have certainly changed. > > Fred > fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Fri May 26 13:07:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfmI-00081Y-FB for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 13:07:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfmG-0001Fz-Vy for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 13:07:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjflf-000I0R-8M for v6ops-data@psg.com; Fri, 26 May 2006 17:06:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjfle-000I04-IV for v6ops@ops.ietf.org; Fri, 26 May 2006 17:06:30 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA23160; Fri, 26 May 2006 10:06:25 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4QH6TB04528; Fri, 26 May 2006 10:06:29 -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.1830); Fri, 26 May 2006 10:06:28 -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: RE: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 10:05:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C65@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <800A6D98-0294-4C14-8437-07DC0E33CB71@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Operational issues with Tiny Fragments in IPv6 Thread-Index: AcaA5d5HGnaQ641sQomtCGl//74HLAAAFRLA From: "Templin, Fred L" To: "Fred Baker" Cc: "Elwyn Davies" , "Vishwas Manral" , X-OriginalArrivalTime: 26 May 2006 17:06:28.0520 (UTC) FILETIME=[BA6D5A80:01C680E6] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Then you probably remember Ethernet "trailers" too; they were required for certain hardware that could only do DMA when the data was aligned on a page-sized boundary. But I digress... Fred fred.l.templin@boeing.com=20 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Friday, May 26, 2006 10:00 AM To: Templin, Fred L Cc: Elwyn Davies; Vishwas Manral; v6ops@ops.ietf.org Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 yes. And DEQNA was in no sense the only one; Cisco routers to this =20 day have a capability in RIP to insert time delays between RIP =20 updates due to issues in Netware, in which some PC NICs had trouble =20 with back to back packets. As I say, those were different days. The matter of minimizing the number of packets required to represent =20 a transport message, however, remains real. Especially in wireless =20 networks, there are a number of issues that result in a per-datagram =20 probability of loss that is to some degree independent of datagram =20 size. Sending less network layer datagrams per transport message =20 improves the probability of delivering the entire transport message. =20 That is the bottom line of the inspecific ruminations people =20 frequently make about "fragmentation problems" and preferring =20 transport-layer fragmentation and reassembly to network-layer =20 fragmentation and reassembly. So it seems like carrying that =20 recommendation forward has value. On May 26, 2006, at 9:46 AM, Templin, Fred L wrote: >> There is a discussion of fragmentation and reassembly in RFC 1812 =20 >> section 4.2.2.7 that may be useful to reference, or at least learn =20 >> lessons from. In part, this results from the behavior of NIC cards =20 >> in the late 1980's that couldn't reliably receive datagrams back =20 >> to back for very long due to chip or memory issues, > > Digital Equipment Corporation had such NIC cards in the late =20 > 1980's. The DEQNA card in particular could go into "qe restart" =20 > mode when it received back to back fragments that arrived too =20 > quickly for its little legs to carry. This was exacerbated by =20 > packetization mechanisms such as NFS that sent 8KB frames as chains =20 > of back-to-back IPv4 fragments. The follow-on DELQA card, as well =20 > as "faster" VAX processors, improved the situation. > >> and partly this is is due to brain-dead behaviors in early end-=20 >> station OS's. > > Having authored some of the network drivers in one of those "brain-=20 > dead" OSs, there was really nothing that could be done for the =20 > DEQNA case. Ethernet of that day and age was supposed to be 10Mb/=20 > sec, but SUN was one of the first vendors that could actually =20 > achieve that rate. Times have certainly changed. > > Fred > fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Fri May 26 14:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjggS-00022p-3u for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 14:05:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjggQ-0001MV-Py for v6ops-archive@lists.ietf.org; Fri, 26 May 2006 14:05:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjgeo-000MoD-JV for v6ops-data@psg.com; Fri, 26 May 2006 18:03:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fjgem-000Mny-U0 for v6ops@ops.ietf.org; Fri, 26 May 2006 18:03:28 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 May 2006 11:03:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4QI3S0a028005; Fri, 26 May 2006 11:03:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4QI3SHc003409; Fri, 26 May 2006 11:03:28 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QI0Opl019540; Fri, 26 May 2006 11:00:25 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C65@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1818C65@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Elwyn Davies" , "Vishwas Manral" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Date: Fri, 26 May 2006 11:03:26 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=829; t=1148666608; x=1149530608; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20Operational=20issues=20with=20Tiny=20Fragments=20i n=20IPv6; X=v=3Dcisco.com=3B=20h=3Da5ojuOrTQJc1IP87NJ/vxv/Q9kM=3D; b=czVcjrUsPyqNCsrToMe6tee8GsnFY5RFYojDUmvi4SE5cQHVqM7hdMklKp63K1rq+8OxRNm2 YnENVyK5XtT94LWJhRtdcXzjgmpp0YRx0OgK4p8HJiCDPbMWxyYCMfuE; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On May 26, 2006, at 10:05 AM, Templin, Fred L wrote: > Then you probably remember Ethernet "trailers" too all too well. There were great discussions of the degree to which they improved things. On some hardware, they reportedly vastly increased throughput; on other hardware, they made no difference whatsoever. On a router I designed in that timeframe (the company now being defunct), I provided the practical option of treating trailers as there for the convenience of the sender more than the receiver, and therefore converting from trailer to header format in the router. There are days I feel old. It would be better to feel wise, but my experience with people whose opinion of themselves is that they are wise is that their estimate of themselves often exceeds other opinions of them :-) From owner-v6ops@ops.ietf.org Sat May 27 06:55:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjwRi-0001el-Hy for v6ops-archive@lists.ietf.org; Sat, 27 May 2006 06:55:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjwRd-0006XO-9i for v6ops-archive@lists.ietf.org; Sat, 27 May 2006 06:55:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjwMs-000Kwh-Rh for v6ops-data@psg.com; Sat, 27 May 2006 10:50:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.197] (helo=mail-ihug.icp-qv1-irony3.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjwMr-000Kvv-JR for v6ops@ops.ietf.org; Sat, 27 May 2006 10:50:01 +0000 Received: from 203-173-33-253.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.33.253]) by mail-ihug.icp-qv1-irony3.iinet.net.au with ESMTP; 27 May 2006 18:49:58 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,179,1146412800"; d="scan'208"; a="796249639:sNHT14067784" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id B5D657EE0; Sat, 27 May 2006 20:19:55 +0930 (CST) Date: Sat, 27 May 2006 20:19:55 +0930 From: Mark Smith To: Fred Baker Cc: Fred.L.Templin@boeing.com, elwynd@dial.pipex.com, vishwas.ietf@gmail.com, v6ops@ops.ietf.org Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Message-Id: <20060527201955.0f812bc5.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A1818C65@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Fri, 26 May 2006 11:03:26 -0700 Fred Baker wrote: > On May 26, 2006, at 10:05 AM, Templin, Fred L wrote: > > Then you probably remember Ethernet "trailers" too > > > There are days I feel old. It would be better to feel wise, but my > experience with people whose opinion of themselves is that they are > wise is that their estimate of themselves often exceeds other > opinions of them :-) > What a wise thing to say ;-) From owner-v6ops@ops.ietf.org Mon May 29 09:19:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkhf5-00027e-JJ for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:19:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkhez-000577-V0 for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:19:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fkhcj-000OjP-Rd for v6ops-data@psg.com; Mon, 29 May 2006 13:17:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HOT_NASTY autolearn=ham version=3.1.1 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fkhcd-000Oiy-Uy for v6ops@ops.ietf.org; Mon, 29 May 2006 13:17:28 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id DC974341E5; Mon, 29 May 2006 09:17:26 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 09:17:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Date: Mon, 29 May 2006 09:17:24 -0400 Message-ID: <936A4045C332714F975800409DE09240025BCBBB@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Thread-Index: AcaA3kIF8N/9ZrdRTcCPI9ry3Kq3hQCQ8t+g From: "Bound, Jim" To: "Fred Baker" , "Adeel Ahmed ((adahmed))" , , , "Pekka Savola" , "Salman Asadullah ((sasad))" Cc: , "Lindqvist Erik Kurt" X-OriginalArrivalTime: 29 May 2006 13:17:26.0547 (UTC) FILETIME=[3ACFEE30:01C68322] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f I think this to is ready to ship as RFC. I do agree below that section 2 may have to be removed for the reasons stated. We have to be careful on the slippery slope of what we say in the IETF about deployment that is not within our IETF bounds. Naming/Commenting on specific products is not good either. Best, /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Friday, May 26, 2006 12:04 PM > To: Adeel Ahmed ((adahmed)); cpopovic@cisco.com;=20 > jordi.palet@consulintel.es; Pekka Savola; Salman Asadullah ((sasad)) > Cc: v6ops@ops.ietf.org; Lindqvist Erik Kurt > Subject: FW: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt >=20 > FYI. Margaret's original message seems to have not made it to=20 > v6ops, or at least through it to me and reportedly several of you. >=20 > -----Original Message----- > From: Margaret Wasserman > Sent: Thursday, May 25, 2006 11:16 AM > To: 'v6ops@ops.ietf.org'; 'iesg@ietf.org' > Subject: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt >=20 >=20 > Hi All, >=20 > While I was in a mood to review v6ops documents, I also=20 > reviewed draft-ietf-v6ops-bb-deployment-scenarios-04.txt. =20 > IMO, this is a very good document that is full of useful=20 > information, and it is nearly suitable for publication. >=20 > I only found one serious issue in the document, and it non-technical. > I think that section 2 should be removed from the document,=20 > because I don't think it is appropriate for the IETF to=20 > publish documents that indicate how SPs should differentiate=20 > their services and/or to comment on SPs specific products and=20 > services. >=20 > I have a couple of other comments (see below), but nothing=20 > else that Should block publication of this document, IMO. >=20 > Margaret >=20 > --- >=20 > 1.1. Common Terminology >=20 > Add "BB" which is used throughout the document to mean Broadband? >=20 > 2. IPv6 Based BB Services >=20 > At this point IPv6 based services are seen as a=20 > differentiator that > enables SPs to take advantage of the large IPv6 address=20 > space to the > extent that subscribers get up to fixed /48 prefixes versus the > single, temporary IPv4 addresses. Such resources allow the SPs to > better position themselves against the competition. The IPv6 > deployments can be seen as a driver for lower service=20 > support costs > by eliminating NAT with its negative impact on=20 > applications and its > complex behavior. Another reason of IPv6 being popular in some > countries might be the government driven financial incentives and > favorable legislation towards the ISPs who are deploying IPv6. >=20 >=20 > I would remove this entire seciton (section 2) from the=20 > document. I don't think that the IETF is qualified to=20 > comment on business differentiators in the SP industry, and=20 > even if we were qualified to do so, I don't why we would want=20 > to do so. I don't think it is appropriate to mention=20 > specific companies' products and services, and timely=20 > information about what is currently deployed, including the=20 > limitations of those deployments, will probably be outdated=20 > by the time this document is published. >=20 >=20 > If you don't remove this section, I think it will need a lot=20 > of work, as it mentions individual company names and product=20 > names without any disclaimers and/or indication of whether=20 > those companies have approved of what we are saying about=20 > their products, and without including such legal niceties as=20 > trademarks, etc. >=20 > The network is transparent to the Layer 3 protocol. The only > possible changes would come with the intent of filtering and > monitoring IPv6 traffic based on layer 2 information such as IPv6 > Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC > addresses (3333.xxxx.xxxx). >=20 > What format of MAC address is this? I have most often seen=20 > Ethernet addresses represented at xx:xx:xx:xx:xx:xx, so this=20 > would be 33:33:xx:xx:xx:xx, right? But other MAC addresses=20 > may be other lengths, such as EUI-64 identifiers. Also, if=20 > one filters on an EtherType of 0x86DD, one will see all IPv6=20 > traffic. I am not sure why an additional filter for=20 > IPv6-specific multicast addresses would be needed. Can you explain? >=20 > It is important to note that the customers of a Service=20 > Provider can > choose to establish tunnels to publicly available and free tunnel > services. Even though the quality of such services might not be > high, they provide free IPv6 access. In designing their IPv6 > services, the SPs should take into considerations such options > available to their potential customers. The IPv6=20 > deployment should > support services (like multicast, VoIPv6 etc) and a level=20 > of quality > that would make the access through the SP worthwhile to potential > subscribers. >=20 > This paragraph should be removed, as it mainly provides=20 > marketing, not operational, advice to SPs. >=20 > 6. Broadband Cable Networks >=20 > This section describes the infrastructure that exists=20 > today in cable > networks providing BB services to the home. It also=20 > describes IPv6 > deployment options in these cable networks. >=20 > DOCSIS standardizes and documents the operation of data over Cable > Networks. The current version of DOCSIS has limitations=20 > that do not > allow for a smooth implementation of native IPv6=20 > transport. Some of > these limitations are discussed in this section. For this reason, > the IPv6 deployment scenarios discussed in this section for the > existent Cable Networks are tunnel based. The tunneling examples > presented here could also be applied to the other BB technologies > described in sections 7, 8, 9 and 10. >=20 > You should expand the DOCSIS acronym, add a reference for=20 > DOCSIS and state which version is the "current version" that=20 > has these limitations. >=20 > 6.2.4. IPv6 QoS >=20 > IPv6 will not change or add any queuing/scheduling functionality > already existing in DOCSIS specifications. But the QoS=20 > mechanisms on > the CMTS and CM would need to be IPv6 capable. This=20 > includes support > for IPv6 classifiers, so that data traffic to/from host=20 > devices can > be classified appropriately into different service flows and be > assigned appropriate priority. Appropriate=20 > classification criteria > would need to be implemented for unicast and multicast traffic. >=20 > In order to classify IPv6 traffic the following classifiers would > need to be modified in the DOCSIS specification to=20 > support the 128- > bit IPv6 address: >=20 > A. IP source address >=20 > B. IP source mask >=20 > C. IP destination address >=20 > D. IP destination mask >=20 > E. IP traffic class (DSCP) >=20 > The following classifiers would be new for IPv6: >=20 > A. IP version >=20 > B. Flow label (optional) >=20 > Traffic classification and marking should be done at the CM for > upstream traffic and the CMTS/ER for downstream traffic=20 > in order to > support the various types of services: data, voice,=20 > video. The same > IPv4 QoS concepts and methodologies should be applied for IPv6 as > well. >=20 > It is important to note that when traffic is encrypted end-to-end, > the traversed network devices will not have access to many of the > packet fields used for classification purposes. In these cases > routers will most likely place the packets in the default classes. > The QoS design should take into consideration this=20 > scenario and try > to use mainly IP header fields for classification purposes. >=20 > I am not certain about the purpose of this section... Are we=20 > trying to tell DOCSIS what they would need to change in their=20 > specifications in order to support IPv6 QoS? If so, I don't=20 > think that this belongs in a document that is telling SPs how=20 > to support IPv6 in their networks, does it? >=20 > I think you should make it clearer here and in later sections=20 > what will not currently work, rather than just stating that=20 > DOCSIS should change things. >=20 > 7.2.1.2. Addressing >=20 > The Hosts or the Customer Routers have the Edge Router as=20 > their Layer > 3 next hop. >=20 > If there is no Customer Router all the hosts on the=20 > subscriber site > belong to the same /64 subnet that is statically configured on the > Edge Router for that subscriber PVC. The hosts can use stateless > auto-configuration or stateful DHCPv6 based configuration=20 > to acquire > an address via the Edge Router. >=20 > However, as manual configuration for each customer is a=20 > provisioning > challenge, implementations are encouraged to develop mechanism(s) > which automatically map the PVC (or some other customer-specific > information) to an IPv6 subnet prefix, and advertise the customer- > specific prefix to all the customers with minimal configuration. >=20 > How is this done in IPv4? Why does it need to be different in IPv6? >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 29 09:20:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhfG-0002Tl-Qt for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:20:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkhfA-00057Z-9b for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:20:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fkhb1-000Ocy-Px for v6ops-data@psg.com; Mon, 29 May 2006 13:15:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fkhau-000OcM-IT for v6ops@ops.ietf.org; Mon, 29 May 2006 13:15:42 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6732B34245; Mon, 29 May 2006 09:15:37 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 09:15:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Mon, 29 May 2006 09:15:34 -0400 Message-ID: <936A4045C332714F975800409DE09240025BCBBA@tayexc14.americas.cpqcorp.net> In-Reply-To: <7D1EF5F6-0D92-46FE-8917-758D75782D6F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-nap-02.txt Thread-Index: AcaA3l5QTugEWOLPT32La0K/6rMTiQCQz/mw From: "Bound, Jim" To: "Fred Baker" , "Tony Hain" , "Brian E Carpenter" , "EricLKlein" , , "Ralph Droms" Cc: , "Lindqvist Erik Kurt" X-OriginalArrivalTime: 29 May 2006 13:15:37.0173 (UTC) FILETIME=[F99EC850:01C68321] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e535e8fdae689580ce57283401d548ee I am fine with the NAP document most of the below complaints seem to be personal subjective view by the reviewer and objective technical statements. The document should ship to RFC. It has been widely reviewed and presented to the market often and I have not heard any complaints. Technically I have no issue with any of the sections. Editing wise I have not scrutinized the document for grammar or spelling etc. Thus I emphatically disagree strongly with the statements below from this review. Best, /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Friday, May 26, 2006 12:06 PM > To: Tony Hain; Brian E Carpenter; EricLKlein;=20 > gunter@cisco.com; Ralph Droms > Cc: v6ops@ops.ietf.org; Lindqvist Erik Kurt > Subject: FW: Review of draft-ietf-v6ops-nap-02.txt >=20 > FYI. Margaret's original message seems to have not made it to=20 > v6ops, or at least through it to me and reportedly several of you. >=20 > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] On=20 > Behalf Of Margaret Wasserman > Sent: Wednesday, May 24, 2006 7:06 PM > To: 'iesg@ietf.org'; 'v6ops@ops.ietf.org' > Subject: Review of draft-ietf-v6ops-nap-02.txt >=20 > Hi All, >=20 > I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number=20 > of serious issues with the document. I realize that the Last=20 > Calls have already completed and that this document is on the=20 > agenda for this week's IESG telechat, but I consider these=20 > issues to be serious enough that they are worth raising as=20 > late objections. >=20 > I think that there is a serious problem with the way this=20 > document describes existing NAT technology. There are=20 > significant issues with the tone of this document, which is=20 > arrogant and argumentative. I also believe that the document=20 > contains several factual mistakes and some potentially=20 > damaging recommendations. In addition to resolving my review=20 > comments, I would suggest that the document shepherd request=20 > a technical review from members of the Transport area who=20 > focus on NAT-related technologies. >=20 > While there are some strong technical points in this=20 > document, I think that they are severely weakened by the=20 > length of the document and the level of > IPv6 marketing hype included in a document that is=20 > simultaneously bashing NAT providers for exactly this sort of=20 > behaviour. Little of this hype, including the entire=20 > appendix, is actually operational advice of any kind, and I=20 > don't know why the IETF would want to publish it. There are=20 > already existing groups that market IPv6, and I think that it=20 > is outside the scope of the IETF to do so. >=20 > The authors also seem to have inserted quite a bit of their=20 > own religion, and I think that there are large parts of this=20 > document that do not even come close to expressing IETF=20 > consensus on various topics like NAT features, the usefulness=20 > of firewalls, appropriate use of the IGP routing practices,=20 > etc. It seems unlikely that this document has received=20 > adequate review from people in these areas. >=20 > In other words, I think that some of the contents of this=20 > document and the current editorial style make it unsuitable=20 > for publication as an RFC. >=20 > Specific comments are included below, along with the document=20 > exerpts that they refer to. >=20 > Margaret >=20 > --- >=20 >=20 > Abstract >=20 > Although there are many perceived benefits to Network Address > Translation (NAT), its primary benefit of "amplifying" available > address space is not needed in IPv6. In addition to NAT's many > serious disadvantages, there is a perception that other benefits > exist, such as a variety of management and security=20 > attributes that > could be useful for an Internet Protocol site. IPv6 does=20 > not support > NAT by design and this document shows how Network Architecture > Protection (NAP) using IPv6 can provide the same or more benefits > without the need for NAT. >=20 > This abstract seems very slanted. I also think that it would=20 > be incorrect at this point to say that "amplifying" address=20 > space is the primary benefit of NATs, as many companies use=20 > them in spite of the fact that they have plenty of address=20 > space available. >=20 > There are at least three other _real_ benefits of NAT boxes. =20 > While I hold with this document's position that these=20 > benefits can and should be realized in other ways in IPv6, I=20 > do not think it is factual or helpful to argue that they=20 > don't exist. Those benefits are: >=20 > (1) Avoiding the reliance of internal network number on=20 > externally allocated numbers. AKA not having to renumber=20 > when you change ISPs or when ISPs change address allocation=20 > strategies. >=20 > (2) Hiding internal topology from external communicants. >=20 > (3) Avoiding the establishment of unauthorized inbound connections. > While this NAT side effect can also cause problems, it does=20 > provide the real benefits of a stateful firewall. >=20 > 1. Introduction >=20 > Although there are many perceived benefits to Network Address > Translation (NAT), its primary benefit of "amplifying" available > address space is not needed in IPv6. The serious disadvantages of > ambiguous "private" address space and of Network Address=20 > Translation > (NAT) [1][5] have been well documented [4][6]. However, given its > wide market acceptance NAT undoubtedly has some perceived=20 > benefits. > Indeed, in an Internet model based on universal any-to-any > connectivity, product marketing departments have driven a=20 > perception > hat some connectivity and security concerns can only be solved by > using a NAT device or by using logically separated Local=20 > Area Network > (LAN) address spaces. This document describes the reasons for > utilizing a NAT device in an IPv4 environment that are regularly > cited in marketing pronouncements. It then shows how=20 > these needs can > be met without using NAT in an IPv6 network. Some of the IPv6 > solutions offer advantages beyond the equivalent IPv4 NAT=20 > solution. > The use of the facilities from IPv6 described in this=20 > document avoids > the negative impacts of address translation. >=20 >=20 > I don't understand, at all, the mentione of "marketing departments" > and "marketing pronouncements" in this section and think it=20 > should be reworded to remove them and/or cite specific=20 > documents. There are real reasons why people use NATs in=20 > IPv4, and there are better ways to do those things with IPv6.=20 > That's what we should say. The text in the above paragraph=20 > is insulting, incorrect and very likely to get the network=20 > administrator to stop reading before you can offer any advice=20 > on how to set-up an IPv6 network. >=20 >=20 > 2. Perceived Benefits of NAT and its Impact on IPv4 >=20 > This section provides insight into the generally=20 > perceived benefits > of the use of IPv4 NAT as extolled by product marketing. =20 > The goal of >=20 >=20 > Again with the "product marketing". Do the authors of this=20 > document really believe that these benefits do not exist? =20 > Does the IETF as a whole? I think we should be somewhat=20 > embarrassed to publish this document as-is, because it seems=20 > very naive and one-sided. This continues throughout the=20 > document, but I will not continue to mention it. >=20 > 2.2. Simple Security due to Stateful Filter Implementation >=20 > A firewall doesn't fully secure a network, because many=20 > attacks come > from inside or are at a layer higher than the firewall can protect > against. In the final analysis, every system has to be=20 > responsible > for its own security, and every process running on a=20 > system has to be > robust in the face of challenges like stack overflows etc. What a > firewall does is prevent a network administration from=20 > having to pay > for bandwidth to carry unauthorized traffic, and in so=20 > doing reduce > the probability of certain kinds of attacks across the protected > boundary. >=20 > This is the section where we are describing the benefits of=20 > NAT without analyzing them. So, why is this sub-section=20 > here? It is clear that the side effects of NAT can be used=20 > as one element of a system to protect internal nodes. It is=20 > not sufficient to protect them from everything, which doesn't=20 > mean that it doesn't protect them against anything. Much of=20 > this section could appear to be an argument that firewalls of=20 > all kinds are useless because of the existence of Trojan=20 > Horse-style attacks, which is obviously false. Have any=20 > firewall experts been asked to review this section? If not,=20 > I think you should ask someone like Steve Bellovin to do so. >=20 >=20 > 2.3. User/Application tracking >=20 > Although NATs create temporary state for active sessions,=20 > in general > they provide limited capabilities for the administrator=20 > of the NAT to > gather information about who in the private network is requesting > access to which Internet location. This could in theory=20 > be done by > logging the network address translation details of the private and > the public addresses from the NAT device's state database. >=20 > The checking of this database is not always a simple=20 > task, especially > if Port Address Translation is used. It also has an unstated > assumption that the administrative instance has a mapping=20 > between an > IPv4-address and a network element or user at all times, or the > administrator has a time-correlated list of the address/port > mappings. >=20 >=20 > I think that this document is arguing that User/Application=20 > tracking is not a benefit of NAT? If so, why is it even in=20 > this document? >=20 > 2.4. Privacy and Topology Hiding >=20 > The goal of 'topology hiding' is to provide devices on the private > network with an identifier (IPv4 address) which an entity=20 > outside the > network can use to communicate with or to reference the private > network devices in protocols but prevents the external=20 > entity making > a correlation between the topological location of the=20 > private device > and the address on the local network. >=20 > The above sentence does not parse (editorial). >=20 > The use of NAT then results in a user behind a NAT=20 > gateway actually > appearing on the Internet as a user inside the NAT box=20 > itself; i.e., > the IPv4 address that appears on the Internet is only=20 > sufficient to > identify the NAT. When concealed behind a NAT it is impossible to > tell from the outside which member of a family, which=20 > customer of an > Internet cafe, or which employee of a company generated=20 > or received a > particular packet. Thus, although NATs do nothing to provide > application level privacy, they do prevent the external=20 > tracking and > profiling of individual host computers by means of their IP > addresses, usually known as 'device profiling'. At the=20 > same time a > NAT creates a smaller pool of addresses for a much more=20 > focused point > of attack. >=20 > What does the last sentence mean? Give some sort of example=20 > or take it out, perhaps? >=20 > 3.4. Untraceable IPv6 Addresses >=20 > These should be globally routable IPv6 addresses which can be > randomly and independently assigned to IPv6 devices. >=20 > The random assignment is intended to mislead the outside=20 > world about > the structure of the local network. However the local=20 > network needs > to maintain a correlation between the location of the=20 > device and the > untraceable IPv6 address. This correlation could be done by > generating IPv6 host route entries or by utilizing an indirection > device such as a Mobile IPv6 Home Agent. >=20 > Is not technically sound to advocate the dissemination of=20 > host routes in the IGP for infrastructure hiding. IGPs are=20 > not designed to scale well for this sort of use. It would be=20 > much more technically sound to advocate the use of > L2 switching to avoid exposure of network topology at L3. >=20 > Besides, I thought the point of network address hiding (or=20 > one of them), as outlined above was to avoid the ability to=20 > identify different nodes by address for port scanning=20 > purposes, not (merely) to avoid the ability to tell what=20 > subnets they are on. The proposed technique doesn't seem to=20 > address that issue at all. >=20 > With external connectivity the simple gateway could also=20 > use DHCP-PD > to acquire a routing prefix from the service provider for use when > connecting to the global Internet. End-system=20 > connections involving > other nodes on the global Internet will always use the global IPv6 > addresses [9] derived from this prefix delegation. It should be > noted that the address selection policy table in=20 > end-systems needs to > be correctly set up so that true global prefixes are distinguished > from ULAs and will be used for the source address in=20 > preference when > the destination is not a ULA. >=20 > Unless one takes steps to actively screw this up, a globally=20 > routable destination address will always have a=20 > longest-prefix match with a globally routable source and a=20 > ULA will always have a longest-prefix match with a ULA. So,=20 > the last sentence is completely unnecessary and somewhat misleading. >=20 > The tricky part is making sure that the node uses the right=20 > _destination_ address -- a ULA for local traffic and global=20 > address for non-local traffic. > This will generally require the use of some type of split=20 > DNS, with ULAs returned internally but not externally. >=20 > In the very simple case there is no explicit routing=20 > protocol and a > single default route is used out to the global Internet. =20 > A slightly > more complex case might involve local routing protocols,=20 > but with the > entire local network sharing a common global prefix there=20 > would still > not be a need for an external routing protocol as a default route > would continue to be consistent with the connectivity. >=20 > I don't understand this paragraph at all. What does it have=20 > to do with ULAs? Also, the second half of this sentence=20 > doesn't make sense. > I'm not 100% sure what it means, but if it means what I think=20 > it means, it is wrong. >=20 > 4.2. IPv6 and Simple Security >=20 > The vulnerability of an IPv6 host is similar to that of=20 > an IPv4 host > directly connected towards the Internet. The use of firewall and > Intrusion Detection Systems (IDS) is recommended. A proxy may be > used for certain applications, but with the caveat that the end to > end transparancy is broken. However, with IPv6, the following > protections are available without the use of NAT while maintaining > end-to-end reachability: > 1. Short lifetimes on privacy extension suffixes reduce=20 > the attack > profile since the node will not respond to the=20 > address once the > address is no longer valid. > 2. IPsec is a mandatory service for IPv6 implementations. IPsec > functions to prevent session hijacking, prevent content > tampering, and optionally masks the packet contents. =20 > While IPsec > might be available in IPv4 implementations, deployment in NAT > environments either breaks the protocol or requires complex > helper services with limited functionality or efficiency. >=20 > IPsec performs exactly the same purposes in IPv4 as IPv6. I=20 > don't know of any stacks that implement IPsec for IPv6 and=20 > not for IPv4. > Also, it is not clear that end-to-end IPsec is fundamentally=20 > useful, even without the interference of a NAT box, as I=20 > believe that there needs to be some sort of binding to the=20 > upper layer protocol in order for IPsec to provide these protections. >=20 > If you decide to keep this section, you should acknowledge=20 > that use of the > IPv6 stateful firewall mechanisms advocated in bullet 3 will=20 > present similar obstacles to using IPsec. >=20 >=20 > 3. The size of the address space of a typical subnet (64 bits of > IID) will make an effective network ping sweep and resulting > port-scan virtually impossible due to the number of possible > combinations available, provided that IIDs are essentially > randomly distributed across the available space. >=20 > IIDs will not be randomly distributed. They are based on=20 > EUI-64 IDs which are certainly not randomly distributed. In=20 > fact, on Ethernet 16 of the 64-bits will have a known value. =20 > Also, the numbering space for the first three bytes (24-bits)=20 > is not completely allocated and there is very clearly an=20 > unbalanced distribution in that space. The fact that=20 > companies tend to buy somewhat homogenous hardware can make=20 > it possible to guess which three-byte combinations are most=20 > likely to be present within a given company. So, the length=20 > of the IID offers nowhere near the level of protection=20 > described above. >=20 >=20 > This protection is nullified if the attacker has no=20 > access to a > local connection. If an attacker has local access then he > could use ND [3] and ping6 to ff02::1 to detect local > neighbors. (Of course, a locally connected attacker has many > scanning options with IPv4 as well.) It is recommended for > site administrators to take [18] into consideration to achieve > the expected goal. This protection will also be nullified if > IIDs are configured in a group near the start of the=20 > IID space. >=20 > Assuming the network administrator is aware of [18] the increased > size of the IPv6 address will make topology probing much=20 > harder, and > almost impossible for IPv6 devices. The intention of topology > probing is to identify a selection of the available hosts=20 > inside an > enterprise. This mostly starts with a ping-sweep. Since the IPv6 > subnets are 64 bits worth of address space, this means that an > attacker has to send out a simply unrealistic number of=20 > pings to map > the network, and virus/worm propagation will be thwarted in the > process. At full rate 40Gbps (400 times the typical=20 > 100Mbps LAN, and > 13,000 times the typical DSL/Cable access link) it takes over 5000 > years to scan a single 64 bit space. >=20 > See my comments above about why this is not correct. >=20 > 4.3. User/Application Tracking >=20 > IPv6 enables the collection of information about data=20 > flows. Due to > the fact that all addresses used for Internet and=20 > intra-/inter-site > communication are unique, it is possible for an=20 > enterprise or ISP to > get very detailed information on any communication=20 > exchange between > two or more devices. This enhances the capability of data-flow > tracking for security audits compared with IPv4 NAT,=20 > because in IPv6 > a flow between a sender and receiver will always be uniquely > identified due to the unique IPv6 source and destination=20 > addresses. >=20 > Why is this mentioned in this document? Given this=20 > paragraph, I think you have perversely stated another benefit=20 > of NAT -- that my ISP cannot effectively track this=20 > information on a per-machine basis. > Also, how is this consistent with the idea that IPv6 will use=20 > privacy address for client communications? >=20 > There are two possible scenarios for the extreme situation when a > network manager also wishes to fully conceal the internal IPv6 > topology. >=20 > o One could use explicit host routes and remove the correlation > between location and IPv6 address. This solution does however > show severe scalability issues. >=20 > Right. That is why we should not recommend it. >=20 > o The other technology to fully hide the internal=20 > topology would be > to use a tunneling mechanism. Mobile IPv6 without route > optimization is one example. In this example the public facing > addresses are indirected via an edge Home Agent (HA). This > indirection method truly masks the internal topology=20 > as all nodes > with global access appear to share a common prefix. =20 > The downside > of using this method is that it makes usage of=20 > middleware like a > Home Agent (HA). >=20 > This seems awfully complex and may present other problems,=20 > such as brittleness and MTU/fragmentation issues. >=20 > What are the possible benefits of subnet hiding that could=20 > justify this type of solution? >=20 > There are other answers involving L2 bridging with VLANs for=20 > limiting broadcast domains that are much more scalable and=20 > simpler than either of these approaches. >=20 >=20 > 4.5. Independent Control of Addressing in a Private Network >=20 > [...] >=20 > When using IPv6, the need to ask for more address space=20 > will become > far less likely due to the increased size of the subnets. These > subnets typically allow 2^64 addresses per subnet and an=20 > enterprise > will typically receive a /48 which allows segmentation=20 > into at least > 2^16 different subnets. >=20 > The ongoing subnet size maintenance may become simpler when IPv6 > technology is utilised. If IPv4 address space is=20 > optimised one has > to look periodically into the number of hosts on a segment and the > subnet size allocated to the segment; an enterprise today=20 > may have a > mix of /28 - /23 size subnets for example, and may=20 > shrink/grow these > as their network user base changes. For IPv6 all subnets have /64 > prefixes. >=20 > I am not really sure what any of this has to do with=20 > anything, and it isn't entirely correct. The 64-bit IID is a=20 > hard limit in IPv6, but there is no hard limit that all sites=20 > will be allocated a /48. >=20 > 4.6. Global Address Pool Conservation >=20 > IPv6 provides sufficient space to completely avoid the need for > overlapping address space, > 340,282,366,920,938,463,463,374,607,431,768,211,456=20 > (3.4*10^38) total > possible addresses. As previously discussed, the serious >=20 > The naivete of pointing out the number of possible IPv6=20 > addresses actually hurts this argument. Because of the=20 > 64-bit IID and the IETF's recommendations to allocate a /48=20 > to home users, the address space will be much less densely=20 > used than in IPv4. Many people still feel that there will be=20 > enough address space that conservation is not needed, and=20 > there are decent documents that you could cite that make that=20 > argument. This has little or nothing to do with the number=20 > of possible addresses in IPv6, though. >=20 > disadvantages of ambiguous address space have been well=20 > documented, > and with sufficient space there is no need to continue the > increasingly aggressive conservation practices that are necessary > with IPv4. While IPv6 allocation policies and ISP=20 > business practice > will continue to evolve, the recommendations in RFC 3177=20 > are based on > the technical potential of the vast IPv6 address space. That > document demonstrates that there is no resource=20 > limitation which will > require the adoption of the IPv4 workaround of ambiguous=20 > space behind > a NAT. As an example of the direct contrast, many=20 > expansion oriented > IPv6 deployment scenarios result in multiple IPv6 addresses per > device, as opposed to the constriction of IPv4 scenarios where > multiple devices are forced to share a scarce global address. >=20 > 4.7. Multihoming and Renumbering >=20 > Multihoming and renumbering remain technically=20 > challenging with IPv6 > (see the Gap Analysis below). However, IPv6 was designed to allow > sites and hosts to run with several simultaneous=20 > CIDR-like prefixes > and thus with several simultaneous ISPs. An address selection > mechanism [10] is specified so that hosts will behave consistently > when several addresses are simultaneously valid. The fundamental > difficulty that IPv4 has in this regard therefore does=20 > not apply to > IPv6. IPv6 sites can and do run today with multiple ISPs=20 > active, and > the processes for adding and removing active prefixes at=20 > a site have > been documented [12] and [19]. >=20 > To be balanced, you should at least say something here about=20 > the fact that end-user sites that currently have "swamp=20 > space" addresses in IPv4 may need to move ot ISP-provided=20 > addresses in IPv6, thus increasing concerns about renumbering=20 > and multi-homing. >=20 > If there is need to mask the internal structure towards=20 > the external > IPv6 internet, then some form of 'untraceable' addresses=20 > may be used. > These addresses will be derived from a local pool, and may be > assigned to those hosts for which topology masking is required or > which want to reach the IPv6 Internet or other external networks. > The technology to assign these addresses to the hosts=20 > could be based > on DHCPv6. To complement the 'Untraceable' addresses it=20 > is needed to > have at least awareness of the IPv6 address location when=20 > routing an > IPv6 packet through the internal network. This could be=20 > achieved by > 'route-injection' in the network infrastructure. This route- > injection could be done based on /128 host-routes to each=20 > device that > wants to connect to the Internet using an untraceable=20 > address. This > will provide the most dynamic masking, but will have a scalability > limitation, as an IGP is typically not designed to carry many > thousands of IPv6 prefixes. A large enterprise may have=20 > thousands of > hosts willing to connect to the Internet. Less flexible masking > could be to have time-based IPv6 prefixes per link or=20 > subnet. This > may reduce the amount of route entries in the IGP by a significant > factor, but has as trade-off that masking is time and=20 > subnet based. >=20 > This whole "untraceable" address concept seems to be poorly=20 > thought- out. I am concerned that this document, while=20 > supposedly an informational document on existing IPv6=20 > features is trying to specify a new IPv6 feature and doing it=20 > quite inadequately, IMO. >=20 > While a full prefix is expected to be the primary deployment model > there may be cases where the ISP provides a single IPv6=20 > address for > use on a single piece of equipment (PC, PDA, etc.). >=20 > How does this differ from the "single user connection" case=20 > described in 5.3? >=20 > 6.1. Subnet Topology Masking >=20 > There really is no functional gap here as a centrally=20 > assigned pool > of addresses in combination with host routes in the IGP is an > effective way to mask topology. >=20 > You discuss the scaling issues in your own document, so this=20 > seems to be misleading. >=20 > 6.4. Site Multihoming >=20 > This complex problem has never been completely solved for=20 > IPv4, which > is exactly why NAT has been used as a partial solution. For IPv6, > after several years' work, the IETF has converged on an=20 > architectural > approach intended with service restoration as initial aim [20]. > Again, ULAs may help since they will provide stable addressing for > internal communications that are not affected by multihoming. >=20 >=20 > Depending on what benefits are expected from multihoming, the=20 > capacity for > IPv6 to use more than one prefix per interface may help here, too. >=20 > Appendix A. Additional Benefits due to Native IPv6 and=20 > Universal Unique > Addressing >=20 > I am not really sure that including a "marketing brochure"=20 > regarding the general benefits of IPv6 at the end of this=20 > document serves to make it any clearer. >=20 > The users of native IPv6 technology and global unique=20 > IPv6 addresses > have the potential to make use of the enhanced IPv6=20 > capabilities, in > addition to the benefits offered by the IPv4 technology. >=20 > A.1. Universal Any-to-Any Aonnectivity >=20 > Connectivity, perhaps? >=20 > A.4. Increased Security Protection >=20 > The security protection offered by native IPv6 technology is more > advanced than IPv4 technology. There are various transport > mechanisms enhanced to allow a network to operate more=20 > securely with > less performance impact: > o IPv6 has the IPsec technology directly embedded into the IPv6 > protocol. >=20 > See note above. IPsec is no more "embedded" in IPv6 than it=20 > is in IPv4. >=20 > This allows for simpler peer-to-peer encryption and > authentication, once a simple key/trust management model is > developed, while the usage of some other less secure=20 > mechanisms is > avoided (i.e. md5 password hash for neighbor authentication). > o On a local network, any user will have more security awareness. >=20 > IPv6 will make users more security-aware? What does that even mean? >=20 > This awareness will motivate the usage of simple firewall > applications/devices to be inserted on the border between the > external network and the local (or home network) as there is no > Address Translater and hance no false safety perception. > o All flows on the Internet will be better traceable due=20 > to a unique > and globally routable source and destination IPv6=20 > address. This > may facilitate an easier methodology for back-tracing=20 > DoS attacks > and avoid illegal access to network resources by=20 > simpler traffic > filtering. >=20 > We already can trace these flows inside the NAT just fine. =20 > The only place it is now easier to trace is outside my NAT,=20 > where the attackers live. >=20 > o The usage of private address-space in IPv6 is now provided by > Unique Local Addresses, which will avoid conflict=20 > situations when > merging networks and securing the internal communication on a > local network infrastructure due to simpler traffic filtering > policy. >=20 > How is this a security benefit? >=20 > o The technology to enable source-routing on a network > infrastructure has been enhanced to allow this feature to > function, without impacting the processing power of=20 > intermediate > network devices. The only devices impacted with the source- > routing will be the source and destination node and the > intermediate source-routed nodes. This impact behavior is > different if IPv4 is used, because then all=20 > intermediate devices > would have had to look into the source-route header. >=20 > Again, how is this a security benefit? >=20 > A.5. Mobility >=20 > Anytime, anywhere, universal access requires MIPv6 services in > support of mobile nodes. While a Home Agent is required=20 > for initial > connection establishment in either protocol version, IPv6 mobile > nodes are able to optimize the path between them using the MIPv6 > option header while IPv4 mobile nodes are required to=20 > triangle route > all packets. In general terms this will minimize the network > resources used and maximize the quality of the communication. >=20 > Nice plug for MIP6, but why is it here? And, have you run=20 > this text by the > MIP4 WG to make sure that they agree with it? >=20 > A.7. Community of interest >=20 > Although some Internet-enabled devices will function as=20 > fully- fledged > Internet hosts, it is believed that many will be operated=20 > in a highly > restricted manner functioning largely or entirely within=20 > a Community > of Interest. By Community of Interest we mean a=20 > collection of hosts > that are logically part of a group reflecting their ownership or > function. Typically, members of a Community of Interest need to > communicate within the community but should not be generally > accessible on the Internet. They want the benefits of the > connectivity provided by the Internet, but do not want to=20 > be exposed > to the rest of the world. This functionality will be available > through the usage of NAP and native IPv6 dataflows, without any > stateful device in the middle. It will also allow to=20 > build virtual > organization networks on the fly, which is very difficult to do in > IPv4+NAT scenarios. >=20 > Uh... What is this all about? VPNs? Something else? Why=20 > is this different in IPv6 than in IPv4? >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 29 09:52:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkiAE-0005Js-LT for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:52:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkiA9-0000vO-Bz for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:52:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fki8t-0001SF-1U for v6ops-data@psg.com; Mon, 29 May 2006 13:50:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fki8s-0001S0-Bd for v6ops@ops.ietf.org; Mon, 29 May 2006 13:50:46 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 5298A341E2; Mon, 29 May 2006 09:50:45 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 09:50:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Status of Operational issues with Tiny Fragments in IPv6 Date: Mon, 29 May 2006 09:50:43 -0400 Message-ID: <936A4045C332714F975800409DE09240025BCBC0@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Operational issues with Tiny Fragments in IPv6 Thread-Index: AcaA7v8bHpbWwXekSv+Z0gMPfO39fQCNjVyw From: "Bound, Jim" To: "Fred Baker" , "Templin, Fred L" Cc: "Elwyn Davies" , "Vishwas Manral" , X-OriginalArrivalTime: 29 May 2006 13:50:45.0115 (UTC) FILETIME=[E20D34B0:01C68326] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 I may be missing the issue in the draft but I take the main issue to be as follows: From section 4 of the spec >Having tiny fragments could mean that none of the fragments would be the Initial=20 >Fragment. So any access control/ tunneling based onthat may not work unless reassembly >is done, or extra state like nextHeader and previous header length remaining are kept >across fragments. My first thought now is this is life with IPv4 or IPv6. Packet assembly and reassembly is required. The spec does not provide for me why this cannot be done from an IETF protocol view for IPv6. Is this an implementation problem and not IETF specification problem, thus it was correct to send it to v6ops to do logic check if there is anything we can do operationally to address the stated issue. I don't think this spec should even move forward, but again maybe I am missing the issue that is other than the mid box doing normal packet reassembly for IPv6? NB: Also if the packet was encrypted with IPsec many of the security issues are addressed and also the entire notion of Firewalls for implementation (as opposed to IETF standardization) is current discussion in multiple market vertical segments how end-to-end with IPsec is implemented when Firewalls are present. Best, /jim From owner-v6ops@ops.ietf.org Mon May 29 09:54:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkiC6-00065x-2R for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:54:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkiC1-0001Dz-G0 for v6ops-archive@lists.ietf.org; Mon, 29 May 2006 09:54:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FkiBe-0001i9-Vc for v6ops-data@psg.com; Mon, 29 May 2006 13:53:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [158.38.62.9] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FkiBc-0001hq-Rt for v6ops@ops.ietf.org; Mon, 29 May 2006 13:53:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 5C17A87BE2; Mon, 29 May 2006 15:53:35 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21671-01-23; Mon, 29 May 2006 15:53:34 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 6839E87BD4; Mon, 29 May 2006 15:53:34 +0200 (CEST) Message-ID: <447AFCDE.604@uninett.no> Date: Mon, 29 May 2006 15:53:34 +0200 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060428) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker Cc: Elwyn Davies , Vishwas Manral , v6ops@ops.ietf.org Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Fred Baker wrote: > On May 26, 2006, at 1:21 AM, Elwyn Davies wrote: > >> I would suggest that rather than making this into a separate draft we >> can look at improving the text in the security overview (if >> necessary) given that we are probably going to have to do *another* >> round on this one. > > > That seems rational to me. Me too. As Pekka said any normative changes to the IPv6 protocol would probably have to go elsewhere anyway. > > A quick comment: > >> - no overlapping fragments and Overlapping fragments is the main problem IMO. I would have liked this to be banned so that implementations can just drop such packets. Of course some hosts might still accept them, and e.g. a firewall would need to keep some state to detect overlap. >> - non-last fragments to be close to the guaranteed minimum MTU. > > > I think the latter point wants to read "non-last fragments close to the > PATH MTU, and therefore at least as large as the largest fragment size > less than or equal in size to the minimum MTU." The draft doesn't talk about overlap, but talks about this latter point. Unless overlap is forbidden, a minimum size alone is not sufficient. You might have an initial fragment containing most of the datagram (of sufficient size), and then have a second overlapping one that overwrites parts of the header. Whatever minimum size we set, one may add so many extension headers that e.g. the transport header does not go into the first fragment anyway. If a minimum fragment size is specified, then I think it should be about half the minimum MTU. Rather than using the MTU for all fragments but the last, it might make sense to distribute the data evenly so that all fragments are roughly the same size. See below. > There is a discussion of fragmentation and reassembly in RFC 1812 > section 4.2.2.7 that may be useful to reference, or at least learn > lessons from. In part, this results from the behavior of NIC cards in > the late 1980's that couldn't reliably receive datagrams back to back > for very long due to chip or memory issues, and partly this is is due > to brain-dead behaviors in early end-station OS's. One issue was that > many systems sent packets at the minimum MTU size (then 576 bytes, > derived from the memory structure of the Fuzzball and BBN Routers) > rather than at the path MTU, which meant that there were greater > opportunities for per-datagram errors because there were more of them. > There were also various strategies on how to fragment - should the > first datagram be the smallest, the last, or should the fragmenting > system try to make them all approximately the same size? It makes some > specific recommendations: > >> 4.2.2.7 Fragmentation: RFC 791 Section 3.2 >> >> Fragmentation, as described in [INTERNET:1], MUST be supported by a >> router. >> >> When a router fragments an IP datagram, it SHOULD minimize the number >> of fragments. When a router fragments an IP datagram, it SHOULD send >> the fragments in order. A fragmentation method that may generate one >> IP fragment that is significantly smaller than the other MAY cause >> the first IP fragment to be the smaller one. >> >> DISCUSSION >> There are several fragmentation techniques in common use in the >> Internet. One involves splitting the IP datagram into IP >> fragments with the first being MTU sized, and the others being >> approximately the same size, smaller than the MTU. The reason for >> this is twofold. The first IP fragment in the sequence will be >> the effective MTU of the current path between the hosts, and the >> following IP fragments are sized to minimize the further >> fragmentation of the IP datagram. Another technique is to split >> the IP datagram into MTU sized IP fragments, with the last >> fragment being the only one smaller, as described in [INTERNET:1]. >> >> A common trick used by some implementations of TCP/IP is to >> fragment an IP datagram into IP fragments that are no larger than >> 576 bytes when the IP datagram is to travel through a router. >> This is intended to allow the resulting IP fragments to pass the >> rest of the path without further fragmentation. This would, >> though, create more of a load on the destination host, since it >> would have a larger number of IP fragments to reassemble into one >> IP datagram. It would also not be efficient on networks where the >> MTU only changes once and stays much larger than 576 bytes. >> Examples include LAN networks such as an IEEE 802.5 network with a >> MTU of 2048 or an Ethernet network with an MTU of 1500). >> >> One other fragmentation technique discussed was splitting the IP >> datagram into approximately equal sized IP fragments, with the >> size less than or equal to the next hop network's MTU. This is >> intended to minimize the number of fragments that would result >> from additional fragmentation further down the path, and assure >> equal delay for each fragment. This latter point is what I'm refering to above. Also note that as mentioned above, some implementations send fragments out of order (e.g. Linux has been known to do this). The reason is that you don't know the total size of the datagram until you receive the last fragment. Receiving the last fragment first means that you can allocate the right amount of memory immediately. Stig >> >> Routers SHOULD generate the least possible number of IP fragments. >> >> Work with slow machines leads us to believe that if it is >> necessary to fragment messages, sending the small IP fragment >> first maximizes the chance of a host with a slow interface of >> receiving all the fragments. > > > I think the NIC card issue (where should the smallest fragment be?) is > historical and not to be worried about. But the matter of generating > (by whatever algorithm) the least number of fragments that can > represent a transport-level message is, I think, important. > From owner-v6ops@ops.ietf.org Tue May 30 01:08:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkwTA-0000vc-VC for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 01:08:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkwT7-0005YU-Kp for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 01:08:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FkwQG-0008Gs-As for v6ops-data@psg.com; Tue, 30 May 2006 05:05:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.197] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FkwQF-0008GS-HO for v6ops@ops.ietf.org; Tue, 30 May 2006 05:05:39 +0000 Received: by wx-out-0102.google.com with SMTP id s8so419151wxc for ; Mon, 29 May 2006 22:05:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rbSOzCPTENYkLSp1O02YaH/WLCt1DvSj9UuX3UZWxVHGJ0rSGIKAR5obzPpMtHH6Na+gwcvExo5hxrZJ5hkWicZc7yTSWXyteRalTjU2kLiWu/QiR2FRDdlWY6pBWWF8b2RJxHuCQ9MbTmSc0GSW3fP65E7Ki0zTTR3XJeXe/40= Received: by 10.70.31.14 with SMTP id e14mr3140569wxe; Mon, 29 May 2006 22:05:38 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Mon, 29 May 2006 22:05:38 -0700 (PDT) Message-ID: <77ead0ec0605292205p2a295aadr1109ccd620f13f3a@mail.gmail.com> Date: Tue, 30 May 2006 10:35:38 +0530 From: "Vishwas Manral" To: "Bound, Jim" Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Cc: "Fred Baker" , "Templin, Fred L" , "Elwyn Davies" , v6ops@ops.ietf.org In-Reply-To: <936A4045C332714F975800409DE09240025BCBC0@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <936A4045C332714F975800409DE09240025BCBC0@tayexc14.americas.cpqcorp.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi Jim, You raise a valid concern. The issue I see in my view came up when working on firewalls in the Fastpath. I figured out that in IPv4 the header options are optional, so packets with options are either sent to the slow path or are dropped(the more common case). This also means that a non-last fragment of less than 64 bytes can easily be dropped(which means that we will have the TCP header in the first fragmet), so most TCP and transport level header checks like TCP-SYN attacks can be easily detected. Even a simple 5 tuple based check may not work. In IPv6, however the extension headers are part of the base protocol and as we do not have a minimum length for non-last fragment, there is no way to guarantee that the TCP header is present in the first header. So basic checks as above cannot be done easily. That said, for IPsec ESP tunnelled packets(for AH the header inside can always be looked into) the IPsec authentication at the device doing the decryption will guarantee that the packet is valid. Note with RFC4301 the authentication itself is a MUST for ESP now. Do let me know if I am missing the point altogather? Thanks, Vishwas On 5/29/06, Bound, Jim wrote: > I may be missing the issue in the draft but I take the main issue to be > as follows: > > From section 4 of the spec > >Having tiny fragments could mean that none of the fragments would be > the Initial > >Fragment. So any access control/ tunneling based onthat may not work > unless reassembly >is done, or extra state like nextHeader and previous > header length remaining are kept >across fragments. > > My first thought now is this is life with IPv4 or IPv6. Packet assembly > and reassembly is required. The spec does not provide for me why this > cannot be done from an IETF protocol view for IPv6. > > Is this an implementation problem and not IETF specification problem, > thus it was correct to send it to v6ops to do logic check if there is > anything we can do operationally to address the stated issue. > > I don't think this spec should even move forward, but again maybe I am > missing the issue that is other than the mid box doing normal packet > reassembly for IPv6? > > NB: Also if the packet was encrypted with IPsec many of the security > issues are addressed and also the entire notion of Firewalls for > implementation (as opposed to IETF standardization) is current > discussion in multiple market vertical segments how end-to-end with > IPsec is implemented when Firewalls are present. > > > Best, > /jim > From owner-v6ops@ops.ietf.org Tue May 30 11:26:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl66y-00081u-JX for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 11:26:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl66t-0005jU-3E for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 11:26:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl638-000PW2-NI for v6ops-data@psg.com; Tue, 30 May 2006 15:22:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl634-000PVg-HW for v6ops@ops.ietf.org; Tue, 30 May 2006 15:22:22 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 2A4363439B; Tue, 30 May 2006 11:22:19 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 11:22:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Status of Operational issues with Tiny Fragments in IPv6 Date: Tue, 30 May 2006 11:22:16 -0400 Message-ID: <936A4045C332714F975800409DE09240025BCED5@tayexc14.americas.cpqcorp.net> In-Reply-To: <77ead0ec0605292205p2a295aadr1109ccd620f13f3a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Operational issues with Tiny Fragments in IPv6 Thread-Index: AcaDprOh9YjvejdQQAGZlWnmw1DLxAAU68Pg From: "Bound, Jim" To: "Vishwas Manral" Cc: "Fred Baker" , "Templin, Fred L" , "Elwyn Davies" , X-OriginalArrivalTime: 30 May 2006 15:22:18.0946 (UTC) FILETIME=[D70B0A20:01C683FC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Hi Vishwas, My first question was if the issue is not doing complete packet reassembly and as I see that issue it simply is a requirement for any node receiving an end-to-end set of fragments the way it is done with IPv6. Once the packet is assembled and processed then this next issue requires analysis, but the next header values can assist with locating upper layer headers but RFC 2460 is pretty clear on receivers: From RFC 2460: Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. A firewall or intrusion detection need to make certain implementation decisions as they are typically not the end receiver per RFC 2460. The question really is when an extension header does not apply to the implementation it can by pass that extension? But from RFC 2460: If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. So I view the issue possibly not one of tiny fragments as all because nodes need to do packet assembly, but how do secure interim nodes process ext headers before the next header these secure interim nodes require. My answer is as follows. The node IP stack implementation must adhere to the spec. But, the IETF makes no requirement at all what users implement or any other standards body, as all we really provide is the opportunity and ability for things to work correctly from our specifications. Firewalls or edge Intrusion Detection devices/software/sensors are anomaly's within the users environment to protect them beyond what open networking standards define. Thus, in this case of implementations that want to do next header scan as for a Firewall it is certainly possible and in my humble "individual" (not HP) opinion valid code path, or as you stated fast-path.=20 End result is not clear. There is an issue but lets see what other v6ops persons think as again maybe I am just missing the forest for the trees, but it is not the IETF or any standards bodies business to mandate use to the market that is their prerogative to accept or alter anything we provide them from the IETF. Hope this helps, /jim =20 > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Tuesday, May 30, 2006 1:06 AM > To: Bound, Jim > Cc: Fred Baker; Templin, Fred L; Elwyn Davies; v6ops@ops.ietf.org > Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 >=20 > Hi Jim, >=20 > You raise a valid concern. >=20 > The issue I see in my view came up when working on firewalls=20 > in the Fastpath. I figured out that in IPv4 the header=20 > options are optional, so packets with options are either sent=20 > to the slow path or are dropped(the more common case). This=20 > also means that a non-last fragment of less than 64 bytes can=20 > easily be dropped(which means that we will have the TCP=20 > header in the first fragmet), so most TCP and transport level=20 > header checks like TCP-SYN attacks can be easily detected.=20 > Even a simple 5 tuple based check may not work. >=20 > In IPv6, however the extension headers are part of the base=20 > protocol and as we do not have a minimum length for non-last=20 > fragment, there is no way to guarantee that the TCP header is=20 > present in the first header. So basic checks as above cannot=20 > be done easily. >=20 > That said, for IPsec ESP tunnelled packets(for AH the header=20 > inside can always be looked into) the IPsec authentication at=20 > the device doing the decryption will guarantee that the=20 > packet is valid. Note with RFC4301 the authentication itself=20 > is a MUST for ESP now. >=20 > Do let me know if I am missing the point altogather? >=20 > Thanks, > Vishwas >=20 > On 5/29/06, Bound, Jim wrote: > > I may be missing the issue in the draft but I take the main=20 > issue to=20 > > be as follows: > > > > From section 4 of the spec > > >Having tiny fragments could mean that none of the=20 > fragments would be > > the Initial > > >Fragment. So any access control/ tunneling based onthat=20 > may not work > > unless reassembly >is done, or extra state like nextHeader and=20 > > previous header length remaining are kept >across fragments. > > > > My first thought now is this is life with IPv4 or IPv6. Packet=20 > > assembly and reassembly is required. The spec does not=20 > provide for me=20 > > why this cannot be done from an IETF protocol view for IPv6. > > > > Is this an implementation problem and not IETF=20 > specification problem,=20 > > thus it was correct to send it to v6ops to do logic check=20 > if there is=20 > > anything we can do operationally to address the stated issue. > > > > I don't think this spec should even move forward, but again=20 > maybe I am=20 > > missing the issue that is other than the mid box doing=20 > normal packet=20 > > reassembly for IPv6? > > > > NB: Also if the packet was encrypted with IPsec many of the=20 > security=20 > > issues are addressed and also the entire notion of Firewalls for=20 > > implementation (as opposed to IETF standardization) is current=20 > > discussion in multiple market vertical segments how end-to-end with=20 > > IPsec is implemented when Firewalls are present. > > > > > > Best, > > /jim > > >=20 From owner-v6ops@ops.ietf.org Tue May 30 11:27:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl68L-0008VL-80 for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 11:27:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl68I-0005lp-UB for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 11:27:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl68C-000Puc-D7 for v6ops-data@psg.com; Tue, 30 May 2006 15:27:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl68B-000PuQ-Cq for v6ops@ops.ietf.org; Tue, 30 May 2006 15:27:39 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 May 2006 08:27:40 -0700 X-IronPort-AV: i="4.05,190,1146466800"; d="scan'208"; a="323785994:sNHT31792642" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4UFRdP3024384; Tue, 30 May 2006 08:27:39 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4UFRcCU019115; Tue, 30 May 2006 08:27:38 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4UFOLrD016223; Tue, 30 May 2006 08:24:21 -0700 In-Reply-To: <447AFCDE.604@uninett.no> References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <447AFCDE.604@uninett.no> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <024DBDEB-8070-4BD5-8297-F1A36BD6CB03@cisco.com> Cc: Elwyn Davies , Vishwas Manral , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Date: Tue, 30 May 2006 08:27:37 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=933; t=1149002859; x=1149866859; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Status=20of=20Operational=20issues=20with=20Tiny=20Fragments=20i n=20IPv6; X=v=3Dcisco.com=3B=20h=3Da5ojuOrTQJc1IP87NJ/vxv/Q9kM=3D; b=lVW/7jYoHpsEqiwU4ozyUcB34hct+uZirtaiDykZs48tPXkxU6BzQ0nfushJg4/qN/IniApu r6+lxbYxRSiyvYs7zR+dnxxjNhDMNMKol8A8QTQT6o35CepmGCjjiyJa; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On May 29, 2006, at 6:53 AM, Stig Venaas wrote: > Also note that as mentioned above, some implementations send > fragments out of order (e.g. Linux has been known to do this). The > reason is that you don't know the total size of the datagram until > you receive the last fragment. Receiving the last fragment first > means that you can allocate the right amount of memory immediately. On that particular point, since packets can be reordered in flight in a best effort network, it seems to me that the sender can neither prevent packets from arriving last fragment first. a middle box cannot accurately detect that the sender did or did not do this, and the receiver cannot depend on packets being sent last first. So if it happens it happens, but thinking very hard about it sounds like a fool's errand. Better to simply hang on to the mblks-or-equivalent until the segments have all arrived. From owner-v6ops@ops.ietf.org Tue May 30 12:08:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6lO-0007sK-HX for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 12:08:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl6lN-00017V-3F for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 12:08:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl6kk-0003Cc-Lm for v6ops-data@psg.com; Tue, 30 May 2006 16:07:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fl6kh-0003CL-EH for v6ops@ops.ietf.org; Tue, 30 May 2006 16:07:27 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9E8E87FFB; Tue, 30 May 2006 18:07:18 +0200 (CEST) Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 From: Jeroen Massar To: Fred Baker Cc: v6ops@ops.ietf.org In-Reply-To: <024DBDEB-8070-4BD5-8297-F1A36BD6CB03@cisco.com> References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <447AFCDE.604@uninett.no> <024DBDEB-8070-4BD5-8297-F1A36BD6CB03@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0lI7t7VHGcTE2RhBkswI" Organization: Unfix Date: Tue, 30 May 2006 18:07:08 +0200 Message-Id: <1149005228.19401.35.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --=-0lI7t7VHGcTE2RhBkswI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2006-05-30 at 08:27 -0700, Fred Baker wrote: > On May 29, 2006, at 6:53 AM, Stig Venaas wrote: > > Also note that as mentioned above, some implementations send =20 > > fragments out of order (e.g. Linux has been known to do this). The =20 > > reason is that you don't know the total size of the datagram until =20 > > you receive the last fragment. Receiving the last fragment first =20 > > means that you can allocate the right amount of memory immediately. >=20 > On that particular point, since packets can be reordered in flight in =20 > a best effort network, it seems to me that the sender can neither =20 > prevent packets from arriving last fragment first. a middle box =20 > cannot accurately detect that the sender did or did not do this, and =20 > the receiver cannot depend on packets being sent last first. So if it =20 > happens it happens, but thinking very hard about it sounds like a =20 > fool's errand. Better to simply hang on to the mblks-or-equivalent =20 > until the segments have all arrived. IMHO NAT's(*) and Firewalls are to treat the IP they are passing as they are end-hosts. They are in the middle and want to do full packet analysis/translation/filtering. There have been a number of problems with firewall vendors making a wrong implementation where it was trivial to send fragmented packets in such a way that it either caused the implementation to pass those packets on, while they should have firewalled those packets. Thus the sole issue, not issues as in the section title, with firewalls is that the firewall implementation is broken as it does not handle fragmented packet assembly properly. If the firewall would properly handle reassembly then there would be no issue, whatever nice or not-so-nice people would send to it. If they are passing through fragments, how sure are they that the receiver actually wanted to receive this in the first place, or is it just guess work it is doing? =46rom my point of view this is thus a real implementation issue, which might be good to note as informational to the implementators, but not something that should make all implementations worldwide to change their behaviour, as they are doing it correctly. Policy Boxes are the same for me as firewalls, I wonder why they are listed separetely, or do "Firewalls" not apply any "Policy" ? :) NAT-PT is (afaik on the list for) deprecation, thus we should not care about this either. For the ones that want to implement it: act like an endhost and handle the fragementation in that manner. As for the proposed solutions, it lists the misses option E: " Reassemble all the fragments, and transmit the packet on when the packet is okay for the policy or translation that needs to be applied to it". as that is what an end host would do also: it would re-assemble the packet and then pass it on to it's next hop, usually the user-space application. Section 6 IMHO is completely bogus as it would mean all the existing implementation would have to be changed. As there are people still clinging to ip6.int for instance and that is only DNS, you really think that all the implementations around the world would start doing this? Next to that, in case you would have a cellphone or other lowbandwidth device, eg a network of 100000 sensors on your carpet, you don't want to send out 1280 bytes instead of only the 40 that you want because of various concerns like powerconsumption etc. Next to that, what does one do with the trailing data that should not be there in the first place. Also, if we would 'align' packets on 1280, we might want to start doing this for multiples of 1500 etc too at a certain point, the end would become endless at a certain point. Adding these changes to IPv6 would IMHO cause more problems than it is worth, afaik no currently 'nice' implementation causes issues with fragments in this way, thus it is only to 'protect' against the not-so-nice implementations, who will try anything they like anyway. Maybe we could consult RFC3514? :) Otherwise said: fix the implementations of the middle boxes and warn them for this issue in the arch rfc's. (Then again if they did't get that fragments and other weirdly constructed packets will cause issues with their firewall...) Greets, Jeroen * =3D Who came up with the silly idea of making an IPv6 NAT box!? If one expects/want NAT then please stick with IPv4, no need to start abusing IPv6 for that. --=-0lI7t7VHGcTE2RhBkswI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkR8bawuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I378AKCVIja2jaUcp453bwaJ2mecghXL OgCdFN6escTvJ4l5V5mN1+juH6bbSLs= =3qtN -----END PGP SIGNATURE----- --=-0lI7t7VHGcTE2RhBkswI-- From owner-v6ops@ops.ietf.org Tue May 30 19:31:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDgC-0000Wq-JS for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 19:31:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDgB-0002Xp-7y for v6ops-archive@lists.ietf.org; Tue, 30 May 2006 19:31:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlD3J-0004lx-4v for v6ops-data@psg.com; Tue, 30 May 2006 22:51:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlD3I-0004lb-6t for v6ops@ops.ietf.org; Tue, 30 May 2006 22:51:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1mU007755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000md-9O; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-802-16-deployment-scenarios-00.txt Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks Author(s) : M. Shin, Y. Han Filename : draft-ietf-v6ops-802-16-deployment-scenarios-00.txt Pages : 22 Date : 2006-5-30 This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-802-16-deployment-scenarios-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-802-16-deployment-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-802-16-deployment-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30161712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-802-16-deployment-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-802-16-deployment-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30161712.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed May 31 00:43:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlIYf-0005jq-BK for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 00:43:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlIYd-0006Np-T6 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 00:43:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlITa-0007Ef-LP for v6ops-data@psg.com; Wed, 31 May 2006 04:38:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.202] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlITY-0007EL-30 for v6ops@ops.ietf.org; Wed, 31 May 2006 04:38:32 +0000 Received: by wx-out-0102.google.com with SMTP id s8so603765wxc for ; Tue, 30 May 2006 21:38:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l3vOUVz/Fc+nXO837WJveqANTYn/vyBLM4lrcOZ+84IWKRL5iPTjpEiQzfekVCgmg1GNNVePKbdwb1rjLeVTEdAQXtixMZr9lp0nz/BEgtdqxtfWR4qn/8JWbIl0pwh9I3Rl2bM10/swVtlPl24kyMpSWVEM66xtkSewiiwZVaI= Received: by 10.70.69.8 with SMTP id r8mr4481626wxa; Tue, 30 May 2006 21:38:30 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Tue, 30 May 2006 21:38:30 -0700 (PDT) Message-ID: <77ead0ec0605302138r768bdaeande4b3991ed5eccbe@mail.gmail.com> Date: Wed, 31 May 2006 10:08:30 +0530 From: "Vishwas Manral" To: "Jeroen Massar" Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Cc: "Fred Baker" , v6ops@ops.ietf.org In-Reply-To: <1149005228.19401.35.camel@firenze.zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <447AFCDE.604@uninett.no> <024DBDEB-8070-4BD5-8297-F1A36BD6CB03@cisco.com> <1149005228.19401.35.camel@firenze.zurich.ibm.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Hi Jeroen, You have raised some very valid points. I will add the proposal you define, "e." to the draft. I also agree and will replace Issues with issue e.g. "Issues with Policy Boxes" with "Issue with policy boxes" I am however not sure of the issue you raise with Section 6., as bogus. I tried reading the text a couple of times, but could not understand it. The proposal is to make the non-last fragement slightly lesser than 1280, to address any fragmentation if tunnelling was to be done. I do not feel it needs to be done that way by all implemntation, but we can raise the concern that might arise if we make the fragment size as 1280 or more. Am I missing the point altogather? Thanks, Vishwas On 5/30/06, Jeroen Massar wrote: > On Tue, 2006-05-30 at 08:27 -0700, Fred Baker wrote: > > On May 29, 2006, at 6:53 AM, Stig Venaas wrote: > > > Also note that as mentioned above, some implementations send > > > fragments out of order (e.g. Linux has been known to do this). The > > > reason is that you don't know the total size of the datagram until > > > you receive the last fragment. Receiving the last fragment first > > > means that you can allocate the right amount of memory immediately. > > > > On that particular point, since packets can be reordered in flight in > > a best effort network, it seems to me that the sender can neither > > prevent packets from arriving last fragment first. a middle box > > cannot accurately detect that the sender did or did not do this, and > > the receiver cannot depend on packets being sent last first. So if it > > happens it happens, but thinking very hard about it sounds like a > > fool's errand. Better to simply hang on to the mblks-or-equivalent > > until the segments have all arrived. > > IMHO NAT's(*) and Firewalls are to treat the IP they are passing as they > are end-hosts. They are in the middle and want to do full packet > analysis/translation/filtering. There have been a number of problems > with firewall vendors making a wrong implementation where it was trivial > to send fragmented packets in such a way that it either caused the > implementation to pass those packets on, while they should have > firewalled those packets. > > Thus the sole issue, not issues as in the section title, with firewalls > is that the firewall implementation is broken as it does not handle > fragmented packet assembly properly. If the firewall would properly > handle reassembly then there would be no issue, whatever nice or > not-so-nice people would send to it. If they are passing through > fragments, how sure are they that the receiver actually wanted to > receive this in the first place, or is it just guess work it is doing? > From my point of view this is thus a real implementation issue, which > might be good to note as informational to the implementators, but not > something that should make all implementations worldwide to change their > behaviour, as they are doing it correctly. Policy Boxes are the same for > me as firewalls, I wonder why they are listed separetely, or do > "Firewalls" not apply any "Policy" ? :) > > NAT-PT is (afaik on the list for) deprecation, thus we should not care > about this either. For the ones that want to implement it: act like an > endhost and handle the fragementation in that manner. > > As for the proposed solutions, it lists the misses option E: > " Reassemble all the fragments, and transmit the packet on when > the packet is okay for the policy or translation that needs > to be applied to it". > as that is what an end host would do also: it would re-assemble the > packet and then pass it on to it's next hop, usually the user-space > application. > > Section 6 IMHO is completely bogus as it would mean all the existing > implementation would have to be changed. As there are people still > clinging to ip6.int for instance and that is only DNS, you really think > that all the implementations around the world would start doing this? > Next to that, in case you would have a cellphone or other lowbandwidth > device, eg a network of 100000 sensors on your carpet, you don't want to > send out 1280 bytes instead of only the 40 that you want because of > various concerns like powerconsumption etc. Next to that, what does one > do with the trailing data that should not be there in the first place. > Also, if we would 'align' packets on 1280, we might want to start doing > this for multiples of 1500 etc too at a certain point, the end would > become endless at a certain point. > > Adding these changes to IPv6 would IMHO cause more problems than it is > worth, afaik no currently 'nice' implementation causes issues with > fragments in this way, thus it is only to 'protect' against the > not-so-nice implementations, who will try anything they like anyway. > Maybe we could consult RFC3514? :) > > > Otherwise said: fix the implementations of the middle boxes and warn > them for this issue in the arch rfc's. > > (Then again if they did't get that fragments and other weirdly > constructed packets will cause issues with their firewall...) > > Greets, > Jeroen > > * = Who came up with the silly idea of making an IPv6 NAT box!? > If one expects/want NAT then please stick with IPv4, no need > to start abusing IPv6 for that. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Jeroen Massar / http://unfix.org/~jeroen/ > From owner-v6ops@ops.ietf.org Wed May 31 00:48:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlIcw-0005yV-5a for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 00:48:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlIcv-0006rU-Lo for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 00:48:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlIcY-0007pj-C0 for v6ops-data@psg.com; Wed, 31 May 2006 04:47:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.199] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlIcX-0007pV-7Z for v6ops@ops.ietf.org; Wed, 31 May 2006 04:47:49 +0000 Received: by wx-out-0102.google.com with SMTP id s8so604551wxc for ; Tue, 30 May 2006 21:47:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i9hf0GB1AcKNdyYbXfXrm9gJ8nLOw8gAbsvikJNu0AFw7Ukm91lfmVNYMmSSw5SlRnE1IgcazMrLKwqUNIAtUgJsSTfNWaEtkMTphRqW9sesCYPiApvClrCyBfdeSaB3gucboFPxZ0Rnx6wzie3e2DC4fYbBaHkFe2MeUN1lwcM= Received: by 10.70.131.16 with SMTP id e16mr4457858wxd; Tue, 30 May 2006 21:47:48 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Tue, 30 May 2006 21:47:48 -0700 (PDT) Message-ID: <77ead0ec0605302147m26a8158yfa5354502c43b5c4@mail.gmail.com> Date: Wed, 31 May 2006 10:17:48 +0530 From: "Vishwas Manral" To: "Bound, Jim" Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 Cc: "Fred Baker" , "Templin, Fred L" , "Elwyn Davies" , v6ops@ops.ietf.org In-Reply-To: <936A4045C332714F975800409DE09240025BCED5@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0605292205p2a295aadr1109ccd620f13f3a@mail.gmail.com> <936A4045C332714F975800409DE09240025BCED5@tayexc14.americas.cpqcorp.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Hi Jim, I agree to the holistic issue you raise here. I guess it can be a policy question and can be left to the administrator, about what a middle box should do with an extension header it does not recognize. A good idea would be to drop it(but that would also mean that the firewalling device needs to be updated when a new extension header is introduced before any of the end hosts). Let us hear more from people on the v6ops list. Thanks, Vishwas On 5/30/06, Bound, Jim wrote: > Hi Vishwas, > > My first question was if the issue is not doing complete packet > reassembly and as I see that issue it simply is a requirement for any > node receiving an end-to-end set of fragments the way it is done with > IPv6. Once the packet is assembled and processed then this next issue > requires analysis, but the next header values can assist with locating > upper layer headers but RFC 2460 is pretty clear on receivers: > > From RFC 2460: > > Therefore, extension headers must > be processed strictly in the order they appear in the packet; a > receiver must not, for example, scan through a packet looking for a > particular kind of extension header and process that header prior to > processing all preceding ones. > > A firewall or intrusion detection need to make certain implementation > decisions as they are typically not the end receiver per RFC 2460. The > question really is when an extension header does not apply to the > implementation it can by pass that extension? > > But from RFC 2460: > > If, as a result of processing a header, a node is required to proceed > to the next header but the Next Header value in the current header is > unrecognized by the node, it should discard the packet and send an > ICMP Parameter Problem message to the source of the packet, with an > ICMP Code value of 1 ("unrecognized Next Header type encountered") > and the ICMP Pointer field containing the offset of the unrecognized > value within the original packet. The same action should be taken if > a node encounters a Next Header value of zero in any header other > than an IPv6 header. > > So I view the issue possibly not one of tiny fragments as all because > nodes need to do packet assembly, but how do secure interim nodes > process ext headers before the next header these secure interim nodes > require. > > My answer is as follows. The node IP stack implementation must adhere > to the spec. But, the IETF makes no requirement at all what users > implement or any other standards body, as all we really provide is the > opportunity and ability for things to work correctly from our > specifications. Firewalls or edge Intrusion Detection > devices/software/sensors are anomaly's within the users environment to > protect them beyond what open networking standards define. Thus, in > this case of implementations that want to do next header scan as for a > Firewall it is certainly possible and in my humble "individual" (not HP) > opinion valid code path, or as you stated fast-path. > > End result is not clear. There is an issue but lets see what other v6ops > persons think as again maybe I am just missing the forest for the trees, > but it is not the IETF or any standards bodies business to mandate use > to the market that is their prerogative to accept or alter anything we > provide them from the IETF. > > Hope this helps, > /jim > > > > > > -----Original Message----- > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Tuesday, May 30, 2006 1:06 AM > > To: Bound, Jim > > Cc: Fred Baker; Templin, Fred L; Elwyn Davies; v6ops@ops.ietf.org > > Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 > > > > Hi Jim, > > > > You raise a valid concern. > > > > The issue I see in my view came up when working on firewalls > > in the Fastpath. I figured out that in IPv4 the header > > options are optional, so packets with options are either sent > > to the slow path or are dropped(the more common case). This > > also means that a non-last fragment of less than 64 bytes can > > easily be dropped(which means that we will have the TCP > > header in the first fragmet), so most TCP and transport level > > header checks like TCP-SYN attacks can be easily detected. > > Even a simple 5 tuple based check may not work. > > > > In IPv6, however the extension headers are part of the base > > protocol and as we do not have a minimum length for non-last > > fragment, there is no way to guarantee that the TCP header is > > present in the first header. So basic checks as above cannot > > be done easily. > > > > That said, for IPsec ESP tunnelled packets(for AH the header > > inside can always be looked into) the IPsec authentication at > > the device doing the decryption will guarantee that the > > packet is valid. Note with RFC4301 the authentication itself > > is a MUST for ESP now. > > > > Do let me know if I am missing the point altogather? > > > > Thanks, > > Vishwas > > > > On 5/29/06, Bound, Jim wrote: > > > I may be missing the issue in the draft but I take the main > > issue to > > > be as follows: > > > > > > From section 4 of the spec > > > >Having tiny fragments could mean that none of the > > fragments would be > > > the Initial > > > >Fragment. So any access control/ tunneling based onthat > > may not work > > > unless reassembly >is done, or extra state like nextHeader and > > > previous header length remaining are kept >across fragments. > > > > > > My first thought now is this is life with IPv4 or IPv6. Packet > > > assembly and reassembly is required. The spec does not > > provide for me > > > why this cannot be done from an IETF protocol view for IPv6. > > > > > > Is this an implementation problem and not IETF > > specification problem, > > > thus it was correct to send it to v6ops to do logic check > > if there is > > > anything we can do operationally to address the stated issue. > > > > > > I don't think this spec should even move forward, but again > > maybe I am > > > missing the issue that is other than the mid box doing > > normal packet > > > reassembly for IPv6? > > > > > > NB: Also if the packet was encrypted with IPsec many of the > > security > > > issues are addressed and also the entire notion of Firewalls for > > > implementation (as opposed to IETF standardization) is current > > > discussion in multiple market vertical segments how end-to-end with > > > IPsec is implemented when Firewalls are present. > > > > > > > > > Best, > > > /jim > > From owner-v6ops@ops.ietf.org Wed May 31 10:13:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRRr-0000T2-77 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:13:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRRr-0007Yo-56 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:13:23 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRNW-00082a-IS for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:08:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRJd-0009jA-JC for v6ops-data@psg.com; Wed, 31 May 2006 14:04:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.110.152] (helo=e34.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRJc-0009ip-Kc for v6ops@ops.ietf.org; Wed, 31 May 2006 14:04:52 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4VE4TFs014364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 May 2006 10:04:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k4VE4Rg2255180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 May 2006 08:04:28 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4VE4QLY028135 for ; Wed, 31 May 2006 08:04:26 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-205-176.mts.ibm.com [9.65.205.176]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4VE4P7t028054; Wed, 31 May 2006 08:04:25 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k4VE4cOK003744; Wed, 31 May 2006 10:04:45 -0400 Message-Id: <200605311404.k4VE4cOK003744@cichlid.raleigh.ibm.com> To: "Bound, Jim" cc: "Fred Baker" , "Tony Hain" , "Brian E Carpenter" , "EricLKlein" , gunter@cisco.com, "Ralph Droms" , v6ops@ops.ietf.org, "Lindqvist Erik Kurt" , Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt In-Reply-To: Message from "Bound, Jim" of "Mon, 29 May 2006 09:15:34 EDT." <936A4045C332714F975800409DE09240025BCBBA@tayexc14.americas.cpqcorp.net> Date: Wed, 31 May 2006 10:04:38 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 FWIW, I, without having done a complete review of the document or of Margaret's comments, did look long enough to agree that more work is needed. Specifically: > > Abstract > > > > Although there are many perceived benefits to Network Address > > Translation (NAT), its primary benefit of "amplifying" available > > address space is not needed in IPv6. In addition to NAT's many > > serious disadvantages, there is a perception that other benefits > > exist, such as a variety of management and security > > attributes that > > could be useful for an Internet Protocol site. IPv6 does > > not support > > NAT by design and this document shows how Network Architecture > > Protection (NAP) using IPv6 can provide the same or more benefits > > without the need for NAT. > > > > This abstract seems very slanted. I also think that it would > > be incorrect at this point to say that "amplifying" address > > space is the primary benefit of NATs, as many companies use > > them in spite of the fact that they have plenty of address > > space available. > > > > There are at least three other _real_ benefits of NAT boxes. > > While I hold with this document's position that these > > benefits can and should be realized in other ways in IPv6, I > > do not think it is factual or helpful to argue that they > > don't exist. Those benefits are: > > > > (1) Avoiding the reliance of internal network number on > > externally allocated numbers. AKA not having to renumber > > when you change ISPs or when ISPs change address allocation > > strategies. This is _so_ true. I then skimmed the document and the word "renumbering" barely appears at all, and never mentions avoiding the need to renumber as one of the real benefits of NAT. IMO, this document is completely inadequate and unbalanced if it doesn't recognize the clear value that NAT plays in the renumbering debate and speak to that point directly. Reading section 2 (the alleged benefits), I do not find the topic of renumbering to be covered adequately. Take section 2, entitled: > 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6 and section 2.5 in particular > 2.5. Independent Control of Addressing in a Private Network > > Many private IPv4 networks take benefit from using the address space > defined in RFC 1918 to enlarge the available addressing space for > their private network, and at the same time reduce their need for > globally routable addresses. This type of local control of address > resources allows a clean and hierarchical addressing structure in the > network. > > Another benefit is due to the usage of independent addresses on > majority of the network infrastructure there is an increased ability > to change provider with less operational difficulties. > > Section 2.7 describes some disadvantages that appear if independent > networks using [RFC1918] addresses have to be merged. The above seriously understates the issue of the renumbering problem and how NATs play into that discussion. Indeed the document later says: > 4.7. Multihoming and Renumbering > > Multihoming and renumbering remain technically challenging with IPv6 > (see the Gap Analysis below). The WG needs to treat Margarat's review seriously. While the tone of some of the comments may seem harsh, there is substance there. And this document does have the problem of trying to blame "marketing" for misperceptions about NAT's benefits. In fact, some of the benefits are real (like avoidance of renumbering). Another area I find weak is the discusion about NATs vs. firewalls. E.g.: > Additionally, thanks to successful marketing campaigns it is > perceived by end users that their equipment is protected from the > malicious entities and attackers on the public IPv4 Internet. Sorry, but it is true that firewalls do add protection. And suggesting that the firewall function (not the NAT function) has no value undermines the credibility of this document. (This document could do a much better job of distinguishing between the NAT function and the Firewall function, since they are not the same.) Thomas From owner-v6ops@ops.ietf.org Wed May 31 10:13:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRRr-0000TH-95 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:13:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRRr-0007Yo-7h for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:13:23 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRNP-00082R-2W for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 10:08:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRMQ-000A1T-H7 for v6ops-data@psg.com; Wed, 31 May 2006 14:07:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.110.150] (helo=e32.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRMP-000A1G-SY for v6ops@ops.ietf.org; Wed, 31 May 2006 14:07:46 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4VE7iuX027461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 May 2006 10:07:44 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k4VE7iSR272698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 May 2006 08:07:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4VE7hDH026359 for ; Wed, 31 May 2006 08:07:44 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-205-176.mts.ibm.com [9.65.205.176]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4VE7gUN026329; Wed, 31 May 2006 08:07:43 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k4VE8DHn003842; Wed, 31 May 2006 10:08:19 -0400 Message-Id: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> To: "Bound, Jim" cc: "Fred Baker" , "Tony Hain" , "Brian E Carpenter" , "EricLKlein" , gunter@cisco.com, "Ralph Droms" , v6ops@ops.ietf.org, "Lindqvist Erik Kurt" , Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt In-Reply-To: Message from "Bound, Jim" of "Mon, 29 May 2006 09:15:34 EDT." <936A4045C332714F975800409DE09240025BCBBA@tayexc14.americas.cpqcorp.net> Date: Wed, 31 May 2006 10:08:13 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Oh, and one more peeve. Does the WG really believe this statement is a fair representation of reality: > 4.6. Global Address Pool Conservation > > IPv6 provides sufficient space to completely avoid the need for > overlapping address space, > 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total > possible addresses. That is, given /48s to end sites, stateless address autoconfiguration and 64-bit interface identifiers, do we undermine our own credibility by claiming IPv6 supports 10^38 addresses? Thomas From owner-v6ops@ops.ietf.org Wed May 31 11:00:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSB2-0004Xq-Ci for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:00:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSB1-0004pN-3a for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:00:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSAI-000FO0-PD for v6ops-data@psg.com; Wed, 31 May 2006 14:59:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSAI-000FNm-2l for v6ops@ops.ietf.org; Wed, 31 May 2006 14:59:18 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 May 2006 07:59:15 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4VExFdW026971; Wed, 31 May 2006 07:59:15 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4VExDCU017869; Wed, 31 May 2006 07:59:13 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4VEtpR7015308; Wed, 31 May 2006 07:55:51 -0700 In-Reply-To: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> References: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C6CC738-34E1-4A1F-AD24-42AFE065727D@cisco.com> Cc: "Bound, Jim" , "Tony Hain" , "Brian E Carpenter" , "EricLKlein" , gunter@cisco.com, "Ralph Droms" , v6ops@ops.ietf.org, "Lindqvist Erik Kurt" , Margaret Wasserman Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 07:59:11 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=859; t=1149087555; x=1149951555; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt=20; X=v=3Dcisco.com=3B=20h=3DL7dXh/0Y+wnU5NCMyPFRtjvkHMY=3D; b=PQuXSat31PODJK87AinNA6cJU7tBDGIERbMjlxF2Fimgrv64rVJKIZq99QpNLf2IBXGVFvEw 4wm9HBZBkX26xofDZdPTMVmHwv77lG7sS8aYTDqcK1zwUzIAWypGMrvl; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On May 31, 2006, at 7:08 AM, Thomas Narten wrote: > That is, given /48s to end sites, stateless address autoconfiguration > and 64-bit interface identifiers, do we undermine our own credibility > by claiming IPv6 supports 10^38 addresses? as opposed to 10^128? Stateless autoconfiguration provides a way that any system can get an address. It reduces the count of LANs to 10^64, and the business about /48s means we reduce the number of sites on the backbone to 10^32 ISPs each supporting 2^16 customers. I would prefer that we talked about /48s for campuses and /56s for SOHO environments, and I thought that was on the table at least at one point (wasn't that draft-narten-ipv6-3177bis-48boundary?). Frankly, the requirement stated that we needed to support 10^12 LANs and 10^15 hosts. We passed that a long time back. From owner-v6ops@ops.ietf.org Wed May 31 11:43:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSqu-0007Yg-2E for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:43:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSqs-0001mq-P6 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:43:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSpR-000JEF-Q3 for v6ops-data@psg.com; Wed, 31 May 2006 15:41:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSpR-000JE1-AN for v6ops@ops.ietf.org; Wed, 31 May 2006 15:41:49 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 08:41:49 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="286153559:sNHT41271428" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VFfmsT008344; Wed, 31 May 2006 08:41:48 -0700 Received: from gvandevewxp (ams3-vpn-dhcp4552.cisco.com [10.61.81.199]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4VFffLf014992; Wed, 31 May 2006 17:41:41 +0200 (MEST) Reply-To: From: "Gunter Van de Velde \(gvandeve\)" To: "'Thomas Narten'" , "'Bound, Jim'" Cc: "'Fred Baker'" , "'Tony Hain'" , "'Brian E Carpenter'" , "'EricLKlein'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 17:41:40 +0200 Message-ID: <11df01c684c8$b9e3af70$e7513d0a@emea.cisco.com> 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.2869 Thread-Index: AcaEu9yDI8xWB5DuQuWM3gkIFkV4OQADHd2Q In-Reply-To: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1088; t=1149090108; x=1149954108; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=gvandeve@cisco.com; z=From:=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:RE=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt=20; X=v=3Dcisco.com=3B=20h=3DbToJoWaJn4Nm/TWFgzef9mZvC58=3D; b=I80hAhWl97CdCX6B9TdakohK/jvQTVy8v3ZsneWXYmEqt1IH0dJ9668LMFzWOd6iEAYCWzPM 1i7CIHuas9iGf4HaxNA9s6w72dYomXqjGYYI33qZuWDIv2P9BWP1Ehi/; Authentication-Results: sj-dkim-1.cisco.com; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Thomas, They do not believe that was fair... That is an edit mistake of me as there was a comment about that in the archives. G/ -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Thomas Narten Sent: Wednesday, May 31, 2006 4:08 PM To: Bound, Jim Cc: Fred Baker; Tony Hain; Brian E Carpenter; EricLKlein; gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist Erik Kurt; Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Oh, and one more peeve. Does the WG really believe this statement is a fair representation of reality: > 4.6. Global Address Pool Conservation > > IPv6 provides sufficient space to completely avoid the need for > overlapping address space, > 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total > possible addresses. That is, given /48s to end sites, stateless address autoconfiguration and 64-bit interface identifiers, do we undermine our own credibility by claiming IPv6 supports 10^38 addresses? Thomas From owner-v6ops@ops.ietf.org Wed May 31 11:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSwm-00042T-Az for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:49:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSwj-0002Q4-TO for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 11:49:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSwQ-000Jyr-2S for v6ops-data@psg.com; Wed, 31 May 2006 15:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlSwP-000Jwv-3I for v6ops@ops.ietf.org; Wed, 31 May 2006 15:49:01 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 08:48:51 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="1816348791:sNHT5198161142" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VFmoB0016805; Wed, 31 May 2006 08:48:50 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4VFmnCU025387; Wed, 31 May 2006 08:48:49 -0700 (PDT) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4VFjSe4016440; Wed, 31 May 2006 08:45:28 -0700 In-Reply-To: <2C6CC738-34E1-4A1F-AD24-42AFE065727D@cisco.com> References: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> <2C6CC738-34E1-4A1F-AD24-42AFE065727D@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CBED129-65A0-4986-B4F8-189F60AA490D@cisco.com> Cc: Jim Bound , Tony Hain , Brian E Carpenter , EricLKlein , gunter@cisco.com, Ralph Droms , v6ops@ops.ietf.org, Lindqvist Erik Kurt , Margaret Wasserman Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 08:48:48 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2729; t=1149090530; x=1149954530; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt=20; X=v=3Dcisco.com=3B=20h=3DLZ/B036V6ovdCoVY3YNrfpOy7CU=3D; b=R3cynqSSv8mewseJePm+2cmo/Cv2nwPHd6nLw1GFtOjyCYPePAUQwahnBDi4qAkglUWIHEwO yl5xTEylliMj2dYqCNlMdzvk2CK3OCo/dHY+raHESXOTRswNRrQRbnoN; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Havard Eidnes read the numbers a little closer than I did: yes, 10^38 is approximately 2^128. I think the point remains that the requirement originally stated was this: CRITERION The IPng Protocol must scale to allow the identification and addressing of at least 10**12 end systems (and preferably much more). The IPng Protocol, and its associated routing protocols and architecture must allow for at least 10**9 individual networks (and preferably more). The routing schemes must scale at a rate that is less than the square root of the number of constituent networks [10]. http://www.ietf.org/rfc/rfc1726.txt 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL) Without running through all the history, and the arguments of whether in 2006 the numbers selected in 1994 are adequate, the fact is that we support a very large number of enumerable networks, on the order of the square of the original requirement, and not only do we support 10^12 hosts in the address space, we support that many and quite a few more on each LAN. Yes, we support about 3 * 10^38 addresses in the address space. That is a mathematically accurate statement. I think the point you're asking is "does that mean we should throw the addresses away with both hands?". And I would say, no, that's what we did with the IPv4 address space, and we eventually learned the error of those ways. It does make sense to think about rational- sized address blocks, but frankly I would expect that this is more of an RIR issue than an IETF issue. They are currently handing out /32s to ISPs, and more if the ISPs can justify it. That means that they are allowing for ~4 billion address allocations, each of which is presumably enough for 2^16 ISP customers, each of which potentially has 2^16 LANs. I do believe that there is a question of market dynamics there - if the customer is unlikely to create more than 256 LANs, selling them a /56 makes sense, and helps with the overall address usage density, and if the customer really only needs a single /64 or to be a member of a /64, I think those should be options the customer can buy. saying "ISPs should only ever under any circumstances hand out a /48" seems a trifle over the top. And I do remember this thing about CIDR, that it removed the classful address straight-jacket, which at least at the time some of us thought was a good thing, and I wonder why we seem to be re-creating it here. But that wasn't your question. From owner-v6ops@ops.ietf.org Wed May 31 12:44:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlToI-0004ZY-6q for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 12:44:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlToG-0007j8-Qn for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 12:44:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlTmM-0003k1-OW for v6ops-data@psg.com; Wed, 31 May 2006 16:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.0.34.14] (helo=smtp01.icann.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlTmM-0003ji-0k for v6ops@ops.ietf.org; Wed, 31 May 2006 16:42:42 +0000 Received: from [192.168.1.156] (g35-062.icann.org [192.0.35.62] (may be forged)) (authenticated bits=0) by smtp01.icann.org (8.12.11/8.12.11) with ESMTP id k4VGgWjV022328 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 May 2006 09:42:32 -0700 In-Reply-To: <9CBED129-65A0-4986-B4F8-189F60AA490D@cisco.com> References: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> <2C6CC738-34E1-4A1F-AD24-42AFE065727D@cisco.com> <9CBED129-65A0-4986-B4F8-189F60AA490D@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <333AA46E-7743-4915-A212-F624647A4234@icann.org> Cc: Thomas Narten , Jim Bound , Tony Hain , Brian E Carpenter , EricLKlein , gunter@cisco.com, Ralph Droms , v6ops@ops.ietf.org, Lindqvist Erik Kurt , Margaret Wasserman Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 09:42:34 -0700 To: Fred Baker X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Fred, On May 31, 2006, at 8:48 AM, Fred Baker wrote: > Yes, we support about 3 * 10^38 addresses in the address space. > That is a mathematically accurate statement. No. A mathematically correct statement would be that IPv6 can, in theory, address up to about 3*10^38 objects. The number of objects that can actually be supported is, of course, far, far less. Rgds, -drc From owner-v6ops@ops.ietf.org Wed May 31 14:03:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV2n-0000Ar-HI for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:03:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV2l-00067P-7N for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:03:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlV0m-0009z8-DR for v6ops-data@psg.com; Wed, 31 May 2006 18:01:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlV0k-0009yr-0F for v6ops@ops.ietf.org; Wed, 31 May 2006 18:01:38 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 11:01:37 -0700 X-IronPort-AV: i="4.05,194,1146466800"; d="scan'208"; a="286269733:sNHT43248506" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4VI1av7019594; Wed, 31 May 2006 11:01:37 -0700 Received: from gvandevewxp (ams3-vpn-dhcp4552.cisco.com [10.61.81.199]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4VI1XLf017117; Wed, 31 May 2006 20:01:33 +0200 (MEST) Reply-To: From: "Gunter Van de Velde \(gvandeve\)" To: "'David Conrad'" , "'Fred Baker'" Cc: "'Thomas Narten'" , "'Jim Bound'" , "'Tony Hain'" , "'Brian E Carpenter'" , "'EricLKlein'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 20:01:32 +0200 Message-ID: <121b01c684dc$42257360$e7513d0a@emea.cisco.com> 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.2869 Thread-Index: AcaE0ZINzC3cN/vzStG2FN/B/IqLfQACi8ow In-Reply-To: <333AA46E-7743-4915-A212-F624647A4234@icann.org> DKIM-Signature: a=rsa-sha1; q=dns; l=1026; t=1149098497; x=1149962497; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:RE=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt; X=v=3Dcisco.com=3B=20h=3D7VyUJ0dxSoK5+fDUEJPrPEKciFQ=3D; b=HVFYLkCJ8W+11Fns37KtjmsSfzrbjUurRn5QBo2TaDYgBZaW9fkAFkRTuGCAjI7kSUdon801 duxOJ8/f6YLbegCGna/I3rg2MaMF+q8Poafy30oV77ivCfJCH18IcYFJ; Authentication-Results: sj-dkim-4.cisco.com; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Why the difference between objects and addresses in this particular case for the matematical model? Practically I completely agree, but matemathical i'm not sure yet? (what if all prefixes are /128?) G/ -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of David Conrad Sent: Wednesday, May 31, 2006 6:43 PM To: Fred Baker Cc: Thomas Narten; Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist Erik Kurt; Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Fred, On May 31, 2006, at 8:48 AM, Fred Baker wrote: > Yes, we support about 3 * 10^38 addresses in the address space. > That is a mathematically accurate statement. No. A mathematically correct statement would be that IPv6 can, in theory, address up to about 3*10^38 objects. The number of objects that can actually be supported is, of course, far, far less. Rgds, -drc From owner-v6ops@ops.ietf.org Wed May 31 14:29:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVRh-0003BO-I3 for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:29:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVRd-0007j0-6z for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:29:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlVQk-000Bzl-7V for v6ops-data@psg.com; Wed, 31 May 2006 18:28:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlVQi-000BzW-NI for v6ops@ops.ietf.org; Wed, 31 May 2006 18:28:28 +0000 Received: (qmail 20434 invoked by uid 417); 31 May 2006 18:28:27 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 31 May 2006 18:28:27 -0000 Received: from ericklaptop ([132.70.222.113]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 31 May 2006 12:28:23 -0600 Message-ID: <00db01c684e8$3efc0260$6402a8c0@ftssoft.com> From: "Eric Klein" To: "Bound, Jim" , "Thomas Narten" Cc: "Fred Baker" , "Tony Hain" , "Brian E Carpenter" , gunter@cisco.com, "Ralph Droms" , v6ops@ops.ietf.org, "Lindqvist Erik Kurt" , "Margaret Wasserman" References: <200605311404.k4VE4cOK003744@cichlid.raleigh.ibm.com> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 20:48:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 From: "Thomas Narten" > FWIW, I, without having done a complete review of the document or of > Margaret's comments, did look long enough to agree that more work is > needed. Specifically: > This is _so_ true. I then skimmed the document and the word > "renumbering" barely appears at all, and never mentions avoiding the > need to renumber as one of the real benefits of NAT. IMO, this > document is completely inadequate and unbalanced if it doesn't > recognize the clear value that NAT plays in the renumbering debate and > speak to that point directly. > > Reading section 2 (the alleged benefits), I do not find the topic of > renumbering to be covered adequately. > I thought that DHCPv6 was the solution to renumbering. From owner-v6ops@ops.ietf.org Wed May 31 14:45:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVhL-0008Uw-FX for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:45:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVhJ-0001wa-Uf for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 14:45:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlVgU-000DU0-4A for v6ops-data@psg.com; Wed, 31 May 2006 18:44:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlVgT-000DTM-8A for v6ops@ops.ietf.org; Wed, 31 May 2006 18:44:45 +0000 Received: from waltxp (c-69-255-22-217.hsd1.va.comcast.net[69.255.22.217]) by comcast.net (sccrmhc13) with SMTP id <2006053118444301300m1brve>; Wed, 31 May 2006 18:44:44 +0000 From: "Walt Lazear" To: "'Fred Baker'" , "'Thomas Narten'" Cc: "'Jim Bound'" , "'Tony Hain'" , "'Brian E Carpenter'" , "'EricLKlein'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 31 May 2006 14:44:41 -0400 Message-ID: <009501c684e2$488021f0$5100a8c0@WaltXP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <9CBED129-65A0-4986-B4F8-189F60AA490D@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f I agree! I'm a firm believer in the need for IPv6, but I get a deja-vu knot in my stomach when I hear some IPv6 evangelists (such as at an IPv6 Summit) talking about the infinite address space and great applications it enables. There is breast beating about Jon Postel wantonly handing out Class A's to buds in IPv4 land and yet I see the same kind of large chunks of IPv6 land being distributed freely. Perhaps we're letting the RIR's head down the same road? /64's for serial links! 15 quintillion addresses where 2-4 will suffice?!?!?! What's scary are the applications that give addresses to every retail item so it can be tracked during it's lifetime. No reuse of addresses is contemplated (because they're infinite). Imagine the ultimate usage, where nano-things in aerosol sprays each have an address that is literally "cast to the wind". Is there a /70 or /80 in every can of this stuff? Why is there no built-in mandatory recycling of address space for these applications? We're undoing CIDR-like usage. Hierarchical addressing is going to be wasteful by nature. I don't know how the IETF can influence the RIR allocation policy, but it's scary how much history seems to be repeating itself. We're at the early end of the cycle, so it may not seem to some that we're handing out addresses with both hands, but we are. Walt Lazear > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Wednesday, May 31, 2006 11:49 AM > To: Thomas Narten > Cc: Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; > gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist > Erik Kurt; Margaret Wasserman > Subject: Re: Review of draft-ietf-v6ops-nap-02.txt > > > Havard Eidnes read the numbers a little closer than I did: > yes, 10^38 > is approximately 2^128. > > I think the point remains that the requirement originally stated was > this: > > CRITERION > The IPng Protocol must scale to allow the identification and > addressing of at least 10**12 end systems (and preferably much > more). The IPng Protocol, and its associated routing protocols > and architecture must allow for at least 10**9 individual > networks > (and preferably more). The routing schemes must scale > at a rate > that is less than the square root of the number of constituent > networks [10]. > > http://www.ietf.org/rfc/rfc1726.txt > 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. > Partridge, F. Kastenholz. December 1994. (Format: > TXT=74109 bytes) > (Status: INFORMATIONAL) > > Without running through all the history, and the arguments of > whether > in 2006 the numbers selected in 1994 are adequate, the fact is that > we support a very large number of enumerable networks, on the order > of the square of the original requirement, and not only do we > support > 10^12 hosts in the address space, we support that many and quite a > few more on each LAN. > > Yes, we support about 3 * 10^38 addresses in the address space. That > is a mathematically accurate statement. > > I think the point you're asking is "does that mean we should throw > the addresses away with both hands?". And I would say, no, that's > what we did with the IPv4 address space, and we eventually learned > the error of those ways. It does make sense to think about rational- > sized address blocks, but frankly I would expect that this is > more of > an RIR issue than an IETF issue. They are currently handing out /32s > to ISPs, and more if the ISPs can justify it. That means that they > are allowing for ~4 billion address allocations, each of which is > presumably enough for 2^16 ISP customers, each of which potentially > has 2^16 LANs. I do believe that there is a question of market > dynamics there - if the customer is unlikely to create more than 256 > LANs, selling them a /56 makes sense, and helps with the overall > address usage density, and if the customer really only needs a > single /64 or to be a member of a /64, I think those should be > options the customer can buy. saying "ISPs should only ever > under any > circumstances hand out a /48" seems a trifle over the top. > > And I do remember this thing about CIDR, that it removed the > classful > address straight-jacket, which at least at the time some of us > thought was a good thing, and I wonder why we seem to be re-creating > it here. But that wasn't your question. > > > > > From owner-v6ops@ops.ietf.org Wed May 31 15:22:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWGb-0002gZ-Lv for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 15:22:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWGa-0005vz-9h for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 15:22:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlWEu-000GMA-Te for v6ops-data@psg.com; Wed, 31 May 2006 19:20:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlWEu-000GLj-09 for v6ops@ops.ietf.org; Wed, 31 May 2006 19:20:20 +0000 Received: (qmail 10796 invoked by uid 417); 31 May 2006 19:20:17 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 31 May 2006 19:20:17 -0000 Received: from ericklaptop ([132.70.222.113]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 31 May 2006 13:20:12 -0600 Message-ID: <013101c684ef$7c5ce230$6402a8c0@ftssoft.com> From: "Eric Klein" To: "Manfredi, Albert E" , ipv6@ietf.org Cc: v6ops@ops.ietf.org References: Subject: Re: Making private IPv4 addresses public Date: Wed, 31 May 2006 22:04:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cross posting this to v6OPs as the whole NAT issue is under discussion that as part of draft-ietf-v6ops-nap-02.txt From: "Manfredi, Albert E" Not sure if this is the right wg for this idea, or for that matter if > I'm suggesting anything new. > > A comment yesterday made me wonder why private IPv4 addresses can't be > used more effectively, with an updated version of the NAT. > > RFC 3022 explains that you can have "Basic NAT" or "NAPT." Basic NAT is > very easy to use, because all you do is map one unique global address > into one unique private address. No messing around with Port IDs at all. > > NAPT is used to map one public IP address to multiple private IP > addresses behind the box (the common use of NAT). NAPT is great for > expanding the usefuless of the 32-bit IPv4 address, but for the most > part, it depends on applications from behind the NAT initiating > sessions, and it has to change the value of TCP or UDP Port IDs. So this > is not so great. > > Wouldn't it be nice if we could have NAPT without the TCP/UDP Port ID > trick? > > What if the private IP addresses behind the NAT became explicitly > visible from the WAN side of the NAPT box? Packets addressed to hosts > behind the NAT would carry both the global IP address of the NAT and, > appended, the private IP address of the host. The DNS would also carry > that information. > > To enable this, one could assign an option in the IP header, > conceptually similar to the source routing option. So at the end of the > standard IP header would be appended the source and destination private > IP addresses from behind the NAT. Dynamic DNS can be augmented to > include this information. And note that the private IP addresses behind > any given NAT can be reused by other NATs at will, just as they are now. > DHCP would also work just as it does now in NAPT. > > When the packet arrives at the NAT, with the additional IP header > option, the NAT routes directly to the explicitly identified host, > without having to use the Port ID bits for this purpose. > > In principle, this creates a 64-bit address space for IPv4 (and possibly > you could even concatenate the scheme to increase this further). > > The address notation might look something like > > 138.194.35.33:192.168.1.5 > > where the : separates the global from the private addresses. > > No reason why such a scheme can't be introduced gracefully, without > precluding operating the old fashioned way at the same time. > As we are working to remove NAT from the general world of IPv6 I am concerned to see ideas about extending IPv4 NAT in to IPv6. NATPT is a limited use area and as I understand it should not be extropolated to the general rules for IPv6. From owner-v6ops@ops.ietf.org Wed May 31 15:51:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWir-0000HI-Ej for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 15:51:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWim-0000Hj-4x for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 15:51:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlWi6-000IsR-Mx for v6ops-data@psg.com; Wed, 31 May 2006 19:50:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlWi4-000Irv-0j for v6ops@ops.ietf.org; Wed, 31 May 2006 19:50:28 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k4VJoAsE021850; Wed, 31 May 2006 19:50:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k4VJo4Lf021848; Wed, 31 May 2006 19:50:04 GMT Date: Wed, 31 May 2006 19:50:03 +0000 From: bmanning@vacation.karoshi.com To: Walt Lazear Cc: "'Fred Baker'" , "'Thomas Narten'" , "'Jim Bound'" , "'Tony Hain'" , "'Brian E Carpenter'" , "'EricLKlein'" , gunter@cisco.com, "'Ralph Droms'" , v6ops@ops.ietf.org, "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060531195003.GA21588@vacation.karoshi.com.> References: <9CBED129-65A0-4986-B4F8-189F60AA490D@cisco.com> <009501c684e2$488021f0$5100a8c0@WaltXP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009501c684e2$488021f0$5100a8c0@WaltXP> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > We're undoing CIDR-like usage. Hierarchical addressing is > going to be wasteful by nature. I don't know how the IETF > can influence the RIR allocation policy, but it's scary > how much history seems to be repeating itself. We're > at the early end of the cycle, so it may not seem to some > that we're handing out addresses with both hands, but we are. > > Walt Lazear > > RIR policy is derived from those who participate in the policy development process. The policy development process is analogous to the IETF of last century, when what mattered was individual participation... people weigh in with thier thoughts and opinions. ... Not companies or organizations per.se. If you don't like what the RIR's are doing, consider that the polcies are set by folks active in developing policy... http://www.arin.net/policy/irpep.html policies can and have been changed over time. --bill From owner-v6ops@ops.ietf.org Wed May 31 18:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZIA-0003bV-8e for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 18:35:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZI8-00026V-OQ for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 18:35:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlZFg-0006MX-Fa for v6ops-data@psg.com; Wed, 31 May 2006 22:33:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlZFf-0006ML-Na for v6ops@ops.ietf.org; Wed, 31 May 2006 22:33:19 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA24197; Wed, 31 May 2006 17:32:47 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4VMWk301988; Wed, 31 May 2006 17:32:46 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 15:32:45 -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: Requirements for IP-in-IP tunnel MTU assurance Date: Wed, 31 May 2006 15:32:44 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C85@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <013101c684ef$7c5ce230$6402a8c0@ftssoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements for IP-in-IP tunnel MTU assurance Thread-Index: AcaE523TKDUNWufwQUW22z7rKmOLUAAFx9yA From: "Templin, Fred L" To: , "Fred Baker" Cc: , , , , "Templin, Fred L" X-OriginalArrivalTime: 31 May 2006 22:32:45.0372 (UTC) FILETIME=[2334A7C0:01C68502] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Fred, At the v6ops wg meeting during IETF64, I presented "Requirements for IP-in-IP tunnel MTU assurance": http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-01.txt Paraphrasing from the minutes (see below), the plan was for the document to try to find a home in a different working group such as pmtud or softwires then brought back to v6ops if the other avenues didn't pan out. Since IETF64, there has been some discussion in the other groups but apparently no sustainable traction, so I am returning again to v6ops as suggested. Please advise on how to proceed from here. Thanks - Fred fred.l.templin@boeing.com Exceprt from IETF64 v6ops minutes: ********************************** IP in IP tunnel MTU assurance (Fred Templin)=20 Draft presentation=20 Tunnel mechanisms have no means of assuring tunnel MTU=20 Issue: IPv4 fragmentation is bad, IPv4 path MTU is not reliable (NAT, Firewall)=20 List of requirements=20 Dave Thaler: assurance might be too strong a word, we have no assurance=20 on Ethernet for example, this is best effort.=20 Fred: best effort is what is meant, need to define the terminology=20 Dave Thaler: this should be reviewed by the pmtud wg=20 Pekka: see some potential problems, maybe not as bad as author sees.=20 Would be interested in working on this if this was done in the venue that=20 will work on the solution=20 Fred: what would be the correct venue? Pmtud?=20 Pekka: maybe, need to look again at their charter=20 Dave Thaler: pmtud is the right place with the right expertise,=20 may require a charter update. Documenting the issue in v6ops=20 (and separating the requirement) is the right thing to do=20 Alain: the purpose of v6ops is to document operational issues,=20 so this document belongs here=20 Thomas Narten: Softwire may be the right place to fix the problem=20 pmtud is focusing on TCP, this is a generic tunneling problem,=20 so softwire might be a better place.=20 Fred: go talk to chairs of pmtud and chairs of softwire if they want to take it.=20 If this remains an issue, go back to v6ops and we will see with AD what to do From owner-v6ops@ops.ietf.org Wed May 31 18:43:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZPv-0002XD-BW for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 18:43:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZPu-0002ex-KP for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 18:43:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlZPY-00078g-L0 for v6ops-data@psg.com; Wed, 31 May 2006 22:43:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO,HOT_NASTY,RCVD_NUMERIC_HELO, SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlZPV-000789-WC for v6ops@ops.ietf.org; Wed, 31 May 2006 22:43:30 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 May 2006 15:43:30 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="429459207:sNHT39101272" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4VMhTb2021215; Wed, 31 May 2006 15:43:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4VMhRKP019430; Wed, 31 May 2006 15:43:27 -0700 (PDT) Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 15:43:27 -0700 Received: from 64.101.146.210 ([64.101.146.210]) by xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 May 2006 22:43:27 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 31 May 2006 17:46:28 -0500 Subject: Re: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt From: Salman Asadullah To: "Bound, Jim" , Fred Baker , "Adeel Ahmed ((adahmed))" , , , Pekka Savola CC: , Lindqvist Erik Kurt Message-ID: Thread-Topic: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Thread-Index: AcaA3kIF8N/9ZrdRTcCPI9ry3Kq3hQCQ8t+gAHiAAfI= In-Reply-To: <936A4045C332714F975800409DE09240025BCBBB@tayexc14.americas.cpqcorp.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2006 22:43:27.0778 (UTC) FILETIME=[A21C0820:01C68503] DKIM-Signature: a=rsa-sha1; q=dns; l=9651; t=1149115409; x=1149979409; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sasad@cisco.com; z=From:Salman=20Asadullah=20 |Subject:Re=3A=20Review=20of=20draft-ietf-v6ops-bb-deployment-scenarios-04.txt; X=v=3Dcisco.com=3B=20h=3Dim8F8raKlzuIDhd1yhbLY+Mpnv4=3D; b=NLm7lUd3IlVefYJV1QO3SbSRV3G5EiFl34+A4133bdhnbesTq0F6Zq7Y4rcXXFzIaoY3bWXR Wk5Otd9MNfLA+OzpTAhzFGvXIR5HZaBR31GVx/j2JfhTqvMqOYDlNL0e; Authentication-Results: sj-dkim-3.cisco.com; header.From=sasad@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.2 (++) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Thanks Jim. We have removed the section 2. Regards, Salman On 5/29/06 8:17 AM, "Bound, Jim" wrote: > I think this to is ready to ship as RFC. I do agree below that section > 2 may have to be removed for the reasons stated. We have to be careful > on the slippery slope of what we say in the IETF about deployment that > is not within our IETF bounds. Naming/Commenting on specific products > is not good either. > > Best, > /jim > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker >> Sent: Friday, May 26, 2006 12:04 PM >> To: Adeel Ahmed ((adahmed)); cpopovic@cisco.com; >> jordi.palet@consulintel.es; Pekka Savola; Salman Asadullah ((sasad)) >> Cc: v6ops@ops.ietf.org; Lindqvist Erik Kurt >> Subject: FW: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt >> >> FYI. Margaret's original message seems to have not made it to >> v6ops, or at least through it to me and reportedly several of you. >> >> -----Original Message----- >> From: Margaret Wasserman >> Sent: Thursday, May 25, 2006 11:16 AM >> To: 'v6ops@ops.ietf.org'; 'iesg@ietf.org' >> Subject: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt >> >> >> Hi All, >> >> While I was in a mood to review v6ops documents, I also >> reviewed draft-ietf-v6ops-bb-deployment-scenarios-04.txt. >> IMO, this is a very good document that is full of useful >> information, and it is nearly suitable for publication. >> >> I only found one serious issue in the document, and it non-technical. >> I think that section 2 should be removed from the document, >> because I don't think it is appropriate for the IETF to >> publish documents that indicate how SPs should differentiate >> their services and/or to comment on SPs specific products and >> services. >> >> I have a couple of other comments (see below), but nothing >> else that Should block publication of this document, IMO. >> >> Margaret >> >> --- >> >> 1.1. Common Terminology >> >> Add "BB" which is used throughout the document to mean Broadband? >> >> 2. IPv6 Based BB Services >> >> At this point IPv6 based services are seen as a >> differentiator that >> enables SPs to take advantage of the large IPv6 address >> space to the >> extent that subscribers get up to fixed /48 prefixes versus the >> single, temporary IPv4 addresses. Such resources allow the SPs to >> better position themselves against the competition. The IPv6 >> deployments can be seen as a driver for lower service >> support costs >> by eliminating NAT with its negative impact on >> applications and its >> complex behavior. Another reason of IPv6 being popular in some >> countries might be the government driven financial incentives and >> favorable legislation towards the ISPs who are deploying IPv6. >> >> >> I would remove this entire seciton (section 2) from the >> document. I don't think that the IETF is qualified to >> comment on business differentiators in the SP industry, and >> even if we were qualified to do so, I don't why we would want >> to do so. I don't think it is appropriate to mention >> specific companies' products and services, and timely >> information about what is currently deployed, including the >> limitations of those deployments, will probably be outdated >> by the time this document is published. >> >> >> If you don't remove this section, I think it will need a lot >> of work, as it mentions individual company names and product >> names without any disclaimers and/or indication of whether >> those companies have approved of what we are saying about >> their products, and without including such legal niceties as >> trademarks, etc. >> >> The network is transparent to the Layer 3 protocol. The only >> possible changes would come with the intent of filtering and >> monitoring IPv6 traffic based on layer 2 information such as IPv6 >> Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC >> addresses (3333.xxxx.xxxx). >> >> What format of MAC address is this? I have most often seen >> Ethernet addresses represented at xx:xx:xx:xx:xx:xx, so this >> would be 33:33:xx:xx:xx:xx, right? But other MAC addresses >> may be other lengths, such as EUI-64 identifiers. Also, if >> one filters on an EtherType of 0x86DD, one will see all IPv6 >> traffic. I am not sure why an additional filter for >> IPv6-specific multicast addresses would be needed. Can you explain? >> >> It is important to note that the customers of a Service >> Provider can >> choose to establish tunnels to publicly available and free tunnel >> services. Even though the quality of such services might not be >> high, they provide free IPv6 access. In designing their IPv6 >> services, the SPs should take into considerations such options >> available to their potential customers. The IPv6 >> deployment should >> support services (like multicast, VoIPv6 etc) and a level >> of quality >> that would make the access through the SP worthwhile to potential >> subscribers. >> >> This paragraph should be removed, as it mainly provides >> marketing, not operational, advice to SPs. >> >> 6. Broadband Cable Networks >> >> This section describes the infrastructure that exists >> today in cable >> networks providing BB services to the home. It also >> describes IPv6 >> deployment options in these cable networks. >> >> DOCSIS standardizes and documents the operation of data over Cable >> Networks. The current version of DOCSIS has limitations >> that do not >> allow for a smooth implementation of native IPv6 >> transport. Some of >> these limitations are discussed in this section. For this reason, >> the IPv6 deployment scenarios discussed in this section for the >> existent Cable Networks are tunnel based. The tunneling examples >> presented here could also be applied to the other BB technologies >> described in sections 7, 8, 9 and 10. >> >> You should expand the DOCSIS acronym, add a reference for >> DOCSIS and state which version is the "current version" that >> has these limitations. >> >> 6.2.4. IPv6 QoS >> >> IPv6 will not change or add any queuing/scheduling functionality >> already existing in DOCSIS specifications. But the QoS >> mechanisms on >> the CMTS and CM would need to be IPv6 capable. This >> includes support >> for IPv6 classifiers, so that data traffic to/from host >> devices can >> be classified appropriately into different service flows and be >> assigned appropriate priority. Appropriate >> classification criteria >> would need to be implemented for unicast and multicast traffic. >> >> In order to classify IPv6 traffic the following classifiers would >> need to be modified in the DOCSIS specification to >> support the 128- >> bit IPv6 address: >> >> A. IP source address >> >> B. IP source mask >> >> C. IP destination address >> >> D. IP destination mask >> >> E. IP traffic class (DSCP) >> >> The following classifiers would be new for IPv6: >> >> A. IP version >> >> B. Flow label (optional) >> >> Traffic classification and marking should be done at the CM for >> upstream traffic and the CMTS/ER for downstream traffic >> in order to >> support the various types of services: data, voice, >> video. The same >> IPv4 QoS concepts and methodologies should be applied for IPv6 as >> well. >> >> It is important to note that when traffic is encrypted end-to-end, >> the traversed network devices will not have access to many of the >> packet fields used for classification purposes. In these cases >> routers will most likely place the packets in the default classes. >> The QoS design should take into consideration this >> scenario and try >> to use mainly IP header fields for classification purposes. >> >> I am not certain about the purpose of this section... Are we >> trying to tell DOCSIS what they would need to change in their >> specifications in order to support IPv6 QoS? If so, I don't >> think that this belongs in a document that is telling SPs how >> to support IPv6 in their networks, does it? >> >> I think you should make it clearer here and in later sections >> what will not currently work, rather than just stating that >> DOCSIS should change things. >> >> 7.2.1.2. Addressing >> >> The Hosts or the Customer Routers have the Edge Router as >> their Layer >> 3 next hop. >> >> If there is no Customer Router all the hosts on the >> subscriber site >> belong to the same /64 subnet that is statically configured on the >> Edge Router for that subscriber PVC. The hosts can use stateless >> auto-configuration or stateful DHCPv6 based configuration >> to acquire >> an address via the Edge Router. >> >> However, as manual configuration for each customer is a >> provisioning >> challenge, implementations are encouraged to develop mechanism(s) >> which automatically map the PVC (or some other customer-specific >> information) to an IPv6 subnet prefix, and advertise the customer- >> specific prefix to all the customers with minimal configuration. >> >> How is this done in IPv4? Why does it need to be different in IPv6? >> >> From owner-v6ops@ops.ietf.org Wed May 31 19:37:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlaG6-0006da-CJ for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 19:37:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlaG5-00014R-OK for v6ops-archive@lists.ietf.org; Wed, 31 May 2006 19:37:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlaDi-000BWa-7x for v6ops-data@psg.com; Wed, 31 May 2006 23:35:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO,HOT_NASTY,RCVD_NUMERIC_HELO, SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlaDh-000BWP-AV for v6ops@ops.ietf.org; Wed, 31 May 2006 23:35:21 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 May 2006 16:35:21 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="429464811:sNHT36024568" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4VNZKiv031100; Wed, 31 May 2006 16:35:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4VNYZKP014648; Wed, 31 May 2006 16:34:35 -0700 (PDT) Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 16:34:35 -0700 Received: from 64.101.146.210 ([64.101.146.210]) by xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 May 2006 23:34:34 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 31 May 2006 18:37:35 -0500 Subject: Re: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt From: Salman Asadullah To: Fred Baker , "Adeel Ahmed ((adahmed))" , , , Pekka Savola CC: , Lindqvist Erik Kurt Message-ID: Thread-Topic: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt Thread-Index: AcaFCzGacC6FnPD+EdqNPgARJNUbag== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2006 23:34:35.0020 (UTC) FILETIME=[C65404C0:01C6850A] DKIM-Signature: a=rsa-sha1; q=dns; l=9602; t=1149118520; x=1149982520; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sasad@cisco.com; z=From:Salman=20Asadullah=20 |Subject:Re=3A=20Review=20of=20draft-ietf-v6ops-bb-deployment-scenarios-04.txt; X=v=3Dcisco.com=3B=20h=3Dim8F8raKlzuIDhd1yhbLY+Mpnv4=3D; b=swWGehEnZzP6yRCzBVoLt+eHFc8jV+JIpAjbZGDfSegWKbDaIYwueYu7dblaFabThDk0ojvd JhVVJE5PDqt7LtqE+cAnNbVCucA0vDB0k3N5/RlntQtTzD5HoNiMPk3l; Authentication-Results: sj-dkim-3.cisco.com; header.From=sasad@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.2 (++) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Hello, Thanks for Margaret's feedback. We have integrated her feedback and should appear in -05 of the draft. Please see our comments below. Regards, Salman On 5/26/06 11:04 AM, "Fred Baker" wrote: > FYI. Margaret's original message seems to have not made it to v6ops, > or at least through it to me and reportedly several of you. > > -----Original Message----- > From: Margaret Wasserman > Sent: Thursday, May 25, 2006 11:16 AM > To: 'v6ops@ops.ietf.org'; 'iesg@ietf.org' > Subject: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt > > > Hi All, > > While I was in a mood to review v6ops documents, I also reviewed > draft-ietf-v6ops-bb-deployment-scenarios-04.txt. IMO, this is a very > good document that is full of useful information, and it is nearly > suitable for publication. > > I only found one serious issue in the document, and it non-technical. > I think that section 2 should be removed from the document, because I > don't think it is appropriate for the IETF to publish documents that > indicate how SPs should differentiate their services and/or to comment > on SPs specific products and services. Removed section 2. > > I have a couple of other comments (see below), but nothing else that > Should block publication of this document, IMO. > > Margaret > > --- > > 1.1. Common Terminology > > Add "BB" which is used throughout the document to mean Broadband? > > 2. IPv6 Based BB Services > > At this point IPv6 based services are seen as a differentiator that > enables SPs to take advantage of the large IPv6 address space to the > extent that subscribers get up to fixed /48 prefixes versus the > single, temporary IPv4 addresses. Such resources allow the SPs to > better position themselves against the competition. The IPv6 > deployments can be seen as a driver for lower service support costs > by eliminating NAT with its negative impact on applications and its > complex behavior. Another reason of IPv6 being popular in some > countries might be the government driven financial incentives and > favorable legislation towards the ISPs who are deploying IPv6. > > > I would remove this entire seciton (section 2) from the document. I > don't think that the IETF is qualified to comment on business > differentiators in the SP industry, and even if we were qualified to do > so, I don't why we would want to do so. I don't think it is appropriate > to mention specific companies' products and services, and timely > information about what is currently deployed, including the limitations > of those deployments, will probably be outdated by the time this > document is published. > > > If you don't remove this section, I think it will need a lot of work, as > it mentions individual company names and product names without any > disclaimers and/or indication of whether those companies have approved > of what we are saying about their products, and without including such > legal niceties as trademarks, etc. > > The network is transparent to the Layer 3 protocol. The only > possible changes would come with the intent of filtering and > monitoring IPv6 traffic based on layer 2 information such as IPv6 > Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC > addresses (3333.xxxx.xxxx). > > What format of MAC address is this? I have most often seen Ethernet > addresses represented at xx:xx:xx:xx:xx:xx, so this would be > 33:33:xx:xx:xx:xx, right? Good catch :-) Corrected it. But other MAC addresses may be other lengths, > such as EUI-64 identifiers. Also, if one filters on an EtherType of > 0x86DD, one will see all IPv6 traffic. I am not sure why an additional > filter for IPv6-specific multicast addresses would be needed. Can you > explain? Yes you are correct. One would use one type of the filter or other, not both at the same time. > > It is important to note that the customers of a Service Provider can > choose to establish tunnels to publicly available and free tunnel > services. Even though the quality of such services might not be > high, they provide free IPv6 access. In designing their IPv6 > services, the SPs should take into considerations such options > available to their potential customers. The IPv6 deployment should > support services (like multicast, VoIPv6 etc) and a level of quality > that would make the access through the SP worthwhile to potential > subscribers. > > This paragraph should be removed, as it mainly provides marketing, not > operational, advice to SPs. Removed the above paragraph as recommended. > > 6. Broadband Cable Networks > > This section describes the infrastructure that exists today in cable > networks providing BB services to the home. It also describes IPv6 > deployment options in these cable networks. > > DOCSIS standardizes and documents the operation of data over Cable > Networks. The current version of DOCSIS has limitations that do not > allow for a smooth implementation of native IPv6 transport. Some of > these limitations are discussed in this section. For this reason, > the IPv6 deployment scenarios discussed in this section for the > existent Cable Networks are tunnel based. The tunneling examples > presented here could also be applied to the other BB technologies > described in sections 7, 8, 9 and 10. > > You should expand the DOCSIS acronym, add a reference for DOCSIS and > state which version is the "current version" that has these limitations. Done. > > 6.2.4. IPv6 QoS > > IPv6 will not change or add any queuing/scheduling functionality > already existing in DOCSIS specifications. But the QoS > mechanisms on > the CMTS and CM would need to be IPv6 capable. This includes > support > for IPv6 classifiers, so that data traffic to/from host devices can > be classified appropriately into different service flows and be > assigned appropriate priority. Appropriate classification criteria > would need to be implemented for unicast and multicast traffic. > > In order to classify IPv6 traffic the following classifiers would > need to be modified in the DOCSIS specification to support the 128- > bit IPv6 address: > > A. IP source address > > B. IP source mask > > C. IP destination address > > D. IP destination mask > > E. IP traffic class (DSCP) > > The following classifiers would be new for IPv6: > > A. IP version > > B. Flow label (optional) > > Traffic classification and marking should be done at the CM for > upstream traffic and the CMTS/ER for downstream traffic in order to > support the various types of services: data, voice, video. The same > IPv4 QoS concepts and methodologies should be applied for IPv6 as > well. > > It is important to note that when traffic is encrypted end-to-end, > the traversed network devices will not have access to many of the > packet fields used for classification purposes. In these cases > routers will most likely place the packets in the default classes. > The QoS design should take into consideration this scenario and try > to use mainly IP header fields for classification purposes. > > I am not certain about the purpose of this section... Are we trying to > tell DOCSIS what they would need to change in their specifications in > order to support IPv6 QoS? If so, I don't think that this belongs in a > document that is telling SPs how to support IPv6 in their networks, does > it? > > I think you should make it clearer here and in later sections what will > not currently work, rather than just stating that DOCSIS should change > things. We have deleted the following from the above section as recommended. In order to classify IPv6 traffic the following classifiers would > need to be modified in the DOCSIS specification to support the 128- > bit IPv6 address: > > A. IP source address > > B. IP source mask > > C. IP destination address > > D. IP destination mask > > E. IP traffic class (DSCP) > > The following classifiers would be new for IPv6: > > A. IP version > > B. Flow label (optional) > > 7.2.1.2. Addressing > > The Hosts or the Customer Routers have the Edge Router as their > Layer > 3 next hop. > > If there is no Customer Router all the hosts on the subscriber site > belong to the same /64 subnet that is statically configured on the > Edge Router for that subscriber PVC. The hosts can use stateless > auto-configuration or stateful DHCPv6 based configuration to acquire > an address via the Edge Router. > > However, as manual configuration for each customer is a provisioning > challenge, implementations are encouraged to develop mechanism(s) > which automatically map the PVC (or some other customer-specific > information) to an IPv6 subnet prefix, and advertise the customer- > specific prefix to all the customers with minimal configuration. > > How is this done in IPv4? Why does it need to be different in IPv6? IPv4 has the same issue but with IPv6 we are suggesting that we could work on coming up with betters schemes. ========== ==========