From ux@megatron.ietf.org Mon Mar 1 00:55:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09ECE3A88EF for ; Mon, 1 Mar 2010 00:55:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 1 Mar 2010 00:54:59 -0800 (PST) Received: from 219-89-126-160.adsl.xtra.co.nz (219-89-126-160.adsl.xtra.co.nz [219.89.126.160]) by core3.amsl.com (Postfix) with SMTP id 1605E3A83C6 for ; Mon, 1 Mar 2010 00:54:57 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100301085458.1605E3A83C6@core3.amsl.com> Date: Mon, 1 Mar 2010 00:54:57 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 77809 Inc. All rights reserved.

From secmech-request@lists.ietf.org Mon Mar 1 09:28:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED78928C3C2 for ; Mon, 1 Mar 2010 09:28:25 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 1 Mar 2010 09:28:19 -0800 (PST) Received: from affymetrix.com (unknown [190.191.32.11]) by core3.amsl.com (Postfix) with SMTP id 417CC28C14C for ; Mon, 1 Mar 2010 09:28:10 -0800 (PST) From: Approved VIAGRA® Store Subject: Your Future Order with 75% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100301172816.417CC28C14C@core3.amsl.com> Date: Mon, 1 Mar 2010 09:28:10 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78963 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Mon Mar 1 23:22:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701C928C6EB for ; Mon, 1 Mar 2010 23:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.37 X-Spam-Level: X-Spam-Status: No, score=-16.37 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2VKjWWClkls for ; Mon, 1 Mar 2010 23:22:31 -0800 (PST) Received: from 83-131-252-75.adsl.net.t-com.hr (83-131-252-75.adsl.net.t-com.hr [83.131.252.75]) by core3.amsl.com (Postfix) with ESMTP id C2B9F28C6E8 for ; Mon, 1 Mar 2010 23:22:30 -0800 (PST) From: "SuperShop on-line" To: v6ops-archive@megatron.ietf.org Subject: For v6ops-archive,we return to -80% prices Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100302072230.C2B9F28C6E8@core3.amsl.com> Date: Mon, 1 Mar 2010 23:22:30 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@megatron.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 FIXEOTAM. All rights reserved.
From v6ops-archive@lists.ietf.org Tue Mar 2 03:39:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D63A3A87F4 for ; Tue, 2 Mar 2010 03:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.303 X-Spam-Level: X-Spam-Status: No, score=-23.303 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piuedr4NKF+C for ; Tue, 2 Mar 2010 03:39:36 -0800 (PST) Received: from gwkosm.zskosmonautu13.cz (gwkosm.zskosmonautu13.cz [193.179.197.81]) by core3.amsl.com (Postfix) with ESMTP id 6DDE13A87D9 for ; Tue, 2 Mar 2010 03:39:35 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@lists.ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100302113935.6DDE13A87D9@core3.amsl.com> Date: Tue, 2 Mar 2010 03:39:35 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Giqylqtq. All rights reserved.
 Click to unsubscribe
From v6ops-archive@megatron.ietf.org Tue Mar 2 03:40:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77063A8539 for ; Tue, 2 Mar 2010 03:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.303 X-Spam-Level: X-Spam-Status: No, score=-43.303 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zz1DtgWGkAT for ; Tue, 2 Mar 2010 03:40:10 -0800 (PST) Received: from gwkosm.zskosmonautu13.cz (gwkosm.zskosmonautu13.cz [193.179.197.81]) by core3.amsl.com (Postfix) with ESMTP id 49B6A3A69BE for ; Tue, 2 Mar 2010 03:40:09 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@megatron.ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100302114009.49B6A3A69BE@core3.amsl.com> Date: Tue, 2 Mar 2010 03:40:09 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Myezqz. All rights reserved.
 Click to unsubscribe
From v6ops-archive@ietf.org Tue Mar 2 03:40:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287633A875F for ; Tue, 2 Mar 2010 03:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.303 X-Spam-Level: X-Spam-Status: No, score=-43.303 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKGpVi+EBahT for ; Tue, 2 Mar 2010 03:40:51 -0800 (PST) Received: from gwkosm.zskosmonautu13.cz (gwkosm.zskosmonautu13.cz [193.179.197.81]) by core3.amsl.com (Postfix) with ESMTP id 0D2043A6AA3 for ; Tue, 2 Mar 2010 03:40:50 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100302114051.0D2043A6AA3@core3.amsl.com> Date: Tue, 2 Mar 2010 03:40:50 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Kjlal. All rights reserved.
 Click to unsubscribe
From owner-v6ops@ops.ietf.org Tue Mar 2 05:12:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A79A3A891D for ; Tue, 2 Mar 2010 05:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxTquxdqwzeM for ; Tue, 2 Mar 2010 05:12:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A83C3A6AD0 for ; Tue, 2 Mar 2010 05:12:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmRnS-000Asu-Ah for v6ops-data0@psg.com; Tue, 02 Mar 2010 13:05:58 +0000 Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmRnO-000AsS-I0 for v6ops@ops.ietf.org; Tue, 02 Mar 2010 13:05:54 +0000 Received: from localhost ([127.0.0.1] helo=squirrel.six.silmor.de) by p15139323.pureserver.info with esmtp (Exim 4.69) (envelope-from ) id 1NmRnM-0006Nz-CW; Tue, 02 Mar 2010 14:05:52 +0100 Received: from 2002:d9a0:db4b::4 (proxying for 188.92.33.52) (SquirrelMail authenticated user konrad) by squirrel.six.silmor.de with HTTP; Tue, 2 Mar 2010 14:05:52 +0100 (CET) Message-ID: <8a9555f15593bb5971e3ad806dc91c3b.squirrel@squirrel.six.silmor.de> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589C90C388@NOK-EUMSG-01.mgdnok.nokia. com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F589562C7C8@NOK-EUMSG-01.mgdnok.nokia.com> <885074f5a3bc21decfca6e7fcf3e6069.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C90C388@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 2 Mar 2010 14:05:52 +0100 (CET) Subject: RE: Call for v6ops agenda items From: "Konrad Rosenbaum" To: teemu.savolainen@nokia.com Cc: v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, February 25, 2010 13:55, teemu.savolainen@nokia.com wrote: >> * there already is a well working protocol for PD: DHCPv6; although I >> like the idea of finally getting rid of it > > Right. IMHO as is proven by 6RD, there's interest to have prefix > delegation also without DHCPv6 if easily doable. 6RD, as I understand it, is not primarily a configuration protocol, but a transition mechanism from IPv4 to IPv6 on large already deployed networks. As that 6RD is an excellent idea. I personally expect it to fade away ten years from now, while SLAAC and DHCPv6 are likely to stay. >> * the unique-bits part is too large to work on more than one level, so >> it >> would be reserved to the ISP-to-User-line, but then again SLAAC is also >> reserved to the link level of routing > > I don't agree, the draft intents to say unique-bits can be of about any > length. For example: > - if length of unique bits is 1, there can be two routers below the > gateway, which both would get delegated prefix of: > [SPD-prefix][0/1][subnet ID]. Now if the SPD prefix is say 40 bits, and > V6UNIQUE is 1 bit, the router would get /41, right? Then this router could > further choose to delegate say /56 by configuring downlink routers by > provisioning them with: [SPD-prefix+1][V6UNIQUE of 14 bits of > length][subnet ID]. Right? > > In fact, this unique bits could be minimum of 1 bit and maximum is many > bits (I have to think about that), right? Thinking about this again: regardless of how unique bits are assigned to the customer, the minimum amount of them is the same (log2 of the amount of customers on the (sub-)network). So there would be no problem if we could use the minimum amount or an amount close to minimum. Unfortunately most sources of unique bits are made up of very large blocks of bits that have to be used completely. E.g. Link Layer is most often 48 or 64 bits, which do not follow any schema that a network operator can influence (at least on Ethernet based setups), so you waste a lot of bits just to make sure it stays unique (as also witnessed by 64bit host IDs in IPv6). This leaves only sources that I can influence as a network operator: PPP interface ID, /64 prefix of the 1:1 link, very few others, none on shared ethernets. This severely limits the usability of SPD. >> * semantically it's not the right protocol for this: SLAAC is >> transmitted >> on the same link it configures, PD is transmitted on the upstream link >> of >> those (different links) that are configured > > With SLAAC you refer to the case where bits are taken from the /64 prefix > configured with SLAAC? Yes. > Right, but what is the significant difference to > 6RD that uses uplinks IPv4 address? The 6RD encapsulation happens in a very different layer of the protocol: the virtual interface level. SLAAC happens on an established IPv6 link on the IPv6/ICMPv6 level. The protocol only uses very abstract services from the lower layers of the protocol stack (transmit/receive packet, give me the modified EUI-64 of the interface). It does not care whether the lower layer constructs the EUI-64 from a MAC, from some prior negotiation or the last 64bits of the last crashes stack dump. It will never ask for a MAC address or an IPv4 address - because there might be none. 6RD (and for that matter 6to4) on the other hand is a collection of protocols on several, well separated, layers: * 6in4 knows how to encapsulate IPv6 packets in IPv4 packets and where to send them - the latter because userspace told it the destination * the route setup (usually a script written by a vendor or the local admin) knows what IPv6 route happens to coincide with the local/remote IPv4 endpoint address; this is the userspace that tells the virtual interface what to do My (rather philosophical) problem with your proposal is that you try to teach the SLAAC/ICMPv6 part of the protocol stack about protocols it does not need to know about. This makes the driver more complex and hence more error prone. In my opinion unnecessarily. The normal reaction of prudent implementers will probably be to implement this part of the protocol in userspace in a separate process. Result: you have gained nothing over DHCPv6. I shudder to think what security bulletins I'll see if an implementer does not behave prudently... >> * for most OSes it has to be implemented in a user-space program >> anyway, >> since the kernel cannot know which interfaces to configure, but in >> userspace it does not matter whether I implement DHCP rapid commit or >> "stateless" PD with a request message - the complexity is the same > > True. On the requesting router side the savings are indeed less - the main > benefits would be on the network side. What would be the savings? I implemented a semi-stateless version of DHCPv6 for my internal experiments with IPv6 over PPP - it responds with the same prefix to any query from the same customer, so it did not need to store any states. Including reading and understanding the standard, writing the server and client, and testing it with other implementations, it took me a weekend and resulted in a few hundred lines of code (most of that code deals with parsing command line arguments and handling its socket). I do not believe that there is any significant gain in development time, binary size, CPU cycles or memory consumption compared to SPD. In fact it would require CE router vendors (and possibly provider side AC vendors) to support yet another protocol. I can imagine any number of (semi-)stateless DHCPv6 implementations that do exactly what you propose within the bounds of established standards. >> I/2: should be unified into just I, since it is guaranteed to exist and >> is >> dependent on layer 2 IDs anyway > > Done, but added "T": tunnel identifier. What I'm thinking here is that > e.g. the GTP TEID of 3GPP access could be unique part. Each bearer has > this locally unique 32bit identifier. I think this requires further > clarification. "T" represents the same mix of layers again. >> 4: I have a really big problem with this: it mixes protocols and >> requires >> a lot of dual-stack logic to exist on the host - you can make it a MAY, >> but then DHCPv6-PD has to exist as well as a backup > > What do you think about 6RD? I think 6RD is a much needed and very fine _transition_mechanism_. See above. In short: I think we would gain more by defining the minimum requirements for provider Access Concentrators using existing standards as a complement to the upcoming CPE-router standard. regards, Konrad From owner-v6ops@ops.ietf.org Tue Mar 2 05:22:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EBE3A84BD for ; Tue, 2 Mar 2010 05:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iI0FzQkkirJ for ; Tue, 2 Mar 2010 05:22:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E1BF3A6922 for ; Tue, 2 Mar 2010 05:22:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmS1p-000CRp-3X for v6ops-data0@psg.com; Tue, 02 Mar 2010 13:20:49 +0000 Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmS1k-000CRN-7n for v6ops@ops.ietf.org; Tue, 02 Mar 2010 13:20:44 +0000 Received: from localhost ([127.0.0.1] helo=squirrel.six.silmor.de) by p15139323.pureserver.info with esmtp (Exim 4.69) (envelope-from ) id 1NmS1f-0006Q3-Ol; Tue, 02 Mar 2010 14:20:40 +0100 Received: from 2002:d9a0:db4b::4 (proxying for 188.92.33.52) (SquirrelMail authenticated user konrad) by squirrel.six.silmor.de with HTTP; Tue, 2 Mar 2010 14:20:39 +0100 (CET) Message-ID: <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> In-Reply-To: <1267309761.3168.5.camel@Nokia-N900-51-1> References: <1267309761.3168.5.camel@Nokia-N900-51-1> Date: Tue, 2 Mar 2010 14:20:39 +0100 (CET) Subject: Re: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) From: "Konrad Rosenbaum" To: teemu.savolainen@nokia.com Cc: otroan@employees.org, 3gv6@ietf.org, v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Sat, February 27, 2010 23:29, teemu.savolainen@nokia.com wrote: > Have you seen also > http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 ? With DHCPv6 > PD there's the issue of not being able to use one /64 on the WAN from the > delegated space. On the other hand, not having a global /64 prefix on the > WAN at all (unnumbred model) probably would be too big change for the > 3GPP. Any thoughts about this issue? I assume you mean specifically section 5 of this draft - the supposed problem with DHCPv6 not allowing to assign prefixes backward. This has good reasons: DHCP is a forward assignment - assigning part of the delegated prefix back to the originating link usually leads to problems with routing. The solution is to assign a separate portion of the provider prefix to direct link prefixes and delegate something different from this. It requires a bit more thinking on the network operators part, but causes much less pain for the support hotline... ;-) Eg. if the provider uses 2001:db8::/32 and has about 10mio customers (24bit customer ID) one solution would be to reserve 2001:db8:0::/40 for link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for PD. As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC for the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation downstream. Konrad From owner-v6ops@ops.ietf.org Tue Mar 2 07:03:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C170328C0F0 for ; Tue, 2 Mar 2010 07:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.721 X-Spam-Level: X-Spam-Status: No, score=-4.721 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8RkemhhKojn for ; Tue, 2 Mar 2010 07:03:38 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3FB33A86D7 for ; Tue, 2 Mar 2010 07:03:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmTaA-000Ona-F8 for v6ops-data0@psg.com; Tue, 02 Mar 2010 15:00:22 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmTa6-000Om6-0D for v6ops@ops.ietf.org; Tue, 02 Mar 2010 15:00:18 +0000 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22Exwid005009; Tue, 2 Mar 2010 17:00:12 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:59:51 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:59:46 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 2 Mar 2010 15:59:45 +0100 From: To: CC: Date: Tue, 2 Mar 2010 15:59:43 +0100 Subject: RE: Call for v6ops agenda items Thread-Topic: Call for v6ops agenda items Thread-Index: Acq6CSB/C4Ou9cp1S4C6fhHUBuGWHQACxycg Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCE31@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F589562C7C8@NOK-EUMSG-01.mgdnok.nokia.com> <885074f5a3bc21decfca6e7fcf3e6069.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C90C388@NOK-EUMSG-01.mgdnok.nokia.com> <8a9555f15593bb5971e3ad806dc91c3b.squirrel@squirrel.six.silmor.de> In-Reply-To: <8a9555f15593bb5971e3ad806dc91c3b.squirrel@squirrel.six.silmor.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2010 14:59:46.0390 (UTC) FILETIME=[FF9C5F60:01CABA18] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Konrad, > 6RD, as I understand it, is not primarily a configuration protocol, but > a > transition mechanism from IPv4 to IPv6 on large already deployed > networks. > As that 6RD is an excellent idea. I personally expect it to fade away > ten > years from now, while SLAAC and DHCPv6 are likely to stay. Nevertheless, people do not see problem for using IPv4 address as part of a= utomatic prefix delegation.. > Unfortunately most sources of unique bits are made up of very large > blocks > of bits that have to be used completely. E.g. Link Layer is most often > 48 > or 64 bits, which do not follow any schema that a network operator can > influence (at least on Ethernet based setups), so you waste a lot of > bits > just to make sure it stays unique (as also witnessed by 64bit host IDs > in > IPv6). It is true that such sources of uniqueness cannot be used. I probably need = to clarify the applicability scenarios for the next revision. > This leaves only sources that I can influence as a network operator: > PPP > interface ID, /64 prefix of the 1:1 link, very few others, none on > shared > ethernets. > > This severely limits the usability of SPD. That is subjective. World's cellular networks are usually using 1:1 links (= e.g. all 3GPP(2) networks), which from my point of view is population large= enough to justify a technology. But it is true that this is not as widely = applicable as DHCPv6 PD (and not even supposed to be so). =20 > My (rather philosophical) problem with your proposal is that you try to > teach the SLAAC/ICMPv6 part of the protocol stack about protocols it > does > not need to know about. This makes the driver more complex and hence > more > error prone. In my opinion unnecessarily. I don't think I'm trying to teach SLAAC/ICMPv6 anything? Why do you think s= o (i.e. where do I need to clarify)? The user space software would use the Stateless DHCPv6 to learn the configu= ration information, and calculate the delegated prefixes as described. Why = SLAAC/ICMPv6 would have to be touched? > The normal reaction of prudent implementers will probably be to > implement > this part of the protocol in userspace in a separate process. Result: > you > have gained nothing over DHCPv6. I shudder to think what security > bulletins I'll see if an implementer does not behave prudently... This userspace process would ask for the configuration information with Sta= teless DHCPv6, and based on the response would calculate automatically dele= gated prefixes and configure routing and RAs of local interfaces. So less D= HCPv6 functionality would be needed, right? Devices that currently do not i= mplement DHCPv6 for anything else than parameter configuration would not ne= ed to implement more of DHCPv6, but could manage still with just Stateless = DHCPv6.=20 Avoiding new DHCPv6 code on a host should be less risky? > I implemented a semi-stateless version of DHCPv6 for my internal > experiments with IPv6 over PPP - it responds with the same prefix to > any > query from the same customer, so it did not need to store any states. Yes, this lightweight DHCPv6 server (on a gateway) is an interesting option= as well. It could indeed provide much of the functions I'm after as was di= scussed in another thread with Ole. I'm studying that as well. Best regards, Teemu From owner-v6ops@ops.ietf.org Tue Mar 2 07:59:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4939C3A8B7B for ; Tue, 2 Mar 2010 07:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.946 X-Spam-Level: X-Spam-Status: No, score=-4.946 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi4HPHYOjs7m for ; Tue, 2 Mar 2010 07:59:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02BFF3A8B73 for ; Tue, 2 Mar 2010 07:59:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmUSp-0005iy-4E for v6ops-data0@psg.com; Tue, 02 Mar 2010 15:56:51 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmUSk-0005hs-98 for v6ops@ops.ietf.org; Tue, 02 Mar 2010 15:56:46 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22FuYxJ006977; Tue, 2 Mar 2010 17:56:37 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:26 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:07 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 2 Mar 2010 16:56:06 +0100 From: To: CC: , <3gv6@ietf.org>, Date: Tue, 2 Mar 2010 16:56:04 +0100 Subject: RE: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) Thread-Topic: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) Thread-Index: Acq6CzHVfTCzgn3cSkWN1xOmH+2TkgADc2vw Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> In-Reply-To: <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2010 15:56:07.0021 (UTC) FILETIME=[DE9FB9D0:01CABA20] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Conrad, > I assume you mean specifically section 5 of this draft - the supposed > problem with DHCPv6 not allowing to assign prefixes backward. This has > good reasons: DHCP is a forward assignment - assigning part of the > delegated prefix back to the originating link usually leads to problems > with routing. Rather the delegating router would delegate a prefix minus one /64. I.e. th= e one /64 would not be really assigned back to the originating link, but ra= ther never assigned to requesting router at the first place... > The solution is to assign a separate portion of the provider prefix to > direct link prefixes and delegate something different from this. It > requires a bit more thinking on the network operators part, but causes > much less pain for the support hotline... ;-) >=20 > Eg. if the provider uses 2001:db8::/32 and has about 10mio customers > (24bit customer ID) one solution would be to reserve 2001:db8:0::/40 > for > link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for > PD. > As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC > for > the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation > downstream. Isn't this close to what I describe in stateless draft, i.e. having a /32 b= it ISP prefix, and then using 24 lowest bits of the /64 prefix given to UE = (with SLAAC) in calculating the delegated /56 prefix? In DHCPv6-"light" thi= s calculation would be done by DR, in Stateless this would be done by RR. Best regards, Teemu From v6ops-archive@lists.ietf.org Tue Mar 2 09:15:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F5828C172 for ; Tue, 2 Mar 2010 09:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.057 X-Spam-Level: X-Spam-Status: No, score=-92.057 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNA=1.231, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+VgtEDB7P7u for ; Tue, 2 Mar 2010 09:14:59 -0800 (PST) Received: from alston.com (unknown [212.124.3.67]) by core3.amsl.com (Postfix) with SMTP id 8267828C16E for ; Tue, 2 Mar 2010 09:14:55 -0800 (PST) To: Subject: Delivery Status Notification From: Frieda MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100302171455.8267828C16E@core3.amsl.com> Date: Tue, 2 Mar 2010 09:14:55 -0800 (PST)

If you have any difficulty seeing the contents of this e-mail, please click here.

This picture is blocked. Click to unblock now
Copyright © 2010 87781 Corp.
Privacy Policy | Terms of Use | Contact Us | Unsubscribe
From owner-v6ops@ops.ietf.org Tue Mar 2 09:30:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C8C28C1EA for ; Tue, 2 Mar 2010 09:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkTCT90IGeIX for ; Tue, 2 Mar 2010 09:30:08 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 723C928C1F0 for ; Tue, 2 Mar 2010 09:30:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmVr5-000IMa-02 for v6ops-data0@psg.com; Tue, 02 Mar 2010 17:25:59 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmVqz-000ILy-4x for v6ops@ops.ietf.org; Tue, 02 Mar 2010 17:25:54 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8C770E081DB for ; Tue, 2 Mar 2010 18:25:46 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8E0FDE080D7 for ; Tue, 2 Mar 2010 18:25:44 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Native IPv6 statelessly offered by ISP across NAT44s - New draft on SAM Date: Tue, 2 Mar 2010 18:25:44 +0100 References: To: IPv6 v6ops Message-Id: <684CF380-E671-4B56-9A28-3F7288D135B9@free.fr> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi all, The announce draft is now available at = tools.ietf.org/id/draft-despres-softwire-sam-00. The section which describes the particular IPv6-via-NAT44 scenario is in = section 3.1.1. Note that the presentation in Anaheim is planned to be understandable = without having looked at the draft before. =20 But comments are most welcome at any time. Regards, RD > De : R=E9mi Despr=E9s > Date : 19 f=E9vrier 2010 14:09:29 HNEC > =C0 : Fred Baker > Cc : IPv6 Operations > Objet : R=E9p : Call for v6ops agenda items - native IPv6 across = NAT44s >=20 > Fred, >=20 > Draft-despres-softwire-sam-00, which I will post in a few days, = contains an updated description of SAM, the generic Stateless Address = Mapping mechanism which applies to a variety of scenarios. >=20 > Among those, one permits ISPs to deliver native IPv6 connectivity = across legacy CPEs that only support NAT44 with port forwarding. > This solution is like 6rd in that: > - ISPs don't need to change their IPv4 infrastructures > - They only need to operate gateways between these and their IPv6 = accesses > - These gateways are stateless > It is unlike 6rd in that: > - Legacy CPEs don't need to be upgraded > - To exploit of their IPv6 addresses, hosts have to be upgraded to = support SAM. >=20 > Operation considerations of this scenario are relevant to v6ops. > A time slot for a presentation will be appreciated. >=20 > Regards, > RD From owner-v6ops@ops.ietf.org Tue Mar 2 09:47:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F923A8BCC for ; Tue, 2 Mar 2010 09:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqdD3dvS8-dZ for ; Tue, 2 Mar 2010 09:47:07 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31CE828C125 for ; Tue, 2 Mar 2010 09:47:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmW9n-000Ksh-LO for v6ops-data0@psg.com; Tue, 02 Mar 2010 17:45:19 +0000 Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmW9l-000Ks8-3Q for v6ops@ops.ietf.org; Tue, 02 Mar 2010 17:45:17 +0000 Received: from localhost ([127.0.0.1] helo=squirrel.six.silmor.de) by p15139323.pureserver.info with esmtp (Exim 4.69) (envelope-from ) id 1NmW9j-0007Mt-1X; Tue, 02 Mar 2010 18:45:15 +0100 Received: from 2002:d9a0:db4b::4 (proxying for 188.92.33.52) (SquirrelMail authenticated user konrad) by squirrel.six.silmor.de with HTTP; Tue, 2 Mar 2010 18:45:15 +0100 (CET) Message-ID: In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCE31@NOK-EUMSG-01.mgdnok.nokia. com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F589562C7C8@NOK-EUMSG-01.mgdnok.nokia.com> <885074f5a3bc21decfca6e7fcf3e6069.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C90C388@NOK-EUMSG-01.mgdnok.nokia.com> <8a9555f15593bb5971e3ad806dc91c3b.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCE31@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 2 Mar 2010 18:45:15 +0100 (CET) Subject: RE: Call for v6ops agenda items From: "Konrad Rosenbaum" To: "teemu.savolainen@nokia.com" Cc: v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Tue, March 2, 2010 15:59, teemu.savolainen@nokia.com wrote: >> My (rather philosophical) problem with your proposal is that you try to >> teach the SLAAC/ICMPv6 part of the protocol stack about protocols it >> does >> not need to know about. This makes the driver more complex and hence >> more >> error prone. In my opinion unnecessarily. > > I don't think I'm trying to teach SLAAC/ICMPv6 anything? Why do you think > so (i.e. where do I need to clarify)? Oooooops. That's embarassing: for some reason I assumed your protocol was an extension of Router Advertisements. Do I read it correctly now in that you plan to extend DHCPv6 and/or IPv6CP? If so, a lot of my arguments just lost their teeth. Could you make it clearer what exact protocols can carry your extension and how they interact with it? > The user space software would use the Stateless DHCPv6 to learn the > configuration information, and calculate the delegated prefixes as > described. Why SLAAC/ICMPv6 would have to be touched? In that case they wouldn't. > Avoiding new DHCPv6 code on a host should be less risky? Yes. Avoiding any extra code is less risky. As is avoiding any mix of layers. >> I implemented a semi-stateless version of DHCPv6 for my internal >> experiments with IPv6 over PPP - it responds with the same prefix to >> any >> query from the same customer, so it did not need to store any states. > > Yes, this lightweight DHCPv6 server (on a gateway) is an interesting > option as well. It could indeed provide much of the functions I'm after as > was discussed in another thread with Ole. I'm studying that as well. This also has the upside of the provider and/or AC vendor being able to impose any policy on prefix calculation without having to worry about the state of implementations on the CPE side. What I still worry about is a wholly different aspect of SPD: Pseudo-stateful PD requires you to implement the calculation of prefixes exactly once on the AC (DR) - even if it misinterprets some standard in the calculation it will probably still work - the clients (RR) do not care how their prefix was calculated, they just use it. As long as the RR works with any single other implementation of DHCP server it will probably work with almost all of them. Stateless PD requires this calculation to be implemented exactly the same way on the AC/DR (it has to calculate the routing table) and all the variants of RR, with the RR having to implement several variants at once since they do not know what network they will end up in. Especially the RR implementers will be under a lot of pressure (CPE devices and mobile phones are not exactly the most expensive network components). Per Murphy's Law they will get it wrong. In many different ways. So we will have a DR doing the calculation one way and several types of RR doing the same calculation randomly the same way, a slightly different way, a very different way or not at all. I do not want to seem unnecessarily gloomy, but I suspect high support costs are on the way if more than one way of calculation is supported and if there is the slightest chance of misinterpreting the standard. Konrad From owner-v6ops@ops.ietf.org Tue Mar 2 09:57:42 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B691428C144 for ; Tue, 2 Mar 2010 09:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQR6hyMZ3b+8 for ; Tue, 2 Mar 2010 09:57:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D8B828C13B for ; Tue, 2 Mar 2010 09:57:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmWKZ-000MIi-16 for v6ops-data0@psg.com; Tue, 02 Mar 2010 17:56:27 +0000 Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmWKW-000MII-ER for v6ops@ops.ietf.org; Tue, 02 Mar 2010 17:56:24 +0000 Received: from localhost ([127.0.0.1] helo=squirrel.six.silmor.de) by p15139323.pureserver.info with esmtp (Exim 4.69) (envelope-from ) id 1NmWKR-0007PQ-Sm; Tue, 02 Mar 2010 18:56:20 +0100 Received: from 2002:d9a0:db4b::4 (proxying for 188.92.33.52) (SquirrelMail authenticated user konrad) by squirrel.six.silmor.de with HTTP; Tue, 2 Mar 2010 18:56:19 +0100 (CET) Message-ID: In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia. com> References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 2 Mar 2010 18:56:19 +0100 (CET) Subject: RE: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) From: "Konrad Rosenbaum" To: teemu.savolainen@nokia.com Cc: otroan@employees.org, 3gv6@ietf.org, v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Tue, March 2, 2010 16:56, teemu.savolainen@nokia.com wrote: > Rather the delegating router would delegate a prefix minus one /64. I.e. > the one /64 would not be really assigned back to the originating link, but > rather never assigned to requesting router at the first place... In theory what you propose should work, but... Let's assume we assign 2001:db8:1:200::/56 to the device. It would give the uplink 2001:db8:1:200::/64 and say 2001:db8:1:201::/64 to its WLAN port. For the device itself everything is fine - its routing table contains two orthogonal /64 routes. However the Access Concentrator has to deal with a paradoxical situation: several overlapping routes. If we assume the AC has host-ID ::1 and the CPE device or mobile phone has ::2: 2001:db8:1:200::1/128 loops back to the AC(*) 2001:db8:1:200::/64 has the link as direct target without gateway 2001:db8:1:200::/56 goes to gateway fe80::2 via the same link (*)some IPv6 stacks may omit this one It may work or it may not work. The alternative is a lot more entries in the routing table. What I described below has the upside that the third route does not overlap with the others. It has of course the downside that it uses up slightly more address space. >> The solution is to assign a separate portion of the provider prefix to >> direct link prefixes and delegate something different from this. It >> requires a bit more thinking on the network operators part, but causes >> much less pain for the support hotline... ;-) >> >> Eg. if the provider uses 2001:db8::/32 and has about 10mio customers >> (24bit customer ID) one solution would be to reserve 2001:db8:0::/40 >> for >> link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for >> PD. >> As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC >> for >> the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation >> downstream. > > Isn't this close to what I describe in stateless draft, i.e. having a /32 > bit ISP prefix, and then using 24 lowest bits of the /64 prefix given to > UE (with SLAAC) in calculating the delegated /56 prefix? In DHCPv6-"light" > this calculation would be done by DR, in Stateless this would be done by > RR. Correct. Konrad From owner-v6ops@ops.ietf.org Tue Mar 2 10:49:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A011128C22E for ; Tue, 2 Mar 2010 10:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7WYzXH0yggZ for ; Tue, 2 Mar 2010 10:49:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D30573A8BFE for ; Tue, 2 Mar 2010 10:49:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmX5t-0002NL-Jp for v6ops-data0@psg.com; Tue, 02 Mar 2010 18:45:21 +0000 Received: from [2a00:801::217:8ff:fe5b:81eb] (helo=uplift.swm.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmX5r-0002N2-10 for v6ops@ops.ietf.org; Tue, 02 Mar 2010 18:45:19 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1DB0D9E; Tue, 2 Mar 2010 19:45:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1BB819C; Tue, 2 Mar 2010 19:45:17 +0100 (CET) Date: Tue, 2 Mar 2010 19:45:17 +0100 (CET) From: Mikael Abrahamsson To: Konrad Rosenbaum cc: teemu.savolainen@nokia.com, v6ops@ops.ietf.org, otroan@employees.org, 3gv6@ietf.org Subject: Re: [3gv6] Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) In-Reply-To: Message-ID: References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 2 Mar 2010, Konrad Rosenbaum wrote: > However the Access Concentrator has to deal with a paradoxical > situation: several overlapping routes. If we assume the AC has host-ID > ::1 and the CPE device or mobile phone has ::2: Hm, I don't really endorse this model (I prefer the WAN interface unnumbered model), but I don't understand why this overlapping routes situation is paradoxical? Longest prefix routing is the norm on the Internet and should handle this just fine? -- Mikael Abrahamsson email: swmike@swm.pp.se From secmech-request@lists.ietf.org Tue Mar 2 14:14:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3028628C22D for ; Tue, 2 Mar 2010 14:14:28 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 2 Mar 2010 14:14:21 -0800 (PST) Received: from af-ct.com (unknown [190.177.156.20]) by core3.amsl.com (Postfix) with SMTP id 7B87428C188 for ; Tue, 2 Mar 2010 14:14:04 -0800 (PST) From: Approved VIAGRA® Store Subject: Special Discount 71% for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100302221413.7B87428C188@core3.amsl.com> Date: Tue, 2 Mar 2010 14:14:04 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 50958 Inc. All rights reserved.

From sigtran-archive@lists.ietf.org Tue Mar 2 15:55:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8030A28C0DC for ; Tue, 2 Mar 2010 15:55:22 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 2 Mar 2010 15:55:16 -0800 (PST) Received: from ll62-216-193-251-62.ll62.iam.net.ma (ll62-216-193-251-62.ll62.iam.net.ma [62.251.193.216]) by core3.amsl.com (Postfix) with SMTP id 9859D3A8576 for ; Tue, 2 Mar 2010 15:55:06 -0800 (PST) From: Approved VIAGRA® Store Subject: Your Future Order with 79% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100302235514.9859D3A8576@core3.amsl.com> Date: Tue, 2 Mar 2010 15:55:06 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 04297 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 2 19:03:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF1F3A85C5 for ; Tue, 2 Mar 2010 19:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bGOw4wMLRqc for ; Tue, 2 Mar 2010 19:03:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD1103A859E for ; Tue, 2 Mar 2010 19:02:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmemR-0004Yt-5s for v6ops-data0@psg.com; Wed, 03 Mar 2010 02:57:47 +0000 Received: from [209.85.219.220] (helo=mail-ew0-f220.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmemO-0004YU-Pq for v6ops@ops.ietf.org; Wed, 03 Mar 2010 02:57:44 +0000 Received: by ewy20 with SMTP id 20so668060ewy.1 for ; Tue, 02 Mar 2010 18:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WsjPvMNcdvqvG9pHhNK9COm+rXh3108932DreWhz9QI=; b=E87OV2lff77Mud3gJPuLpkIkwuqHlvP+YThsjh3qoBzzYm6qTPA27JbceCmrMsFcVq 1db7JghzmCdnmpYXP/WtyJCj/7eyXbXD0q2PWFRRy6tayR+LoQBE6C2bP9Cfg/pHXVum p29DuKm8haZWvLGnrSIW9Jxg1lMIGEpH+fNS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=KV70ZBp0o2iianJ8nr74fhigATMNOkt/G3Z/Upq1UM51yirCgEG9MykV83dkh9n/wg j1amwEJCllSvFvxaaxQKxNB1E2qRSmA0NIBHshAao/XhGpCw14dTLO5+iZV4ASMc2b/F 7iEqxz42drAIMyOuhAVm5Ady9StUwfrQx5nZ8= Received: by 10.213.104.95 with SMTP id n31mr1672736ebo.27.1267585063395; Tue, 02 Mar 2010 18:57:43 -0800 (PST) Received: from ?169.223.34.224? (224.34.dhcp.conference.apricot.net [169.223.34.224]) by mx.google.com with ESMTPS id 28sm7622474eyg.6.2010.03.02.18.57.37 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 18:57:42 -0800 (PST) Message-ID: <4B8DD019.2030307@gmail.com> Date: Wed, 03 Mar 2010 15:57:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Fred Baker , IPv6 Operations Subject: Re: Call for v6ops agenda items References: <8435F624-9A17-45D3-A320-7C0C50AE341A@cisco.com> <4B7312F6.9010808@gmail.com> In-Reply-To: <4B7312F6.9010808@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I just bumped into Kurtis in Kuala Lumpur, and he didn't recall seeing this request. draft-carpenter-v6ops-isp-scenarios-01 is out now. Regards Brian Carpenter On 2010-02-11 09:11, Brian E Carpenter wrote: > There will be a substantive update to draft-carpenter-v6ops-isp-scenarios, > including at least a first analysis of the questionnaire replies we've > received (29 so far). We'd like to present that; to give reasonable detail > about the replies would need ~30 minutes. > > Brian Carpenter > Sheng Jiang > > On 2010-02-11 04:58, Fred Baker wrote: >> The draft cut-off for -00 drafts is the first of March, and for all >> drafts is 8 March. Let me ask now: who plans to have documents to >> discuss in Anaheim, on what topics? >> >> http://www.ipinc.net/IPv4.GIF >> >> >> > From owner-v6ops@ops.ietf.org Wed Mar 3 00:12:51 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6CD28C2CD for ; Wed, 3 Mar 2010 00:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfF2cKymLG2G for ; Wed, 3 Mar 2010 00:12:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0806D28C25B for ; Wed, 3 Mar 2010 00:12:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmjd3-000B9u-4x for v6ops-data0@psg.com; Wed, 03 Mar 2010 08:08:25 +0000 Received: from [119.145.14.66] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmjd0-000B90-Q0 for v6ops@ops.ietf.org; Wed, 03 Mar 2010 08:08:23 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYP00DU65809E@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Wed, 03 Mar 2010 16:07:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYP00G3B57Z9F@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Wed, 03 Mar 2010 16:07:11 +0800 (CST) Received: from j66104a ([10.111.12.51]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYP00E5757ZFC@szxml06-in.huawei.com> for v6ops@ops.ietf.org; Wed, 03 Mar 2010 16:07:11 +0800 (CST) Date: Wed, 03 Mar 2010 16:07:11 +0800 From: Sheng Jiang Subject: FW: New Version Notification for draft-jiang-v6ops-nc-protection-01 To: 'IPv6 Operations' Cc: chenxu0128@huawei.com Message-id: <004d01cabaa8$872177b0$330c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acq57MfcxpFhWxxzRBm+MYfG2E88vgAu3z7w Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: An update version of draft-jiang-v6ops-nc-protection has been posted. Your comments are welcome. Best regards, Sheng > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, March 02, 2010 5:43 PM > To: shengjiang@huawei.com > Cc: chenxu0128@huawei.com; songxuan@huawei.com > Subject: New Version Notification for > draft-jiang-v6ops-nc-protection-01 > > > A new version of I-D, draft-jiang-v6ops-nc-protection-01.txt > has been successfuly submitted by Sheng Jiang and posted to > the IETF repository. > > Filename: draft-jiang-v6ops-nc-protection > Revision: 01 > Title: Neighbor Cache Protection in Neighbor > Discover Protocol > Creation_date: 2010-03-02 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > In Neighbor Discover Protocol, routers and hosts record the > neighbor information in the local Neighbor Cache database. It > is vulnerable by malicious attacks. This document analyzes > these security threats and proposes a solution, mainly using > reverse detection mechanism, to prevent the potential damage. > > > > > The IETF Secretariat. From v6ops-archive@megatron.ietf.org Wed Mar 3 07:33:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C8228C41C for ; Wed, 3 Mar 2010 07:33:40 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 3 Mar 2010 07:33:33 -0800 (PST) Received: from aluminumerectors.com (unknown [196.202.206.116]) by core3.amsl.com (Postfix) with SMTP id 2780028C102 for ; Wed, 3 Mar 2010 07:33:18 -0800 (PST) From: Approved VIAGRA® Store Subject: Sales Event get 70% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100303153322.2780028C102@core3.amsl.com> Date: Wed, 3 Mar 2010 07:33:18 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 92241 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Wed Mar 3 09:42:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C995D28C1D2 for ; Wed, 3 Mar 2010 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.895 X-Spam-Level: X-Spam-Status: No, score=-107.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6ovus4YeB4i for ; Wed, 3 Mar 2010 09:42:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81C4728C287 for ; Wed, 3 Mar 2010 09:42:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmsVJ-0003qh-Mz for v6ops-data0@psg.com; Wed, 03 Mar 2010 17:37:01 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmsVG-0003p3-F2 for v6ops@ops.ietf.org; Wed, 03 Mar 2010 17:36:58 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM4sjkurRN+J/2dsb2JhbACbBnOoPZhVhHwEgxc X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208";a="491131341" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 03 Mar 2010 17:36:57 +0000 Received: from dhcp-64-101-108-179.cisco.com (dhcp-64-101-108-179.cisco.com [64.101.108.179]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o23Hav8P014513; Wed, 3 Mar 2010 17:36:57 GMT Subject: Re: Call for v6ops agenda items Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4B8DD019.2030307@gmail.com> Date: Wed, 3 Mar 2010 09:36:57 -0800 Cc: Kurt Erik Lindqvist , IPv6 Operations Content-Transfer-Encoding: 7bit Message-Id: <475E8245-9979-40ED-9721-9E6648C9C9B8@cisco.com> References: <8435F624-9A17-45D3-A320-7C0C50AE341A@cisco.com> <4B7312F6.9010808@gmail.com> <4B8DD019.2030307@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: thanks On Mar 2, 2010, at 6:57 PM, Brian E Carpenter wrote: > I just bumped into Kurtis in Kuala Lumpur, and he didn't > recall seeing this request. > > draft-carpenter-v6ops-isp-scenarios-01 is out now. > > Regards > Brian Carpenter > > On 2010-02-11 09:11, Brian E Carpenter wrote: >> There will be a substantive update to draft-carpenter-v6ops-isp-scenarios, >> including at least a first analysis of the questionnaire replies we've >> received (29 so far). We'd like to present that; to give reasonable detail >> about the replies would need ~30 minutes. >> >> Brian Carpenter >> Sheng Jiang >> >> On 2010-02-11 04:58, Fred Baker wrote: >>> The draft cut-off for -00 drafts is the first of March, and for all >>> drafts is 8 March. Let me ask now: who plans to have documents to >>> discuss in Anaheim, on what topics? >>> >>> http://www.ipinc.net/IPv4.GIF >>> >>> >>> >> http://www.ipinc.net/IPv4.GIF From v6ops-archive@ietf.org Wed Mar 3 11:09:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB37E28C475 for ; Wed, 3 Mar 2010 11:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.434 X-Spam-Level: X-Spam-Status: No, score=-52.434 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM6wLHz95NJW for ; Wed, 3 Mar 2010 11:09:31 -0800 (PST) Received: from r190-134-165-25.dialup.adsl.anteldata.net.uy (r190-134-172-99.dialup.adsl.anteldata.net.uy [190.134.172.99]) by core3.amsl.com (Postfix) with ESMTP id 6B05828C167 for ; Wed, 3 Mar 2010 11:09:29 -0800 (PST) From: "SuperShop on-line" To: v6ops-archive@ietf.org Subject: For v6ops-archive,we return to -80% prices Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100303190930.6B05828C167@core3.amsl.com> Date: Wed, 3 Mar 2010 11:09:29 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 ETYPIWUKY. All rights reserved.
From v6ops-archive@lists.ietf.org Wed Mar 3 11:09:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA0E28C475 for ; Wed, 3 Mar 2010 11:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.434 X-Spam-Level: X-Spam-Status: No, score=-42.434 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlERvqovxUMl for ; Wed, 3 Mar 2010 11:09:39 -0800 (PST) Received: from r190-134-165-25.dialup.adsl.anteldata.net.uy (r190-134-172-99.dialup.adsl.anteldata.net.uy [190.134.172.99]) by core3.amsl.com (Postfix) with ESMTP id 876E028C255 for ; Wed, 3 Mar 2010 11:09:38 -0800 (PST) From: "SuperShop on-line" To: v6ops-archive@lists.ietf.org Subject: For v6ops-archive,we return to -80% prices Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100303190938.876E028C255@core3.amsl.com> Date: Wed, 3 Mar 2010 11:09:38 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@lists.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 QABATYL. All rights reserved.
From v6ops-archive@megatron.ietf.org Wed Mar 3 11:09:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7292C28C475 for ; Wed, 3 Mar 2010 11:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.934 X-Spam-Level: X-Spam-Status: No, score=-51.934 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxACU-dYfvao for ; Wed, 3 Mar 2010 11:09:46 -0800 (PST) Received: from r190-134-165-25.dialup.adsl.anteldata.net.uy (r190-134-172-99.dialup.adsl.anteldata.net.uy [190.134.172.99]) by core3.amsl.com (Postfix) with ESMTP id E815728C255 for ; Wed, 3 Mar 2010 11:09:44 -0800 (PST) From: "SuperShop on-line" To: v6ops-archive@megatron.ietf.org Subject: For v6ops-archive,we return to -80% prices Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100303190944.E815728C255@core3.amsl.com> Date: Wed, 3 Mar 2010 11:09:44 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@megatron.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 AWYVIGIVE. All rights reserved.
From owner-v6ops@ops.ietf.org Wed Mar 3 13:27:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7283A8CA8 for ; Wed, 3 Mar 2010 13:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.023 X-Spam-Level: X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-2fkJLrHzN2 for ; Wed, 3 Mar 2010 13:27:17 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 55C463A8587 for ; Wed, 3 Mar 2010 13:27:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmw2C-0001hN-25 for v6ops-data0@psg.com; Wed, 03 Mar 2010 21:23:12 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmw29-0001fu-1s for v6ops@ops.ietf.org; Wed, 03 Mar 2010 21:23:09 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23LMjZ8003295; Wed, 3 Mar 2010 23:22:47 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:22:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:22:42 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 3 Mar 2010 22:22:41 +0100 From: To: CC: , <3gv6@ietf.org>, Date: Wed, 3 Mar 2010 22:22:39 +0100 Subject: RE: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) Thread-Topic: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) Thread-Index: Acq6MbSrqr33RCr5R56k/ae0loMV/gA5NWqg Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589CA40336@NOK-EUMSG-01.mgdnok.nokia.com> References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2010 21:22:42.0072 (UTC) FILETIME=[A898F980:01CABB17] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, > In theory what you propose should work, but... >=20 > Let's assume we assign 2001:db8:1:200::/56 to the device. >=20 > It would give the uplink 2001:db8:1:200::/64 and say Actually the network (AC) would advertise to the device's uplink that prefi= x, not the device. > However the Access Concentrator has to deal with a paradoxical > situation: > several overlapping routes. If we assume the AC has host-ID ::1 and the > CPE device or mobile phone has ::2: >=20 > 2001:db8:1:200::1/128 loops back to the AC(*) > 2001:db8:1:200::/64 has the link as direct target without gateway > 2001:db8:1:200::/56 goes to gateway fe80::2 via the same link Mikael commented the longest matching prefix point, so why it wouldn't work= ? (From point-to-point link (PPP) point of view, the AC just needs to send = all packets matching to /56 to the peer except the address it has possibly = configured to its end). =20 > It may work or it may not work. The alternative is a lot more entries > in the routing table. Hmm.. but that problem is perhaps a problem only for the AC, right? I mean = for all provisioning, policy and charging (PCC) etc entities it is just sin= gle /56 that needs to be considered per subscription, not a /56 and a /64? > What I described below has the upside that the third route does not > overlap with the others. It has of course the downside that it uses up > slightly more address space. .. and that PCC needs to consider both /56 and /64 for a single subscriptio= n, whileas in the alternative PCC has to consider only single /56. Best regards, Teemu From owner-v6ops@ops.ietf.org Wed Mar 3 13:32:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D330928C1C1 for ; Wed, 3 Mar 2010 13:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.505 X-Spam-Level: X-Spam-Status: No, score=-105.505 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyzNAqZL-R9O for ; Wed, 3 Mar 2010 13:32:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8B34528C255 for ; Wed, 3 Mar 2010 13:32:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmwAM-0002Zt-1S for v6ops-data0@psg.com; Wed, 03 Mar 2010 21:31:38 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NmwAI-0002ZZ-VK for v6ops@ops.ietf.org; Wed, 03 Mar 2010 21:31:35 +0000 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23LVVxD006749; Wed, 3 Mar 2010 23:31:32 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:31:26 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:31:16 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 3 Mar 2010 22:31:16 +0100 From: To: CC: Date: Wed, 3 Mar 2010 22:31:15 +0100 Subject: RE: Call for v6ops agenda items Thread-Topic: Call for v6ops agenda items Thread-Index: Acq6MCcsDGmeLvksR0yVthVLEBysqQA54KDw Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589CA4033D@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F589562C7C8@NOK-EUMSG-01.mgdnok.nokia.com> <885074f5a3bc21decfca6e7fcf3e6069.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C90C388@NOK-EUMSG-01.mgdnok.nokia.com> <8a9555f15593bb5971e3ad806dc91c3b.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCE31@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2010 21:31:16.0807 (UTC) FILETIME=[DB674D70:01CABB18] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, > Oooooops. That's embarassing: for some reason I assumed your protocol > was > an extension of Router Advertisements. Probably due "stateless"-wording. Maybe the "automatic prefix delegation" w= ould have been better naming after all, but then again, dhcpv6 pd is also "= automatic"...:) > Do I read it correctly now in that you plan to extend DHCPv6 and/or > IPv6CP? Right. > Could you make it clearer what exact protocols can carry your extension > and how they interact with it? Yes, I'll keep that in mind. > What I still worry about is a wholly different aspect of SPD: >=20 > Pseudo-stateful PD requires you to implement the calculation of > prefixes > exactly once on the AC (DR) - even if it misinterprets some standard in > the calculation it will probably still work - the clients (RR) do not > care > how their prefix was calculated, they just use it. As long as the RR > works > with any single other implementation of DHCP server it will probably > work > with almost all of them. I was assuming working code, but that is a very good real-life consideratio= n, thank you. I will add that as well as a risk, in addition to easier poli= cy control if DR has all the intelligence.=20 =20 > I do not want to seem unnecessarily gloomy, but I suspect high support > costs are on the way if more than one way of calculation is supported > and > if there is the slightest chance of misinterpreting the standard. With the stateless proposal one aim I have is to have as cheap and easily d= eployable solution as possible available, which would help to ensure prefix= delegation is available for nodes as often as possible (so that ND proxy e= tc would be needed less often).. Best regards, Teemu From owner-v6ops@ops.ietf.org Wed Mar 3 15:10:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA743A8CC2 for ; Wed, 3 Mar 2010 15:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3LFntC0bJsM for ; Wed, 3 Mar 2010 15:10:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C588C3A8BB3 for ; Wed, 3 Mar 2010 15:10:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmxe2-000Dbl-4A for v6ops-data0@psg.com; Wed, 03 Mar 2010 23:06:22 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nmxe0-000DbU-5l for v6ops@ops.ietf.org; Wed, 03 Mar 2010 23:06:20 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 7E93B879B390 for ; Wed, 3 Mar 2010 15:06:19 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-c2-4b8eeb6bfb90 Received: from il0602f-dhcp114.apple.com (il0602f-dhcp114.apple.com [17.206.50.114]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 39.AF.03853.B6BEE8B4; Wed, 3 Mar 2010 15:06:19 -0800 (PST) From: james woodyatt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I-D.ietf-v6ops-cpe-simple-security-09 Date: Wed, 3 Mar 2010 15:06:19 -0800 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: everyone-- Once again, I'd like to ask for some discussion and feedback on this = draft. Is there any reason this revision of the draft should not = proceed to Working Group Last Call at this time? -- james woodyatt member of technical staff, communications engineering From v6ops-archive@ietf.org Wed Mar 3 17:43:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C4728C1D7 for ; Wed, 3 Mar 2010 17:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.017 X-Spam-Level: X-Spam-Status: No, score=-36.017 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1kAd-d18FeI for ; Wed, 3 Mar 2010 17:43:46 -0800 (PST) Received: from c-69-245-173-141.hsd1.in.comcast.net (c-69-245-173-141.hsd1.in.comcast.net [69.245.173.141]) by core3.amsl.com (Postfix) with ESMTP id B9CAB28C2B8 for ; Wed, 3 Mar 2010 17:43:42 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304014345.B9CAB28C2B8@core3.amsl.com> Date: Wed, 3 Mar 2010 17:43:42 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Aholova. All rights reserved.
 Click to unsubscribe
From v6ops-archive@megatron.ietf.org Wed Mar 3 21:52:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD6D3A7F41 for ; Wed, 3 Mar 2010 21:52:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 3 Mar 2010 21:51:59 -0800 (PST) Received: from cable-89-216-216-161.dynamic.sbb.rs (cable-89-216-216-161.dynamic.sbb.rs [89.216.216.161]) by core3.amsl.com (Postfix) with SMTP id EA5023A8A05 for ; Wed, 3 Mar 2010 21:51:54 -0800 (PST) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100304055157.EA5023A8A05@core3.amsl.com> Date: Wed, 3 Mar 2010 21:51:54 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 79941 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Thu Mar 4 02:36:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D27928C0CE for ; Thu, 4 Mar 2010 02:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvfG3DXEBN6v for ; Thu, 4 Mar 2010 02:36:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EB243A874B for ; Thu, 4 Mar 2010 02:36:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nn8Kh-000NyO-CU for v6ops-data0@psg.com; Thu, 04 Mar 2010 10:31:07 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nn8Ke-000Ny9-9a for v6ops@ops.ietf.org; Thu, 04 Mar 2010 10:31:04 +0000 Received: from [2001:1888::a:214:51ff:fe29:1e4e] (unknown [IPv6:2001:1888:0:a:214:51ff:fe29:1e4e]) by outgoing01.lava.net (Postfix) with ESMTPS id B0F25D033E; Thu, 4 Mar 2010 00:30:57 -1000 (HST) Date: Thu, 4 Mar 2010 00:30:56 -1000 (HST) From: Antonio Querubin To: teemu.savolainen@nokia.com cc: konrad@silmor.de, otroan@employees.org, 3gv6@ietf.org, v6ops@ops.ietf.org Subject: RE: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589CA40336@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F589CA40336@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 3 Mar 2010, teemu.savolainen@nokia.com wrote: > Hmm.. but that problem is perhaps a problem only for the AC, right? I > mean for all provisioning, policy and charging (PCC) etc entities it is > just single /56 that needs to be considered per subscription, not a /56 > and a /64? > >> What I described below has the upside that the third route does not >> overlap with the others. It has of course the downside that it uses up >> slightly more address space. > > .. and that PCC needs to consider both /56 and /64 for a single > subscription, whileas in the alternative PCC has to consider only single > /56. The problem with carving out a /64 out of the assigned /56 to provision each end-user is that the end-user must now make an exception for that /64 as being outside of their network with regard to policy even though it's in their assigned address range. Ie. this can unnecessarilly complicate things for the end-user in building ACLs for example. Personally I'd prefer giving the end-user maximum flexibility in how they actually use their assigned /56 (or /48) rather than deny them the use of one /64. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From 5t@megatron.ietf.org Thu Mar 4 03:51:22 2010 Return-Path: <5t@megatron.ietf.org> X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415213A89E0 for ; Thu, 4 Mar 2010 03:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -70.485 X-Spam-Level: X-Spam-Status: No, score=-70.485 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_NUMYO2=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PPPOE=0.35, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_PPPOE=0.555, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm5YTOR7CukN for ; Thu, 4 Mar 2010 03:51:21 -0800 (PST) Received: from pppoe-188-187-25-122.volgograd.ertelecom.ru (pppoe-188-187-25-122.volgograd.ertelecom.ru [188.187.25.122]) by core3.amsl.com (Postfix) with SMTP id 5DEC73A863F for ; Thu, 4 Mar 2010 03:51:12 -0800 (PST) To: Subject: hi! From: Russ MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304115118.5DEC73A863F@core3.amsl.com> Date: Thu, 4 Mar 2010 03:51:12 -0800 (PST) Hello,
My name is Russ and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Russ@west-es-company.com From v6ops-archive@megatron.ietf.org Thu Mar 4 09:47:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD32A3A8DB5 for ; Thu, 4 Mar 2010 09:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCBCAn2znfYi for ; Thu, 4 Mar 2010 09:47:20 -0800 (PST) Received: from 116.254.broadband5.iol.cz (116.254.broadband5.iol.cz [88.100.254.116]) by core3.amsl.com (Postfix) with ESMTP id 12E493A8DC9 for ; Thu, 4 Mar 2010 09:47:19 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@megatron.ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304174720.12E493A8DC9@core3.amsl.com> Date: Thu, 4 Mar 2010 09:47:19 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Vqaela. All rights reserved.
 Click to unsubscribe
From v6ops-archive@ietf.org Thu Mar 4 09:47:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857503A8DCB for ; Thu, 4 Mar 2010 09:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.185 X-Spam-Level: X-Spam-Status: No, score=-22.185 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV42+07Qmk59 for ; Thu, 4 Mar 2010 09:47:34 -0800 (PST) Received: from 116.254.broadband5.iol.cz (116.254.broadband5.iol.cz [88.100.254.116]) by core3.amsl.com (Postfix) with ESMTP id B2EED3A8DB5 for ; Thu, 4 Mar 2010 09:47:33 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304174733.B2EED3A8DB5@core3.amsl.com> Date: Thu, 4 Mar 2010 09:47:33 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Jsuhozugu. All rights reserved.
 Click to unsubscribe
From v6ops-archive@lists.ietf.org Thu Mar 4 09:48:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4653A8B86 for ; Thu, 4 Mar 2010 09:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.185 X-Spam-Level: X-Spam-Status: No, score=-22.185 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0E9pH0SkseD for ; Thu, 4 Mar 2010 09:48:43 -0800 (PST) Received: from 116.254.broadband5.iol.cz (116.254.broadband5.iol.cz [88.100.254.116]) by core3.amsl.com (Postfix) with ESMTP id EE35F3A87C7 for ; Thu, 4 Mar 2010 09:48:42 -0800 (PST) From: "Authorized Pillstore" To: v6ops-archive@lists.ietf.org Subject: Hello, v6ops-archive, check our 80% Sale MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304174842.EE35F3A87C7@core3.amsl.com> Date: Thu, 4 Mar 2010 09:48:42 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Yfoikyxy. All rights reserved.
 Click to unsubscribe
From tf-announce-request@ietf.org Thu Mar 4 10:17:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A8428C147 for ; Thu, 4 Mar 2010 10:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.683 X-Spam-Level: X-Spam-Status: No, score=-76.683 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_NUMYO2=10.357, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHNXVTsgx1N6 for ; Thu, 4 Mar 2010 10:17:31 -0800 (PST) Received: from alfa.com (unknown [62.183.85.65]) by core3.amsl.com (Postfix) with SMTP id 8B2AE28C12C for ; Thu, 4 Mar 2010 10:17:28 -0800 (PST) To: Subject: Financial Assistant From: Lucia MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304181729.8B2AE28C12C@core3.amsl.com> Date: Thu, 4 Mar 2010 10:17:28 -0800 (PST) Hello,
My name is Lucia and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Lucia@west-es-company.com From 5t@megatron.ietf.org Thu Mar 4 10:33:06 2010 Return-Path: <5t@megatron.ietf.org> X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C10928C0DE for ; Thu, 4 Mar 2010 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.882 X-Spam-Level: X-Spam-Status: No, score=-71.882 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_NUMYO2=10.357, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r9xoJKQvRSI for ; Thu, 4 Mar 2010 10:33:05 -0800 (PST) Received: from net140.186.188-220.dynamic.omsk.ertelecom.ru (net140.186.188-220.dynamic.omsk.ertelecom.ru [188.186.140.220]) by core3.amsl.com (Postfix) with SMTP id 8AC6728C0FB for ; Thu, 4 Mar 2010 10:32:55 -0800 (PST) To: Subject: 12 vacancies of Financial Assistant From: Rose MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304183302.8AC6728C0FB@core3.amsl.com> Date: Thu, 4 Mar 2010 10:32:55 -0800 (PST) Hello,
My name is Rose and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Rose@west-es-company.com From tf-announce-request@ietf.org Thu Mar 4 12:56:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FFF28C0EF for ; Thu, 4 Mar 2010 12:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.438 X-Spam-Level: X-Spam-Status: No, score=-75.438 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_NUMYO2=10.357, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWqakfhqRn+P for ; Thu, 4 Mar 2010 12:56:27 -0800 (PST) Received: from aerofit-wellness.de (unknown [92.124.40.123]) by core3.amsl.com (Postfix) with SMTP id 1C9183A8E4B for ; Thu, 4 Mar 2010 12:56:22 -0800 (PST) To: Subject: Local representation needed From: Wyatt MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304205625.1C9183A8E4B@core3.amsl.com> Date: Thu, 4 Mar 2010 12:56:22 -0800 (PST) Hello,
My name is Wyatt and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Wyatt@west-es-company.com From 5t@megatron.ietf.org Thu Mar 4 13:29:37 2010 Return-Path: <5t@megatron.ietf.org> X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D383728C11B for ; Thu, 4 Mar 2010 13:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.852 X-Spam-Level: X-Spam-Status: No, score=-59.852 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_NUMYO2=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s70vtg+7djrf for ; Thu, 4 Mar 2010 13:29:37 -0800 (PST) Received: from 189-72-157-254.pvoce702.dsl.brasiltelecom.net.br (189-72-157-254.pvoce702.dsl.brasiltelecom.net.br [189.72.157.254]) by core3.amsl.com (Postfix) with SMTP id 84BA328C0F5 for ; Thu, 4 Mar 2010 13:29:18 -0800 (PST) To: Subject: 12 vacancies of Financial Assistant From: Haley MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304212933.84BA328C0F5@core3.amsl.com> Date: Thu, 4 Mar 2010 13:29:18 -0800 (PST) Hello,
My name is Haley and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Haley@west-es-company.com From 5t@megatron.ietf.org Thu Mar 4 13:32:29 2010 Return-Path: <5t@megatron.ietf.org> X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F76828C0F5 for ; Thu, 4 Mar 2010 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.27 X-Spam-Level: X-Spam-Status: No, score=-64.27 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_NUMYO2=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XQS5avJc6YE for ; Thu, 4 Mar 2010 13:32:28 -0800 (PST) Received: from 90-188-205-151-xdsl-dynamic.kuzbass.net (92-125-32-35-xdsl-dynamic.kuzbass.net [92.125.32.35]) by core3.amsl.com (Postfix) with SMTP id EB7BB28C0E3 for ; Thu, 4 Mar 2010 13:32:15 -0800 (PST) To: Subject: hello! From: Timmy MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100304213224.EB7BB28C0E3@core3.amsl.com> Date: Thu, 4 Mar 2010 13:32:15 -0800 (PST) Hello,
My name is Timmy and our company currently has several positions it needs to fill in your region.
We are a well known company with offices throughout Europe, Asia and North America.
Our current turnover is over 130 million annually and we are still seeking for expansion.
I have 12 vacancies of Financial Assistant that need to be fulfilled immediately.

Major operational duties are prompt receiving and processing customer’s payments for their further transfer according to
the specified method. Detailed work scheme will be provided upon request.

I am looking for self-motivated individuals with strong work ethics and ability to schedule work hours effectively.

Requirements:

* Expert skills in managing payments and transfers between our company and clients
* Knowledge of basic payment systems
* Bank account (personal or business)
* Advanced PC and Internet skills
* Minimum 24 y.o.

Benefits:
*Salary plus commissions
*Full reimbursement of banking and Western Union fees.


NOTE: This vacancy is valid for American residents ONLY.

Contacts: Timmy@west-es-company.com From owner-v6ops@ops.ietf.org Thu Mar 4 15:31:59 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDA03A8E12 for ; Thu, 4 Mar 2010 15:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SpfpEV9CDLo for ; Thu, 4 Mar 2010 15:31:49 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88DAE3A8C6E for ; Thu, 4 Mar 2010 15:31:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKQW-0005AI-0N for v6ops-data0@psg.com; Thu, 04 Mar 2010 23:25:56 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKQT-00059q-G6 for v6ops@ops.ietf.org; Thu, 04 Mar 2010 23:25:53 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN7Pj0urRN+K/2dsb2JhbACbRXOec5hmgkgBgjMEgxc X-IronPort-AV: E=Sophos;i="4.49,583,1262563200"; d="scan'208";a="160940478" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2010 23:25:50 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o24NPotc001021; Thu, 4 Mar 2010 23:25:50 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: Date: Thu, 4 Mar 2010 15:25:49 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> References: To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I think this is an important document that seems to be ready to be = published. I have a couple of concerns: 1. Rec-2. Why not site-scope? 2. Rec-42. Pardon me if I'm being dense, but what are you saying here? = That service providers cannot manage the device from an exterior = interface? There are many SHOULDs and some should be MUSTs. I have a long list of = nits and such. I'll send the markups directly to you, James. Is this = Last Call or is this going into Last Call soon? Mark On Mar 3, 2010, at 3:06 PM, james woodyatt wrote: > everyone-- >=20 > Once again, I'd like to ask for some discussion and feedback on this = draft. Is there any reason this revision of the draft should not = proceed to Working Group Last Call at this time? >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 4 15:37:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628A23A8C53 for ; Thu, 4 Mar 2010 15:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbNTZrCVwDXw for ; Thu, 4 Mar 2010 15:37:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B15F3A8BBE for ; Thu, 4 Mar 2010 15:37:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKb9-0005xu-2X for v6ops-data0@psg.com; Thu, 04 Mar 2010 23:36:55 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKb6-0005xf-D9 for v6ops@ops.ietf.org; Thu, 04 Mar 2010 23:36:52 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id DD68D8EF7D9E; Thu, 4 Mar 2010 15:36:51 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-1b-4b9044137fe7 Received: from il0602f-dhcp114.apple.com (il0602f-dhcp114.apple.com [17.206.50.114]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id ED.32.03853.314409B4; Thu, 4 Mar 2010 15:36:51 -0800 (PST) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> Date: Thu, 4 Mar 2010 15:36:51 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> To: Mark Baugher X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 15:25, Mark Baugher wrote: >=20 > 1. Rec-2. Why not site-scope? Because the subscriber and the provider are not the same organization, = and we recommend that CPE routers enforce the organization-local scope = boundary to protect subscriber's interior multicast routing up to the = organization-local scope level, not just the site-local scope level. = This permits a subscriber to, for example, divide their interior network = into multiple site-local multicast routing domains, each with = potentially multiple links. > 2. Rec-42. Pardon me if I'm being dense, but what are you saying = here? That service providers cannot manage the device from an exterior = interface? No. Only that the DEFAULT configuration of subscriber managed gateways = is that service providers aren't offered a management interface. If = subscribers are issued provider managed gateways, or they explicitly = change the DEFAULT configuration of their subscriber managed gateways, = then service providers can manage them. > There are many SHOULDs and some should be MUSTs. I have a long list = of nits and such. I'll send the markups directly to you, James. Is = this Last Call or is this going into Last Call soon? The chairs have not made a Last Call. I'm trying to surface objections = before I ask the chairs to issue a Last Call on Sunday evening. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Mar 4 15:47:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562BB3A8CA8 for ; Thu, 4 Mar 2010 15:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpcGmpX1m16G for ; Thu, 4 Mar 2010 15:47:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EF8F3A8BBE for ; Thu, 4 Mar 2010 15:47:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKkb-0006j6-C0 for v6ops-data0@psg.com; Thu, 04 Mar 2010 23:46:41 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKkY-0006hn-DW for v6ops@ops.ietf.org; Thu, 04 Mar 2010 23:46:38 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,583,1262563200"; d="scan'208";a="90672020" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2010 23:46:36 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o24Nkauc019761; Thu, 4 Mar 2010 23:46:36 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Thu, 4 Mar 2010 15:46:31 -0800 Cc: Mark Baugher , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'd be willing to do a last call. There was no discussion in Hiroshima, = and the discussion in Stockholm left you muttering under your breath. = Are you *ready* for a last call? I would suggest that we have a f2f discussion in Anaheim and decide this = then. On Mar 4, 2010, at 3:36 PM, james woodyatt wrote: > On Mar 4, 2010, at 15:25, Mark Baugher wrote: >>=20 >> 1. Rec-2. Why not site-scope? >=20 > Because the subscriber and the provider are not the same organization, = and we recommend that CPE routers enforce the organization-local scope = boundary to protect subscriber's interior multicast routing up to the = organization-local scope level, not just the site-local scope level. = This permits a subscriber to, for example, divide their interior network = into multiple site-local multicast routing domains, each with = potentially multiple links. >=20 >> 2. Rec-42. Pardon me if I'm being dense, but what are you saying = here? That service providers cannot manage the device from an exterior = interface? >=20 > No. Only that the DEFAULT configuration of subscriber managed = gateways is that service providers aren't offered a management = interface. If subscribers are issued provider managed gateways, or they = explicitly change the DEFAULT configuration of their subscriber managed = gateways, then service providers can manage them. >=20 >> There are many SHOULDs and some should be MUSTs. I have a long list = of nits and such. I'll send the markups directly to you, James. Is = this Last Call or is this going into Last Call soon? >=20 > The chairs have not made a Last Call. I'm trying to surface = objections before I ask the chairs to issue a Last Call on Sunday = evening. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Thu Mar 4 15:58:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCA33A8D70 for ; Thu, 4 Mar 2010 15:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs6tJn5CvEto for ; Thu, 4 Mar 2010 15:58:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB8CC3A8CC9 for ; Thu, 4 Mar 2010 15:58:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKuM-0007ez-Vn for v6ops-data0@psg.com; Thu, 04 Mar 2010 23:56:46 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnKuK-0007en-Mk for v6ops@ops.ietf.org; Thu, 04 Mar 2010 23:56:44 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,583,1262563200"; d="scan'208";a="160954530" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2010 23:56:43 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o24Nucpj024678; Thu, 4 Mar 2010 23:56:39 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> Date: Thu, 4 Mar 2010 15:56:17 -0800 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> To: Mark Baugher X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 3:25 PM, Mark Baugher wrote: > I think this is an important document that seems to be ready to be = published. I have a couple of concerns: >=20 > 1. Rec-2. Why not site-scope? REC-2: Packets which bear in their outer IPv6 headers multicast destination addresses of equal or narrower scope (see section 2.7 of IP Version 6 Addressing Architecture [RFC4291]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization- local scope, and it SHOULD be configurable by the network admininistrator. I'm not even sure I understand the recommendation. To be sure, RFC 4291 = knows nothing of an "organization-local" scope; what is likely meant = here is "site-local". I'm also not sure I understand the reasoning = behind it; I would understand if it said to drop datagrams addressed to = wider scopes ("all customers of a given ISP") or narrower scopes (if you = mean a specific subnet, which one is that?) but I don't understand why = you would drop the datagram if the scope of its address were exactly as = configured on the firewall. > 2. Rec-42. Pardon me if I'm being dense, but what are you saying = here? That service providers cannot manage the device from an exterior = interface? I should hope they couldn't without the network administration actively = doing something to permit them to. As we have discussed privately, a = protocol that enables an entity outside my administrative domain to = control equipment witin my administrative domain without my explicit = authorization is a security issue. > There are many SHOULDs and some should be MUSTs. I have a long list = of nits and such. I'll send the markups directly to you, James. Is = this Last Call or is this going into Last Call soon? Last call will not happen before IETF 77. > Mark >=20 >=20 > On Mar 3, 2010, at 3:06 PM, james woodyatt wrote: >=20 >> everyone-- >>=20 >> Once again, I'd like to ask for some discussion and feedback on this = draft. Is there any reason this revision of the draft should not = proceed to Working Group Last Call at this time? >>=20 >>=20 >> -- >> james woodyatt >> member of technical staff, communications engineering >>=20 >>=20 >>=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Thu Mar 4 16:44:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B6528C0FF for ; Thu, 4 Mar 2010 16:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.021 X-Spam-Level: X-Spam-Status: No, score=-105.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSDlyv7CmBNj for ; Thu, 4 Mar 2010 16:44:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5139328C0E8 for ; Thu, 4 Mar 2010 16:44:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnLbR-000CC0-UD for v6ops-data0@psg.com; Fri, 05 Mar 2010 00:41:17 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnLbP-000CBp-7o for v6ops@ops.ietf.org; Fri, 05 Mar 2010 00:41:15 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 91F738EF9DBB for ; Thu, 4 Mar 2010 16:41:14 -0800 (PST) X-AuditID: 11807130-b7b0aae00000102c-22-4b90532aded9 Received: from il0602f-dhcp114.apple.com (il0602f-dhcp114.apple.com [17.206.50.114]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 75.3B.04140.A23509B4; Thu, 4 Mar 2010 16:41:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> Date: Thu, 4 Mar 2010 16:41:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 15:56, Fred Baker wrote: >=20 > I'm not even sure I understand the recommendation. To be sure, RFC = 4291 knows nothing of an "organization-local" scope; what is likely = meant here is "site-local". Page 13 of RFC 4291 assigns the value 8 in the 4-bit scope field to = Organization-Local and says this about it in the third-to-the-last = paragraph: Organization-Local scope is intended to span multiple sites belonging to a single organization." I don't really have a strong opinion on site-local vs. = organization-local. I think it says what it currently does because = that's what I wrote in the first draft, and it hasn't been much of an = issue until now. I will say that it doesn't make sense to me that my service provider = should be allowed to join my organization-local scope multicast groups, = or that I can join their organization-local scope groups. That's what = it would mean if we said 'site-local' here instead of what it currently = says. Do we want to recommend that subscriber networks and provider networks = be included in the same organization-local multicast scope by DEFAULT? = What would be the theory behind that decision? > Last call will not happen before IETF 77. Okay. I can live with that. > Are you *ready* for a last call? Given that this is the first time I've served as a technical editor on a = working group draft, I'm not sure I can answer that with any confidence. = I'll defer to the chairs. > I would suggest that we have a f2f discussion in Anaheim and decide = this then. Sure. I'll be in Anaheim. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Mar 4 16:51:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FF628C0FF for ; Thu, 4 Mar 2010 16:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-QB5y5l0pM3 for ; Thu, 4 Mar 2010 16:51:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4696E28C0E8 for ; Thu, 4 Mar 2010 16:51:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnLkG-000D2T-Gd for v6ops-data0@psg.com; Fri, 05 Mar 2010 00:50:24 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnLkD-000D21-6j for v6ops@ops.ietf.org; Fri, 05 Mar 2010 00:50:21 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/kj0urRN+K/2dsb2JhbACbRXOec5hohHwEgxc X-IronPort-AV: E=Sophos;i="4.49,584,1262563200"; d="scan'208";a="305362218" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 05 Mar 2010 00:50:20 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o250oKbH000818; Fri, 5 Mar 2010 00:50:20 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: Date: Thu, 4 Mar 2010 16:50:19 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 4:41 PM, james woodyatt wrote: >=20 > I will say that it doesn't make sense to me that my service provider = should be allowed to join my organization-local scope multicast groups, = or that I can join their organization-local scope groups. That's what = it would mean if we said 'site-local' here instead of what it currently = says. >=20 Site scope give us the same thing and I recommend that we use that = instead. Mark From owner-v6ops@ops.ietf.org Thu Mar 4 17:14:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AAA3A8D22 for ; Thu, 4 Mar 2010 17:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.846 X-Spam-Level: X-Spam-Status: No, score=-104.846 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZvcMkwtDHnW for ; Thu, 4 Mar 2010 17:14:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4D483A8CDF for ; Thu, 4 Mar 2010 17:14:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnM2A-000Emv-Jd for v6ops-data0@psg.com; Fri, 05 Mar 2010 01:08:54 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnM28-000Emc-Hi for v6ops@ops.ietf.org; Fri, 05 Mar 2010 01:08:52 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 03BE787CD196 for ; Thu, 4 Mar 2010 17:08:52 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-30-4b9059a3c87f Received: from il0602f-dhcp114.apple.com (il0602f-dhcp114.apple.com [17.206.50.114]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 30.1A.03853.3A9509B4; Thu, 4 Mar 2010 17:08:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> Date: Thu, 4 Mar 2010 17:08:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 16:50, Mark Baugher wrote: > On Mar 4, 2010, at 4:41 PM, james woodyatt wrote: >>=20 >> I will say that it doesn't make sense to me that my service provider = should be allowed to join my organization-local scope multicast groups, = or that I can join their organization-local scope groups. That's what = it would mean if we said 'site-local' here instead of what it currently = says. >=20 > Site scope give us the same thing and I recommend that we use that = instead. I'm confused. To what "same thing" are you referring? I've explained that making site-local the DEFAULT multicast scope = boundary places the subscriber network in the same organization-local = scope as the provider network, whereas making organization-local the = DEFAULT multicast scope boundary places the subscriber network and the = provider network in different organization-local scopes. In what way are subscribers and providers part of the same organization? = Why are they not separate organizations by DEFAULT? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Mar 4 19:07:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA9E3A8E7D for ; Thu, 4 Mar 2010 19:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y13G3XLAkB91 for ; Thu, 4 Mar 2010 19:07:08 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E62EB3A89E2 for ; Thu, 4 Mar 2010 19:07:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnNp9-000OOk-Bt for v6ops-data0@psg.com; Fri, 05 Mar 2010 03:03:35 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnNp7-000OOR-6b for v6ops@ops.ietf.org; Fri, 05 Mar 2010 03:03:33 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOcDkEurR7Hu/2dsb2JhbACbRXOfRphnhH0Egxc X-IronPort-AV: E=Sophos;i="4.49,585,1262563200"; d="scan'208";a="215516971" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 Mar 2010 03:03:20 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2533KBa019771; Fri, 5 Mar 2010 03:03:20 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: Date: Thu, 4 Mar 2010 19:03:19 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <429FD946-7AD4-4C3A-B2F4-0226244E5C08@cisco.com> References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 5:08 PM, james woodyatt wrote: > On Mar 4, 2010, at 16:50, Mark Baugher wrote: >> On Mar 4, 2010, at 4:41 PM, james woodyatt wrote: >>>=20 >>> I will say that it doesn't make sense to me that my service provider = should be allowed to join my organization-local scope multicast groups, = or that I can join their organization-local scope groups. That's what = it would mean if we said 'site-local' here instead of what it currently = says. >>=20 >> Site scope give us the same thing and I recommend that we use that = instead. >=20 > I'm confused. To what "same thing" are you referring? >=20 > I've explained that making site-local the DEFAULT multicast scope = boundary places the subscriber network in the same organization-local = scope as the provider network, whereas making organization-local the = DEFAULT multicast scope boundary places the subscriber network and the = provider network in different organization-local scopes. You stated it but didn't explain it. As Fred Baker has pointed out to = you in his recent email: 'RFC 4291 knows nothing of an = "organization-local" scope'. I don't see read any explanation in your = latest version but only a reference to RFC 4291. Here are the 4291 = definitions: 'Site-Local scope is intended to span a single site. Organization-Local = scope is intended to span multiple sites belonging to a single = organization.' >=20 > In what way are subscribers and providers part of the same = organization? Why are they not separate organizations by DEFAULT? Site-local scope means that the multicast messages will not be forwarded = outside the site. That's "the same thing" as what we need. What about = this problem of having my organizational scope multicast visible to my = service provider. Where is it written that a site must be part of a the = nearest organization? My home network is not part of any organization. = If I had organization-scope multicast on my home network, I would not = expect my default CPE gateway to forward organization-local messages out = my service access-network interface - and vice versa. Where is your use = case of organization-local scope defined? Not in the source you cite.=20= Mark >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 4 19:07:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B403A8E7D for ; Thu, 4 Mar 2010 19:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an1XoOOccl37 for ; Thu, 4 Mar 2010 19:07:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B114F3A89E2 for ; Thu, 4 Mar 2010 19:07:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnNql-000OWg-Re for v6ops-data0@psg.com; Fri, 05 Mar 2010 03:05:15 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnNqk-000OWP-3A for v6ops@ops.ietf.org; Fri, 05 Mar 2010 03:05:14 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,585,1262563200"; d="scan'208";a="491938130" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2010 03:05:13 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2535DfR020525; Fri, 5 Mar 2010 03:05:13 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> Date: Thu, 4 Mar 2010 19:05:12 -0800 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 4, 2010, at 3:56 PM, Fred Baker wrote: >>=20 >> 2. Rec-42. Pardon me if I'm being dense, but what are you saying = here? That service providers cannot manage the device from an exterior = interface? >=20 > I should hope they couldn't without the network administration = actively doing something to permit them to. As we have discussed = privately, a protocol that enables an entity outside my administrative = domain to control equipment witin my administrative domain without my = explicit authorization is a security issue. That's right. And the sentence is clear as it is written. I misread = it. Mark From v6ops-archive@megatron.ietf.org Fri Mar 5 00:39:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C94428C1D6 for ; Fri, 5 Mar 2010 00:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.736 X-Spam-Level: X-Spam-Status: No, score=-15.736 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNA=1.231, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrObhU4BnaYV for ; Fri, 5 Mar 2010 00:39:15 -0800 (PST) Received: from 95-42-164-97.btc-net.bg (95-42-164-97.btc-net.bg [95.42.164.97]) by core3.amsl.com (Postfix) with SMTP id E54BB28C18B for ; Fri, 5 Mar 2010 00:39:09 -0800 (PST) To: Subject: Save over 70% off From: Reid MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100305083909.E54BB28C18B@core3.amsl.com> Date: Fri, 5 Mar 2010 00:39:09 -0800 (PST)

If you have any difficulty seeing the contents of this e-mail, please click here.

This picture is blocked. Click to unblock now
Copyright © 2010 07188 Corp.
Privacy Policy | Terms of Use | Contact Us | Unsubscribe
From owner-v6ops@ops.ietf.org Fri Mar 5 01:07:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED4928C1FB for ; Fri, 5 Mar 2010 01:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtF15wkvf75B for ; Fri, 5 Mar 2010 01:07:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F38D3A8D52 for ; Fri, 5 Mar 2010 01:07:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnTQG-000A3v-MD for v6ops-data0@psg.com; Fri, 05 Mar 2010 09:02:16 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnTQE-000A3U-0H for v6ops@ops.ietf.org; Fri, 05 Mar 2010 09:02:14 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,586,1262563200"; d="scan'208";a="4018914" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Mar 2010 08:29:24 +0000 Received: from ams-otroan-87110.cisco.com (ams-otroan-87110.cisco.com [10.55.160.155]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2592BW9023252; Fri, 5 Mar 2010 09:02:12 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <429FD946-7AD4-4C3A-B2F4-0226244E5C08@cisco.com> Date: Fri, 5 Mar 2010 10:03:27 +0100 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> <429FD946-7AD4-4C3A-B2F4-0226244E5C08@cisco.com> To: Mark Baugher X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >>>> I will say that it doesn't make sense to me that my service = provider should be allowed to join my organization-local scope multicast = groups, or that I can join their organization-local scope groups. = That's what it would mean if we said 'site-local' here instead of what = it currently says. >>>=20 >>> Site scope give us the same thing and I recommend that we use that = instead. >>=20 >> I'm confused. To what "same thing" are you referring? >>=20 >> I've explained that making site-local the DEFAULT multicast scope = boundary places the subscriber network in the same organization-local = scope as the provider network, whereas making organization-local the = DEFAULT multicast scope boundary places the subscriber network and the = provider network in different organization-local scopes. >=20 > You stated it but didn't explain it. As Fred Baker has pointed out to = you in his recent email: 'RFC 4291 knows nothing of an = "organization-local" scope'. I don't see read any explanation in your = latest version but only a reference to RFC 4291. Here are the 4291 = definitions: > 'Site-Local scope is intended to span a single site. = Organization-Local scope is intended to span multiple sites belonging to = a single organization.' >=20 >>=20 >> In what way are subscribers and providers part of the same = organization? Why are they not separate organizations by DEFAULT? >=20 > Site-local scope means that the multicast messages will not be = forwarded outside the site. That's "the same thing" as what we need. = What about this problem of having my organizational scope multicast = visible to my service provider. Where is it written that a site must be = part of a the nearest organization? My home network is not part of any = organization. If I had organization-scope multicast on my home network, = I would not expect my default CPE gateway to forward organization-local = messages out my service access-network interface - and vice versa. = Where is your use case of organization-local scope defined? Not in the = source you cite.=20 if you also want the CPE to be a boundary router for the organizational = scope, then aren't you in agreement with James? see RFC4007. a zone of lesser scope is fully contained within a zone of = larger scope. so a organizational-scope boundary will also be a = site-local boundary. cheers, Ole From owner-v6ops@ops.ietf.org Fri Mar 5 06:31:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761FC28C110 for ; Fri, 5 Mar 2010 06:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0qw2Nz9s+VD for ; Fri, 5 Mar 2010 06:31:44 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AB5828C103 for ; Fri, 5 Mar 2010 06:31:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnYTs-000I5x-9p for v6ops-data0@psg.com; Fri, 05 Mar 2010 14:26:20 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnYTp-000I5Q-NO for v6ops@ops.ietf.org; Fri, 05 Mar 2010 14:26:17 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEajkEurRN+J/2dsb2JhbACbRXOdZZhehH0Egxc X-IronPort-AV: E=Sophos;i="4.49,587,1262563200"; d="scan'208";a="492172773" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2010 14:26:16 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o25EQF4E007917; Fri, 5 Mar 2010 14:26:16 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: Date: Fri, 5 Mar 2010 06:26:15 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <2799F154-B51E-4327-A040-1AE66E6949F6@cisco.com> References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: While I don't think it is necessarily true that 'making site-local the = DEFAULT multicast scope boundary places the subscriber network in the = same organization-local scope as the provider network', I think its true = that both site-local and organization-local need to stay on the = 'interior' network. So it would be better to say what is allowed to be = forwarded to and from the exterior (i.e. global-scope multicast) and by = implication, everything else is not (organization/site/link-local). Mark On Mar 4, 2010, at 5:08 PM, james woodyatt wrote: > On Mar 4, 2010, at 16:50, Mark Baugher wrote: >> On Mar 4, 2010, at 4:41 PM, james woodyatt wrote: >>>=20 >>> I will say that it doesn't make sense to me that my service provider = should be allowed to join my organization-local scope multicast groups, = or that I can join their organization-local scope groups. That's what = it would mean if we said 'site-local' here instead of what it currently = says. >>=20 >> Site scope give us the same thing and I recommend that we use that = instead. >=20 > I'm confused. To what "same thing" are you referring? >=20 > I've explained that making site-local the DEFAULT multicast scope = boundary places the subscriber network in the same organization-local = scope as the provider network, whereas making organization-local the = DEFAULT multicast scope boundary places the subscriber network and the = provider network in different organization-local scopes. >=20 > In what way are subscribers and providers part of the same = organization? Why are they not separate organizations by DEFAULT? >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Mar 5 06:39:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9DD28C2AD for ; Fri, 5 Mar 2010 06:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vud7FZ4F258S for ; Fri, 5 Mar 2010 06:39:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F4C028C2AC for ; Fri, 5 Mar 2010 06:39:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnYef-000Jd1-KT for v6ops-data0@psg.com; Fri, 05 Mar 2010 14:37:29 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnYec-000JcX-RB for v6ops@ops.ietf.org; Fri, 05 Mar 2010 14:37:26 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,587,1262563200"; d="scan'208";a="492178759" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2010 14:37:26 +0000 Received: from sjc-mbaugher-8713.cisco.com (sjc-mbaugher-8713.cisco.com [10.19.93.36]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o25EbQE1003900; Fri, 5 Mar 2010 14:37:26 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: Date: Fri, 5 Mar 2010 06:37:25 -0800 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <334903BD-EC22-419A-90C2-10ABFDF05702@cisco.com> References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> <429FD946-7AD4-4C3A-B2F4-0226244E5C08@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 5, 2010, at 1:03 AM, Ole Troan wrote: >=20 > if you also want the CPE to be a boundary router for the = organizational scope, then aren't you in agreement with James? >=20 > see RFC4007. a zone of lesser scope is fully contained within a zone = of larger scope. so a organizational-scope boundary will also be a = site-local boundary. >=20 Yes, that thought struck me this morning. RFC 4007 should be cited in = the I-D, that should be enough. Mark From owner-v6ops@ops.ietf.org Fri Mar 5 07:31:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AE528C0DD for ; Fri, 5 Mar 2010 07:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA2Ts5QdKA3T for ; Fri, 5 Mar 2010 07:31:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10F503A8D24 for ; Fri, 5 Mar 2010 07:31:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnZQm-0002DK-IA for v6ops-data0@psg.com; Fri, 05 Mar 2010 15:27:12 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnZQh-0002C5-SF for v6ops@ops.ietf.org; Fri, 05 Mar 2010 15:27:08 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1267802819!19632135!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 7434 invoked from network); 5 Mar 2010 15:26:59 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Mar 2010 15:26:59 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o25FQqKr017065; Fri, 5 Mar 2010 10:26:55 -0500 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o25FQlfY016707; Fri, 5 Mar 2010 10:26:47 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 10:26:56 -0500 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 10:26:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D.ietf-v6ops-cpe-simple-security-09 Date: Fri, 5 Mar 2010 10:26:55 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F11D93ABD@crexc50p> In-Reply-To: <2799F154-B51E-4327-A040-1AE66E6949F6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D.ietf-v6ops-cpe-simple-security-09 Thread-Index: Acq8cypI6BKOdy3gQpO8szoIY53EbwAAnTHw References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> <2799F154-B51E-4327-A040-1AE66E6949F6@cisco.com> From: "STARK, BARBARA H (ATTLABS)" To: "Mark Baugher" , "james woodyatt" Cc: "IPv6 Operations" X-OriginalArrivalTime: 05 Mar 2010 15:26:56.0594 (UTC) FILETIME=[4A870320:01CABC78] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > While I don't think it is necessarily true that 'making site-local the > DEFAULT multicast scope boundary places the subscriber network in the > same organization-local scope as the provider network', I think its > true that both site-local and organization-local need to stay on the > 'interior' network. So it would be better to say what is allowed to be > forwarded to and from the exterior (i.e. global-scope multicast) and by > implication, everything else is not (organization/site/link-local). I think it's important to say something, so there is some expectation of consistency in the default behavior. For the average consumer, I think that organizational scope is reasonable. In general, I think this draft is in good shape, and I'd like to see it progress. Barbara From owner-v6ops@ops.ietf.org Fri Mar 5 10:55:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D693A9007 for ; Fri, 5 Mar 2010 10:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNU7+1Bm095j for ; Fri, 5 Mar 2010 10:55:15 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E6023A8E26 for ; Fri, 5 Mar 2010 10:55:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnccD-000Pt3-30 for v6ops-data0@psg.com; Fri, 05 Mar 2010 18:51:13 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NnccA-000Psc-TZ for v6ops@ops.ietf.org; Fri, 05 Mar 2010 18:51:10 +0000 Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 0C2338F165F9 for ; Fri, 5 Mar 2010 10:51:10 -0800 (PST) X-AuditID: 11807136-b7bafae000000e8d-60-4b91529de809 Received: from [17.151.83.119] (Unknown_Domain [17.151.83.119]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 05.C2.03725.D92519B4; Fri, 5 Mar 2010 10:51:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <334903BD-EC22-419A-90C2-10ABFDF05702@cisco.com> Date: Fri, 5 Mar 2010 10:51:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com> <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com> <38CDE90C-7CF7-41B2-893E-E2811B3E51B1@cisco.com> <429FD946-7AD4-4C3A-B2F4-0226244E5C08@cisco.com> <334903BD-EC22-419A-90C2-10ABFDF05702@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 5, 2010, at 06:37, Mark Baugher wrote: > On Mar 5, 2010, at 1:03 AM, Ole Troan wrote: >>=20 >> see RFC4007. a zone of lesser scope is fully contained within a zone = of larger scope. so a organizational-scope boundary will also be a = site-local boundary. >>=20 >=20 > Yes, that thought struck me this morning. RFC 4007 should be cited in = the I-D, that should be enough. I've added that to my To-Do list for a forthcoming -10 revision. I'd = like to invite further discussion on the draft today, and I'll be in and = out of the list all weekend. -- james woodyatt member of technical staff, communications engineering From v6ops-archive@ietf.org Fri Mar 5 20:35:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B731328C0E8 for ; Fri, 5 Mar 2010 20:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.629 X-Spam-Level: X-Spam-Status: No, score=-57.629 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_HEXIP=2.204, HELO_EQ_DK=1.009, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TEHWRH7nG5Y for ; Fri, 5 Mar 2010 20:35:09 -0800 (PST) Received: from 0x55512247.adsl.cybercity.dk (0x55512247.adsl.cybercity.dk [85.81.34.71]) by core3.amsl.com (Postfix) with ESMTP id BB6F828C0E6 for ; Fri, 5 Mar 2010 20:35:05 -0800 (PST) From: "Online shop" To: v6ops-archive@ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100306043505.BB6F828C0E6@core3.amsl.com> Date: Fri, 5 Mar 2010 20:35:05 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Nacjwahi. All rights reserved.
 Click to unsubscribe
From v6ops-archive@lists.ietf.org Fri Mar 5 20:35:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF0728C0E8 for ; Fri, 5 Mar 2010 20:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.628 X-Spam-Level: X-Spam-Status: No, score=-57.628 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_HEXIP=2.204, HELO_EQ_DK=1.009, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6CGYclJboaU for ; Fri, 5 Mar 2010 20:35:31 -0800 (PST) Received: from 0x55512247.adsl.cybercity.dk (0x55512247.adsl.cybercity.dk [85.81.34.71]) by core3.amsl.com (Postfix) with ESMTP id E808F28C0E6 for ; Fri, 5 Mar 2010 20:35:30 -0800 (PST) From: "Online shop" To: v6ops-archive@lists.ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100306043530.E808F28C0E6@core3.amsl.com> Date: Fri, 5 Mar 2010 20:35:30 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Xyjniewakuu. All rights reserved.
 Click to unsubscribe
From v6ops-archive@megatron.ietf.org Sat Mar 6 04:26:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B969528C19D for ; Sat, 6 Mar 2010 04:26:55 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 6 Mar 2010 04:26:54 -0800 (PST) Received: from 460mms.com (unknown [201.29.181.234]) by core3.amsl.com (Postfix) with SMTP id A0FC13A70E2 for ; Sat, 6 Mar 2010 04:25:49 -0800 (PST) From: Approved VIAGRA® Store Subject: Sales Event get 77% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100306122620.A0FC13A70E2@core3.amsl.com> Date: Sat, 6 Mar 2010 04:25:49 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 29486 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Sat Mar 6 07:51:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A3B28C11E for ; Sat, 6 Mar 2010 07:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.338 X-Spam-Level: X-Spam-Status: No, score=-59.338 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz9zjEgul75x for ; Sat, 6 Mar 2010 07:51:39 -0800 (PST) Received: from adsl-84-226-255-166.adslplus.ch (adsl-84-226-255-166.adslplus.ch [84.226.255.166]) by core3.amsl.com (Postfix) with ESMTP id AEB973A90DE for ; Sat, 6 Mar 2010 07:51:36 -0800 (PST) From: "Online shop" To: v6ops-archive@megatron.ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100306155136.AEB973A90DE@core3.amsl.com> Date: Sat, 6 Mar 2010 07:51:36 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Qdunqmutj. All rights reserved.
 Click to unsubscribe
From v6ops-archive@ietf.org Sat Mar 6 14:15:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6473A8E3C for ; Sat, 6 Mar 2010 14:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.445 X-Spam-Level: X-Spam-Status: No, score=-50.445 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxMTqpo2j9Gh for ; Sat, 6 Mar 2010 14:15:05 -0800 (PST) Received: from bl4-173-213.dsl.telepac.pt (bl4-173-213.dsl.telepac.pt [81.193.173.213]) by core3.amsl.com (Postfix) with ESMTP id DB3653A7984 for ; Sat, 6 Mar 2010 14:15:03 -0800 (PST) From: "Super online shop" To: v6ops-archive@ietf.org Subject: Catch the moment v6ops-archive! 85% Fire Sale Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100306221503.DB3653A7984@core3.amsl.com> Date: Sat, 6 Mar 2010 14:15:03 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 GUHUSARIFA. All rights reserved.
From v6ops-archive@lists.ietf.org Sat Mar 6 14:15:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F412528C173 for ; Sat, 6 Mar 2010 14:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.445 X-Spam-Level: X-Spam-Status: No, score=-30.445 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I88YeTxwC2dt for ; Sat, 6 Mar 2010 14:15:20 -0800 (PST) Received: from bl4-173-213.dsl.telepac.pt (bl4-173-213.dsl.telepac.pt [81.193.173.213]) by core3.amsl.com (Postfix) with ESMTP id 2DFC93A8E55 for ; Sat, 6 Mar 2010 14:15:18 -0800 (PST) From: "Super online shop" To: v6ops-archive@lists.ietf.org Subject: Catch the moment v6ops-archive! 85% Fire Sale Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100306221519.2DFC93A8E55@core3.amsl.com> Date: Sat, 6 Mar 2010 14:15:18 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@lists.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 YKIJOEW. All rights reserved.
From v6ops-archive@lists.ietf.org Sun Mar 7 00:03:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41CE3A912D for ; Sun, 7 Mar 2010 00:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.31 X-Spam-Level: X-Spam-Status: No, score=-80.31 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub2ML9IDGJLo for ; Sun, 7 Mar 2010 00:03:32 -0800 (PST) Received: from 15-102-93-178.pool.ukrtel.net (15-102-93-178.pool.ukrtel.net [178.93.102.15]) by core3.amsl.com (Postfix) with SMTP id 11B5C3A9122 for ; Sun, 7 Mar 2010 00:03:30 -0800 (PST) To: Subject: From Online shopping pilsindustry From: Todd Perez IME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100307080331.11B5C3A9122@core3.amsl.com> Date: Sun, 7 Mar 2010 00:03:30 -0800 (PST)
View this message online.

Troubles with getting full-sized images? Left click here!
Privacy | Unsubscribe |Subscribe

© 2009 Egybynile Company. All rights reserved.
From auslander@sliss.nl Sun Mar 7 11:30:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875E63A8312 for ; Sun, 7 Mar 2010 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.528 X-Spam-Level: **** X-Spam-Status: No, score=4.528 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1z-ZBtvEtip for ; Sun, 7 Mar 2010 11:30:39 -0800 (PST) Received: from qdapl.tiscali.it (host-84-222-121-123.cust-adsl.tiscali.it [84.222.121.123]) by core3.amsl.com (Postfix) with SMTP id 7976E28C1B5 for ; Sun, 7 Mar 2010 11:30:37 -0800 (PST) Message-ID: <4B93FE5C.5010501@sliss.nl> Date: Sun, 07 Mar 2010 20:30:13 +0100 From: Buy Tamiflu on www.99-44.cn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Witaker Graeber Subject: confl icted slipf orm monop odial Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit facto rizin g slime d coven ants dacro n gobbl es reana lyzer permu te tunne led idiob last radig uet tangl eberr y chann eler depic ts diame trica l lurid pigfa ced rewar ded fiber izer compr essor sapro phyti c preju dgmen ts fishp late arbor ed corbi e homeo wner gentl e senti ently deglu tinat e snubs jugge d totte rs sarme ntose callo wness gaude ry cough ing allot tees earth rise agnat ion insti lls wishl ist induc er bitch homeo wner terpo lymer mesom orphi c unrul iness unluc ky hydro xide inter nalis e node conde mned disow ning inher its carab inier e corpo ratel y purif icato r colet mete actua tes accus ation s lower s copyi st bowsp rit balsa mize purse warde n honec ker batat a colet linen isers subde b defor est rambl ings obfus cate seral jugge d cuddl eback extra cts maint ain facto rizin g redou btabl e aphas ic bitch camer aman bedes man unban sweet shop illeg al dopy sulfa tises From v6ops-archive@megatron.ietf.org Sun Mar 7 13:55:59 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CAF3A91B3 for ; Sun, 7 Mar 2010 13:55:59 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 7 Mar 2010 13:55:58 -0800 (PST) Received: from cE692BF51.dhcp.bluecom.no (cE692BF51.dhcp.bluecom.no [81.191.146.230]) by core3.amsl.com (Postfix) with SMTP id ADFB43A9192 for ; Sun, 7 Mar 2010 13:55:57 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100307215557.ADFB43A9192@core3.amsl.com> Date: Sun, 7 Mar 2010 13:55:57 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 89025 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Mon Mar 8 06:32:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DEC3A6904 for ; Mon, 8 Mar 2010 06:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.656 X-Spam-Level: X-Spam-Status: No, score=-78.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-pAczsujaLC for ; Mon, 8 Mar 2010 06:32:07 -0800 (PST) Received: from jzr211.internetdsl.tpnet.pl (jzr211.internetdsl.tpnet.pl [95.50.43.211]) by core3.amsl.com (Postfix) with ESMTP id 3F6963A69B4 for ; Mon, 8 Mar 2010 06:32:06 -0800 (PST) From: "Online shop" To: v6ops-archive@megatron.ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100308143207.3F6963A69B4@core3.amsl.com> Date: Mon, 8 Mar 2010 06:32:06 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Tezifudi. All rights reserved.
 Click to unsubscribe
From v6ops-archive@ietf.org Mon Mar 8 06:32:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5920E3A69B4 for ; Mon, 8 Mar 2010 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.656 X-Spam-Level: X-Spam-Status: No, score=-58.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzoG-7HAAmSI for ; Mon, 8 Mar 2010 06:32:33 -0800 (PST) Received: from jzr211.internetdsl.tpnet.pl (jzr211.internetdsl.tpnet.pl [95.50.43.211]) by core3.amsl.com (Postfix) with ESMTP id 4CB6D3A69C4 for ; Mon, 8 Mar 2010 06:32:32 -0800 (PST) From: "Online shop" To: v6ops-archive@ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100308143232.4CB6D3A69C4@core3.amsl.com> Date: Mon, 8 Mar 2010 06:32:32 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Dynjzyd. All rights reserved.
 Click to unsubscribe
From v6ops-archive@lists.ietf.org Mon Mar 8 06:33:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A9C3A699C for ; Mon, 8 Mar 2010 06:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.656 X-Spam-Level: X-Spam-Status: No, score=-58.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTbE6pG4o6A7 for ; Mon, 8 Mar 2010 06:33:13 -0800 (PST) Received: from jzr211.internetdsl.tpnet.pl (jzr211.internetdsl.tpnet.pl [95.50.43.211]) by core3.amsl.com (Postfix) with ESMTP id AAB503A69C0 for ; Mon, 8 Mar 2010 06:33:12 -0800 (PST) From: "Online shop" To: v6ops-archive@lists.ietf.org Subject: Surprise for v6ops-archive! 73% Off right now MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100308143312.AAB503A69C0@core3.amsl.com> Date: Mon, 8 Mar 2010 06:33:12 -0800 (PST)
Having trouble reading this email? Click here to view this email online
Click here


© 2009 Oabavuz. All rights reserved.
 Click to unsubscribe
From vaa27223@ietf.org Mon Mar 8 06:34:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D57A3A6952 for ; Mon, 8 Mar 2010 06:34:34 -0800 (PST) X-Quarantine-ID: <55PQEGDdTbRG> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 8 Mar 2010 06:34:27 -0800 (PST) Received: from 201-236-170-59.adsl.tie.cl (201-236-170-59.adsl.tie.cl [201.236.170.59]) by core3.amsl.com (Postfix) with SMTP id 288023A69C0 for ; Mon, 8 Mar 2010 06:34:17 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100308143424.288023A69C0@core3.amsl.com> Date: Mon, 8 Mar 2010 06:34:17 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 73775 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 8 09:26:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8663A69D3 for ; Mon, 8 Mar 2010 09:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8rjJlFiewfe for ; Mon, 8 Mar 2010 09:26:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6F0D3A6AD4 for ; Mon, 8 Mar 2010 09:26:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nogch-000InW-7h for v6ops-data0@psg.com; Mon, 08 Mar 2010 17:20:07 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nogcd-000ImO-Rt for v6ops@ops.ietf.org; Mon, 08 Mar 2010 17:20:04 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id E31FFE08092 for ; Mon, 8 Mar 2010 18:19:58 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E6F18E080EB for ; Mon, 8 Mar 2010 18:19:50 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages Date: Mon, 8 Mar 2010 18:19:50 +0100 References: To: IPv6 v6ops Message-Id: <7A4FF316-2F67-4DDF-B6BF-91E5D7A7E079@free.fr> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Retransmission to the list (omitted by mistake). D=E9but du message r=E9exp=E9di=E9 : > De : R=E9mi Despr=E9s > Date : 8 mars 2010 09:22:38 HNEC > =C0 : james woodyatt > Cc : Brian E Carpenter > Objet : R=E9p : I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error = Messages >=20 > James, >=20 > Sorry to come so late on this tread. > But the point below is IMHO important. >=20 > In the draft, the only REC-n concerning ICMP is so far: > "REC-16: If a gateway forwards a UDP exchange, it MUST also forward = ICMP Destination Unreachable messages containing UDP headers that match = the exchange state record." >=20 > In my understanding, what is needed is, for each of the transport = protocols: > "REC-n: If a gateway forwards a NNN exchange, it MUST also forward, in = both directions, ICMP Error messages containing UDP headers that match = the exchange state record." >=20 > - Forwarded error messages must be also for TCP, DCCP, etc., and must = be more general than just Destination Unreachable: they must include in = particular Packet Too Big notifications which are essential for IPv6 = path-MTU discovery. > - Reliable PMTUD is much more important in IPv6 than in IPv4. > While IPv4 packets can be fragmented within the network where they are = too long for the local MTU, IPv6 fragmentation is only end to end.=20 > Thus, as long as PMTUD cannot be considered reliable, all IPv6 MTUs = must remain clamped to 1280 octets.=20 > This is not really dramatic, but is significantly less than optimum in = many environments. Furthermore, in dual-stack hosts that apply the same = MTU to IPv4 and IPv6, and also to on-link and off-link packets, this = limitation spreads out to on-link IPv4 packets, which is also less = dramatic than losing connectivity, but is unfortunate. >=20 > I have added Brian as destination because of the point he made, in = Softwire, that in IPv6-PMTUD was unreliable. >=20 > Regards, >=20 > RD >=20 >=20 >=20 >> everyone-- >>=20 >> Once again, I'd like to ask for some discussion and feedback on this = draft. Is there any reason this revision of the draft should not = proceed to Working Group Last Call at this time? >>=20 >>=20 >> -- >> james woodyatt >> member of technical staff, communications engineering >>=20 >>=20 >>=20 >=20 From vaa27223@ietf.org Mon Mar 8 13:59:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6103A68E7 for ; Mon, 8 Mar 2010 13:59:21 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 8 Mar 2010 13:59:15 -0800 (PST) Received: from allianz.es (unknown [190.157.238.207]) by core3.amsl.com (Postfix) with SMTP id AF5243A69C6 for ; Mon, 8 Mar 2010 13:58:59 -0800 (PST) From: Approved VIAGRA® Store Subject: Sales Event get 73% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100308215905.AF5243A69C6@core3.amsl.com> Date: Mon, 8 Mar 2010 13:58:59 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 47791 Inc. All rights reserved.

From v6ops-archive@ietf.org Mon Mar 8 14:30:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF243A6A8C for ; Mon, 8 Mar 2010 14:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.203 X-Spam-Level: X-Spam-Status: No, score=-14.203 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJFcvcsRhGiX for ; Mon, 8 Mar 2010 14:30:15 -0800 (PST) Received: from c12-165.icpnet.pl (c12-165.icpnet.pl [62.21.12.165]) by core3.amsl.com (Postfix) with ESMTP id 920763A6A4B for ; Mon, 8 Mar 2010 14:30:12 -0800 (PST) From: "Super online shop" To: v6ops-archive@ietf.org Subject: Catch the moment v6ops-archive! 85% Fire Sale Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100308223012.920763A6A4B@core3.amsl.com> Date: Mon, 8 Mar 2010 14:30:12 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 INIOYPEAWO. All rights reserved.
From v6ops-archive@lists.ietf.org Mon Mar 8 14:30:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F146C3A6A4B for ; Mon, 8 Mar 2010 14:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N72z9Z6CefV for ; Mon, 8 Mar 2010 14:30:21 -0800 (PST) Received: from c12-165.icpnet.pl (c12-165.icpnet.pl [62.21.12.165]) by core3.amsl.com (Postfix) with ESMTP id 1BEB93A6A06 for ; Mon, 8 Mar 2010 14:30:19 -0800 (PST) From: "Super online shop" To: v6ops-archive@lists.ietf.org Subject: Catch the moment v6ops-archive! 85% Fire Sale Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100308223020.1BEB93A6A06@core3.amsl.com> Date: Mon, 8 Mar 2010 14:30:19 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@lists.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 HOCOXI. All rights reserved.
From v6ops-archive@megatron.ietf.org Mon Mar 8 14:30:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B873A6A4B for ; Mon, 8 Mar 2010 14:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mDbQEpMa-GS for ; Mon, 8 Mar 2010 14:30:30 -0800 (PST) Received: from c12-165.icpnet.pl (c12-165.icpnet.pl [62.21.12.165]) by core3.amsl.com (Postfix) with ESMTP id CD6C73A6A06 for ; Mon, 8 Mar 2010 14:30:25 -0800 (PST) From: "Super online shop" To: v6ops-archive@megatron.ietf.org Subject: Catch the moment v6ops-archive! 85% Fire Sale Content-Type: text/html; charset="ISO-8859-1" MIME-Version: 1.0 Message-Id: <20100308223025.CD6C73A6A06@core3.amsl.com> Date: Mon, 8 Mar 2010 14:30:25 -0800 (PST)
Cannot see this email?  click here.


Click here
You are subscribed as v6ops-archive@megatron.ietf.org
You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 CYSYUOW. All rights reserved.
From owner-v6ops@ops.ietf.org Mon Mar 8 15:27:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E7C3A6767 for ; Mon, 8 Mar 2010 15:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYmNLwzbp2OK for ; Mon, 8 Mar 2010 15:27:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63F2D3A62C1 for ; Mon, 8 Mar 2010 15:27:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NomGJ-0008X3-EB for v6ops-data0@psg.com; Mon, 08 Mar 2010 23:21:23 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NomGF-0008Wt-6A for v6ops@ops.ietf.org; Mon, 08 Mar 2010 23:21:19 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO8UlUutJV2d/2dsb2JhbACbL3OhN5g+hHgEgxc X-IronPort-AV: E=Sophos;i="4.49,605,1262563200"; d="scan'208";a="91234418" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2010 23:21:16 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o28NLHkr022081; Mon, 8 Mar 2010 23:21:17 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Mar 2010 18:19:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: New Version Notification for draft-koodli-ipv6-in-mobile-networks-01 Date: Mon, 8 Mar 2010 18:19:45 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266610B33775@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-koodli-ipv6-in-mobile-networks-01 Thread-Index: Acq/Eq9qXRucpvKLRxGW6Wq7gmglwQAAN7nA From: "Koodli, Rajeev" To: <3gv6@ietf.org>, X-OriginalArrivalTime: 08 Mar 2010 23:19:48.0058 (UTC) FILETIME=[D87A1BA0:01CABF15] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 Hello folks, I have submitted version 01. Thanks for all the input.=20 I have, hopefully, captured the input received (on the ML, as well as in the IETF-3GPP workshop).=20 http://www.ietf.org/id/draft-koodli-ipv6-in-mobile-networks-01.txt Comments welcome! Regards, -Rajeev -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, March 08, 2010 2:59 PM To: Koodli, Rajeev Subject: New Version Notification for draft-koodli-ipv6-in-mobile-networks-01=20 A new version of I-D, draft-koodli-ipv6-in-mobile-networks-01.txt has been successfuly submitted by Rajeev Koodli and posted to the IETF repository. Filename: draft-koodli-ipv6-in-mobile-networks Revision: 01 Title: Mobile Networks Considerations for IPv6 Deployment Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 15 Abstract: Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addressing. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and IPv6 is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks with their own unique architecture and deployment models. =20 The IETF Secretariat. From v6ops-archive@megatron.ietf.org Mon Mar 8 15:28:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DCF3A6359 for ; Mon, 8 Mar 2010 15:28:40 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 8 Mar 2010 15:28:33 -0800 (PST) Received: from net-93-70-130-86.cust.dsl.vodafone.it (net-93-70-130-86.cust.dsl.vodafone.it [93.70.130.86]) by core3.amsl.com (Postfix) with SMTP id B2D883A62C1 for ; Mon, 8 Mar 2010 15:28:32 -0800 (PST) From: Approved VIAGRA® Store Subject: Confirmation ref # [167446] To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100308232832.B2D883A62C1@core3.amsl.com> Date: Mon, 8 Mar 2010 15:28:32 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 32958 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 8 16:04:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1CF3A6BE7 for ; Mon, 8 Mar 2010 16:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.62 X-Spam-Level: X-Spam-Status: No, score=-101.62 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk0uLhoRk1bO for ; Mon, 8 Mar 2010 16:04:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DDE03A677E for ; Mon, 8 Mar 2010 16:04:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nomru-000Bg6-EL for v6ops-data0@psg.com; Tue, 09 Mar 2010 00:00:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nomrn-000Bf3-EH for v6ops@ops.ietf.org; Tue, 09 Mar 2010 00:00:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id DE7EF3A6358; Mon, 8 Mar 2010 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-tunnel-security-concerns-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100309000001.DE7EF3A6358@core3.amsl.com> Date: Mon, 8 Mar 2010 16:00:01 -0800 (PST) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --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 : Security Concerns With IP Tunneling Author(s) : J. Hoagland, et al. Filename : draft-ietf-v6ops-tunnel-security-concerns-02.txt Pages : 20 Date : 2010-03-08 A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness regarding the security issues with IP tunnels as deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-security-concerns-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-tunnel-security-concerns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08155129.I-D@ietf.org> --NextPart-- From secmech-request@lists.ietf.org Tue Mar 9 08:15:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8443A6983 for ; Tue, 9 Mar 2010 08:15:40 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 9 Mar 2010 08:15:26 -0800 (PST) Received: from host86-139-174-170.range86-139.btcentralplus.com (host86-139-174-170.range86-139.btcentralplus.com [86.139.174.170]) by core3.amsl.com (Postfix) with SMTP id 623E43A6919 for ; Tue, 9 Mar 2010 08:15:15 -0800 (PST) From: Approved VIAGRA® Store Subject: Sales Event get 77% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100309161522.623E43A6919@core3.amsl.com> Date: Tue, 9 Mar 2010 08:15:15 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 48657 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Tue Mar 9 11:13:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4E73A6A2C for ; Tue, 9 Mar 2010 11:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAJTUTknhyJP for ; Tue, 9 Mar 2010 11:13:21 -0800 (PST) Received: from ppp85-140-8-227.pppoe.mtu-net.ru (ppp85-140-8-227.pppoe.mtu-net.ru [85.140.8.227]) by core3.amsl.com (Postfix) with SMTP id 1DD403A69F2 for ; Tue, 9 Mar 2010 11:13:12 -0800 (PST) To: Subject: Wellness solutions for the entire family From: Dalton Blevins IME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100309191313.1DD403A69F2@core3.amsl.com> Date: Tue, 9 Mar 2010 11:13:12 -0800 (PST)
View this message online.

Troubles with getting full-sized images? Left click here!
Privacy | Unsubscribe |Subscribe

© 2009 585083 Company. All rights reserved.
From v6ops-archive@ietf.org Tue Mar 9 21:41:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B283A6858 for ; Tue, 9 Mar 2010 21:41:48 -0800 (PST) X-Quarantine-ID: <4A5LPZJb0rM1> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 9 Mar 2010 21:41:41 -0800 (PST) Received: from cable-188-2-152-54.dynamic.sbb.rs (cable-188-2-152-54.dynamic.sbb.rs [188.2.152.54]) by core3.amsl.com (Postfix) with SMTP id 2E92F3A6846 for ; Tue, 9 Mar 2010 21:41:28 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100310054134.2E92F3A6846@core3.amsl.com> Date: Tue, 9 Mar 2010 21:41:28 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 15903 Inc. All rights reserved.

From v6ops-archive@ietf.org Wed Mar 10 07:05:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5CE3A6800 for ; Wed, 10 Mar 2010 07:05:24 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -13.837 X-Spam-Level: X-Spam-Status: No, score=-13.837 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUyfBxkdrDba for ; Wed, 10 Mar 2010 07:05:18 -0800 (PST) Received: from 0-180-95-178.pool.ukrtel.net (0-180-95-178.pool.ukrtel.net [178.95.180.0]) by core3.amsl.com (Postfix) with SMTP id 4D2B53A6817 for ; Wed, 10 Mar 2010 07:05:18 -0800 (PST) From: VIAGRA Official Site To: Subject: For v6ops-archive@ietf.org Discount ID68440 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100310150518.4D2B53A6817@core3.amsl.com> Date: Wed, 10 Mar 2010 07:05:18 -0800 (PST)
Click here to view as a web page.

View image in browser now
Email to v6ops-archive@ietf.org | Privacy Policy | Contact Us

Copyright 2010 arqbc. All rights reserved.
From v6ops-archive@megatron.ietf.org Wed Mar 10 07:23:43 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E57E3A6988 for ; Wed, 10 Mar 2010 07:23:43 -0800 (PST) X-Quarantine-ID: <2mBcSi5wLOOb> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 10 Mar 2010 07:23:34 -0800 (PST) Received: from vfbb233127.4u.com.gh (vfbb235217.4u.com.gh [41.218.235.217]) by core3.amsl.com (Postfix) with SMTP id B88C63A6B31 for ; Wed, 10 Mar 2010 07:23:09 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100310152312.B88C63A6B31@core3.amsl.com> Date: Wed, 10 Mar 2010 07:23:09 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 23504 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Wed Mar 10 12:54:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B043A690C for ; Wed, 10 Mar 2010 12:54:58 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 10 Mar 2010 12:54:51 -0800 (PST) Received: from cdma-92-36-70-119.msk.skylink.ru (cdma-92-36-70-119.msk.skylink.ru [92.36.70.119]) by core3.amsl.com (Postfix) with SMTP id AA99F3A68EE for ; Wed, 10 Mar 2010 12:54:39 -0800 (PST) From: Approved VIAGRA® Store Subject: Confirmation ref # [094878] To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100310205443.AA99F3A68EE@core3.amsl.com> Date: Wed, 10 Mar 2010 12:54:39 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 86063 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Wed Mar 10 13:01:36 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE223A69F8 for ; Wed, 10 Mar 2010 13:01:36 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 10 Mar 2010 13:01:30 -0800 (PST) Received: from acrossboard.co.jp (unknown [201.240.238.151]) by core3.amsl.com (Postfix) with SMTP id 38F743A6964 for ; Wed, 10 Mar 2010 13:01:28 -0800 (PST) From: Approved VIAGRA® Store Subject: Sales Event get 76% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100310210129.38F743A6964@core3.amsl.com> Date: Wed, 10 Mar 2010 13:01:28 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 52964 Inc. All rights reserved.

From v6ops-archive@ietf.org Wed Mar 10 14:19:49 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671313A6812 for ; Wed, 10 Mar 2010 14:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.631 X-Spam-Level: X-Spam-Status: No, score=-51.631 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om7rR8kWbT3j for ; Wed, 10 Mar 2010 14:19:48 -0800 (PST) Received: from p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp (p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp [124.86.97.103]) by core3.amsl.com (Postfix) with ESMTP id B0C403A69B8 for ; Wed, 10 Mar 2010 14:19:37 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100310221937.B0C403A69B8@core3.amsl.com> Date: Wed, 10 Mar 2010 14:19:37 -0800 (PST) Click here to visit our shop http://22.roperoot.ru/ Wqvima xuwoladjm ezyt pemojjmi Odyricid ibqcor tunqpaimaxj owqdj Gulagoqpowia nevatuoizy ohav Tiwekusosajm afeuxux qamihj jfegqneaqn Qpyxofqnofql ipudimyalezo ekqno iopafodizuhe Civiixazymym yic Azegjtysyl epuliviy qwjsocqri jbjeihjgawj Juhosqki rjpyzotivo yfucyujyt tirjq Udoorocojopu narajljn qpjwiy fiw Diypi Jkujrerydux qkofomq gqgenqg dujp From v6ops-archive@megatron.ietf.org Wed Mar 10 14:20:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B00B3A6830 for ; Wed, 10 Mar 2010 14:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.131 X-Spam-Level: X-Spam-Status: No, score=-51.131 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k0NkagX-1un for ; Wed, 10 Mar 2010 14:20:25 -0800 (PST) Received: from p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp (p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp [124.86.97.103]) by core3.amsl.com (Postfix) with ESMTP id 8D5953A68B2 for ; Wed, 10 Mar 2010 14:20:20 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@megatron.ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100310222020.8D5953A68B2@core3.amsl.com> Date: Wed, 10 Mar 2010 14:20:20 -0800 (PST) Click here to visit our shop http://ee.roperoot.ru/ Saw qloq qygj buroal Tezuazor calyqzueuhqx izua abqmufesake Yry yko jrjwalemynqn Ixulyyb zumqbinyfq osycokqgq ybame Famixubqdj ucobixe jbug cyro Udyooie xine Hirot sitomqa uky unqrama Ufqfidyni uoun qumqrikou efqhjomi Otamq lqybeg qdadof zetjd Lafqarye Apqn qzak rucylqbyy qiwjvef From v6ops-archive@lists.ietf.org Wed Mar 10 14:21:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761F13A68B2 for ; Wed, 10 Mar 2010 14:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.131 X-Spam-Level: X-Spam-Status: No, score=-51.131 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlxKreKpIsZG for ; Wed, 10 Mar 2010 14:21:13 -0800 (PST) Received: from p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp (p3103-ipbf502hodogaya.kanagawa.ocn.ne.jp [124.86.97.103]) by core3.amsl.com (Postfix) with ESMTP id 1EC923A6830 for ; Wed, 10 Mar 2010 14:20:59 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@lists.ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100310222100.1EC923A6830@core3.amsl.com> Date: Wed, 10 Mar 2010 14:20:59 -0800 (PST) Click here to visit our shop http://65.roperoot.ru/ Euqc eranqs jsuigq iwuavun Padatqoveyx esojzj uvuexih ucubjc Kepusidil tiho okqezes Jhababjq yranq xihi ralunu Qnefqatyhu ovq roxjpaxinewq yhjezatyjpq Dum igiubqd Njna hqy upy jmemeudqizix Acuxure urqmquhq uywogikupyce uynipuq Umaviho iljcof lyjfyr yfetiwier Ygibq Ymuvjmuy wipjuacezyg ebiq qqvq From smf-discussion@lists.ietf.org Wed Mar 10 23:06:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864353A6850 for ; Wed, 10 Mar 2010 23:06:57 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 10 Mar 2010 23:06:50 -0800 (PST) Received: from ppp-58-10-33-40.revip2.asianet.co.th (ppp-58-10-33-40.revip2.asianet.co.th [58.10.33.40]) by core3.amsl.com (Postfix) with SMTP id 4E3873A67D9 for ; Wed, 10 Mar 2010 23:06:41 -0800 (PST) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100311070649.4E3873A67D9@core3.amsl.com> Date: Wed, 10 Mar 2010 23:06:41 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 28454 Inc. All rights reserved.

From vaa27223@ietf.org Thu Mar 11 04:05:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFBC3A6845 for ; Thu, 11 Mar 2010 04:05:34 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 11 Mar 2010 04:05:29 -0800 (PST) Received: from 3cha.jp (unknown [186.82.45.200]) by core3.amsl.com (Postfix) with SMTP id 8F7073A67A8 for ; Thu, 11 Mar 2010 04:05:17 -0800 (PST) From: Approved VIAGRA® Store Subject: Special Code for 79% for v6ops-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100311120520.8F7073A67A8@core3.amsl.com> Date: Thu, 11 Mar 2010 04:05:17 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78620 Inc. All rights reserved.

From v6ops-archive@ietf.org Thu Mar 11 06:34:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0333A67E5 for ; Thu, 11 Mar 2010 06:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.047 X-Spam-Level: X-Spam-Status: No, score=-29.047 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68FWPunXuqSS for ; Thu, 11 Mar 2010 06:34:29 -0800 (PST) Received: from reporterly.rung.volia.net (reporterly.rung.volia.net [77.123.248.194]) by core3.amsl.com (Postfix) with SMTP id D09C73A67D7 for ; Thu, 11 Mar 2010 06:34:26 -0800 (PST) From: Doctor Loraine To: Subject: For v6ops-archive@ietf.org Discount ID77922 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100311143426.D09C73A67D7@core3.amsl.com> Date: Thu, 11 Mar 2010 06:34:26 -0800 (PST) If you cannot see the images below, please click here
From v6ops-archive@megatron.ietf.org Thu Mar 11 10:02:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5153A6CEC for ; Thu, 11 Mar 2010 10:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.701 X-Spam-Level: X-Spam-Status: No, score=-54.701 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55dsbs4nrKVA for ; Thu, 11 Mar 2010 10:02:18 -0800 (PST) Received: from chello082119107090.chello.sk (chello082119107090.chello.sk [82.119.107.90]) by core3.amsl.com (Postfix) with ESMTP id 7EFB83A6E0A for ; Thu, 11 Mar 2010 09:40:32 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@megatron.ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100311174032.7EFB83A6E0A@core3.amsl.com> Date: Thu, 11 Mar 2010 09:40:32 -0800 (PST) Click here to visit our shop http://f0.gladsystem.ru/ Zawq gow enagano iqzamqxe Qcozqn ucawaraci qdazipoo zoroag Uib conjwofoqke qfyjep Hjweogorq yhybugqgywqw jtjadu fyicaj Jlavydafeby toda xqwafefa ibydoe Atamjfeduiw yduhipahjh Ahusotat qtynikybayy yneecytecu uopu Uwytj gugqhiidunu odqjse jcjhufej Qsosj sqdqry kqwyducitadq uzudor Olq Ahoxiuqw jfegipexqa hukehurydiny awir From v6ops-archive@ietf.org Thu Mar 11 10:03:06 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ECE13A6CE4 for ; Thu, 11 Mar 2010 10:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.701 X-Spam-Level: X-Spam-Status: No, score=-54.701 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLTK47x6X10z for ; Thu, 11 Mar 2010 10:02:58 -0800 (PST) Received: from chello082119107090.chello.sk (chello082119107090.chello.sk [82.119.107.90]) by core3.amsl.com (Postfix) with ESMTP id 69E353A6E17 for ; Thu, 11 Mar 2010 09:41:06 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100311174106.69E353A6E17@core3.amsl.com> Date: Thu, 11 Mar 2010 09:41:06 -0800 (PST) Click here to visit our shop http://ff.gladsystem.ru/ Fyegeafo omor omiegyryz ojtomu Qxj jugu novyry avopq Xonam modesite viqdys Adjyicjxeqdj unesemuuud hekyharem nikqh Ylyc aose ybejxiyzuw aweo Gitirogyopi poqceamjsyp Jrjfyo dejabjmebap akupewqve emqv Uqgoxahedu yceubytyvao onyfefqh ohu Iqm iamqhjsqqmj pariloawaki jcjf Lecinqr Ylecaikiv bjfinqotek uazixjno oofi From v6ops-archive@lists.ietf.org Thu Mar 11 10:05:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DCD3A68C5 for ; Thu, 11 Mar 2010 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.701 X-Spam-Level: X-Spam-Status: No, score=-54.701 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8kfxzl2yd2Z for ; Thu, 11 Mar 2010 10:05:49 -0800 (PST) Received: from chello082119107090.chello.sk (chello082119107090.chello.sk [82.119.107.90]) by core3.amsl.com (Postfix) with ESMTP id 0E5CE3A6E54 for ; Thu, 11 Mar 2010 09:43:00 -0800 (PST) From: "Pfizer Online shop" To: v6ops-archive@lists.ietf.org Subject: ** Dear v6ops-archive! 73% Off right now ** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100311174301.0E5CE3A6E54@core3.amsl.com> Date: Thu, 11 Mar 2010 09:43:00 -0800 (PST) Click here to visit our shop http://9e.gladsystem.ru/ Iywovo osulyxi upizakirjnu fih Vygaljxo qyolemjbevj qvelywq iasimu Opyo pqtabjcib tjtagyrawa Zohjpiazasod jgibaw qriqh bouta Yqr jty ukjgjiy upqnad Ucjv yitolymidoz Iqcafak habozozjm qxeycebot ipywanqunoe Fylaatj nofquyqp ekaojkip gje Wqulo ujsqvqmoygj igohaxjbabof qnqsuzix Noiqlqz Ewqbaki eapuduxjcobe xobut ofofexqko From owner-v6ops@ops.ietf.org Thu Mar 11 12:34:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813CB3A6BC9 for ; Thu, 11 Mar 2010 12:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.608 X-Spam-Level: X-Spam-Status: No, score=-104.608 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLs6p0dpLddC for ; Thu, 11 Mar 2010 12:34:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 893963A6BFE for ; Thu, 11 Mar 2010 12:23:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Npooy-0001Sj-Ul for v6ops-data0@psg.com; Thu, 11 Mar 2010 20:17:28 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Npoow-0001SA-Lr for v6ops@ops.ietf.org; Thu, 11 Mar 2010 20:17:26 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 9EF4D88F291B; Thu, 11 Mar 2010 12:17:25 -0800 (PST) X-AuditID: 11807130-b7b0aae00000102c-34-4b994fd55dca Received: from il0602f-dhcp114.apple.com (il0602f-dhcp114.apple.com [17.206.50.114]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 97.BC.04140.5DF499B4; Thu, 11 Mar 2010 12:17:25 -0800 (PST) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: james woodyatt In-Reply-To: Date: Thu, 11 Mar 2010 12:17:25 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 8, 2010, at 00:22, R=E9mi Despr=E9s wrote: >=20 > In the draft, the only REC-n concerning ICMP is so far: > "REC-16: If a gateway forwards a UDP exchange, it MUST also forward = ICMP Destination Unreachable messages containing UDP headers that match = the exchange state record." >=20 > In my understanding, what is needed is, for each of the transport = protocols: > "REC-n: If a gateway forwards a NNN exchange, it MUST also forward, in = both directions, ICMP Error messages containing UDP headers that match = the exchange state record." Please also see REC-29, REC-34 and REC-38. > - Forwarded error messages must be also for TCP, DCCP, etc., and must = be more general than just Destination Unreachable: they must include in = particular Packet Too Big notifications which are essential for IPv6 = path-MTU discovery. Agreed, but I'm now inclined to remove all four of those recommendations = and insert an explicit recommendation into the "Stateless Filters" = section that cites RFC 4890 and specifically references section 4.3.1 = "Traffic The Must Not Be Dropped". Does anyone object to that revision? -- james woodyatt member of technical staff, communications engineering From uk@megatron.ietf.org Fri Mar 12 02:09:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B583A6A50 for ; Fri, 12 Mar 2010 02:09:10 -0800 (PST) X-Quarantine-ID: <3gfdsNAp2pGJ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 12 Mar 2010 02:09:02 -0800 (PST) Received: from 68-114-73-048.dhcp.mant.nc.charter.com (68-114-73-048.dhcp.mant.nc.charter.com [68.114.73.48]) by core3.amsl.com (Postfix) with SMTP id B00E83A6B07 for ; Fri, 12 Mar 2010 02:08:46 -0800 (PST) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100312100846.B00E83A6B07@core3.amsl.com> Date: Fri, 12 Mar 2010 02:08:46 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 24555 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Fri Mar 12 05:11:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0EC3A68CE for ; Fri, 12 Mar 2010 05:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKgobChELo-H for ; Fri, 12 Mar 2010 05:11:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4F8F3A6888 for ; Fri, 12 Mar 2010 05:11:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nq4YT-000EtD-JP for v6ops-data0@psg.com; Fri, 12 Mar 2010 13:05:29 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nq4YM-000EsH-Te for v6ops@ops.ietf.org; Fri, 12 Mar 2010 13:05:23 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 91683E08144; Fri, 12 Mar 2010 14:05:16 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5873BE0816B; Fri, 12 Mar 2010 14:05:14 +0100 (CET) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages + Vocabulary Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 12 Mar 2010 14:05:13 +0100 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <1F8B4155-2216-4E0B-9F23-327EC0DA338B@free.fr> References: To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: 1. Le 11 mars 2010 =E0 21:17, james woodyatt a =E9crit : > ... >> - Forwarded error messages ... must be more general than just = Destination Unreachable: they must include in particular Packet Too Big = notifications which are essential for IPv6 path-MTU discovery. >=20 > Agreed, but I'm now inclined to remove all four of those = recommendations and insert an explicit recommendation into the = "Stateless Filters" section that cites RFC 4890 and specifically = references section 4.3.1 "Traffic The Must Not Be Dropped". >=20 > Does anyone object to that revision? No objection, and active support for this approach. (You are right, ICMP is at the IP layer, not at the transport layer.) 2. The draft uses "interior" and "exterior", while the traditional = vocabulary for NATs is AFAIK "internal" and "external" (e.g. in RFC = 4787). A suggestion would be to align the vocabulary.=20 RD From v6ops-archive@megatron.ietf.org Fri Mar 12 09:24:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A957B3A6452 for ; Fri, 12 Mar 2010 09:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.916 X-Spam-Level: X-Spam-Status: No, score=-16.916 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K93kOjsY-+7O for ; Fri, 12 Mar 2010 09:23:59 -0800 (PST) Received: from host86-166-175-197.range86-166.btcentralplus.com (host86-144-139-146.range86-144.btcentralplus.com [86.144.139.146]) by core3.amsl.com (Postfix) with ESMTP id E3F133A67C0 for ; Fri, 12 Mar 2010 09:23:30 -0800 (PST) From: Pfizer VIAGRA Reseller To: v6ops-archive@megatron.ietf.org Subject: Dear v6ops-archive@megatron.ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100312172330.E3F133A67C0@core3.amsl.com> Date: Fri, 12 Mar 2010 09:23:30 -0800 (PST) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Ogozey. All rights reserved.
From v6ops-archive@ietf.org Fri Mar 12 09:24:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D243A68B0 for ; Fri, 12 Mar 2010 09:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.916 X-Spam-Level: X-Spam-Status: No, score=-36.916 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2-rNsoT02QP for ; Fri, 12 Mar 2010 09:24:33 -0800 (PST) Received: from host86-166-175-197.range86-166.btcentralplus.com (host86-144-139-146.range86-144.btcentralplus.com [86.144.139.146]) by core3.amsl.com (Postfix) with ESMTP id A9DA73A67BD for ; Fri, 12 Mar 2010 09:24:12 -0800 (PST) From: Pfizer VIAGRA Reseller To: v6ops-archive@ietf.org Subject: Dear v6ops-archive@ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100312172412.A9DA73A67BD@core3.amsl.com> Date: Fri, 12 Mar 2010 09:24:12 -0800 (PST) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Ubjk. All rights reserved.
From v6ops-archive@lists.ietf.org Fri Mar 12 09:26:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387E63A67EA for ; Fri, 12 Mar 2010 09:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.915 X-Spam-Level: X-Spam-Status: No, score=-6.915 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL6FQUofcyo4 for ; Fri, 12 Mar 2010 09:26:26 -0800 (PST) Received: from host86-166-175-197.range86-166.btcentralplus.com (host86-144-139-146.range86-144.btcentralplus.com [86.144.139.146]) by core3.amsl.com (Postfix) with ESMTP id 9FD783A67C0 for ; Fri, 12 Mar 2010 09:26:25 -0800 (PST) From: Pfizer VIAGRA Reseller To: v6ops-archive@lists.ietf.org Subject: Dear v6ops-archive@lists.ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100312172625.9FD783A67C0@core3.amsl.com> Date: Fri, 12 Mar 2010 09:26:25 -0800 (PST) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Jegqxo. All rights reserved.
From owner-v6ops@ops.ietf.org Fri Mar 12 13:17:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C4B3A699E for ; Fri, 12 Mar 2010 13:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.209 X-Spam-Level: X-Spam-Status: No, score=-5.209 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MJrMHikQP9H for ; Fri, 12 Mar 2010 13:17:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2797C3A695C for ; Fri, 12 Mar 2010 13:17:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NqCAa-000PEH-UW for v6ops-data0@psg.com; Fri, 12 Mar 2010 21:13:20 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NqCAU-000PDa-Dk for v6ops@ops.ietf.org; Fri, 12 Mar 2010 21:13:14 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2CLD6hc006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2CLD6G2009102; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2CLD6PB009097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 12 Mar 2010 13:13:06 -0800 From: "Templin, Fred L" To: Dmitry Anipko , Gabi Nakibly , v6ops CC: "ipv6@ietf.org" , "secdir@ietf.org" Date: Fri, 12 Mar 2010 13:13:05 -0800 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyAAALQzQA== Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Dmitry, > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: Friday, March 12, 2010 12:54 PM > To: Templin, Fred L; Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Hello, >=20 > I wanted to follow up on Fred's comment earlier in this thread: >=20 > >> OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. >=20 > For the designers of new tunneling protocols, shall perhaps a recommendat= ion on best practices be > included into the draft or another document, that for the new tunnels a d= ifferent protocol value / > format should be used? Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? If so, IMHO this document would be the natural location for such a recommendation.=20 > Examples of such protocol / formats could include using a different next-= protocol value, potentially > with some multiplexing schema if just using different next-protocol value= s is not scalable, or > possibly some other format. Yes, I think it would be very good to declare ip-proto-41 as fully-developed and recommend that new tunneling protocols use a different ip protocol number and/or TCP/UDP port number. This would greatly reduce the concern for having to go back and revisit tunneling implementations that perform src/dst checks if a new tunneling protocol happens to emerge. Gabi - do you have any thoughts on this? Thanks - Fred fred.l.templin@boeing.com > Thank you, > Dmitry >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of T= emplin, Fred L > Sent: Friday, August 28, 2009 1:25 PM > To: Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Gabi, >=20 > > -----Original Message----- > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > Sent: Friday, August 28, 2009 12:07 PM > > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Correct. All the attacks rely on the fact that the ISATAP router > encapsulates/decapsulates a packet > > the 6to4 relay decapsulates/encapsulates, respectively. So the two > tunnels must have the same > > encapsulation type. >=20 > OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. >=20 > Fred > fred.l.templin@boeing.com >=20 > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Friday, August 28, 2009 7:23:03 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > Correct me if I am wrong, but if there were a new version > > > of ISATAP that did not use ip-proto-41 encapsulation but > > > instead used a different kind of encapsulation, then it > > > need not concern itself with routing loop interactions > > > with 6to4 relays since 6to4 relays only know about > > > ip-proto-41. Does that match your understanding? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Fri Mar 12 15:21:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656C43A67FC for ; Fri, 12 Mar 2010 15:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.81 X-Spam-Level: X-Spam-Status: No, score=-6.81 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srKcd+M0deAm for ; Fri, 12 Mar 2010 15:21:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A77523A6830 for ; Fri, 12 Mar 2010 15:21:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NqE7D-000E0q-2C for v6ops-data0@psg.com; Fri, 12 Mar 2010 23:17:59 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NqE76-000E0L-Kt for v6ops@ops.ietf.org; Fri, 12 Mar 2010 23:17:53 +0000 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74212483; Fri, 12 Mar 2010 18:17:44 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 18:03:45 -0500 Received: from mail pickup service by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC; Fri, 12 Mar 2010 18:03:43 -0500 Received: from PAOAKEXCSMTP01.cable.comcast.com ([10.52.116.30]) by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:52 -0500 Received: from PACDCEXCSMTP03.cable.comcast.com ([24.40.15.92]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:29 -0500 Received: from cable.comcast.com ([24.40.8.136]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:29 -0500 Received: from ([24.40.8.143]) by pacdcimi02.cable.comcast.com with ESMTP id 5503616.86917225; Fri, 12 Mar 2010 16:13:23 -0500 Received: from ([64.170.98.32]) by pacdcedge01.cable.comcast.com with ESMTP id 5302275.EDGE; Fri, 12 Mar 2010 16:13:23 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1753A695B; Fri, 12 Mar 2010 13:13:09 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE4C3A691A; Fri, 12 Mar 2010 13:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB1kViD9-IFR; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0F6A93A6901; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2CLD6hc006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2CLD6G2009102; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2CLD6PB009097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 12 Mar 2010 13:13:06 -0800 From: "Templin, Fred L" To: Dmitry Anipko , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 13:13:05 -0800 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyAAALQzQA== Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "secdir@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-esp: ESP<-40>= SHA:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-49> SIG: DSC:<0> TRU_scam_spam: <0> TRU_urllinks: <0> TRU_playsites: <0> TRU_spam2: <0> TRU_ru_spamsubj: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> URL Real-Time Signatures: <0> TRU_marketing_spam: <0> TRU_phish_spam: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_html_image_spam: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_spam1: <0> X-OriginalArrivalTime: 12 Mar 2010 21:13:29.0352 (UTC) FILETIME=[DCDE5880:01CAC228] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Dmitry, > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: Friday, March 12, 2010 12:54 PM > To: Templin, Fred L; Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels > > Hello, > > I wanted to follow up on Fred's comment earlier in this thread: > > >> OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. > > For the designers of new tunneling protocols, shall perhaps a recommendation on best practices be > included into the draft or another document, that for the new tunnels a different protocol value / > format should be used? Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? If so, IMHO this document would be the natural location for such a recommendation. > Examples of such protocol / formats could include using a different next-protocol value, potentially > with some multiplexing schema if just using different next-protocol values is not scalable, or > possibly some other format. Yes, I think it would be very good to declare ip-proto-41 as fully-developed and recommend that new tunneling protocols use a different ip protocol number and/or TCP/UDP port number. This would greatly reduce the concern for having to go back and revisit tunneling implementations that perform src/dst checks if a new tunneling protocol happens to emerge. Gabi - do you have any thoughts on this? Thanks - Fred fred.l.templin@boeing.com > Thank you, > Dmitry > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, August 28, 2009 1:25 PM > To: Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels > > Gabi, > > > -----Original Message----- > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > Sent: Friday, August 28, 2009 12:07 PM > > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Correct. All the attacks rely on the fact that the ISATAP router > encapsulates/decapsulates a packet > > the 6to4 relay decapsulates/encapsulates, respectively. So the two > tunnels must have the same > > encapsulation type. > > OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. > > Fred > fred.l.templin@boeing.com > > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Friday, August 28, 2009 7:23:03 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > Correct me if I am wrong, but if there were a new version > > > of ISATAP that did not use ip-proto-41 encapsulation but > > > instead used a different kind of encapsulation, then it > > > need not concern itself with routing loop interactions > > > with 6to4 relays since 6to4 relays only know about > > > ip-proto-41. Does that match your understanding? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From uk@megatron.ietf.org Fri Mar 12 17:06:42 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836623A6835 for ; Fri, 12 Mar 2010 17:06:42 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 12 Mar 2010 17:06:35 -0800 (PST) Received: from cable-188-2-177-193.dynamic.sbb.rs (cable-188-2-177-193.dynamic.sbb.rs [188.2.177.193]) by core3.amsl.com (Postfix) with SMTP id 5885A3A67B6 for ; Fri, 12 Mar 2010 17:06:33 -0800 (PST) From: Approved VIAGRA® Store Subject: Special Discount 71% for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100313010634.5885A3A67B6@core3.amsl.com> Date: Fri, 12 Mar 2010 17:06:33 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 54585 Inc. All rights reserved.

From sip-archive@lists.ietf.org Fri Mar 12 23:14:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347D13A6860 for ; Fri, 12 Mar 2010 23:14:34 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 12 Mar 2010 23:14:28 -0800 (PST) Received: from HSI-KBW-078-043-110-174.hsi4.kabel-badenwuerttemberg.de (HSI-KBW-078-043-110-174.hsi4.kabel-badenwuerttemberg.de [78.43.110.174]) by core3.amsl.com (Postfix) with SMTP id E1F953A698B for ; Fri, 12 Mar 2010 23:14:08 -0800 (PST) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100313071411.E1F953A698B@core3.amsl.com> Date: Fri, 12 Mar 2010 23:14:08 -0800 (PST)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 12855 Inc. All rights reserved.

From v6ops-archive@ietf.org Sat Mar 13 04:11:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389EA3A6964 for ; Sat, 13 Mar 2010 04:11:24 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: -58.205 X-Spam-Level: X-Spam-Status: No, score=-58.205 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omQ2Ln9RWGfL for ; Sat, 13 Mar 2010 04:11:22 -0800 (PST) Received: from icq-mr1.icq.com (208-86-112-92.pool.ukrtel.net [92.112.86.208]) by core3.amsl.com (Postfix) with SMTP id B9C683A69EA for ; Sat, 13 Mar 2010 04:11:09 -0800 (PST) X-Originating-IP: [71.34.456.775] X-Originating-Email: [v6ops-archive@ietf.org] X-Sender: v6ops-archive@ietf.org From: Pfizer Inc 1999-2010 To: v6ops-archive@ietf.org Subject: USA MensHealth Discount ID5414 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100313121110.B9C683A69EA@core3.amsl.com> Date: Sat, 13 Mar 2010 04:11:09 -0800 (PST)


Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2010 | Unsubscribe | More Newsletters | Privacy
From v6ops-archive@ietf.org Sat Mar 13 18:48:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650FA3A68BA for ; Sat, 13 Mar 2010 18:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.807 X-Spam-Level: X-Spam-Status: No, score=-10.807 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW52kT1pkd78 for ; Sat, 13 Mar 2010 18:48:21 -0800 (PST) Received: from aeon.biz (unknown [110.138.227.34]) by core3.amsl.com (Postfix) with SMTP id 96C7F3A686C for ; Sat, 13 Mar 2010 18:48:06 -0800 (PST) To: Subject: Bestsellers. 70% Discount. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100314024816.96C7F3A686C@core3.amsl.com> Date: Sat, 13 Mar 2010 18:48:06 -0800 (PST)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 85% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-507-818-9347 from the U.S. & Canada or +376-50-5511717in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From v6ops-archive@ietf.org Sun Mar 14 13:46:49 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A96D3A6820 for ; Sun, 14 Mar 2010 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.78 X-Spam-Level: X-Spam-Status: No, score=-11.78 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkKFBE1RXpBq for ; Sun, 14 Mar 2010 13:46:42 -0700 (PDT) Received: from 91-168-81-252.rev.libertysurf.net (91-168-81-252.rev.libertysurf.net [91.168.81.252]) by core3.amsl.com (Postfix) with ESMTP id CBB273A6848 for ; Sun, 14 Mar 2010 13:46:34 -0700 (PDT) From: Official Pfizer Pharmacy To: v6ops-archive@ietf.org Subject: User v6ops-archive receives 70% discounts on all products. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100314204634.CBB273A6848@core3.amsl.com> Date: Sun, 14 Mar 2010 13:46:34 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Try using this link in case of problems with images
 

c 1999-2009 JONYNARAW, Inc.
This e-mail was sent to v6ops-archive@ietf.org.

Click here to unsubscribe
From v6ops-archive@lists.ietf.org Sun Mar 14 13:46:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEC03A6823 for ; Sun, 14 Mar 2010 13:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX7NJm3NpNG9 for ; Sun, 14 Mar 2010 13:46:51 -0700 (PDT) Received: from 91-168-81-252.rev.libertysurf.net (91-168-81-252.rev.libertysurf.net [91.168.81.252]) by core3.amsl.com (Postfix) with ESMTP id 822723A67C0 for ; Sun, 14 Mar 2010 13:46:45 -0700 (PDT) From: Official Pfizer Pharmacy To: v6ops-archive@lists.ietf.org Subject: User v6ops-archive receives 70% discounts on all products. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100314204645.822723A67C0@core3.amsl.com> Date: Sun, 14 Mar 2010 13:46:45 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Try using this link in case of problems with images
 

c 1999-2009 ALIRAIEVI, Inc.
This e-mail was sent to v6ops-archive@lists.ietf.org.

Click here to unsubscribe
From v6ops-archive@ietf.org Mon Mar 15 05:52:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2E63A68B2 for ; Mon, 15 Mar 2010 05:52:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -24.14 X-Spam-Level: X-Spam-Status: No, score=-24.14 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3-pce6nZHGw for ; Mon, 15 Mar 2010 05:52:39 -0700 (PDT) Received: from icq-mr1.icq.com (187-27-223-99.3g.claro.net.br [187.27.223.99]) by core3.amsl.com (Postfix) with SMTP id E5F263A6C6F for ; Mon, 15 Mar 2010 05:35:12 -0700 (PDT) From: VIAGRA Official Seller To: Subject: SALE 79% OFF on PFIZER! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100315123512.E5F263A6C6F@core3.amsl.com> Date: Mon, 15 Mar 2010 05:35:12 -0700 (PDT)
Click here to view as a web page.

View image in browser now
This Email was sent to v6ops-archive@ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From whackiestnhy3@mironovanton.ru Mon Mar 15 09:56:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEB83A6972; Mon, 15 Mar 2010 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.668 X-Spam-Level: X-Spam-Status: No, score=-53.668 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSwJ5mdhtI79; Mon, 15 Mar 2010 09:56:14 -0700 (PDT) Received: from dhcp-077-250-008-202.chello.nl (dhcp-077-250-008-202.chello.nl [77.250.8.202]) by core3.amsl.com (Postfix) with ESMTP id 0DEF13A6856; Mon, 15 Mar 2010 09:56:10 -0700 (PDT) Received: from 77.250.8.202 by ALT2.ASPMX.L.GOOGLE.COM; Mon, 15 Mar 2010 17:56:16 +0100 Message-ID: <000d01cac460$6d8cf7e0$6400a8c0@whackiestnhy3> From: v6ops-archive@lists.ietf.org To: Subject: Include Quick Slim in your diet and start your Miracles today. Date: Mon, 15 Mar 2010 17:56:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Regulate your metabolism and lose weight fast. http://sacucesar.cn/ From urn-ietf@ietf.org Tue Mar 16 04:28:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121453A6A0E for ; Tue, 16 Mar 2010 04:28:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 16 Mar 2010 04:28:47 -0700 (PDT) Received: from chello089073170153.chello.pl (chello089073170153.chello.pl [89.73.170.153]) by core3.amsl.com (Postfix) with SMTP id C460D3A6A63 for ; Tue, 16 Mar 2010 04:26:54 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100316112656.C460D3A6A63@core3.amsl.com> Date: Tue, 16 Mar 2010 04:26:54 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 06567 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 16 12:29:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5DC93A69CD for ; Tue, 16 Mar 2010 12:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA+J37YOoqlm for ; Tue, 16 Mar 2010 12:29:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D22E3A69A0 for ; Tue, 16 Mar 2010 12:29:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrcMU-00019N-5e for v6ops-data0@psg.com; Tue, 16 Mar 2010 19:23:30 +0000 Received: from n71.bullet.mail.sp1.yahoo.com ([98.136.44.36]) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrcMR-00018s-HU for v6ops@ops.ietf.org; Tue, 16 Mar 2010 19:23:27 +0000 Received: from [69.147.84.145] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 16 Mar 2010 19:23:27 -0000 Received: from [98.136.44.165] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 16 Mar 2010 19:23:27 -0000 Received: from [127.0.0.1] by omp606.mail.sp1.yahoo.com with NNFMP; 16 Mar 2010 19:23:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 47163.43739.bm@omp606.mail.sp1.yahoo.com Received: (qmail 48375 invoked by uid 60001); 16 Mar 2010 19:23:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1268767406; bh=z8MZigie8YPwGtw8ohm5ZIv2ymepSE4YA8ZbGew6wEs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Gwr8UPbD9urp5A3nj+YoJ1AxXT4cSp601IezKc8wcHesQSLY3OSArEIqhzn76oxgxjwDliiPj8Ho/46LZuy4HgsEna4/Xzus29A/TtSqtNv0mVpNOXwVRY6MzztSGiFHzzcRP3hTSLr+szBZ/UYGSzF3UEqTInWt7hA8z1khRVE= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uSZv/WYvKOO104L5m6K4jOicX8OeIxFLBKl9X1NiIeaR1p9E7CTEmNuaDxs/78uqodYpCTb+9e3u/QMQP8894s4rcB7UTnYyRdFFvqxXTE0Q14sTGqWeozRtunrYhrWcSJVPM8/dMZB+9aXrn2pvpUo42QN72nyGAlHxLd2OW54=; Message-ID: <911278.48361.qm@web45513.mail.sp1.yahoo.com> X-YMail-OSG: d2e.RpEVM1ndPpiZK4T14YYNWIhW9G4O6drPnMwi5w2KsEzRgR1CNIqzWlMr0bDR.VI8ugq.4TziiJQgqMX_c9kcKdmmnWxTPVIrGniaGOjk8AHq7QqgCXs9nYfCKSZ5c0LjPByFZd9fvRgQ_ulwMmSQldOdUOOBYBLsi7mZ7.p9I5jpwVg6jWOaA1LfG_mRPc99PiDCGpOClkD5cGOFZtMuNI1Aa6jrVJmBITTuGCcyw.qSisVTUMjbJORVD4oryJLVKmynL.vM.Gqhy32xeX98l8g3mJKSN1dSn6LKHPyDRjjcPI_rDDJm Received: from [89.138.44.217] by web45513.mail.sp1.yahoo.com via HTTP; Tue, 16 Mar 2010 12:23:26 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 16 Mar 2010 12:23:26 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , Dmitry Anipko , v6ops In-Reply-To: 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 List-ID: Dmitry and Fred,=0AIndeed using different values=A0in the Protocol field fo= r different automatic tunnel protocols can help in mitigating the routing l= oops. It is useful=A0when the two victims=A0employ _different_ tunneling pr= otocols. However, this measure will not be useful for mitigating routing lo= ops between two nodes that employ the same tunneling protocol. In think tha= t this may reduce the motivation to apply this measure.=0AIn addition, maki= ng such a change to the=A0semantics of the Protocol=A0field is=A0a big=A0st= ep that should be considered thoroughly.=0A=0AGabi=0A=0A=0A----- Original M= essage ----=0A> From: "Templin, Fred L" =0A> To:= Dmitry Anipko ; Gabi Nakibly ; v6ops =0A> Cc: "ipv6@ietf.org" ; "= secdir@ietf.org" =0A> Sent: Fri, March 12, 2010 11:13:05 P= M=0A> Subject: RE: Routing loop attacks using IPv6 tunnels=0A> =0A> Hi Dmit= ry,=0A=0A> -----Original Message-----=0A> From: Dmitry Anipko =0A> [mailto:= > href=3D"mailto:Dmitry.Anipko@microsoft.com">Dmitry.Anipko@microsoft.com]= =0A> =0A> Sent: Friday, March 12, 2010 12:54 PM=0A> To: Templin, Fred L; Ga= bi Nakibly; =0A> v6ops=0A> Cc: > href=3D"mailto:ipv6@ietf.org">ipv6@ietf.or= g; > ymailto=3D"mailto:secdir@ietf.org" =0A> href=3D"mailto:secdir@ietf.org= ">secdir@ietf.org=0A> Subject: RE: Routing =0A> loop attacks using IPv6 tun= nels=0A> =0A> Hello,=0A> =0A> I =0A> wanted to follow up on Fred's comment = earlier in this thread:=0A> =0A> =0A> >> OK. That will greatly simplify the= checks needed for new=0A> =0A> automatic tunneling protocols that have a f= ormat other=0A> than =0A> ip-proto-41.=0A> =0A> For the designers of new tu= nneling protocols, =0A> shall perhaps a recommendation on best practices be= =0A> included into the =0A> draft or another document, that for the new tun= nels a different protocol value =0A> /=0A> format should be used?=0A=0AAre = you are referring here to =0A> 'draft-nakibly-v6ops-tunnel-loop-01'?=0AIf s= o, IMHO this document would be the =0A> natural location for such a=0Arecom= mendation. =0A=0A> Examples of such =0A> protocol / formats could include u= sing a different next-protocol value, =0A> potentially=0A> with some multip= lexing schema if just using different =0A> next-protocol values is not scal= able, or=0A> possibly some other =0A> format.=0A=0AYes, I think it would be= very good to declare ip-proto-41 =0A> as=0Afully-developed and recommend t= hat new tunneling protocols use=0Aa =0A> different ip protocol number and/o= r TCP/UDP port number. This=0Awould greatly =0A> reduce the concern for hav= ing to go back and=0Arevisit tunneling =0A> implementations that perform sr= c/dst checks=0Aif a new tunneling protocol =0A> happens to emerge. Gabi - d= o you=0Ahave any thoughts on this?=0A=0AThanks - =0A> Fred=0A> href=3D"mail= to:fred.l.templin@boeing.com">fred.l.templin@boeing.com=0A=0A> =0A> Thank y= ou,=0A> Dmitry=0A> =0A> -----Original Message-----=0A> =0A> From: > href=3D= "mailto:ipv6-bounces@ietf.org">ipv6-bounces@ietf.org [mailto:> ymailto=3D"m= ailto:ipv6-bounces@ietf.org" =0A> href=3D"mailto:ipv6-bounces@ietf.org">ipv= 6-bounces@ietf.org] On Behalf Of =0A> Templin, Fred L=0A> Sent: Friday, Aug= ust 28, 2009 1:25 PM=0A> To: Gabi =0A> Nakibly; v6ops=0A> Cc: > href=3D"mai= lto:ipv6@ietf.org">ipv6@ietf.org; > ymailto=3D"mailto:secdir@ietf.org" =0A>= href=3D"mailto:secdir@ietf.org">secdir@ietf.org=0A> Subject: RE: Routing = =0A> loop attacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> > =0A> -----Or= iginal Message-----=0A> > From: Gabi Nakibly [mailto:> ymailto=3D"mailto:gn= akibly@yahoo.com" =0A> href=3D"mailto:gnakibly@yahoo.com">gnakibly@yahoo.co= m]=0A> > Sent: =0A> Friday, August 28, 2009 12:07 PM=0A> > To: Templin, Fre= d L; v6ops=0A> =0A> > Cc: > href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org; > = ymailto=3D"mailto:secdir@ietf.org" =0A> href=3D"mailto:secdir@ietf.org">sec= dir@ietf.org=0A> > Subject: Re: =0A> Routing loop attacks using IPv6 tunnel= s=0A> >=0A> > Correct. All =0A> the attacks rely on the fact that the ISATA= P router=0A> =0A> encapsulates/decapsulates a packet=0A> > the 6to4 relay = =0A> decapsulates/encapsulates, respectively. So the two=0A> tunnels must h= ave =0A> the same=0A> > encapsulation type.=0A> =0A> OK. That will greatly = =0A> simplify the checks needed for new=0A> automatic tunneling protocols t= hat =0A> have a format other=0A> than ip-proto-41.=0A> =0A> Fred=0A> > ymai= lto=3D"mailto:fred.l.templin@boeing.com" =0A> href=3D"mailto:fred.l.templin= @boeing.com">fred.l.templin@boeing.com=0A> =0A> =0A> > ----- Original Messa= ge ----=0A> > > From: "Templin, Fred =0A> L" <> href=3D"mailto:Fred.L.Templ= in@boeing.com">Fred.L.Templin@boeing.com>=0A> =0A> > > To: Gabi Nakibly <> = href=3D"mailto:gnakibly@yahoo.com">gnakibly@yahoo.com>; v6ops <> ymailto=3D= "mailto:v6ops@ops.ietf.org" =0A> href=3D"mailto:v6ops@ops.ietf.org">v6ops@o= ps.ietf.org>=0A> > > =0A> Cc: > href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org= ; > ymailto=3D"mailto:secdir@ietf.org" =0A> href=3D"mailto:secdir@ietf.org"= >secdir@ietf.org=0A> > > Sent: =0A> Friday, August 28, 2009 7:23:03 PM=0A> = > > Subject: RE: Routing loop =0A> attacks using IPv6 tunnels=0A> > >=0A> >= > Gabi,=0A> =0A> > >=0A> > > Correct me if I am wrong, but if there were a= new =0A> version=0A> > > of ISATAP that did not use ip-proto-41 encapsulat= ion =0A> but=0A> > > instead used a different kind of encapsulation, then = =0A> it=0A> > > need not concern itself with routing loop =0A> interactions= =0A> > > with 6to4 relays since 6to4 relays only know =0A> about=0A> > > ip= -proto-41. Does that match your understanding?=0A> =0A> > >=0A> > > Thanks = - Fred=0A> > > > ymailto=3D"mailto:fred.l.templin@boeing.com" =0A> href=3D"= mailto:fred.l.templin@boeing.com">fred.l.templin@boeing.com=0A> =0A> >=0A> = >=0A> >=0A> >=0A> =0A> ----------------------------------------------------= ----------------=0A> =0A> IETF IPv6 working group mailing list=0A> > href= =3D"mailto:ipv6@ietf.org">ipv6@ietf.org=0A> Administrative Requests: =0A> >= >https://www.ietf.org/mailman/listinfo/ipv6=0A> =0A> ---------------------= -----------------------------------------------=0A=0A=0A From owner-v6ops@ops.ietf.org Tue Mar 16 14:09:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C693A6AB3 for ; Tue, 16 Mar 2010 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.078 X-Spam-Level: X-Spam-Status: No, score=-109.078 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abYoD3ZD52yQ for ; Tue, 16 Mar 2010 14:09:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60CD13A6AA9 for ; Tue, 16 Mar 2010 14:09:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrdxo-000Hl4-71 for v6ops-data0@psg.com; Tue, 16 Mar 2010 21:06:08 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrdxl-000Hkb-KL for v6ops@ops.ietf.org; Tue, 16 Mar 2010 21:06:05 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJiPn0tAZnwM/2dsb2JhbACBRJlAc6FcmHmEdgQ X-IronPort-AV: E=Sophos;i="4.49,652,1262563200"; d="scan'208,217";a="93343626" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2010 21:06:04 +0000 Received: from [10.149.3.175] (rtp-vpn2-1455.cisco.com [10.82.245.176]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GL63jb017934 for ; Tue, 16 Mar 2010 21:06:04 GMT From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-227-556071310 Subject: Proposed agenda for IPv6 Operations - IETF 77 Date: Tue, 16 Mar 2010 17:06:03 -0400 Message-Id: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-227-556071310 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments please... Basically I am putting three security issues and two = 3GPP-relevant drafts on Monday morning and the remainder on Friday = morning. Each discussion gets about half an hour. If time permits in the = meeting, I'll pull agenda items forward from Friday to Monday. I have = two drafts on here that were not marked for v6ops but the authors asked = me to include; next time I'd appreciate it if folks used the = draft-*-v6ops-* naming convention; it makes my job easier. If I have = missed anything, let me know. IPv6 Operations - IETF 77 Monday 22 March, 9:00 AM Agenda bashing =20 Recommended Simple Security Capabilities in Customer Premises Equipment = for Providing Residential IPv6 Internet Service 18-Feb-10, Advanced Security for IPv6 CPE 8-Mar-10, Routing Loops using ISATAP and 6to4: Problem Statement and Proposed = Solutions 1-Feb-10, IPv6 in 3GPP Evolved Packet System 24-Feb-10, Mobile Networks Considerations for IPv6 Deployment 8-Mar-10, Friday 26 March, 9:00 AM Emerging Service Provider Scenarios for IPv6 Deployment 23-Feb-10, Unicast Transmission of IPv6 Multicast Messages on Link-layer 15-Feb-10, Neighbor Cache Protection in Neighbor Discovery Protocol 2-Mar-10, DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks 16-Feb-10, Advanced Requirements for IPv6 Customer Edge Routers 8-Mar-10, http://www.ipinc.net/IPv4.GIF --Apple-Mail-227-556071310 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations - IETF 77
Comments please... Basically I am putting three security issues and two 3GPP-relevant drafts on Monday morning and the remainder on Friday morning. Each discussion gets about half an hour. If time permits in the meeting, I'll pull agenda items forward from Friday to Monday. I have two drafts on here that were not marked for v6ops but the authors asked me to include; next time I'd appreciate it if folks used the draft-*-v6ops-* naming convention; it makes my job easier. If I have missed anything, let me know.

IPv6 Operations - IETF 77

Monday 22 March, 9:00 AM

Agenda bashing
 
Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
18-Feb-10, <draft-ietf-v6ops-cpe-simple-security-09.txt>
Advanced Security for IPv6 CPE
8-Mar-10, <draft-vyncke-advanced-ipv6-security-01.txt>
Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions
1-Feb-10, <draft-nakibly-v6ops-tunnel-loops-01.txt>

IPv6 in 3GPP Evolved Packet System
24-Feb-10, <draft-korhonen-v6ops-3gpp-eps-01.txt>
Mobile Networks Considerations for IPv6 Deployment
8-Mar-10, <draft-koodli-ipv6-in-mobile-networks-01.txt>

Friday 26 March, 9:00 AM

Emerging Service Provider Scenarios for IPv6 Deployment
23-Feb-10, <draft-carpenter-v6ops-isp-scenarios-01.txt>
Unicast Transmission of IPv6 Multicast Messages on Link-layer
15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>
Neighbor Cache Protection in Neighbor Discovery Protocol
2-Mar-10, <draft-jiang-v6ops-nc-protection-01.txt>
DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks
16-Feb-10, <draft-sarikaya-v6ops-prefix-delegation-00.txt>
Advanced Requirements for IPv6 Customer Edge Routers
8-Mar-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-02.txt>




--Apple-Mail-227-556071310-- From owner-v6ops@ops.ietf.org Tue Mar 16 14:09:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C051A3A6AAE for ; Tue, 16 Mar 2010 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.247 X-Spam-Level: X-Spam-Status: No, score=-109.247 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLqLkoHy39Yg for ; Tue, 16 Mar 2010 14:09:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBBAC3A676A for ; Tue, 16 Mar 2010 14:09:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nre0U-000ID6-LS for v6ops-data0@psg.com; Tue, 16 Mar 2010 21:08:54 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nre0S-000ICm-Eg for v6ops@ops.ietf.org; Tue, 16 Mar 2010 21:08:52 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIeQn0tAZnwM/2dsb2JhbACbBHOhU5h5hHYE X-IronPort-AV: E=Sophos;i="4.49,652,1262563200"; d="scan'208";a="93344098" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2010 21:08:39 +0000 Received: from [10.149.3.175] (rtp-vpn2-1455.cisco.com [10.82.245.176]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GL8dA5018483 for ; Tue, 16 Mar 2010 21:08:39 GMT From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Slides... Date: Tue, 16 Mar 2010 17:08:38 -0400 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks who wish to present, please post your slides (powerpoint or pdf) = to me by Sunday evening for me to post by Monday morning. http://www.ipinc.net/IPv4.GIF From v6ops-archive@megatron.ietf.org Tue Mar 16 18:52:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5AC3A6BB2 for ; Tue, 16 Mar 2010 18:52:16 -0700 (PDT) X-Quarantine-ID: <9JBgUeysdv0h> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 16 Mar 2010 18:52:09 -0700 (PDT) Received: from amcore.com (unknown [201.244.117.58]) by core3.amsl.com (Postfix) with SMTP id 45D213A6BA9 for ; Tue, 16 Mar 2010 18:51:59 -0700 (PDT) From: Approved VIAGRA® Store Subject: Confirmation ref # [305080] To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100317015200.45D213A6BA9@core3.amsl.com> Date: Tue, 16 Mar 2010 18:51:59 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 60016 Inc. All rights reserved.

From v6ops-archive@lists.ietf.org Tue Mar 16 19:26:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574113A6BC0 for ; Tue, 16 Mar 2010 19:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.219 X-Spam-Level: X-Spam-Status: No, score=-22.219 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qV8tsBRJCGX for ; Tue, 16 Mar 2010 19:26:00 -0700 (PDT) Received: from 200-113-107-11.static.tie.cl (200-113-107-11.static.tie.cl [200.113.107.11]) by core3.amsl.com (Postfix) with ESMTP id 2CEF13A6A9E for ; Tue, 16 Mar 2010 19:26:00 -0700 (PDT) From: Pfizer VIAGRA Reseller To: v6ops-archive@lists.ietf.org Subject: Dear v6ops-archive@lists.ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317022600.2CEF13A6A9E@core3.amsl.com> Date: Tue, 16 Mar 2010 19:26:00 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Ieuigop. All rights reserved.
From v6ops-archive@ietf.org Tue Mar 16 19:26:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622C13A6BC6 for ; Tue, 16 Mar 2010 19:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.089 X-Spam-Level: X-Spam-Status: No, score=-21.089 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH6yoBGNiYrW for ; Tue, 16 Mar 2010 19:26:14 -0700 (PDT) Received: from 200-113-107-11.static.tie.cl (200-113-107-11.static.tie.cl [200.113.107.11]) by core3.amsl.com (Postfix) with ESMTP id 2F2C13A6BB3 for ; Tue, 16 Mar 2010 19:26:04 -0700 (PDT) From: Pfizer VIAGRA Reseller To: v6ops-archive@ietf.org Subject: Dear v6ops-archive@ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317022605.2F2C13A6BB3@core3.amsl.com> Date: Tue, 16 Mar 2010 19:26:04 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Syg. All rights reserved.
From v6ops-archive@megatron.ietf.org Tue Mar 16 19:26:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A203A6BC6 for ; Tue, 16 Mar 2010 19:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.219 X-Spam-Level: X-Spam-Status: No, score=-22.219 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpfOrFDYAM01 for ; Tue, 16 Mar 2010 19:26:30 -0700 (PDT) Received: from 200-113-107-11.static.tie.cl (200-113-107-11.static.tie.cl [200.113.107.11]) by core3.amsl.com (Postfix) with ESMTP id 5120C3A6BC0 for ; Tue, 16 Mar 2010 19:26:09 -0700 (PDT) From: Pfizer VIAGRA Reseller To: v6ops-archive@megatron.ietf.org Subject: Dear v6ops-archive@megatron.ietf.org receive 80% OFF on Pfizer MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317022609.5120C3A6BC0@core3.amsl.com> Date: Tue, 16 Mar 2010 19:26:09 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Graphics not loaded? Hit this link

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Yibiuir. All rights reserved.
From v6ops-archive@megatron.ietf.org Tue Mar 16 19:33:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1433A6BC9 for ; Tue, 16 Mar 2010 19:33:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 16 Mar 2010 19:33:48 -0700 (PDT) Received: from andrew.com (unknown [121.96.165.168]) by core3.amsl.com (Postfix) with SMTP id 5E1CF3A6783 for ; Tue, 16 Mar 2010 19:33:44 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100317023345.5E1CF3A6783@core3.amsl.com> Date: Tue, 16 Mar 2010 19:33:44 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 06843 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 16 21:25:42 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3203A6892 for ; Tue, 16 Mar 2010 21:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.074 X-Spam-Level: X-Spam-Status: No, score=-98.074 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJnQ4MHcSWZx for ; Tue, 16 Mar 2010 21:25:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED3363A6833 for ; Tue, 16 Mar 2010 21:25:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrkkK-000HYW-Ok for v6ops-data0@psg.com; Wed, 17 Mar 2010 04:20:40 +0000 Received: from [192.51.44.37] (helo=fgwmail7.fujitsu.co.jp) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrkkH-000HYG-K1 for v6ops@ops.ietf.org; Wed, 17 Mar 2010 04:20:38 +0000 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o2H4KZUK009947 for (envelope-from matsuhira@jp.fujitsu.com); Wed, 17 Mar 2010 13:20:35 +0900 Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 45B3F45DE50 for ; Wed, 17 Mar 2010 13:20:35 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 1C40045DE4F for ; Wed, 17 Mar 2010 13:20:35 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id E1D33E38003 for ; Wed, 17 Mar 2010 13:20:34 +0900 (JST) Received: from m003.s.css.fujitsu.com (m003.s.css.fujitsu.com [10.23.4.33]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 7FA56E08001 for ; Wed, 17 Mar 2010 13:20:34 +0900 (JST) Received: from m003.css.fujitsu.com (m003 [127.0.0.1]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 667DE2DFA41; Wed, 17 Mar 2010 13:20:34 +0900 (JST) Received: from [127.0.0.1] (sirius6.sl051.dhcp.css.fujitsu.com [10.77.51.165]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 37FE02DF8B7; Wed, 17 Mar 2010 13:20:34 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Received: from sirius6[10.77.51.165] by sirius6 (FujitsuOutboundMailChecker v1.3.1/9992[10.77.51.165]); Wed, 17 Mar 2010 13:20:30 +0900 (JST) Message-ID: <4BA05888.2030401@jp.fujitsu.com> Date: Wed, 17 Mar 2010 13:20:24 +0900 From: Naoki Matsuhira User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> In-Reply-To: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, I would like to present "Stateless automatic IPv4 over IPv6 Tunneling (SA46T) draft. Could you add this to the agenda ? http://www.ietf.org/id/draft-matsuhira-sa46t-spec-00.txt http://www.ietf.org/id/draft-matsuhira-sa46t-gaddr-00.txt After submit these drafts, there are many positive reaction from the community in Japan. I believe this technology contribute to the Internet. Ten minutes are appropriate. These draft does not use *-v6ops-* naming convention. I apologizes to complex. Next update, I will change those. Naoki. Fred Baker wrote: > > Comments please... Basically I am putting three security issues and two > 3GPP-relevant drafts on Monday morning and the remainder on Friday > morning. Each discussion gets about half an hour. If time permits in the > meeting, I'll pull agenda items forward from Friday to Monday. I have > two drafts on here that were not marked for v6ops but the authors asked > me to include; next time I'd appreciate it if folks used the > draft-*-v6ops-* naming convention; it makes my job easier. If I have > missed anything, let me know. > > > IPv6 Operations - IETF 77 > > > Monday 22 March, 9:00 AM > > *Agenda bashing* > > *Recommended Simple Security Capabilities in Customer Premises Equipment > for Providing Residential IPv6 Internet Service* > > 18-Feb-10, > *Advanced Security for IPv6 CPE* > > 8-Mar-10, > *Routing Loops using ISATAP and 6to4: Problem Statement and Proposed > Solutions* > 1-Feb-10, > > *IPv6 in 3GPP Evolved Packet System* > > 24-Feb-10, > *Mobile Networks Considerations for IPv6 Deployment* > > 8-Mar-10, > > > Friday 26 March, 9:00 AM > > *Emerging Service Provider Scenarios for IPv6 Deployment* > > 23-Feb-10, > *Unicast Transmission of IPv6 Multicast Messages on Link-layer* > > 15-Feb-10, > *Neighbor Cache Protection in Neighbor Discovery Protocol* > > 2-Mar-10, > *DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks* > > 16-Feb-10, > *Advanced Requirements for IPv6 Customer Edge Routers* > > 8-Mar-10, > > > > > http://www.ipinc.net/IPv4.GIF > From v6ops-archive@megatron.ietf.org Wed Mar 17 00:28:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101A73A6867 for ; Wed, 17 Mar 2010 00:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.416 X-Spam-Level: X-Spam-Status: No, score=-14.416 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_NL=0.55, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_NL=1.545, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjDsujkfI5qk for ; Wed, 17 Mar 2010 00:28:15 -0700 (PDT) Received: from 5ED5E120.cable.ziggo.nl (5ED5E120.cable.ziggo.nl [94.213.225.32]) by core3.amsl.com (Postfix) with SMTP id B839F3A68AB for ; Wed, 17 Mar 2010 00:28:13 -0700 (PDT) To: Subject: Dear v6ops-archive, 15-22 March 2010 +4027 71% 0FF. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100317072813.B839F3A68AB@core3.amsl.com> Date: Wed, 17 Mar 2010 00:28:13 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 83% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-792-300-7549 from the U.S. & Canada or +328-49-8703313in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From v6ops-archive@megatron.ietf.org Wed Mar 17 01:02:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5FB3A67E3 for ; Wed, 17 Mar 2010 01:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.646 X-Spam-Level: X-Spam-Status: No, score=-16.646 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf1FG925HJN9 for ; Wed, 17 Mar 2010 01:02:38 -0700 (PDT) Received: from 87-119-235-52.saransk.ru (87-119-235-52.saransk.ru [87.119.235.52]) by core3.amsl.com (Postfix) with SMTP id 967413A68E6 for ; Wed, 17 Mar 2010 01:02:29 -0700 (PDT) To: Subject: v6ops-archive, 15-22 March +2153 77% Discount. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100317080229.967413A68E6@core3.amsl.com> Date: Wed, 17 Mar 2010 01:02:29 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 89% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-774-520-7847 from the U.S. & Canada or +392-53-1195102in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Wed Mar 17 08:28:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EC03A6C50 for ; Wed, 17 Mar 2010 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.006 X-Spam-Level: X-Spam-Status: No, score=-108.006 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BJjYgsDSNW4 for ; Wed, 17 Mar 2010 08:28:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A96D3A6C3E for ; Wed, 17 Mar 2010 08:27:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrv4M-000N1y-Ro for v6ops-data0@psg.com; Wed, 17 Mar 2010 15:22:02 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrv4J-000N1M-V4 for v6ops@ops.ietf.org; Wed, 17 Mar 2010 15:22:00 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuQoEtAaMHF/2dsb2JhbACbBHOfJZhohHYE Received: from syd-iport-2.cisco.com ([64.104.193.197]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2010 15:21:57 +0000 X-IronPort-AV: E=Sophos;i="4.49,657,1262563200"; d="scan'208";a="62342677" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by syd-iport-2.cisco.com with ESMTP; 17 Mar 2010 15:21:57 +0000 Received: from [10.149.3.219] ([10.21.119.236]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2HFLiNo001209; Wed, 17 Mar 2010 15:21:49 GMT Subject: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BA0EC66.3010403@piuha.net> Date: Wed, 17 Mar 2010 11:18:44 -0400 Cc: Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Content-Transfer-Encoding: quoted-printable Message-Id: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> To: IPv6 Operations X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a structured question for the community. Jari Arkko tells us that he is getting requests from various sources to = take RFC 5006 to Proposed Standard. It is now experimental. http://www.ietf.org/rfc/rfc5006.txt 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT=3D26136 bytes) (Status: EXPERIMENTAL) (1) Please take a look at the document in the next few days; if you have = comments on it (eg, you think it should be changed in some way), please = comment to v6ops. (2) Vendors, please advise on implementations. Are there any? Has = interoperability been demonstrated? (3) Operators, enterprise and/or service provider, please advise on = deployment experience. I'm adding a brief discussion to the agenda Monday morning with a view = to getting a quick thumbs-up/thumbs-down to advise Jari, who can then = take that to 6man later in the week if appropriate. BTW, I have had a flurry of email related to the agenda. The current = agenda may be found at = http://www.ietf.org/proceedings/10mar/agenda/v6ops.html= From owner-v6ops@ops.ietf.org Wed Mar 17 09:15:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807413A697F for ; Wed, 17 Mar 2010 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtvQc11W1tvb for ; Wed, 17 Mar 2010 09:15:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A560E3A6891 for ; Wed, 17 Mar 2010 09:15:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrvsB-0003P4-QT for v6ops-data0@psg.com; Wed, 17 Mar 2010 16:13:31 +0000 Received: from [2001:888:22b3::2] (helo=ecki.hack.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrvs9-0003OI-CX for v6ops@ops.ietf.org; Wed, 17 Mar 2010 16:13:29 +0000 Received: from localhost ([::1] helo=brain.hack.org) by ecki.hack.org with smtp id 1Nrvs7-000OBJ-Dt for v6ops@ops.ietf.org; Wed, 17 Mar 2010 17:13:27 +0100 Received: by brain.hack.org (sSMTP sendmail emulation); Wed, 17 Mar 2010 17:13:27 +0100 From: Michael Cardell Widerkrantz To: IPv6 Operations Subject: Re: RFC 5006 status Organization: Temple of the Moby Hack References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Date: Wed, 17 Mar 2010 17:13:27 +0100 In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> (Fred Baker's message of "Wed, 17 Mar 2010 11:18:44 -0400") Message-ID: <86fx3z3p08.fsf@brain.hack.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred Baker , 2010-03-17 16:18 (+0100): > This is a structured question for the community. > > Jari Arkko tells us that he is getting requests from various sources > to take RFC 5006 to Proposed Standard. It is now experimental. > > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=26136 bytes) (Status: EXPERIMENTAL) > > (2) Vendors, please advise on implementations. Are there any? Has > interoperability been demonstrated? Implementations of RFC 5006 known to me: - Server side: radvd, http://www.litech.org/radvd/ - Client side: My own radns, slowly getting there, http://hack.org/mc/hacks/radns/ rdnssd, now maintained as a part of ndisc6: http://rdnssd.linkfanel.net http://www.remlab.net/ndisc6/ radvd works well with both radns and rdnssd. > (3) Operators, enterprise and/or service provider, please advise on > deployment experience. I have so far only used this with a manual configuration in radvd, but I think this will typically be used in a home or SOHO environment where the ISP gives addresses to DNS resolvers to a home/small office router with DHCPv6 and that router, in turn, sends this information to end nodes with the RDNSS option in RA. -- http://hack.org/mc/ Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5. From uk@megatron.ietf.org Wed Mar 17 09:28:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8622C3A6A86 for ; Wed, 17 Mar 2010 09:28:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 17 Mar 2010 09:28:46 -0700 (PDT) Received: from mcc-dyn-254-237.kosnet.ru (mcc-dyn-254-237.kosnet.ru [93.181.254.237]) by core3.amsl.com (Postfix) with SMTP id AF65C3A6977 for ; Wed, 17 Mar 2010 09:28:38 -0700 (PDT) From: Approved VIAGRA® Store Subject: Confirmation ref # [683823] To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100317162839.AF65C3A6977@core3.amsl.com> Date: Wed, 17 Mar 2010 09:28:38 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 76016 Inc. All rights reserved.

From v6ops-archive@ietf.org Wed Mar 17 09:45:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B953A6A08 for ; Wed, 17 Mar 2010 09:45:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 17 Mar 2010 09:45:50 -0700 (PDT) Received: from agexpront.org.gt (unknown [190.71.120.40]) by core3.amsl.com (Postfix) with SMTP id AD3BE3A67A3 for ; Wed, 17 Mar 2010 09:45:37 -0700 (PDT) From: Approved VIAGRA® Store Subject: Electronic Discount Code 73% for v6ops-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100317-0, 17/03/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100317164537.AD3BE3A67A3@core3.amsl.com> Date: Wed, 17 Mar 2010 09:45:37 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 71900 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Wed Mar 17 09:48:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A223F3A6A48 for ; Wed, 17 Mar 2010 09:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[AWL=3.332, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzwmnp14oWhQ for ; Wed, 17 Mar 2010 09:48:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 228C53A6A08 for ; Wed, 17 Mar 2010 09:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrwML-00081B-Nq for v6ops-data0@psg.com; Wed, 17 Mar 2010 16:44:41 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrwMH-00080T-PU for v6ops@ops.ietf.org; Wed, 17 Mar 2010 16:44:38 +0000 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74541139; Wed, 17 Mar 2010 12:44:17 -0400 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 12:44:16 -0400 Received: from 147.191.223.83 ([147.191.223.83]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Mar 2010 16:44:16 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 17 Mar 2010 12:44:13 -0400 Subject: Re: RFC 5006 status From: "Durand, Alain" To: Fred Baker , IPv6 Operations CC: Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , , , , Daniel Park Message-ID: Thread-Topic: RFC 5006 status Thread-Index: AcrF6NWzwI63Q5B+QISjV0kH0VdhUAACD1Nk In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3351674654_5545301" X-OriginalArrivalTime: 17 Mar 2010 16:44:16.0596 (UTC) FILETIME=[15242140:01CAC5F1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351674654_5545301 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Fred, Here is my input to this. First of, we have in IPv6 two competing auto-config mechanisms: RA & DHCP. For a subset of parameters, they more or less overlap. For others, they do not. DNS is in the later category, only in the standard track for DHCP. An example of what can only be discovered with RA is default router or prefix info. This has been a very poisonous discussion for many years, with the result that the IPv6 autoconf story is more complicated that the IPv4 one. At this point, I would favor opening the larger discussion of =B3How can we fix this mess=B2 rather than pushing a particular technique from experimental to standard track. It might be that the only acceptable answer is we need to defined BOTH mechanisms for every value to discover. Now, about this particular document: 1. The interaction between DHCP & RA is not very well documented. 2. Why do we need a lifetime in that DNS RA? This create extra complexity for no apparent good reasons 3. What is the host suppose to do when it gets DNS RAs from **different** interfaces? Should it treat them the same as if they came from the same interface? Or is it that the information is tied to the prefix, not to the interface? In other words, it seem that the general cases beyond a single interface, single prefix are not well documented. - Alain. On 3/17/10 11:18 AM, "Fred Baker" wrote: > This is a structured question for the community. >=20 > Jari Arkko tells us that he is getting requests from various sources to t= ake > RFC 5006 to Proposed Standard. It is now experimental. >=20 > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=3D26136 bytes) (Status: EXPERIMENTAL) >=20 > (1) Please take a look at the document in the next few days; if you have > comments on it (eg, you think it should be changed in some way), please > comment to v6ops. >=20 > (2) Vendors, please advise on implementations. Are there any? Has > interoperability been demonstrated? >=20 > (3) Operators, enterprise and/or service provider, please advise on deplo= yment > experience. >=20 >=20 > I'm adding a brief discussion to the agenda Monday morning with a view to > getting a quick thumbs-up/thumbs-down to advise Jari, who can then take t= hat > to 6man later in the week if appropriate. >=20 >=20 >=20 > BTW, I have had a flurry of email related to the agenda. The current agen= da > may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html >=20 --B_3351674654_5545301 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: RFC 5006 status Fred,

Here is my input to this.

First of, we have in IPv6 two competing auto-config mechanisms: RA & DH= CP. For a subset of parameters, they more or less overlap. For others, they = do not.
DNS is in the later category, only in the standard track for DHCP. An examp= le of what can only be discovered with RA is default router or prefix info.<= BR> This has been a very poisonous discussion for many years, with the result t= hat the IPv6 autoconf story is more complicated that the IPv4 one.

At this point, I would favor opening the larger discussion of “How ca= n we fix this mess” rather than pushing a particular technique from ex= perimental to standard track.
It might be that the only acceptable answer is we need to defined BOTH mech= anisms for every value to discover.

Now, about this particular document:

  1. The interaction between DHCP & RA is not very we= ll documented.=20
  2. Why do we need a lifetime in that DNS RA? This create ex= tra complexity for no apparent good reasons
  3. What is the host suppose to do when it gets DNS RAs from= **different** interfaces? Should it treat them the same as if they came fro= m the same interface? Or is it that the information is tied to the prefix, n= ot to the interface?

In other words, it seem that the general cases beyond a single interface, s= ingle prefix are not well documented.

   - Alain.



On 3/17/10 11:18 AM, "Fred Baker" <fr= ed@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>This is a structured question for the community.=

Jari Arkko tells us that he is getting requests from various sources to tak= e RFC 5006 to Proposed Standard. It is now experimental.

http://www.ietf.org/rfc/rfc50= 06.txt
5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong,
    Ed., S. Park, L. Beloeil, S. Madanapalli. September= 2007. (Format:
    TXT=3D26136 bytes) (Status: EXPERIMENTAL)

(1) Please take a look at the document in the next few days; if you have co= mments on it (eg, you think it should be changed in some way), please commen= t to v6ops.

(2) Vendors, please advise on implementations. Are there any? Has interoper= ability been demonstrated?

(3) Operators, enterprise and/or service provider, please advise on deploym= ent experience.


I'm adding a brief discussion to the agenda Monday morning with a view to g= etting a quick thumbs-up/thumbs-down to advise Jari, who can then take that = to 6man later in the week if appropriate.



BTW, I have had a flurry of email related to the agenda. The current agenda= may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html

--B_3351674654_5545301-- From owner-v6ops@ops.ietf.org Wed Mar 17 11:21:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91B828C0FF for ; Wed, 17 Mar 2010 11:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.93 X-Spam-Level: X-Spam-Status: No, score=-103.93 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndrB8O6NpHbx for ; Wed, 17 Mar 2010 11:21:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7439328C0E8 for ; Wed, 17 Mar 2010 11:20:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrxnd-000Lux-5P for v6ops-data0@psg.com; Wed, 17 Mar 2010 18:16:57 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrxnb-000Luf-0b for v6ops@ops.ietf.org; Wed, 17 Mar 2010 18:16:55 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 45FAB90DAF84 for ; Wed, 17 Mar 2010 11:16:54 -0700 (PDT) X-AuditID: 1180711d-b7c97ae00000413c-e9-4ba11c948024 Received: from [17.151.87.11] (Unknown_Domain [17.151.87.11]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id B0.4D.16700.59C11AB4; Wed, 17 Mar 2010 11:16:54 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Date: Wed, 17 Mar 2010 11:16:52 -0700 Cc: IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Content-Transfer-Encoding: quoted-printable Message-Id: <4F4DB2B7-7ECC-4BB2-8AEB-510965AB308A@apple.com> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 17, 2010, at 08:18 , Fred Baker wrote: >=20 > (2) Vendors, please advise on implementations. Are there any? Has = interoperability been demonstrated? Both solicitor and advertiser sides of RFC 5006 are implemented in = Apple's AirPort Extreme and Time Capsule (simultaneous dual-band II) = firmware 7.5 and later. It was tested for interoperability with a Linux = implementation prior to its release. -- james woodyatt member of technical staff, communications engineering From v6ops-archive@ietf.org Wed Mar 17 11:52:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290913A69C0 for ; Wed, 17 Mar 2010 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.717 X-Spam-Level: X-Spam-Status: No, score=-38.717 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu12S4bO-G2D for ; Wed, 17 Mar 2010 11:52:16 -0700 (PDT) Received: from 114-39-99-48.dynamic.hinet.net (114-39-99-48.dynamic.hinet.net [114.39.99.48]) by core3.amsl.com (Postfix) with ESMTP id EF96A3A6972 for ; Wed, 17 Mar 2010 11:52:04 -0700 (PDT) From: Official Pfizer Pharmacy To: v6ops-archive@ietf.org Subject: User v6ops-archive receives 70% discounts on all products. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317185204.EF96A3A6972@core3.amsl.com> Date: Wed, 17 Mar 2010 11:52:04 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Try using this link in case of problems with images
 

c 1999-2009 NYMIL, Inc.
This e-mail was sent to v6ops-archive@ietf.org.

Click here to unsubscribe
From owner-v6ops@ops.ietf.org Wed Mar 17 11:52:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660583A688E for ; Wed, 17 Mar 2010 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6VBr4ggVgTy for ; Wed, 17 Mar 2010 11:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D01F03A6879 for ; Wed, 17 Mar 2010 11:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NryJ8-0001M6-Hq for v6ops-data0@psg.com; Wed, 17 Mar 2010 18:49:30 +0000 Received: from web111406.mail.gq1.yahoo.com ([67.195.15.162]) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NryJ6-0001Ll-9t for v6ops@ops.ietf.org; Wed, 17 Mar 2010 18:49:28 +0000 Received: (qmail 89352 invoked by uid 60001); 17 Mar 2010 18:49:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1268851767; bh=qFKOnj1gIej/uzDpfgSV6S6yPTnQJib36p+ZjLy/WJc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uia3c0ssUGW7XOQbOmAkn6Qaq5WK1whbMzQ2A4zP1+SuAgeO6JEcL6M5Ez2dl4+kWY/RpC7Ejo0ae1JxYfS+GQdlOJ2d00h0pD19aHmB7wRO4KGQ6oeM0JHr+nYkHJXScAyFrbrobVdX+5Kmh+jivIOIHFvYZMFr6n+wRyVUFOs= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mo6RHCFwLkQkzkXXuH76+NYWTlVLgVtTM5d6sar8lChoo+D8crhlS83iKAJARHVc2hRQpenhB/JQvEUF2Hd9/RN+Xofx8h0L5WEREuMgyUA/dBTVw8mCnGU12KqwWxpnbLcpWbvuIArWenYzkfjKhnOgQ2Yqk5/ld4wsbab2Oak=; Message-ID: <539561.84679.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: jDcW60UVM1m1mUXEOIgqIlGldOlvvQy7PbnUmx5a_N4M3ms Ao_pcpFe9uwAFH8PXIJ8Pv4BrqEuiF9dF4XYYy2X4e7PhU3Xp.CaWpoSWiYo K_YyvCkHu6e7q10o46TwQoK0JqpxN6mR5ud7GkFxMUB4lu92.VdIQFqUwbDd t2m9agxvBPeB20Gek.uj3Tu7393V03TOtRIe8ajNbMR8wbL.38KUIUt3BFi5 p.tSQFSkkokS1hKveZiOSOYFpNLwdPv.U04yF0LGqM5jFSGQIbecd30a29q6 ivzjpQG2dPbyrdb9sfwUdvsq5yExmdVgPjoCn3pjQ5Q-- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 17 Mar 2010 11:49:27 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: Date: Wed, 17 Mar 2010 11:49:27 -0700 (PDT) From: Behcet Sarikaya Reply-To: Behcet Sarikaya Subject: Re: RFC 5006 status To: "Durand, Alain" , Fred Baker , IPv6 Operations Cc: Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Alain,=0A=0A=0A>Here is my input to this.=0A>=0A>First of, we have in IP= v6 two competing auto-config mechanisms: RA & DHCP. For a subset of paramet= ers, they more or less overlap. For others, they do not.=0A>DNS is in the l= ater category, only in the standard track for DHCP. An example of what can = only be discovered with RA is default router or prefix info.=0A>This has be= en a very poisonous discussion for many years, with the result that the IPv= 6 autoconf story is more complicated that the IPv4 one.=0A>=0A>At this poin= t, I would favor opening the larger discussion of =E2=80=9CHow can we fix t= his mess=E2=80=9D rather than pushing a particular technique from experimen= tal to standard track.=0A>It might be that the only acceptable answer is we= need to defined BOTH mechanisms for every value to discover.=0A=0AI agree.= We need IPv4-like DHCP because it is needed in some networks and IPv6 auto= conf also because it is needed in some other networks.=0A=0A>=0A>Now, about= this particular document:=0A>=0A>=0A>=C2=A0=C2=A0=C2=A0=C2=A01. The intera= ction between DHCP & RA is not very well documented. =0A>=C2=A0=C2=A0=C2=A0= =C2=A02. Why do we need a lifetime in that DNS RA? This create extra comple= xity for no apparent good reasons =0A>=C2=A0=C2=A0=C2=A0=C2=A03. What is th= e host suppose to do when it gets DNS RAs from **different** interfaces? Sh= ould it treat them the same as if they came from the same interface? Or is = it that the information is tied to the prefix, not to the interface?=0A=0A= =0AThis issue is MIF WG issue and I think there is a draft on this issue al= ready.=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From v6ops-archive@lists.ietf.org Wed Mar 17 11:52:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF9D3A69C2 for ; Wed, 17 Mar 2010 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.716 X-Spam-Level: X-Spam-Status: No, score=-18.716 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkFAWVFAknFN for ; Wed, 17 Mar 2010 11:52:26 -0700 (PDT) Received: from 114-39-99-48.dynamic.hinet.net (114-39-99-48.dynamic.hinet.net [114.39.99.48]) by core3.amsl.com (Postfix) with ESMTP id 36DC53A6851 for ; Wed, 17 Mar 2010 11:52:15 -0700 (PDT) From: Official Pfizer Pharmacy To: v6ops-archive@lists.ietf.org Subject: User v6ops-archive receives 70% discounts on all products. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317185215.36DC53A6851@core3.amsl.com> Date: Wed, 17 Mar 2010 11:52:15 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Try using this link in case of problems with images
 

c 1999-2009 VEEJIZYF, Inc.
This e-mail was sent to v6ops-archive@lists.ietf.org.

Click here to unsubscribe
From v6ops-archive@megatron.ietf.org Wed Mar 17 11:52:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3843A6851 for ; Wed, 17 Mar 2010 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.717 X-Spam-Level: X-Spam-Status: No, score=-18.717 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytg6qRzopRuP for ; Wed, 17 Mar 2010 11:52:28 -0700 (PDT) Received: from 114-39-99-48.dynamic.hinet.net (114-39-99-48.dynamic.hinet.net [114.39.99.48]) by core3.amsl.com (Postfix) with ESMTP id DE16A3A69A3 for ; Wed, 17 Mar 2010 11:52:17 -0700 (PDT) From: Official Pfizer Pharmacy To: v6ops-archive@megatron.ietf.org Subject: User v6ops-archive receives 70% discounts on all products. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100317185217.DE16A3A69A3@core3.amsl.com> Date: Wed, 17 Mar 2010 11:52:17 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Try using this link in case of problems with images
 

c 1999-2009 YBEKUSEYW, Inc.
This e-mail was sent to v6ops-archive@megatron.ietf.org.

Click here to unsubscribe
From owner-v6ops@ops.ietf.org Wed Mar 17 12:08:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7CB3A69B2 for ; Wed, 17 Mar 2010 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z409ZC5rDIMK for ; Wed, 17 Mar 2010 12:08:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A0063A6972 for ; Wed, 17 Mar 2010 12:08:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NryZw-0003rB-9Y for v6ops-data0@psg.com; Wed, 17 Mar 2010 19:06:52 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NryZt-0003qr-UE for v6ops@ops.ietf.org; Wed, 17 Mar 2010 19:06:50 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 4588F89E1DEF for ; Wed, 17 Mar 2010 12:06:49 -0700 (PDT) X-AuditID: 11807137-b7c50ae0000001dd-71-4ba128483c84 Received: from [17.151.87.11] (Unknown_Domain [17.151.87.11]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 80.CB.00477.84821AB4; Wed, 17 Mar 2010 12:06:49 -0700 (PDT) From: james woodyatt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-635315871 Subject: Re: RFC 5006 status Date: Wed, 17 Mar 2010 12:06:48 -0700 In-Reply-To: To: IPv6 Operations References: Message-Id: <90376C60-E135-4ABB-8F04-FBF4FE40D42A@apple.com> X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-1-635315871 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 17, 2010, at 09:44 , Durand, Alain wrote: >=20 > Now, about this particular document: >=20 > The interaction between DHCP & RA is not very well documented. That could be improved when revising RFC 5006 for proposed standard. = Apple's implementation merges all IPv4 and IPv6 addresses for DNS = servers from all the available sources, DHCP4, DHCP6 and RFC 5006. > Why do we need a lifetime in that DNS RA? This create extra complexity = for no apparent good reasons Is the reason for the lifetime field really not apparent? It was = perfectly apparent to me when I implemented it, i.e. so that hosts will = stop using DNS servers when their lifetimes expire. This makes = renumbering less painful. I suppose you could argue that the router = lifetime should imply the DNS server lifetime, but that would be a weird = departure from the conventional architecture of ICMP6 timeout = parameters. > What is the host suppose to do when it gets DNS RAs from **different** = interfaces? Should it treat them the same as if they came from the same = interface? Or is it that the information is tied to the prefix, not to = the interface? The same thing the host does when it gets DNS server addresses from DHCP = servers on different interfaces. Multihomed hosts have a choice of = models for dealing with merging of DNS server configuration: A) merge = them all into one list, or B) merge them into a list per interface. = (The RDNSS options are not tied to PIO, so that's not an option.) > In other words, it seem that the general cases beyond a single = interface, single prefix are not well documented. Most of the issues here revolve around configuring multihome/multistack = hosts with recursive DNS server addresses from a variety of sources not = necessarily RFC 5006, and those issues should probably be addressed = separately whether RFC 5006 goes to proposed standard or not. There = really isn't very much here that makes RFC 5006 into a specific problem = in and of itself. We can argue about the lifetime parameter, which I = happen to think is a pretty good idea, but others may differ. -- james woodyatt member of technical staff, communications engineering --Apple-Mail-1-635315871 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Now, about this particular document:

  1. The interaction between DHCP & = RA is not very well documented.=20
That could be improved = when revising RFC 5006 for proposed standard.  Apple's = implementation merges all IPv4 and IPv6 addresses for DNS servers from = all the available sources, DHCP4, DHCP6 and RFC 5006.
  1. Why do we need a = lifetime in that DNS RA? This create extra complexity for no apparent = good reasons
Is the reason for the = lifetime field really not apparent?  It was perfectly apparent to = me when I implemented it, i.e. so that hosts will stop using DNS servers = when their lifetimes expire.  This makes renumbering less painful. =  I suppose you could argue that the router lifetime should imply = the DNS server lifetime, but that would be a weird departure from the = conventional architecture of ICMP6 timeout parameters.
  1. What is the host = suppose to do when it gets DNS RAs from **different** interfaces? Should = it treat them the same as if they came from the same interface? Or is it = that the information is tied to the prefix, not to the = interface?
The same thing = the host does when it gets DNS server addresses from DHCP servers on = different interfaces.  Multihomed hosts have a choice of models for = dealing with merging of DNS server configuration: A) merge them all into = one list, or B) merge them into a list per interface.  (The RDNSS = options are not tied to PIO, so that's not an = option.)

In other words, it seem that the general cases beyond a single = interface, single prefix are not well = documented.

Most of the = issues here revolve around configuring multihome/multistack hosts with = recursive DNS server addresses from a variety of sources not necessarily = RFC 5006, and those issues should probably be addressed separately = whether RFC 5006 goes to proposed standard or not.  There really = isn't very much here that makes RFC 5006 into a specific problem in and = of itself.  We can argue about the lifetime parameter, which I = happen to think is a pretty good idea, but others may = differ.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications = engineering


= --Apple-Mail-1-635315871-- From owner-v6ops@ops.ietf.org Wed Mar 17 13:54:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4ED3A680B for ; Wed, 17 Mar 2010 13:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaOT0jzqWVTo for ; Wed, 17 Mar 2010 13:54:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2AEC3A6976 for ; Wed, 17 Mar 2010 13:54:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns0B6-000Fyi-RN for v6ops-data0@psg.com; Wed, 17 Mar 2010 20:49:20 +0000 Received: from [202.136.110.253] (helo=smtp1.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns0B4-000FyO-1c for v6ops@ops.ietf.org; Wed, 17 Mar 2010 20:49:18 +0000 Received: from 219-90-163-205.ip.adam.com.au ([219.90.163.205] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Ns0B0-0005Vc-Es; Thu, 18 Mar 2010 07:19:14 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 5FFBE4930C; Thu, 18 Mar 2010 07:19:13 +1030 (CST) Date: Thu, 18 Mar 2010 07:19:12 +1030 From: Mark Smith To: Michael Cardell Widerkrantz Cc: IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100318071912.222745e0@opy.nosense.org> In-Reply-To: <86fx3z3p08.fsf@brain.hack.org> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <86fx3z3p08.fsf@brain.hack.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Wed, 17 Mar 2010 17:13:27 +0100 Michael Cardell Widerkrantz wrote: > Fred Baker , 2010-03-17 16:18 (+0100): > > > This is a structured question for the community. > > > > Jari Arkko tells us that he is getting requests from various sources > > to take RFC 5006 to Proposed Standard. It is now experimental. > > > > http://www.ietf.org/rfc/rfc5006.txt > > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > > TXT=26136 bytes) (Status: EXPERIMENTAL) > > > > (2) Vendors, please advise on implementations. Are there any? Has > > interoperability been demonstrated? > > Implementations of RFC 5006 known to me: > > - Server side: radvd, > > http://www.litech.org/radvd/ > > - Client side: > > My own radns, slowly getting there, > http://hack.org/mc/hacks/radns/ > > rdnssd, now maintained as a part of ndisc6: > http://rdnssd.linkfanel.net > http://www.remlab.net/ndisc6/ > > radvd works well with both radns and rdnssd. > radvd and radns have also worked successfully for me. > > (3) Operators, enterprise and/or service provider, please advise on > > deployment experience. > > I have so far only used this with a manual configuration in radvd, but I > think this will typically be used in a home or SOHO environment where > the ISP gives addresses to DNS resolvers to a home/small office router > with DHCPv6 and that router, in turn, sends this information to end > nodes with the RDNSS option in RA. > I've been thinking a bit about the RDNSS verses stateless DHCPv6 question a bit in the last few weeks. I think there is value in the RDNSS option, however I think it is only really useful for low end embedded devices - ones that are resource constrained to the point where running a stateless DHCPv6 client might be too much overhead, although that is a very low point though these days. Sensor networks could be an example. (I'm not sure if my perspective is correct, however I've started to think that the original boundary between RAs and Autoconf was a "bootstrap" connectivity boundary. RAs provided enough information for IPv6 to get to the point of being able to send packets beyond the local router, Autoconf was then to fill in other more user oriented / application supporting parameters. DNS certainly does fit into the latter category, although I can see it also being considered a bootstrap connectivity parameter, which is why the RDNSS option was created) However, I think the other parameters that RDNSS don't support, such as SIP servers or NTP servers, are going to be "widely" useful. I think it's inevitable that all telephones in people's homes will eventually be IP phones, and they'll need SIP server and possibly time server addresses. It's possible that all clocks on people's homes will eventually be "IP clocks" so announcing NTP servers may also be a wide spread requirement. In conjunction with the likely requirement of DHCPv6-PD on CPE, I think stateless DHCPv6 clients will be nearly ubiquitous on IPv6 devices. > -- > http://hack.org/mc/ > Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5. > From v6ops-archive@megatron.ietf.org Wed Mar 17 14:27:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539B53A676A for ; Wed, 17 Mar 2010 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.327 X-Spam-Level: X-Spam-Status: No, score=-13.327 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgK78+BVBJ6W for ; Wed, 17 Mar 2010 14:27:27 -0700 (PDT) Received: from 208-239-93-178.pool.ukrtel.net (208-239-93-178.pool.ukrtel.net [178.93.239.208]) by core3.amsl.com (Postfix) with SMTP id F35EB3A67BD for ; Wed, 17 Mar 2010 14:27:23 -0700 (PDT) To: Subject: Dear v6ops-archive, 15-22 March 2010 +1845 75% 0FF. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100317212723.F35EB3A67BD@core3.amsl.com> Date: Wed, 17 Mar 2010 14:27:23 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 85% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-075-205-6177 from the U.S. & Canada or +374-47-9889737in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Wed Mar 17 14:48:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F373A67BD for ; Wed, 17 Mar 2010 14:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7SGRG+iOvgy for ; Wed, 17 Mar 2010 14:48:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 212D83A676A for ; Wed, 17 Mar 2010 14:48:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns14u-000N3r-8o for v6ops-data0@psg.com; Wed, 17 Mar 2010 21:47:00 +0000 Received: from [209.85.222.195] (helo=mail-pz0-f195.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns14s-000N3Z-6l for v6ops@ops.ietf.org; Wed, 17 Mar 2010 21:46:58 +0000 Received: by pzk33 with SMTP id 33so20083pzk.5 for ; Wed, 17 Mar 2010 14:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ILQdpjkWEcdd8IvpT9uY4UT5a9sOftzIJwI3LYMPofc=; b=Eyhnm1UOxZ6HOirVPMqdqbWJ7JUrWo91ju1+7GMZyNXBtYwtfASLQucQ/NtLz6gtNs 5VlptU5epxO9kKqLs36Qf/ujMnPwvawY+MMISruPCNzrbMwxqyXfl3GOw4XEeJY1518R CSwJSWeqMMoxBZV4ZxSWmdX73qzd/PnjTze4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QzEUHNmwAWA1emeMwR3qwx7vhuRv426E2dnwRMHVRaZeIl6O7SLJIRky4t7/kE114u ztCMJak2nvPQV2tP1Pu5Ai15bW7arnoRH/t5CWPBSqxG4hSQ0QjRu8Av8BBU3zGH8myL VwJJqP6XplyLkmHMmwKHWO6+5tHH8IBqtkepw= Received: by 10.140.57.13 with SMTP id f13mr1753054rva.70.1268862417931; Wed, 17 Mar 2010 14:46:57 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm775529pzk.8.2010.03.17.14.46.54 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Mar 2010 14:46:56 -0700 (PDT) Message-ID: <4BA14DCB.4030804@gmail.com> Date: Thu, 18 Mar 2010 10:46:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This showed up as a requirement in the survey leading to draft-carpenter-v6ops-isp-scenarios-01: "Simple automatic distribution of DNS server details is essential; RFC 5006 support is needed." Only one ISP out of 30 mentioned this explicitly, although seven stated an intention to support SLAAC (often combined with DHCPv6). However, it does seem like the one essential feature for an all-SLAAC deployment. Regards Brian Carpenter On 2010-03-18 04:18, Fred Baker wrote: > This is a structured question for the community. > > Jari Arkko tells us that he is getting requests from various sources to take RFC 5006 to Proposed Standard. It is now experimental. > > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=26136 bytes) (Status: EXPERIMENTAL) > > (1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops. > > (2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated? > > (3) Operators, enterprise and/or service provider, please advise on deployment experience. > > > I'm adding a brief discussion to the agenda Monday morning with a view to getting a quick thumbs-up/thumbs-down to advise Jari, who can then take that to 6man later in the week if appropriate. > > > > BTW, I have had a flurry of email related to the agenda. The current agenda may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > From owner-v6ops@ops.ietf.org Wed Mar 17 20:50:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF5A3A6A95 for ; Wed, 17 Mar 2010 20:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.034 X-Spam-Level: X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+7cSwYeI3Pq for ; Wed, 17 Mar 2010 20:50:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFBFE3A68AD for ; Wed, 17 Mar 2010 20:50:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns6fR-00067h-47 for v6ops-data0@psg.com; Thu, 18 Mar 2010 03:45:05 +0000 Received: from [2a00:801::217:8ff:fe5b:81eb] (helo=uplift.swm.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns6fO-000670-4S for v6ops@ops.ietf.org; Thu, 18 Mar 2010 03:45:02 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id A37CD9E; Thu, 18 Mar 2010 04:44:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A28B49C; Thu, 18 Mar 2010 04:44:59 +0100 (CET) Date: Thu, 18 Mar 2010 04:44:59 +0100 (CET) From: Mikael Abrahamsson To: "Durand, Alain" cc: Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 17 Mar 2010, Durand, Alain wrote: > It might be that the only acceptable answer is we need to defined BOTH > mechanisms for every value to discover. I favour this approach. With my ISP hat on, I want everything that has to do with addresses to be handled by DHCPv6 (this is a MUST to have tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine this is totally the opposite of the original intentions of SLAAC. In a home scenario, I'd like to leave out the complexity of DHCPv6 if possible, so there I favour RFC5006. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Wed Mar 17 21:44:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D535828C0F0 for ; Wed, 17 Mar 2010 21:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9DhInbP5vY3 for ; Wed, 17 Mar 2010 21:44:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B59B3A6781 for ; Wed, 17 Mar 2010 21:44:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns7Yy-000BCP-3y for v6ops-data0@psg.com; Thu, 18 Mar 2010 04:42:28 +0000 Received: from [2001:1888:0:1:202:b3ff:fe1d:6b98] (helo=outgoing03.lava.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ns7Yv-000BCF-Kj for v6ops@ops.ietf.org; Thu, 18 Mar 2010 04:42:25 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTPS id 380591013F; Wed, 17 Mar 2010 18:42:19 -1000 (HST) Date: Wed, 17 Mar 2010 18:42:19 -1000 (HST) From: Antonio Querubin To: Fred Baker cc: IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Message-ID: References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 17 Mar 2010, Fred Baker wrote: > (3) Operators, enterprise and/or service provider, please advise on > deployment experience. No deployment experience here since none of our equipment currently supports it. But it would be a very welcome feature if hardware vendors began supporting it - the sooner the better. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From owner-v6ops@ops.ietf.org Thu Mar 18 01:09:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E533A6901 for ; Thu, 18 Mar 2010 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.08 X-Spam-Level: ** X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R51rl6SSALRx for ; Thu, 18 Mar 2010 01:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEA813A6831 for ; Thu, 18 Mar 2010 01:07:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsAgW-0002pn-Ho for v6ops-data0@psg.com; Thu, 18 Mar 2010 08:02:28 +0000 Received: from [194.109.24.21] (helo=smtp-vbr1.xs4all.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsAgU-0002pS-3C for v6ops@ops.ietf.org; Thu, 18 Mar 2010 08:02:26 +0000 Received: from sweet.marcoh.net (sweet.marcoh.net [195.64.86.179]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id o2I81YxH010880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Mar 2010 09:01:35 +0100 (CET) (envelope-from marcoh@marcoh.net) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marco Hogewoning In-Reply-To: Date: Thu, 18 Mar 2010 09:01:28 +0100 Cc: "Durand, Alain" , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Content-Transfer-Encoding: quoted-printable Message-Id: <292E01AA-2D10-42EA-99B2-F2BB44D7838F@marcoh.net> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18 mrt 2010, at 04:44, Mikael Abrahamsson wrote: > On Wed, 17 Mar 2010, Durand, Alain wrote: >=20 >> It might be that the only acceptable answer is we need to defined = BOTH mechanisms for every value to discover. >=20 > I favour this approach. With my ISP hat on, I want everything that has = to do with addresses to be handled by DHCPv6 (this is a MUST to have = tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine = this is totally the opposite of the original intentions of SLAAC. >=20 > In a home scenario, I'd like to leave out the complexity of DHCPv6 if = possible, so there I favour RFC5006. Count me in, although DHCPv6 would be used by the more demanding users I = can see a huge group of end-users who are perfectly ok with SLAAC on = their home network. MarcoH From owner-v6ops@ops.ietf.org Thu Mar 18 01:16:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E28F3A693B for ; Thu, 18 Mar 2010 01:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLfNHOSxzEpd for ; Thu, 18 Mar 2010 01:16:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43FA53A690F for ; Thu, 18 Mar 2010 01:15:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsAsT-0004O0-Vr for v6ops-data0@psg.com; Thu, 18 Mar 2010 08:14:49 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsAsR-0004NS-No for v6ops@ops.ietf.org; Thu, 18 Mar 2010 08:14:48 +0000 Received: (qmail 89522 invoked by uid 1007); 18 Mar 2010 09:14:45 +0100 Date: Thu, 18 Mar 2010 09:14:45 +0100 From: Gert Doering To: Mikael Abrahamsson Cc: "Durand, Alain" , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status Message-ID: <20100318081445.GC69383@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, Mar 18, 2010 at 04:44:59AM +0100, Mikael Abrahamsson wrote: > I favour this approach. With my ISP hat on, I want everything that has to > do with addresses to be handled by DHCPv6 (this is a MUST to have > tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine this > is totally the opposite of the original intentions of SLAAC. > > In a home scenario, I'd like to leave out the complexity of DHCPv6 if > possible, so there I favour RFC5006. Seconded, for both. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 01:54:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1053A6867 for ; Thu, 18 Mar 2010 01:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnFyhjI2hu6K for ; Thu, 18 Mar 2010 01:54:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7168B3A6831 for ; Thu, 18 Mar 2010 01:54:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBT8-000AEU-7g for v6ops-data0@psg.com; Thu, 18 Mar 2010 08:52:42 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBT4-000ADw-G0 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 08:52:40 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsBT1-0001bWC; Thu, 18 Mar 2010 09:52 +0100 Message-Id: To: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: In-reply-to: Your message of "Thu, 18 Mar 2010 04:44:59 +0100 (CET) ." Date: Thu, 18 Mar 2010 09:52:34 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 18 Mar 2010 04:44:59 +0100 (CET) Mikael Abrahamsson wrote: >On Wed, 17 Mar 2010, Durand, Alain wrote: > >> It might be that the only acceptable answer is we need to defined BOTH >> mechanisms for every value to discover. > >I favour this approach. With my ISP hat on, I want everything that has to >do with addresses to be handled by DHCPv6 (this is a MUST to have >tracability), the rest can be handled by SLAAC or DHCPv6. I'm curious, how does that work. Does each and every lightswitch at the customer have to individually request an IPv6 address from you using DHCPv6? Or do you also support giving the customer a /48 using PD? From owner-v6ops@ops.ietf.org Thu Mar 18 02:06:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E413A6906 for ; Thu, 18 Mar 2010 02:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ik2KxiosVx6 for ; Thu, 18 Mar 2010 02:06:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59DCC3A6874 for ; Thu, 18 Mar 2010 02:06:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBeM-000CDX-Fu for v6ops-data0@psg.com; Thu, 18 Mar 2010 09:04:18 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBeJ-000CCi-U7 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 09:04:16 +0000 Received: (qmail 96842 invoked by uid 1007); 18 Mar 2010 10:04:13 +0100 Date: Thu, 18 Mar 2010 10:04:13 +0100 From: Gert Doering To: Philip Homburg Cc: IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100318090413.GE69383@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, Mar 18, 2010 at 09:52:34AM +0100, Philip Homburg wrote: > I'm curious, how does that work. Does each and every lightswitch at the > customer have to individually request an IPv6 address from you using DHCPv6? > > Or do you also support giving the customer a /48 using PD? Well, what we envision is: - the CPE router gets a /48 or /56 by DHCP-PD - the CPE router does RA/5006 announcements so that "the light switches" can do SLAAC - other services (NTP, ...) will be discovered by service-location protocols running locally in the LAN (bonjour, SLP, ...) - OSX already does a great job here, in discovering stuff without having to fiddle with DHCP server setup etc. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 02:18:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E7E3A691B for ; Thu, 18 Mar 2010 02:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krf-YVKwa3M3 for ; Thu, 18 Mar 2010 02:18:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE9B63A6AC9 for ; Thu, 18 Mar 2010 02:18:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBpR-000Dum-G0 for v6ops-data0@psg.com; Thu, 18 Mar 2010 09:15:45 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBpO-000DuH-PT for v6ops@ops.ietf.org; Thu, 18 Mar 2010 09:15:43 +0000 Received: (qmail 61407 invoked from network); 18 Mar 2010 09:15:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Mar 2010 09:15:39 -0000 Date: Thu, 18 Mar 2010 10:15:39 +0100 (CET) Message-Id: <20100318.101539.74725695.sthaug@nethelp.no> To: gert@space.net Cc: swmike@swm.pp.se, alain_durand@cable.comcast.com, fred@cisco.com, v6ops@ops.ietf.org, kurtis@kurtis.pp.se, rdroms@cisco.com, 6man-chairs@tools.ietf.org, dthaler@windows.microsoft.com, jari.arkko@piuha.net, jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, soohong.park@samsung.com Subject: Re: RFC 5006 status From: sthaug@nethelp.no In-Reply-To: <20100318081445.GC69383@Space.Net> References: <20100318081445.GC69383@Space.Net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > I favour this approach. With my ISP hat on, I want everything that has to > > do with addresses to be handled by DHCPv6 (this is a MUST to have > > tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine this > > is totally the opposite of the original intentions of SLAAC. Agreed. Note that this includes having DHCPv6 delivering the default gateway. > > In a home scenario, I'd like to leave out the complexity of DHCPv6 if > > possible, so there I favour RFC5006. > > Seconded, for both. Agreed here too. Steinar Haug Senior network architect, Ventelo Networks (AS 2116) From owner-v6ops@ops.ietf.org Thu Mar 18 02:28:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509103A690E for ; Thu, 18 Mar 2010 02:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li6Jg4HbggNl for ; Thu, 18 Mar 2010 02:28:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B52693A6849 for ; Thu, 18 Mar 2010 02:28:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBzM-000F78-Gy for v6ops-data0@psg.com; Thu, 18 Mar 2010 09:26:00 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsBzK-000F6U-5n for v6ops@ops.ietf.org; Thu, 18 Mar 2010 09:25:58 +0000 Received: (qmail 1195 invoked by uid 1007); 18 Mar 2010 10:25:56 +0100 Date: Thu, 18 Mar 2010 10:25:56 +0100 From: Gert Doering To: sthaug@nethelp.no Cc: gert@space.net, swmike@swm.pp.se, alain_durand@cable.comcast.com, fred@cisco.com, v6ops@ops.ietf.org, kurtis@kurtis.pp.se, rdroms@cisco.com, 6man-chairs@tools.ietf.org, dthaler@windows.microsoft.com, jari.arkko@piuha.net, jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, soohong.park@samsung.com Subject: Re: RFC 5006 status Message-ID: <20100318092556.GF69383@Space.Net> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z9U9oWULJx7fFSwf" Content-Disposition: inline In-Reply-To: <20100318.101539.74725695.sthaug@nethelp.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --z9U9oWULJx7fFSwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote: > Note that this includes having DHCPv6 delivering the default gateway. This is not really important for us (no cable deployments, and the DSL deployment is PPP based, so the default gateway is always "the other end of the pipe" anyway). But I understand that other networks need this, so I'm certainly not opposing this. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --z9U9oWULJx7fFSwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQCVAwUBS6HxpKkuBuNlUUl1AQJqTgP9FSPQSV9s88dQAQ+0FCzqjQ2ncLj8qIob LiMPXdqswclOS7MrthYD55VSSUCbeu8RFhq7N5uGrO5+Nv7C5R7R6wSxJePp3YzA jr8RhBdrw32MQ9Q0vuweUHmeq2nLGdMJzP0B2v0H25f6y+m3+eJQf9zB2bmkcNAq zLIU+GQuFdo= =s12H -----END PGP SIGNATURE----- --z9U9oWULJx7fFSwf-- From owner-v6ops@ops.ietf.org Thu Mar 18 02:31:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442783A68F1 for ; Thu, 18 Mar 2010 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHUJeOF3Vkzp for ; Thu, 18 Mar 2010 02:31:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3721F3A68F0 for ; Thu, 18 Mar 2010 02:31:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsC3X-000FlB-P9 for v6ops-data0@psg.com; Thu, 18 Mar 2010 09:30:19 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsC3V-000Fko-IA for v6ops@ops.ietf.org; Thu, 18 Mar 2010 09:30:18 +0000 Received: (qmail 65282 invoked from network); 18 Mar 2010 09:30:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Mar 2010 09:30:16 -0000 Date: Thu, 18 Mar 2010 10:30:16 +0100 (CET) Message-Id: <20100318.103016.41657337.sthaug@nethelp.no> To: pch-v6ops@u-1.phicoh.com Cc: v6ops@ops.ietf.org Subject: Re: RFC 5006 status From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > >I favour this approach. With my ISP hat on, I want everything that has to > >do with addresses to be handled by DHCPv6 (this is a MUST to have > >tracability), the rest can be handled by SLAAC or DHCPv6. > > I'm curious, how does that work. Does each and every lightswitch at the > customer have to individually request an IPv6 address from you using DHCPv6? > > Or do you also support giving the customer a /48 using PD? The customer would receive a /56 or /48, depending on local policy. I would expect the customer to have a router which can then handle IPv6 addressing inside the customer's home. Steinar Haug Senior network architect, Ventelo Networks (AS 2116) From owner-v6ops@ops.ietf.org Thu Mar 18 02:41:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB4B3A68EA for ; Thu, 18 Mar 2010 02:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFVpaoZoQqfC for ; Thu, 18 Mar 2010 02:41:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9555C3A68D4 for ; Thu, 18 Mar 2010 02:41:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsCBj-000H59-Rj for v6ops-data0@psg.com; Thu, 18 Mar 2010 09:38:47 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsCBd-000H4X-1Q for v6ops@ops.ietf.org; Thu, 18 Mar 2010 09:38:45 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsCBb-0001blC; Thu, 18 Mar 2010 10:38 +0100 Message-Id: To: Gert Doering Cc: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: <20100318090413.GE69383@Space.Net> In-reply-to: Your message of "Thu, 18 Mar 2010 10:04:13 +0100 ." <20100318090413.GE69383@Space.Net> Date: Thu, 18 Mar 2010 10:38:38 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Thu, 18 Mar 2010 10:04:13 +0100 you wrote: >Hi, > >On Thu, Mar 18, 2010 at 09:52:34AM +0100, Philip Homburg wrote: >> I'm curious, how does that work. Does each and every lightswitch at the >> customer have to individually request an IPv6 address from you using DHCPv6? >> >> Or do you also support giving the customer a /48 using PD? > >Well, what we envision is: > > - the CPE router gets a /48 or /56 by DHCP-PD > - the CPE router does RA/5006 announcements so that "the light switches" > can do SLAAC > - other services (NTP, ...) will be discovered by service-location protocols > running locally in the LAN (bonjour, SLP, ...) - OSX already does a great > job here, in discovering stuff without having to fiddle with DHCP server > setup etc. Now assuming that the light switch also needs the current time. Probably using SNTP. I don't that many customers will dedicated NTP devices, so it is either the router that implements NTP or the ISP's NTP server will be used. So now the light switch has to implement one of those service location protocols as well? Or does it use DHCP? >From an implementors point of view, the main thing I find annoying about RFC-5006 is that information about DNS servers ends up in the kernel instead of in user land where I need it. And I don't want the kernel to store and forward all kinds of user land data. Of course, it is always possible to send an extra router solicitation ICMP from user land... I find it suprising that where essentially every IPv4 device can speak DHCPv4, we now envision IPv6 devices that do speak DNS, but cannot afford to speak enough of DHCPv6 to get the address of DNS resolvers. From owner-v6ops@ops.ietf.org Thu Mar 18 03:57:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B083A683C for ; Thu, 18 Mar 2010 03:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9T9WQTMYMLt for ; Thu, 18 Mar 2010 03:57:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 336A93A6774 for ; Thu, 18 Mar 2010 03:57:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDOb-0001YF-EH for v6ops-data0@psg.com; Thu, 18 Mar 2010 10:56:09 +0000 Received: from [74.125.82.180] (helo=mail-wy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDOZ-0001Y0-1C for v6ops@ops.ietf.org; Thu, 18 Mar 2010 10:56:07 +0000 Received: by wya21 with SMTP id 21so923607wya.11 for ; Thu, 18 Mar 2010 03:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D1sdfCHhumR62XRRsw5MJsA5kXW/X+e+Gmb+jy75m5I=; b=nz0iym4Fot9GSy4QETEzlUJg+rs5Dxl7zvs9vSbCMe1pg2i2+Lcds+YU/mw5j0wdvs RXKOmTJxR/Mlyj6Q02FUbeY86THPhvyjPh9AmNMl/l/Gu6tYuo5s+QvL925EDhuoiL/7 4KzCK4WYSLFHWS/QbQZoRDqseiyesnUsRgFVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gvJS226jmwjEODz8OFAMd01QlmoVEUo1MPQYrZ6wDUGLIKNYNyR8JguTIEy2kSQtBI IwBge3889kyLkb46ZmAiW7fyOmgoIc7mcuk+VaFGlOi7+kaeAVv683pyCkzYXDXRVoRq cfRjvMOzEih+SDH1EZWnk0E/bZH1DJTzsvKjk= MIME-Version: 1.0 Received: by 10.216.88.71 with SMTP id z49mr456322wee.90.1268909765523; Thu, 18 Mar 2010 03:56:05 -0700 (PDT) In-Reply-To: References: <20100318090413.GE69383@Space.Net> Date: Thu, 18 Mar 2010 11:56:05 +0100 Message-ID: <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> Subject: Re: RFC 5006 status From: Benoit Boissinot To: Philip Homburg Cc: Gert Doering , IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, Mar 18, 2010 at 10:38 AM, Philip Homburg wrote: > From an implementors point of view, the main thing I find annoying about > RFC-5006 is that information about DNS servers ends up in the kernel instead > of in user land where I need it. And I don't want the kernel to store and > forward all kinds of user land data. Of course, it is always possible to send > an extra router solicitation ICMP from user land... > As for as I know, rdnssd and radns both process the RA information in userspace. There's no handling of DNS in the kernel. regards, Benoit From owner-v6ops@ops.ietf.org Thu Mar 18 03:57:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D8E3A690A for ; Thu, 18 Mar 2010 03:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[AWL=-2.069, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H81C2Y+6niI for ; Thu, 18 Mar 2010 03:57:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE2243A686A for ; Thu, 18 Mar 2010 03:57:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDLO-00015d-B5 for v6ops-data0@psg.com; Thu, 18 Mar 2010 10:52:50 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDLI-000156-8t for v6ops@ops.ietf.org; Thu, 18 Mar 2010 10:52:45 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id C7C7BE08115; Thu, 18 Mar 2010 11:52:38 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 994C1E0809D; Thu, 18 Mar 2010 11:52:35 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100318092556.GF69383@Space.Net> Date: Thu, 18 Mar 2010 11:52:36 +0100 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: HI, Le 18 mars 2010 =E0 10:25, Gert Doering a =E9crit : > On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote: >> Note that this includes having DHCPv6 delivering the default gateway. >=20 > This is not really important for us (no cable deployments, and the DSL > deployment is PPP based, so the default gateway is always "the other = end > of the pipe" anyway). But I understand that other networks need this, > so I'm certainly not opposing this. Some time ago, Dan Wing proposed (I don't remember where) that RAs could = contain DHCP options that are worth advertising to all hosts. If generalized, this would permit to avoid reinventing in RAs options = that are available in DHCPv6, and yet make the DHCPv6 protocol to be in = general unnecessary. The simplicity of this approach is IMHO very attractive. Any thoughts? RD From owner-v6ops@ops.ietf.org Thu Mar 18 04:22:46 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA49F3A6ABA for ; Thu, 18 Mar 2010 04:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHqxgkQcm2Zw for ; Thu, 18 Mar 2010 04:22:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8F6D3A6A1F for ; Thu, 18 Mar 2010 04:22:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDlP-0005Kp-QL for v6ops-data0@psg.com; Thu, 18 Mar 2010 11:19:43 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsDlJ-0005J5-4U for v6ops@ops.ietf.org; Thu, 18 Mar 2010 11:19:41 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsDlE-0001bZC; Thu, 18 Mar 2010 12:19 +0100 Message-Id: To: Benoit Boissinot Cc: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> In-reply-to: Your message of "Thu, 18 Mar 2010 11:56:05 +0100 ." <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> Date: Thu, 18 Mar 2010 12:19:32 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Thu, 18 Mar 2010 11:56:05 +0100 you wrote: >On Thu, Mar 18, 2010 at 10:38 AM, Philip Homburg > wrote: >> From an implementors point of view, the main thing I find annoying about >> RFC-5006 is that information about DNS servers ends up in the kernel instead >> of in user land where I need it. And I don't want the kernel to store and >> forward all kinds of user land data. Of course, it is always possible to sen >d >> an extra router solicitation ICMP from user land... >> > >As for as I know, rdnssd and radns both process the RA information in >userspace. There's no handling of DNS in the kernel. A quick look at radns suggests that it doesn't send a router solicitation messages. So, if it misses the initial one that is requested by the kernel, it may take a while before you have your DNS addresses. I din't check the rdnssd code, but the manual says: "On Linux, since version 2.6.24, rdnssd takes advantage of a new "netlink interface, forwarding RDNSS options validated by the "kernel to user- land. Otherwise, it merely listens to all ICMPv6 "traffic through a raw socket. Which suggests extra kernel code, or the same problem as radns. From owner-v6ops@ops.ietf.org Thu Mar 18 04:41:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B7E3A6AC9 for ; Thu, 18 Mar 2010 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.263 X-Spam-Level: X-Spam-Status: No, score=-100.263 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gygU0w2vMXUT for ; Thu, 18 Mar 2010 04:41:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 663453A68D9 for ; Thu, 18 Mar 2010 04:41:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsE4M-00088K-8D for v6ops-data0@psg.com; Thu, 18 Mar 2010 11:39:18 +0000 Received: from [2001:888:22b3::2] (helo=ecki.hack.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsE4K-000880-8Y for v6ops@ops.ietf.org; Thu, 18 Mar 2010 11:39:16 +0000 Received: from localhost ([::1] helo=brain.hack.org) by ecki.hack.org with smtp id 1NsE4I-000123-CU for v6ops@ops.ietf.org; Thu, 18 Mar 2010 12:39:14 +0100 Received: by brain.hack.org (sSMTP sendmail emulation); Thu, 18 Mar 2010 12:39:14 +0100 From: Michael Cardell Widerkrantz To: IPv6 Operations Subject: Re: RFC 5006 status Organization: Temple of the Moby Hack References: <20100318090413.GE69383@Space.Net> Date: Thu, 18 Mar 2010 12:39:14 +0100 In-Reply-To: (Philip Homburg's message of "Thu, 18 Mar 2010 10:38:38 +0100") Message-ID: <86pr31luzh.fsf@brain.hack.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Philip Homburg , 2010-03-18 10:38 (+0100): > From an implementors point of view, the main thing I find annoying > about RFC-5006 is that information about DNS servers ends up in the > kernel instead of in user land where I need it. And I don't want the > kernel to store and forward all kinds of user land data. No client side implementation of RFC 5006 that I know of is done in a kernel. I guess I don't understand what you mean. Implementing an RFC 5006 client side would typically be done with ICMP6_FILTER_SETBLOCKALL(&filter); ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &filter); which then gives you RAs in your userland application, to be read from a socket just like any other network data. (Strictly speaking, all network data is passed through the kernel an almost all operating systems, but that, I guess, is beside the point.) -- http://hack.org/mc/ Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5. From owner-v6ops@ops.ietf.org Thu Mar 18 05:04:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A129C3A6965 for ; Thu, 18 Mar 2010 05:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1m13uC+pSNe for ; Thu, 18 Mar 2010 05:03:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D42543A6997 for ; Thu, 18 Mar 2010 05:03:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsEPQ-000Bbm-LF for v6ops-data0@psg.com; Thu, 18 Mar 2010 12:01:04 +0000 Received: from [140.77.166.68] (helo=toccata.ens-lyon.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsEPN-000Bau-8e for v6ops@ops.ietf.org; Thu, 18 Mar 2010 12:01:01 +0000 Received: from localhost (localhost [127.0.0.1]) by toccata.ens-lyon.org (Postfix) with ESMTP id 0AAFC8418E; Thu, 18 Mar 2010 13:00:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org Received: from toccata.ens-lyon.org ([127.0.0.1]) by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-a-2J5v+ZsS; Thu, 18 Mar 2010 13:00:57 +0100 (CET) Received: from localhost (dhcp-13-109.lip.ens-lyon.fr [140.77.13.109]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by toccata.ens-lyon.org (Postfix) with ESMTPSA id C136F8416C; Thu, 18 Mar 2010 13:00:57 +0100 (CET) Date: Thu, 18 Mar 2010 13:00:56 +0100 From: Benoit Boissinot To: Philip Homburg Cc: IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100318120056.GA29515@pirzuine> References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, Mar 18, 2010 at 12:19:32PM +0100, Philip Homburg wrote: > In your letter dated Thu, 18 Mar 2010 11:56:05 +0100 you wrote: > >On Thu, Mar 18, 2010 at 10:38 AM, Philip Homburg > > wrote: > >> From an implementors point of view, the main thing I find annoying > >> about RFC-5006 is that information about DNS servers ends up in the > >> kernel instead of in user land where I need it. And I don't want > >> the kernel to store and forward all kinds of user land data. Of > >> course, it is always possible to send an extra router solicitation > >> ICMP from user land... > >> > > > >As for as I know, rdnssd and radns both process the RA information in > >userspace. There's no handling of DNS in the kernel. > > A quick look at radns suggests that it doesn't send a router solicitation > messages. So, if it misses the initial one that is requested by the kernel, it > may take a while before you have your DNS addresses. > > I din't check the rdnssd code, but the manual says: > "On Linux, since version 2.6.24, rdnssd takes advantage of a new > "netlink interface, forwarding RDNSS options validated by the > "kernel to user- land. Otherwise, it merely listens to all ICMPv6 > "traffic through a raw socket. > > Which suggests extra kernel code, or the same problem as radns. Extra kernel code, yes. But it doesn't store or process anything related to the DNS servers. In the same way it already forwards address, prefix, lifetime, etc., it forwards the user options through netlink. It is not much more than what was previously forwarded, and the code is not specific to RDNSSD (it is a more generic "useropt" information). See here for the code: http://lxr.linux.no/linux+v2.6.33/net/ipv6/ndisc.c#L1373 regards, Benoit -- :wq From owner-v6ops@ops.ietf.org Thu Mar 18 05:24:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3CD3A6B80 for ; Thu, 18 Mar 2010 05:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.092 X-Spam-Level: * X-Spam-Status: No, score=1.092 tagged_above=-999 required=5 tests=[AWL=-2.267, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVlSZ5CNIKHf for ; Thu, 18 Mar 2010 05:24:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6C613A6B93 for ; Thu, 18 Mar 2010 05:22:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsEio-000EXc-TS for v6ops-data0@psg.com; Thu, 18 Mar 2010 12:21:06 +0000 Received: from [202.136.110.253] (helo=smtp1.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsEil-000EX1-Vs for v6ops@ops.ietf.org; Thu, 18 Mar 2010 12:21:04 +0000 Received: from 219-90-163-205.ip.adam.com.au ([219.90.163.205] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NsEih-0007uu-5k; Thu, 18 Mar 2010 22:50:59 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 9C0774930C; Thu, 18 Mar 2010 22:50:58 +1030 (CST) Date: Thu, 18 Mar 2010 22:50:58 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Cc: Gert Doering , IPv6 v6ops Subject: Re: RFC 5006 status Message-ID: <20100318225058.3c5ebb76@opy.nosense.org> In-Reply-To: <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 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 List-ID: On Thu, 18 Mar 2010 11:52:36 +0100 R=E9mi Despr=E9s wrote: > HI, >=20 > Le 18 mars 2010 =E0 10:25, Gert Doering a =E9crit : >=20 > > On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote: > >> Note that this includes having DHCPv6 delivering the default gateway. > >=20 > > This is not really important for us (no cable deployments, and the DSL > > deployment is PPP based, so the default gateway is always "the other end > > of the pipe" anyway). But I understand that other networks need this, > > so I'm certainly not opposing this. >=20 > Some time ago, Dan Wing proposed (I don't remember where) that RAs could = contain DHCP options that are worth advertising to all hosts. >=20 > If generalized, this would permit to avoid reinventing in RAs options tha= t are available in DHCPv6, and yet make the DHCPv6 protocol to be in genera= l unnecessary. >=20 > The simplicity of this approach is IMHO very attractive. >=20 > Any thoughts? >=20 Surely if everything is "crammed" into RAs, the only difference between RAs and stateless DHCPv6 is very slightly less CPU use on the client/server (i.e. typically router), very slightly less RAM on the client, and the ability of clients to ask for what they want and servers being selective about what they give certain clients, rather than getting everything in RA and then ignoring what they don't want. Those costs are all so low they're negligible, so I don't understand why people seem to be so focused on making RAs a slightly less capable substitute for stateless DHCPv6, at the cost of now having two nearly identical mechanisms to achieve the same goal. Antoine de Saint-Exup=E9ry said, "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away." I see adding all the stateless DHCPv6 parameters to RAs as adding something to RAs that, when added, should be taken away, because a simple mechanism already exists to perform those functions. Is there something I'm missing? From owner-v6ops@ops.ietf.org Thu Mar 18 06:17:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EB73A6A39 for ; Thu, 18 Mar 2010 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-1.602, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMAZ4qjnTEoT for ; Thu, 18 Mar 2010 06:17:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16D983A6AC6 for ; Thu, 18 Mar 2010 06:17:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsFXs-000MFM-K7 for v6ops-data0@psg.com; Thu, 18 Mar 2010 13:13:52 +0000 Received: from [209.85.219.209] (helo=mail-ew0-f209.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsFXq-000MEV-Ad for v6ops@ops.ietf.org; Thu, 18 Mar 2010 13:13:50 +0000 Received: by ewy1 with SMTP id 1so1153789ewy.38 for ; Thu, 18 Mar 2010 06:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=RR5G11p4GvvL2878yD8Z4UqyCeWCaoT3j4jKks3wun4=; b=xmuGvgKDyX0nahUaWpuLDDGMHXfREo3HXJ+ykNP4F2O6XQqxsISXN1r3/NeJsZxaul YJoPYWnqiv27sZDSusY5Z4eiIVXKuE1ZcFn0F7eTivBPkBBj6uXps2nUzGBALxdjronF 2f+XWzVoa2nwT36jzKGFbV47hbV6wV6nBhti4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=oOkzt+Us9LJ7eOusp8y69R1iIyT8r1NtRlp/dcqJS5wKt8lzkVreHLvD7TaSUthyAg pY+JUFhv0A2O0GaqApHVnTbHBtnUrVxc9G6gaBUAedhp8OjzuLU7eM8eanHH6/qettjx vkfQ5uMGOJZF4DBh23eLgpXr+TWdcoiXx/O6c= Received: by 10.213.109.212 with SMTP id k20mr4020237ebp.32.1268918028518; Thu, 18 Mar 2010 06:13:48 -0700 (PDT) Received: from ams3-vpn-dhcp4523.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 14sm5150039ewy.2.2010.03.18.06.13.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 06:13:47 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: Date: Thu, 18 Mar 2010 14:15:20 +0100 Cc: Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , , , , Daniel Park Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Durand, Alain" X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Here is my input to this. >=20 > First of, we have in IPv6 two competing auto-config mechanisms: RA & = DHCP. For a subset of parameters, they more or less overlap. For others, = they do not. > DNS is in the later category, only in the standard track for DHCP. An = example of what can only be discovered with RA is default router or = prefix info. > This has been a very poisonous discussion for many years, with the = result that the IPv6 autoconf story is more complicated that the IPv4 = one. >=20 > At this point, I would favor opening the larger discussion of =93How = can we fix this mess=94 rather than pushing a particular technique from = experimental to standard track. > It might be that the only acceptable answer is we need to defined BOTH = mechanisms for every value to discover. we already have proposals for doing other options in ND, which already = exist in DHCP. should we reconsider the idea of a generic DHCPv6 option container = option for ND? cheers, Ole From owner-v6ops@ops.ietf.org Thu Mar 18 06:52:49 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2833A6BC7 for ; Thu, 18 Mar 2010 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.937 X-Spam-Level: X-Spam-Status: No, score=-99.937 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm40zloclBi0 for ; Thu, 18 Mar 2010 06:52:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D7A93A6BC1 for ; Thu, 18 Mar 2010 06:52:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsG7u-0001iA-Ni for v6ops-data0@psg.com; Thu, 18 Mar 2010 13:51:06 +0000 Received: from [2001:888:22b3::2] (helo=ecki.hack.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsG7s-0001hs-9N for v6ops@ops.ietf.org; Thu, 18 Mar 2010 13:51:04 +0000 Received: from localhost ([::1] helo=brain.hack.org) by ecki.hack.org with smtp id 1NsG7q-0001NA-Qc for v6ops@ops.ietf.org; Thu, 18 Mar 2010 14:51:02 +0100 Received: by brain.hack.org (sSMTP sendmail emulation); Thu, 18 Mar 2010 14:51:02 +0100 From: Michael Cardell Widerkrantz To: IPv6 Operations Subject: Re: RFC 5006 status Organization: Temple of the Moby Hack References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> Date: Thu, 18 Mar 2010 14:51:02 +0100 In-Reply-To: (Philip Homburg's message of "Thu, 18 Mar 2010 12:19:32 +0100") Message-ID: <86634tlovt.fsf@brain.hack.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Philip Homburg , 2010-03-18 12:19 (+0100): > A quick look at radns suggests that it doesn't send a router > solicitation messages. True. Do you think it should? In many operating systems, the solicitation is sent from a userland program, in many called rtsol or rtsold. How rtsol and radns works together depends on the order in which they are started. If radns is always started before rtsol, the wait for an RA you hint at should disappear. I confess I haven't looked into this, really. Another idea I've had it so merge radns with rtsold. Opinions? -- http://hack.org/mc/ Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5. From owner-v6ops@ops.ietf.org Thu Mar 18 07:11:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29BF3A6BD8 for ; Thu, 18 Mar 2010 07:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzW84i7CDSO7 for ; Thu, 18 Mar 2010 07:11:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53E223A69D7 for ; Thu, 18 Mar 2010 07:11:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsGPk-0004nP-RV for v6ops-data0@psg.com; Thu, 18 Mar 2010 14:09:32 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsGPh-0004mx-0v for v6ops@ops.ietf.org; Thu, 18 Mar 2010 14:09:30 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsGPe-0001bdC; Thu, 18 Mar 2010 15:09 +0100 Message-Id: To: Michael Cardell Widerkrantz Cc: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: <20100318090413.GE69383@Space.Net> <86pr31luzh.fsf@brain.hack.org> In-reply-to: Your message of "Thu, 18 Mar 2010 12:39:14 +0100 ." <86pr31luzh.fsf@brain.hack.org> Date: Thu, 18 Mar 2010 15:09:26 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Thu, 18 Mar 2010 12:39:14 +0100 you wrote: >Philip Homburg , 2010-03-18 10:38 (+0100): > >> From an implementors point of view, the main thing I find annoying >> about RFC-5006 is that information about DNS servers ends up in the >> kernel instead of in user land where I need it. And I don't want the >> kernel to store and forward all kinds of user land data. > >No client side implementation of RFC 5006 that I know of is done in a >kernel. I guess I don't understand what you mean. Let's assume that I want DUD to start as soon as possible, so my kernel sends the first router solication as soon as the ethernet link is up. Then it may very well be that the kernel receives an RA before the user land DNS configuration program is running. Then the DNS option in the RA will be lost. So, the DNS configuration program has to send its own router solication. If DNS configuration data is actually distributed using DHCP, then we just wasted a multicast and interrupted all routers on the link. Solution, have the kernel store this information. Of course, we can pay attention to the other configuration bit in the RA, and have the kernel store that bit. Then, when that bit is set, we can try DHCP first and if that fails to return DNS servers fall back to sending a router solication. Possible, but annoying. From owner-v6ops@ops.ietf.org Thu Mar 18 07:11:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF333A6BDA for ; Thu, 18 Mar 2010 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.967 X-Spam-Level: X-Spam-Status: No, score=0.967 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfjqjmfPNuE3 for ; Thu, 18 Mar 2010 07:11:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 462CF3A6BD8 for ; Thu, 18 Mar 2010 07:11:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsGQW-0004tz-15 for v6ops-data0@psg.com; Thu, 18 Mar 2010 14:10:20 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsGQS-0004t1-SL for v6ops@ops.ietf.org; Thu, 18 Mar 2010 14:10:17 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 43ADDE08160; Thu, 18 Mar 2010 15:10:10 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2F90AE080DE; Thu, 18 Mar 2010 15:10:08 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100318225058.3c5ebb76@opy.nosense.org> Date: Thu, 18 Mar 2010 15:10:07 +0100 Cc: Gert Doering , IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Mark, Le 18 mars 2010 =E0 13:20, Mark Smith a =E9crit : > On Thu, 18 Mar 2010 11:52:36 +0100 > R=E9mi Despr=E9s wrote: >=20 >> HI, >>=20 >> Le 18 mars 2010 =E0 10:25, Gert Doering a =E9crit : >>=20 >>> On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote: >>>> Note that this includes having DHCPv6 delivering the default = gateway. >>>=20 >>> This is not really important for us (no cable deployments, and the = DSL >>> deployment is PPP based, so the default gateway is always "the other = end >>> of the pipe" anyway). But I understand that other networks need = this, >>> so I'm certainly not opposing this. >>=20 >> Some time ago, Dan Wing proposed (I don't remember where) that RAs = could contain DHCP options that are worth advertising to all hosts. >>=20 >> If generalized, this would permit to avoid reinventing in RAs options = that are available in DHCPv6, and yet make the DHCPv6 protocol to be in = general unnecessary. >>=20 >> The simplicity of this approach is IMHO very attractive. >>=20 >> Any thoughts? >>=20 >=20 > Surely if everything is "crammed" into RAs, the only difference = between > RAs and stateless DHCPv6 is very slightly less CPU use on the > client/server (i.e. typically router), very slightly less RAM on the > client, and the ability of clients to ask for what they > want and servers being selective about what they give certain clients, > rather than getting everything in RA and then ignoring what they > don't want. The point is to PERMIT, with a very simple extension of RAs, that all = common stateless parameters of hosts be available in RAs.=20 > Those costs are all so low they're negligible, so I don't > understand why people seem to be so focused on making RAs a slightly > less capable substitute for stateless DHCPv6, at the cost of now = having > two nearly identical mechanisms to achieve the same goal. >=20 > Antoine de Saint-Exup=E9ry said, "In anything at all, perfection is > finally attained not when there is no longer anything to add, but when > there is no longer anything to take away." I love this sentence, and have tried to work with it in mind for many = years. This is the case in particular for the subject at hand. (To me, in design efforts, MISS is even better than KISS: "MAKE It = Simple, Stupid" may take more time and energy than just "KEEP It Simple, = Stupid", but that's often worth it.) A given function shouldn't be made more complex than necessary for the = (wrong) reason that some of its uses are combined with more complex = functions. Hosts that need only stateless parameters shouldn't be obliged to pay = the cost of supporting the protocol that is needed for stateful = parameters.=20 One more protocol, even if requiring little RAM, is something = Saint-Exupery would suggest to get rid of. If you consider vendors of very small objects that will proliferate with = IPv6, they should be permitted to use IPv6 links between these objects = and their centralized controllers. Having in these objects all network parameters acquired in RAs is = simpler.=20 > I see adding all the stateless DHCPv6 parameters to RAs as adding > something to RAs that, when added, should be taken away, because a > simple mechanism already exists to perform those functions. Note that the idea is not to impose that "all" stateless parameters = should have to be advertised in RAs. It is only that hosts should be prepared to receive some DHCPv6 options = in RAs, with a standardized format for this (trivially simple to do). Options a host doesn't know, or want to know, are simply skipped (thanks = to the TLV format of options). That's it. There is no more to standardize. And IMHO, nothing will have to be taken away, at any time. > Is there something I'm missing? In my understanding, yes, as I tried to explain.=20 Regards, RD From secmech-request@lists.ietf.org Thu Mar 18 07:41:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190533A6C1D for ; Thu, 18 Mar 2010 07:41:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 18 Mar 2010 07:41:24 -0700 (PDT) Received: from 120babes.com (unknown [186.18.145.38]) by core3.amsl.com (Postfix) with SMTP id D4FB83A6C13 for ; Thu, 18 Mar 2010 07:41:17 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100318144122.D4FB83A6C13@core3.amsl.com> Date: Thu, 18 Mar 2010 07:41:17 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78091 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Thu Mar 18 08:06:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6083A686D for ; Thu, 18 Mar 2010 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAkCbl4c5LGJ for ; Thu, 18 Mar 2010 08:06:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54B143A688F for ; Thu, 18 Mar 2010 08:06:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsHEm-000GFQ-7d for v6ops-data0@psg.com; Thu, 18 Mar 2010 15:02:16 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsHEi-000GEL-Tz for v6ops@ops.ietf.org; Thu, 18 Mar 2010 15:02:13 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsHEf-0001c5C; Thu, 18 Mar 2010 16:02 +0100 Message-Id: To: Michael Cardell Widerkrantz Cc: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <86634tlovt.fsf@brain.hack.org> In-reply-to: Your message of "Thu, 18 Mar 2010 14:51:02 +0100 ." <86634tlovt.fsf@brain.hack.org> Date: Thu, 18 Mar 2010 16:02:08 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Thu, 18 Mar 2010 14:51:02 +0100 you wrote: >Philip Homburg , 2010-03-18 12:19 (+0100): >> A quick look at radns suggests that it doesn't send a router >> solicitation messages. > >True. Do you think it should? In many operating systems, the >solicitation is sent from a userland program, in many called rtsol or >rtsold. Yes, if you do that, and then intergrate radns in rtsol it should be no problem. But I'm not sure why you would want a user land rtsol. One thing I noticed when I accidentally plugged a Debian system into an ethernet port with the wrong vlan, is that the Linux kernel picks up new prefixes without invalidating the ones that belong to the old link. I see in the FreeBSD man page for rtsol that it sends out new router solications when the link status changes. (I don't know if old prefixes are also flushed). So I'm wondering how smart it is to have part of this processing in user space. My person reason for putting it in the kernel is to start DUD as soon as possible. From owner-v6ops@ops.ietf.org Thu Mar 18 10:23:13 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C373A6C5B for ; Thu, 18 Mar 2010 10:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.678 X-Spam-Level: X-Spam-Status: No, score=-8.678 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx3Wey-IKcyU for ; Thu, 18 Mar 2010 10:23:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEA5A3A6BB6 for ; Thu, 18 Mar 2010 10:17:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJJ3-000CUa-3m for v6ops-data0@psg.com; Thu, 18 Mar 2010 17:14:49 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJJ0-000CUC-Np for v6ops@ops.ietf.org; Thu, 18 Mar 2010 17:14:46 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,268,1267401600"; d="scan'208";a="168527827" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2010 17:14:42 +0000 Received: from sjc-vpnasa-326.cisco.com (sjc-vpnasa-326.cisco.com [10.21.105.72]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IHEffd008974; Thu, 18 Mar 2010 17:14:41 GMT Cc: Mikael Abrahamsson , Alain Durand , Baker Fred , IPv6 Operations , Lindqvist Kurt Erik , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Message-Id: From: Ralph Droms To: Gert Doering In-Reply-To: <20100318081445.GC69383@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 07:00:48 -0700 References: <20100318081445.GC69383@Space.Net> X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Stateless DHCPv6, in combination with RA/SLAAC address assignment, is simply not complex. It does not require a full DHCPv6 server, easily fits in resource constrained devices and can be configured automatically. Stateless DHCPv6 is certainly less complex than the DHCPv4 servers currently deployed in IPv4 gateways. - Ralph On Mar 18, 2010, at 1:14 AM 3/18/10, Gert Doering wrote: > Hi, > > On Thu, Mar 18, 2010 at 04:44:59AM +0100, Mikael Abrahamsson wrote: >> I favour this approach. With my ISP hat on, I want everything that >> has to >> do with addresses to be handled by DHCPv6 (this is a MUST to have >> tracability), the rest can be handled by SLAAC or DHCPv6. I'd >> imagine this >> is totally the opposite of the original intentions of SLAAC. >> >> In a home scenario, I'd like to leave out the complexity of DHCPv6 if >> possible, so there I favour RFC5006. > > Seconded, for both. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 10:23:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2913A6C5B for ; Thu, 18 Mar 2010 10:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.225 X-Spam-Level: X-Spam-Status: No, score=-8.225 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7fxgB6V879f for ; Thu, 18 Mar 2010 10:23:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61C673A6BC4 for ; Thu, 18 Mar 2010 10:17:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJHQ-000CHy-7E for v6ops-data0@psg.com; Thu, 18 Mar 2010 17:13:08 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJHN-000CHM-2g for v6ops@ops.ietf.org; Thu, 18 Mar 2010 17:13:05 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,268,1267401600"; d="scan'208";a="168526886" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2010 17:13:04 +0000 Received: from sjc-vpnasa-326.cisco.com (sjc-vpnasa-326.cisco.com [10.21.105.72]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2IHCjjs003032; Thu, 18 Mar 2010 17:13:03 GMT Cc: Mikael Abrahamsson , Alain Durand , Baker Fred , IPv6 Operations , Lindqvist Kurt Erik , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Message-Id: <088E7055-DD46-4382-AB4E-B41DE3841879@cisco.com> From: Ralph Droms To: Marco Hogewoning In-Reply-To: <292E01AA-2D10-42EA-99B2-F2BB44D7838F@marcoh.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 06:58:10 -0700 References: <292E01AA-2D10-42EA-99B2-F2BB44D7838F@marcoh.net> X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Giving a counterpoint opinion, home network users don't care which mix of RS/RA and DHCP is used on their networks, as long as they don't have to deal with it in any way. The combination of upstream DHCPv6/ PD provisioning, with automated config of ND and stateless DHCPv6 is easily deployable - I have an existence proof in my lab - and operates without any manual intervention whatsoever. Just as much plug-and- play as the IPv4/NAT/DHCP function in RGs. There are likely other network operators who do have to manually manage configs and the network that might prefer RA-only operation, but in my opinion home networks are not such a good example... - Ralph On Mar 18, 2010, at 1:01 AM 3/18/10, Marco Hogewoning wrote: > > On 18 mrt 2010, at 04:44, Mikael Abrahamsson wrote: > >> On Wed, 17 Mar 2010, Durand, Alain wrote: >> >>> It might be that the only acceptable answer is we need to defined >>> BOTH mechanisms for every value to discover. >> >> I favour this approach. With my ISP hat on, I want everything that >> has to do with addresses to be handled by DHCPv6 (this is a MUST to >> have tracability), the rest can be handled by SLAAC or DHCPv6. I'd >> imagine this is totally the opposite of the original intentions of >> SLAAC. >> >> In a home scenario, I'd like to leave out the complexity of DHCPv6 >> if possible, so there I favour RFC5006. > > > Count me in, although DHCPv6 would be used by the more demanding > users I can see a huge group of end-users who are perfectly ok with > SLAAC on their home network. > > MarcoH > From owner-v6ops@ops.ietf.org Thu Mar 18 10:27:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642153A6BAF for ; Thu, 18 Mar 2010 10:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.021 X-Spam-Level: X-Spam-Status: No, score=-8.021 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPrNYIFMbhv9 for ; Thu, 18 Mar 2010 10:27:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29D903A6C3E for ; Thu, 18 Mar 2010 10:21:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJPJ-000DYX-Nb for v6ops-data0@psg.com; Thu, 18 Mar 2010 17:21:17 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsJPH-000DY6-Eb for v6ops@ops.ietf.org; Thu, 18 Mar 2010 17:21:15 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,268,1267401600"; d="scan'208";a="168532360" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2010 17:21:14 +0000 Received: from sjc-vpnasa-326.cisco.com (sjc-vpnasa-326.cisco.com [10.21.105.72]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IHLE0s017708; Thu, 18 Mar 2010 17:21:14 GMT Cc: Alain Durand , Baker Fred , IPv6 Operations , Lindqvist Kurt Erik , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Message-Id: <9905A45A-22E7-4630-BF7B-B4DE989D007D@cisco.com> From: Ralph Droms To: Ole Troan In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 10:21:14 -0700 References: X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: No - IMO it would be a bad idea to define a generic RA container =20 option for DHCP options. (See previous e-mail.) - Ralph On Mar 18, 2010, at 6:15 AM 3/18/10, Ole Troan wrote: >> Here is my input to this. >> >> First of, we have in IPv6 two competing auto-config mechanisms: RA =20= >> & DHCP. For a subset of parameters, they more or less overlap. For =20= >> others, they do not. >> DNS is in the later category, only in the standard track for DHCP. =20= >> An example of what can only be discovered with RA is default router =20= >> or prefix info. >> This has been a very poisonous discussion for many years, with the =20= >> result that the IPv6 autoconf story is more complicated that the =20 >> IPv4 one. >> >> At this point, I would favor opening the larger discussion of =93How =20= >> can we fix this mess=94 rather than pushing a particular technique =20= >> from experimental to standard track. >> It might be that the only acceptable answer is we need to defined =20 >> BOTH mechanisms for every value to discover. > > we already have proposals for doing other options in ND, which =20 > already exist in DHCP. > should we reconsider the idea of a generic DHCPv6 option container =20 > option for ND? > > cheers, > Ole > From owner-v6ops@ops.ietf.org Thu Mar 18 12:30:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E033A681F for ; Thu, 18 Mar 2010 12:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.672 X-Spam-Level: X-Spam-Status: No, score=-7.672 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucZARxPRShFp for ; Thu, 18 Mar 2010 12:30:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACEBA3A67B4 for ; Thu, 18 Mar 2010 12:30:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLLQ-0006zK-Am for v6ops-data0@psg.com; Thu, 18 Mar 2010 19:25:24 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLLN-0006yz-VZ for v6ops@ops.ietf.org; Thu, 18 Mar 2010 19:25:22 +0000 Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK4aokurR7H+/2dsb2JhbACbLXOhPJh6hHkEgx0 X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="247333410" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2010 19:25:21 +0000 Received: from [72.163.75.201] ([72.163.75.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2IJPLfB025258; Thu, 18 Mar 2010 19:25:21 GMT Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Gert Doering , IPv6 v6ops Message-Id: From: Ralph Droms To: Mark Smith In-Reply-To: <20100318225058.3c5ebb76@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 12:25:20 -0700 References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark - it seems there is a strong opinion that "running stateless =20 DHCPv6" is onerous, and ND/RA is much less overhead. I don't share =20 that opinion - if the network operator really wants to configure all =20 those presumably identical parameters in every router - which is =20 required for ND/RA, one can just as easily configure and run a =20 stateless DHCPv6 server in each router. The stateless DHCPv6 server =20 is really, truly, uncomplicated to implement, configure and run. And, if the operator wants to centralize configuration, she can use =20 the more traditional centralized DHCPv6 server with relay agents in =20 all the routers. So, how is extending RAs to carry the DHCP options any less complicated? There is one way in which RAs involve less overhead - they can use =20 multicast to carry all the options in one message rather than use =20 individual message exchanges for each host. - Ralph On Mar 18, 2010, at 5:20 AM 3/18/10, Mark Smith wrote: > On Thu, 18 Mar 2010 11:52:36 +0100 > R=E9mi Despr=E9s wrote: > >> HI, >> >> Le 18 mars 2010 =E0 10:25, Gert Doering a =E9crit : >> >>> On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote: >>>> Note that this includes having DHCPv6 delivering the default =20 >>>> gateway. >>> >>> This is not really important for us (no cable deployments, and the =20= >>> DSL >>> deployment is PPP based, so the default gateway is always "the =20 >>> other end >>> of the pipe" anyway). But I understand that other networks need =20 >>> this, >>> so I'm certainly not opposing this. >> >> Some time ago, Dan Wing proposed (I don't remember where) that RAs =20= >> could contain DHCP options that are worth advertising to all hosts. >> >> If generalized, this would permit to avoid reinventing in RAs =20 >> options that are available in DHCPv6, and yet make the DHCPv6 =20 >> protocol to be in general unnecessary. >> >> The simplicity of this approach is IMHO very attractive. >> >> Any thoughts? >> > > Surely if everything is "crammed" into RAs, the only difference =20 > between > RAs and stateless DHCPv6 is very slightly less CPU use on the > client/server (i.e. typically router), very slightly less RAM on the > client, and the ability of clients to ask for what they > want and servers being selective about what they give certain clients, > rather than getting everything in RA and then ignoring what they > don't want. Those costs are all so low they're negligible, so I don't > understand why people seem to be so focused on making RAs a slightly > less capable substitute for stateless DHCPv6, at the cost of now =20 > having > two nearly identical mechanisms to achieve the same goal. > > Antoine de Saint-Exup=E9ry said, "In anything at all, perfection is > finally attained not when there is no longer anything to add, but when > there is no longer anything to take away." > > I see adding all the stateless DHCPv6 parameters to RAs as adding > something to RAs that, when added, should be taken away, because a > simple mechanism already exists to perform those functions. > > Is there something I'm missing? > From owner-v6ops@ops.ietf.org Thu Mar 18 12:31:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18993A686D for ; Thu, 18 Mar 2010 12:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K44JP7jIpvip for ; Thu, 18 Mar 2010 12:31:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE1D83A681F for ; Thu, 18 Mar 2010 12:31:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLQY-0007db-Aq for v6ops-data0@psg.com; Thu, 18 Mar 2010 19:30:42 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLQW-0007dG-5n for v6ops@ops.ietf.org; Thu, 18 Mar 2010 19:30:40 +0000 Received: (qmail 13794 invoked by uid 1007); 18 Mar 2010 20:30:36 +0100 Date: Thu, 18 Mar 2010 20:30:36 +0100 From: Gert Doering To: Ralph Droms Cc: Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Gert Doering , IPv6 v6ops Subject: Re: RFC 5006 status Message-ID: <20100318193036.GD69383@Space.Net> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JGRpDW+vuEVQ9uQb" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --JGRpDW+vuEVQ9uQb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 18, 2010 at 12:25:20PM -0700, Ralph Droms wrote: > There is one way in which RAs involve less overhead - they can use =20 > multicast to carry all the options in one message rather than use =20 > individual message exchanges for each host. Another nice benefit of RAs is that unsolicited RAs can be used to=20 add new prefix information (add prefix, deprecate prefix), which becomes=20 active right away - while DHCP information will only be refreshed upon, uh, client-initiated refresh. Please accept that RA is there to stay, and that this infighting between the two groups ("who needs RA when you can have DHCP!!!") is not going to help. The IETF has solidly messed up this part of IPv6 by delaying things for 10 years or so... "real world speaking", Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --JGRpDW+vuEVQ9uQb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQCVAwUBS6J/XKkuBuNlUUl1AQIDxAP/R+Md52+pgfLGHJdPTKvWWuy54B1L/LFD K3Rn0OJCQOqBK4Ro2AIPLCjgXQX9h4DAVAM35GVbU7XSPAHrM72JzpuJ0fsbhK8C 02yQuG+4SGA7ImTmdm303xGwKOgZB2MT+wRN48y68duiSxtrxLXzk1QWsQQhJCr1 2/5weIQ4cHo= =t9ll -----END PGP SIGNATURE----- --JGRpDW+vuEVQ9uQb-- From owner-v6ops@ops.ietf.org Thu Mar 18 12:41:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B082A3A6972 for ; Thu, 18 Mar 2010 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.519 X-Spam-Level: X-Spam-Status: No, score=-7.519 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWIs8es18w5l for ; Thu, 18 Mar 2010 12:41:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 946233A6899 for ; Thu, 18 Mar 2010 12:41:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLZq-0008ve-Kl for v6ops-data0@psg.com; Thu, 18 Mar 2010 19:40:18 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsLZo-0008ux-I7 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 19:40:16 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcdokurR7H+/2dsb2JhbACbLXOhQZh6hHkEgx0 X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="217625684" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2010 19:40:16 +0000 Received: from [72.163.75.201] ([72.163.75.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2IJeFD8009443; Thu, 18 Mar 2010 19:40:15 GMT Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Message-Id: From: Ralph Droms To: Gert Doering In-Reply-To: <20100318193036.GD69383@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 12:40:15 -0700 References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: You miss my point. I have no problem with using RAs for configuration. I don't see this as infighting - unless you consider the expression of a different opinion to be "infighting". I don't happen to share your opinion that "[t]he IETF has solidly messed up this part of IPv6 by delaying things for 10 years or so," which is truly not a helpful opinion. I'm just trying to make sure everyone has the facts straight. - Ralph On Mar 18, 2010, at 12:30 PM 3/18/10, Gert Doering wrote: > Hi, > > On Thu, Mar 18, 2010 at 12:25:20PM -0700, Ralph Droms wrote: >> There is one way in which RAs involve less overhead - they can use >> multicast to carry all the options in one message rather than use >> individual message exchanges for each host. > > Another nice benefit of RAs is that unsolicited RAs can be used to > add new prefix information (add prefix, deprecate prefix), which > becomes > active right away - while DHCP information will only be refreshed > upon, > uh, client-initiated refresh. > > Please accept that RA is there to stay, and that this infighting > between > the two groups ("who needs RA when you can have DHCP!!!") is not going > to help. The IETF has solidly messed up this part of IPv6 by delaying > things for 10 years or so... > > "real world speaking", > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 13:12:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799E93A67B2 for ; Thu, 18 Mar 2010 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csjfRXhHZxud for ; Thu, 18 Mar 2010 13:12:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50D3B3A693D for ; Thu, 18 Mar 2010 13:12:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsM34-000DM3-UD for v6ops-data0@psg.com; Thu, 18 Mar 2010 20:10:30 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsM32-000DKc-5W for v6ops@ops.ietf.org; Thu, 18 Mar 2010 20:10:28 +0000 Received: (qmail 17362 invoked by uid 1007); 18 Mar 2010 21:10:25 +0100 Date: Thu, 18 Mar 2010 21:10:25 +0100 From: Gert Doering To: Ralph Droms Cc: Gert Doering , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Subject: Re: RFC 5006 status Message-ID: <20100318201025.GE69383@Space.Net> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FtaeIcuxf2NsDdb4" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --FtaeIcuxf2NsDdb4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: > I don't happen to share your opinion that "[t]he IETF has solidly=20 > messed up this part of IPv6 by delaying things for 10 years or so,"=20 No need to share any opinion here. Just try to run an IPv6-only network with Windows, Linux and MacOS clients, and consider whether the IETF=20 might have given vendors better guidance. Or finished one or the other RFC 5 years earlier. As an operational person, this endless bickering between the RA camp and the "what do you need RA for that, when DHCP can do this all along" has FAIL stamped all over it. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --FtaeIcuxf2NsDdb4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQCVAwUBS6KIsakuBuNlUUl1AQIMvQP/V+KDMdE5ZlePhXn8HQpqoQrMNaez93SK eELtdRMkE0PCRZAFCybaQnCM27zRTrKsz8zUKWq6kBi5Vc3hEEiKq6RuLHjKob63 5jY6870SvKh7vCDXqWALwXkWfZDzDfXSFCSV2DoEQxAcgnIrMuUoBLbM1mxurBU3 a9F9RumX0Dw= =SIya -----END PGP SIGNATURE----- --FtaeIcuxf2NsDdb4-- From owner-v6ops@ops.ietf.org Thu Mar 18 13:35:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471FB3A69A0 for ; Thu, 18 Mar 2010 13:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=-1.753, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7M8DgoeeLxk for ; Thu, 18 Mar 2010 13:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3923D3A6968 for ; Thu, 18 Mar 2010 13:35:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMOC-000GKC-3W for v6ops-data0@psg.com; Thu, 18 Mar 2010 20:32:20 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMO8-000GHZ-Ca for v6ops@ops.ietf.org; Thu, 18 Mar 2010 20:32:16 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2IKW4g0000311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Mar 2010 13:32:07 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2IKW4lA006034; Thu, 18 Mar 2010 13:32:04 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2IKW3Fp006015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 18 Mar 2010 13:32:04 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 18 Mar 2010 13:32:04 -0700 From: "Templin, Fred L" To: Gert Doering , Ralph Droms CC: Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Date: Thu, 18 Mar 2010 13:32:01 -0700 Subject: RE: RFC 5006 status Thread-Topic: RFC 5006 status Thread-Index: AcrG2FzLO7wCyfNhQiqK0Rb51HneEQAASwZQ Message-ID: References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> In-Reply-To: <20100318201025.GE69383@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gert, > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behal= f Of Gert Doering > Sent: Thursday, March 18, 2010 1:10 PM > To: Ralph Droms > Cc: Gert Doering; Mark Smith; R=E9mi Despr=E9s; IPv6 v6ops > Subject: Re: RFC 5006 status >=20 > Hi, >=20 > On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: > > I don't happen to share your opinion that "[t]he IETF has solidly > > messed up this part of IPv6 by delaying things for 10 years or so," >=20 > No need to share any opinion here. Just try to run an IPv6-only network > with Windows, Linux and MacOS clients, and consider whether the IETF > might have given vendors better guidance. Or finished one or the other > RFC 5 years earlier. >=20 > As an operational person, this endless bickering between the RA camp and > the "what do you need RA for that, when DHCP can do this all along" has > FAIL stamped all over it. If you are meaning to blame the RA/DHCP discussions for the slow uptake of IPv6, I don't think that is correct. IPv6 was declared operational in 2002 and 8 years later we still have yet to see appreciable growth. But, that is a business case failing and not a protocol one. Fred fred.l.templin@boeing.com=20 > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 13:42:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A243A6BA3 for ; Thu, 18 Mar 2010 13:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.311 X-Spam-Level: X-Spam-Status: No, score=-99.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2djF+cVzfsGZ for ; Thu, 18 Mar 2010 13:42:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7B9E3A6B55 for ; Thu, 18 Mar 2010 13:42:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMXQ-000Hh9-A5 for v6ops-data0@psg.com; Thu, 18 Mar 2010 20:41:52 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMXO-000Hgs-2A for v6ops@ops.ietf.org; Thu, 18 Mar 2010 20:41:50 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id CABC68A4; Thu, 18 Mar 2010 21:41:45 +0100 (CET) To: Benoit Boissinot Subject: Re: RFC 5006 status MIME-Version: 1.0 Date: Thu, 18 Mar 2010 21:41:45 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Philip Homburg , Gert Doering , IPv6 Operations Organization: Remlab.net In-Reply-To: <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> Message-ID: <55ad5ed558fb34e580521f461d21c543@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 18 Mar 2010 11:56:05 +0100, Benoit Boissinot wrote: > On Thu, Mar 18, 2010 at 10:38 AM, Philip Homburg > wrote: >> From an implementors point of view, the main thing I find annoying about >> RFC-5006 is that information about DNS servers ends up in the kernel >> instead of in user land where I need it. And I don't want the kernel to >> store and forward all kinds of user land data. Of course, it is always >> possible to send an extra router solicitation ICMP from user land... There is no need to store it. It just needs to be forwarded. (Arguably though, the whole auto-configuration should be entirely done in user space anyway.) > As for as I know, rdnssd and radns both process the RA information in > userspace. There's no handling of DNS in the kernel. As one of the co-author of rdnssd, I can assure you that this is incorrect. rdnssd gets the RDNSS information from the Linux kernel via NetLink out of the kernel SLAAC code. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From owner-v6ops@ops.ietf.org Thu Mar 18 13:55:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25E83A6BF2 for ; Thu, 18 Mar 2010 13:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgQVQ3E08ggc for ; Thu, 18 Mar 2010 13:55:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 951FE3A6BCA for ; Thu, 18 Mar 2010 13:55:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMi8-000JTf-HT for v6ops-data0@psg.com; Thu, 18 Mar 2010 20:52:56 +0000 Received: from [140.77.166.68] (helo=toccata.ens-lyon.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMi5-000JT7-Qg for v6ops@ops.ietf.org; Thu, 18 Mar 2010 20:52:54 +0000 Received: from localhost (localhost [127.0.0.1]) by toccata.ens-lyon.org (Postfix) with ESMTP id 1EB3B8419F; Thu, 18 Mar 2010 21:52:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org Received: from toccata.ens-lyon.org ([127.0.0.1]) by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egnRYF15DMKH; Thu, 18 Mar 2010 21:52:51 +0100 (CET) Received: from localhost (wtf.punw.org [88.160.235.252]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by toccata.ens-lyon.org (Postfix) with ESMTPSA id B81508418F; Thu, 18 Mar 2010 21:52:50 +0100 (CET) Date: Thu, 18 Mar 2010 21:52:49 +0100 From: Benoit Boissinot To: =?iso-8859-1?Q?R=E9mi?= Denis-Courmont Cc: Philip Homburg , Gert Doering , IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100318205249.GF29515@pirzuine> References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <55ad5ed558fb34e580521f461d21c543@chewa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55ad5ed558fb34e580521f461d21c543@chewa.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, Mar 18, 2010 at 09:41:45PM +0100, Rmi Denis-Courmont wrote: > On Thu, 18 Mar 2010 11:56:05 +0100, Benoit Boissinot > wrote: > > On Thu, Mar 18, 2010 at 10:38 AM, Philip Homburg > > wrote: > >> From an implementors point of view, the main thing I find annoying about > >> RFC-5006 is that information about DNS servers ends up in the kernel > >> instead of in user land where I need it. And I don't want the kernel to > >> store and forward all kinds of user land data. Of course, it is always > >> possible to send an extra router solicitation ICMP from user land... > > There is no need to store it. It just needs to be forwarded. (Arguably > though, the whole auto-configuration should be entirely done in user space > anyway.) It would probably be a good idea, much more flexible than configuring via sysctl. > > > As for as I know, rdnssd and radns both process the RA information in > > userspace. There's no handling of DNS in the kernel. > > As one of the co-author of rdnssd, I can assure you that this is incorrect. > rdnssd gets the RDNSS information from the Linux kernel via NetLink out of > the kernel SLAAC code. I should have been clearer. There's indeed a forwarding, but no processing of the DNS information happens in the kernel. regards, Benoit -- :wq From owner-v6ops@ops.ietf.org Thu Mar 18 14:11:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491663A6900 for ; Thu, 18 Mar 2010 14:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.17 X-Spam-Level: X-Spam-Status: No, score=-101.17 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFPo7SAHlWLn for ; Thu, 18 Mar 2010 14:11:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE3563A6831 for ; Thu, 18 Mar 2010 14:11:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMyQ-000MHV-4w for v6ops-data0@psg.com; Thu, 18 Mar 2010 21:09:46 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsMyN-000MGm-T6 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 21:09:44 +0000 Received: (qmail 23109 invoked by uid 1007); 18 Mar 2010 22:09:41 +0100 Date: Thu, 18 Mar 2010 22:09:41 +0100 From: Gert Doering To: "Templin, Fred L" Cc: Gert Doering , Ralph Droms , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Subject: Re: RFC 5006 status Message-ID: <20100318210941.GG69383@Space.Net> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mpzwaonlGz3UQS74" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --mpzwaonlGz3UQS74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 18, 2010 at 01:32:01PM -0700, Templin, Fred L wrote: > > As an operational person, this endless bickering between the RA camp and > > the "what do you need RA for that, when DHCP can do this all along" has > > FAIL stamped all over it. >=20 > If you are meaning to blame the RA/DHCP discussions for > the slow uptake of IPv6, I don't think that is correct. Not alone so, of course. But the lack of standards and/or guidelines in=20 certain areas (RA/DHCP, multi6, selection of src+dst address pairs in the= =20 face of multiple source and destination IPv6 addresses being available) certainly didn't help. As I said: you still can't run an IPv6-only network with the most common client operating systems without manually configuring some missing bits and pieces. Had some standards be available 5 years earlier, most notably 5006, this might all be a non-issue today. Let me repeat: I'm an operational person, and not a researcher or=20 vendor. We funny operational people are not searching for the "most=20 religiously perfect" solution for things. We need something that=20 *works*, and we need it in a timely fashion. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --mpzwaonlGz3UQS74 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQCVAwUBS6KWlakuBuNlUUl1AQIFRAP7BIyi3UX8lKTOUb8KPqhw5xdAUEDxRJTV dfL1PSX9KjyQRxZ8rAG5GIEwJWjHpAbhJM21dy86OU2qOjRfdAO2MyiS2j6f6Jeb bxvSKrcA4bXlU7HnlC69+2iJbDcHQS7jXB2J0WXdfve+zXDA6JmlxkMRZVQ+i9x8 DaHnbHIuPw4= =kQxx -----END PGP SIGNATURE----- --mpzwaonlGz3UQS74-- From owner-v6ops@ops.ietf.org Thu Mar 18 14:19:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FE03A6968 for ; Thu, 18 Mar 2010 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.187 X-Spam-Level: X-Spam-Status: No, score=-4.187 tagged_above=-999 required=5 tests=[AWL=-2.022, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e4PxJY55+FA for ; Thu, 18 Mar 2010 14:19:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CADD63A68B9 for ; Thu, 18 Mar 2010 14:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsN78-000Ndd-Lz for v6ops-data0@psg.com; Thu, 18 Mar 2010 21:18:46 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsN76-000NdL-EZ for v6ops@ops.ietf.org; Thu, 18 Mar 2010 21:18:44 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2ILIXAK019359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Mar 2010 14:18:34 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2ILIX6k009053; Thu, 18 Mar 2010 14:18:33 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2ILIXDh009033 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 18 Mar 2010 14:18:33 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 18 Mar 2010 14:18:33 -0700 From: "Templin, Fred L" To: Gert Doering CC: Ralph Droms , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Date: Thu, 18 Mar 2010 14:18:30 -0700 Subject: RE: RFC 5006 status Thread-Topic: RFC 5006 status Thread-Index: AcrG31z4Fz51Dug0RIOo+d6GvnV7/AAAE0ZQ Message-ID: References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <20100318210941.GG69383@Space.Net> In-Reply-To: <20100318210941.GG69383@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-6.000.1038-17258.007 x-tm-as-result: No--63.683600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Thursday, March 18, 2010 2:10 PM > To: Templin, Fred L > Cc: Gert Doering; Ralph Droms; Mark Smith; R=E9mi Despr=E9s; IPv6 v6ops > Subject: Re: RFC 5006 status >=20 > Hi, >=20 > On Thu, Mar 18, 2010 at 01:32:01PM -0700, Templin, Fred L wrote: > > > As an operational person, this endless bickering between the RA camp = and > > > the "what do you need RA for that, when DHCP can do this all along" h= as > > > FAIL stamped all over it. > > > > If you are meaning to blame the RA/DHCP discussions for > > the slow uptake of IPv6, I don't think that is correct. >=20 > Not alone so, of course. But the lack of standards and/or guidelines in > certain areas (RA/DHCP, multi6, selection of src+dst address pairs in the > face of multiple source and destination IPv6 addresses being available) > certainly didn't help. >=20 > As I said: you still can't run an IPv6-only network with the most > common client operating systems without manually configuring some > missing bits and pieces. Had some standards be available 5 years > earlier, most notably 5006, this might all be a non-issue today. >=20 > Let me repeat: I'm an operational person, and not a researcher or > vendor. We funny operational people are not searching for the "most > religiously perfect" solution for things. We need something that > *works*, and we need it in a timely fashion. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Where is this pressure for this coming from? Are there customers waiting frustrated at your doorstep because you are not yet able to provide them a service they are longing to pay for? (Note: I am a firm believer in the need to move to IPv6 and have been pushing for it for close to 15 years now. But, I still don't see the developing business cases yet.) Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Thu Mar 18 14:47:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F49A3A6857 for ; Thu, 18 Mar 2010 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.11 X-Spam-Level: X-Spam-Status: No, score=-104.11 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TesrjHYl2-Ay for ; Thu, 18 Mar 2010 14:47:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 687E53A680B for ; Thu, 18 Mar 2010 14:47:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNVr-0000qj-4F for v6ops-data0@psg.com; Thu, 18 Mar 2010 21:44:19 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNVo-0000px-JN for v6ops@ops.ietf.org; Thu, 18 Mar 2010 21:44:17 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id A4FB89111F2A; Thu, 18 Mar 2010 14:44:15 -0700 (PDT) X-AuditID: 11807130-b7bdcae000007b51-40-4ba29eaf8a2e Received: from il0602b-dhcp111.apple.com (il0602b-dhcp111.apple.com [17.206.24.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id E0.BE.31569.FAE92AB4; Thu, 18 Mar 2010 14:44:15 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: Date: Thu, 18 Mar 2010 14:44:15 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <75A97C8E-0946-4EBD-8B05-536D5F56A9CF@apple.com> References: <20100318081445.GC69383@Space.Net> To: IPv6 Operations X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 18, 2010, at 07:00, Ralph Droms wrote: >=20 > Stateless DHCPv6, in combination with RA/SLAAC address assignment, is = simply not complex. It does not require a full DHCPv6 server, easily = fits in resource constrained devices and can be configured = automatically. >=20 > Stateless DHCPv6 is certainly less complex than the DHCPv4 servers = currently deployed in IPv4 gateways. This has been my experience. Configuring a stateless DHCP6 server is pretty easy compared to a = stateful DHCP4 server, where you're forced to manage address assignments = as well. If you've already inserted a DHCP4 server into your = residential gateway, it isn't that hard to add a stateless DHCP6 server = for just the IPv6 DNS server addresses. If RFC 5006 were to be revised for Standards Track category, then one = "improvement" we might consider is to require O=3D0 in router = advertisements that contain RDNSS options. This would go some way = toward addressing the ambiguity problem, while still allowing routers to = advertise O=3D0 and PIO with A=3D1 and expect that hosts that SLAAC = their addresses to those prefixes will be able, at least, to run = applications that require them to be able to resolve domain names. The main reason I'm a proponent of RFC 5006 is because it makes the O = bit in the router advertisement something that can usefully be set to = zero. I suppose another way forward would be to deprecate O=3D0 in = router advertisements. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Mar 18 14:59:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154D43A6A65 for ; Thu, 18 Mar 2010 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+b2qDMBvrNX for ; Thu, 18 Mar 2010 14:59:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C40D3A6A5C for ; Thu, 18 Mar 2010 14:59:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNjG-0002ms-BM for v6ops-data0@psg.com; Thu, 18 Mar 2010 21:58:10 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNjD-0002mK-I5 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 21:58:08 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2ILvfxZ025462; Thu, 18 Mar 2010 23:57:43 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 23:57:40 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 23:57:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 23:57:31 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 18 Mar 2010 22:57:30 +0100 From: To: , CC: , , <6man-chairs@tools.ietf.org>, , , , , , Date: Thu, 18 Mar 2010 22:57:27 +0100 Subject: RE: RFC 5006 status Thread-Topic: RFC 5006 status Thread-Index: AcrF51Clny5kg80jTUe6vIg1croVowA/iocw Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589CD258CB@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2010 21:57:31.0405 (UTC) FILETIME=[022223D0:01CAC6E6] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We have implemented this on Symbian OS and on Nokia S40 OS. Tested against = RADVD and TAHI. Not released in products yet. Would like to see this go to Proposed Standard. Best regards, Teemu > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of ext Fred Baker > Sent: 17. maaliskuuta 2010 17:19 > To: IPv6 Operations > Cc: Lindqvist Kurt Erik; Ralph Droms; 6man Chairs; Dave Thaler; Jari > Arkko; jjeong@cs.umn.edu; luc.beloeil@orange-ftgroup.com; > smadanapalli@gmail.com; Daniel Park > Subject: RFC 5006 status >=20 > This is a structured question for the community. >=20 > Jari Arkko tells us that he is getting requests from various sources to > take RFC 5006 to Proposed Standard. It is now experimental. >=20 > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=3D26136 bytes) (Status: EXPERIMENTAL) >=20 > (1) Please take a look at the document in the next few days; if you > have comments on it (eg, you think it should be changed in some way), > please comment to v6ops. >=20 > (2) Vendors, please advise on implementations. Are there any? Has > interoperability been demonstrated? >=20 > (3) Operators, enterprise and/or service provider, please advise on > deployment experience. >=20 >=20 > I'm adding a brief discussion to the agenda Monday morning with a view > to getting a quick thumbs-up/thumbs-down to advise Jari, who can then > take that to 6man later in the week if appropriate. >=20 >=20 >=20 > BTW, I have had a flurry of email related to the agenda. The current > agenda may be found at > http://www.ietf.org/proceedings/10mar/agenda/v6ops.html From owner-v6ops@ops.ietf.org Thu Mar 18 15:00:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF143A6BB2 for ; Thu, 18 Mar 2010 15:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.884, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsGnUhVR82WT for ; Thu, 18 Mar 2010 15:00:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14BB43A6BA8 for ; Thu, 18 Mar 2010 15:00:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNld-000391-2u for v6ops-data0@psg.com; Thu, 18 Mar 2010 22:00:37 +0000 Received: from [209.85.220.219] (helo=mail-fx0-f219.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNla-00038b-QD for v6ops@ops.ietf.org; Thu, 18 Mar 2010 22:00:34 +0000 Received: by fxm19 with SMTP id 19so120620fxm.1 for ; Thu, 18 Mar 2010 15:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kRZdXso8QsjfPHg6tczvrKX7o8FvhwMCckxHL08AbxM=; b=uRZwP/kaPfg4SB/bRUxUqfZs0CKGZVVgIIxPoC7fZEev2OvpSVGd3Q63A9rl8+SuWM ub3PoHhszX9fT8/7jny9bCbqNcfzGPOkB24CM8byUop4J0XURFK49eWl+wU5rtyLV16Y RsBDxVlvBEIP4qQvWVZ29y9v/giLQjAZKyuUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=YIWgY7lhQPnJfH/Yp+JC1lfs4UWoneSm6yGGtrUUsoli/bclfaFfxWl61E3Z/ea2GP QM3D49NTX6Jv1cqdA+1RzeRvrR9s2yBmB69Sz0Sk6vIOlllxivYU/JVxwrH48d6JrMi4 SbEzsfE/ATTEUFNPBrVEcDGsv5mcMLCXV4mc4= Received: by 10.223.7.69 with SMTP id c5mr8864571fac.14.1268949633147; Thu, 18 Mar 2010 15:00:33 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 26sm739805fks.22.2010.03.18.15.00.28 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 15:00:31 -0700 (PDT) Message-ID: <4BA2A275.3030603@gmail.com> Date: Fri, 19 Mar 2010 11:00:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: Gert Doering , Ralph Droms , Mark Smith , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops Subject: Re: RFC 5006 status References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <20100318210941.GG69383@Space.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, >> Let me repeat: I'm an operational person, and not a researcher or >> vendor. We funny operational people are not searching for the "most >> religiously perfect" solution for things. We need something that >> *works*, and we need it in a timely fashion. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Where is this pressure for this coming from? Are there > customers waiting frustrated at your doorstep because > you are not yet able to provide them a service they are > longing to pay for? (Note: I am a firm believer in the > need to move to IPv6 and have been pushing for it for > close to 15 years now. But, I still don't see the > developing business cases yet.) If you have a defective egg, you may not get a chicken at all. The time pressure is at http://www.potaroo.net/tools/ipv4/, and the ISPs we've surveyed have given 2011 as the most common date when they want to offer IPv6 as a standard service. [Shameless plug for my presentation in v6ops and iepg.] Getting back to the purpose of this thread, I've seen enough responses describing operational value in 5006 to convince me that we should standardise it for use in simple deployments. I can't see a downside, quite regardless of who chooses to deploy DHCPv6; that is a separate question entirely. Brian From owner-v6ops@ops.ietf.org Thu Mar 18 15:13:36 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4A33A6AF4 for ; Thu, 18 Mar 2010 15:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMEWZxBT2aqu for ; Thu, 18 Mar 2010 15:13:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05C363A6BB9 for ; Thu, 18 Mar 2010 15:13:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNww-0004gY-Jj for v6ops-data0@psg.com; Thu, 18 Mar 2010 22:12:18 +0000 Received: from [202.136.110.253] (helo=smtp1.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsNwt-0004f7-58 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 22:12:15 +0000 Received: from 219-90-163-205.ip.adam.com.au ([219.90.163.205] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NsNwU-0006gX-R0; Fri, 19 Mar 2010 08:41:50 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 80F434930C; Fri, 19 Mar 2010 08:41:49 +1030 (CST) Date: Fri, 19 Mar 2010 08:41:49 +1030 From: Mark Smith To: Ole Troan Cc: "Durand, Alain" , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , , , , Daniel Park Subject: Re: RFC 5006 status Message-ID: <20100319084149.389ac8fc@opy.nosense.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 18 Mar 2010 14:15:20 +0100 Ole Troan wrote: > > Here is my input to this. > >=20 > > First of, we have in IPv6 two competing auto-config mechanisms: RA & = DHCP. For a subset of parameters, they more or less overlap. For others, = they do not. > > DNS is in the later category, only in the standard track for DHCP. An= example of what can only be discovered with RA is default router or pref= ix info. > > This has been a very poisonous discussion for many years, with the re= sult that the IPv6 autoconf story is more complicated that the IPv4 one. > >=20 > > At this point, I would favor opening the larger discussion of =93How = can we fix this mess=94 rather than pushing a particular technique from e= xperimental to standard track. > > It might be that the only acceptable answer is we need to defined BOT= H mechanisms for every value to discover. >=20 > we already have proposals for doing other options in ND, which already = exist in DHCP. > should we reconsider the idea of a generic DHCPv6 option container opti= on for ND? >=20 We could also have a go at re-inventing the wheel. Sorry to be sarcastic, but now is not the time to be clean slating autoconf methods when there is not another 10 to 15 years before we need to deploy IPv6. Further more, going down that path now will cause even more people to hesitate to deploy it - including me. Why would I want to invest time in deploying today's autoconf methods that work if there is a chance that they'll be completely replaced in 5 to 10 years? People need to accept the existing methods, even though they may not be completely happy with them. The time to influence their design has gone - it was 15 years ago. > cheers, > Ole >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 15:26:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4ABD3A676A for ; Thu, 18 Mar 2010 15:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.468 X-Spam-Level: X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJMStS2sGjpo for ; Thu, 18 Mar 2010 15:26:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64CFB3A67D7 for ; Thu, 18 Mar 2010 15:26:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsO9q-0006i4-Pc for v6ops-data0@psg.com; Thu, 18 Mar 2010 22:25:38 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsO9o-0006hO-1I for v6ops@ops.ietf.org; Thu, 18 Mar 2010 22:25:36 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKNEokurRN+J/2dsb2JhbACbLnOjZph/hHkEgx0 X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="499128618" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2010 22:25:35 +0000 Received: from dhcp-72-163-74-250.cisco.com (dhcp-72-163-74-250.cisco.com [72.163.74.250]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2IMPZW1014780; Thu, 18 Mar 2010 22:25:35 GMT Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Message-Id: <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> From: Ralph Droms To: Gert Doering In-Reply-To: <20100318201025.GE69383@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: RFC 5006 status Date: Thu, 18 Mar 2010 15:25:35 -0700 References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: You still miss my point. I don't think sending config info in RAs is necessarily a bad idea. The IETF has worked from an architectural guideline of providing one way to carry config. Some network operators would rather use one protocol to carry config, be that ND or DHCP. It's just a different philosophy. I do think the idea of carrying config info in RAs is being sold with FUD. I also think the ways in which adding more config info to RAs ought to be thought through fairly carefully, based on some of the IETF's relevant experience with DHCP. - Ralph On Mar 18, 2010, at 1:10 PM 3/18/10, Gert Doering wrote: > Hi, > > On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: >> I don't happen to share your opinion that "[t]he IETF has solidly >> messed up this part of IPv6 by delaying things for 10 years or so," > > No need to share any opinion here. Just try to run an IPv6-only > network > with Windows, Linux and MacOS clients, and consider whether the IETF > might have given vendors better guidance. Or finished one or the > other > RFC 5 years earlier. > > As an operational person, this endless bickering between the RA camp > and > the "what do you need RA for that, when DHCP can do this all along" > has > FAIL stamped all over it. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From v6ops-archive@ietf.org Thu Mar 18 16:09:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A553A67D7 for ; Thu, 18 Mar 2010 16:09:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -7.6 X-Spam-Level: X-Spam-Status: No, score=-7.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RATWARE_MS_HASH=1.398, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJukf5khKn7g for ; Thu, 18 Mar 2010 16:09:29 -0700 (PDT) Received: from 189.114.198.136.dynamic.adsl.gvt.net.br (189.114.198.136.dynamic.adsl.gvt.net.br [189.114.198.136]) by core3.amsl.com (Postfix) with SMTP id 069A53A676A for ; Thu, 18 Mar 2010 16:09:27 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <726d01cac6d6$ee3174c0$88c672bd@murilojr> To: Subject: RE: SALE 85% OFF on PFIZER! From: VIAGRA Official Seller MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 18 Mar 2010 16:09:27 -0700 (PDT) If you cannot see the images below, please click here
From owner-v6ops@ops.ietf.org Thu Mar 18 16:15:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85F13A698F for ; Thu, 18 Mar 2010 16:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.986 X-Spam-Level: X-Spam-Status: No, score=-103.986 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP6qGqcjKKrx for ; Thu, 18 Mar 2010 16:15:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E49DD3A69CD for ; Thu, 18 Mar 2010 16:15:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsOs1-000D0V-BU for v6ops-data0@psg.com; Thu, 18 Mar 2010 23:11:17 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsOrz-000Czq-22 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 23:11:15 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 2BEE9911543F; Thu, 18 Mar 2010 16:11:14 -0700 (PDT) X-AuditID: 11807137-b7c50ae0000001dd-9a-4ba2b3123be1 Received: from il0602b-dhcp111.apple.com (il0602b-dhcp111.apple.com [17.206.24.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 11.F1.00477.213B2AB4; Thu, 18 Mar 2010 16:11:14 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: Date: Thu, 18 Mar 2010 16:11:13 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> References: To: IPv6 Operations X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 18, 2010, at 06:15, Ole Troan wrote: >=20 > we already have proposals for doing other options in ND, which already = exist in DHCP. > should we reconsider the idea of a generic DHCPv6 option container = option for ND? I wouldn't support that. We already have a protocol where merging a = wide variety of configuration options for multiple sources is the main = object of the game, and it's called DHCP. I see no reason to insert all = that complexity into the processing and emission of router = advertisements. I can see utility in the *limited* extension of RDNSS to standards = track, because it allows zero-configuration hosts on IPv6 networks where = all the routers advertise O=3D0 to have some hope of resolving domain = names after joining them. They don't get that today, and I don't see a = good way to use DHCP to do anything about that. Advancing RDNSS to proposed standard would be a recognition that the = Domain Name Service is *not* like the other services that an IPv6 host = may require dynamic configuration to use, i.e. it's not a luxury, it's = expected to be universally available everywhere there is an IPv6 router. = I realize this would be a departure from the current architecture, = where for reasons that I don't quite understand, the DNS is regarded as = an "extra" feature of the Internet that's only relevant to special = interest communities, and under no circumstances should it be regarded = as a fundamental architectural component. Still, I think it's worth = reconsidering the question. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Mar 18 16:28:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5F63A6AF5 for ; Thu, 18 Mar 2010 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.241 X-Spam-Level: X-Spam-Status: No, score=-100.241 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2HB0ockQAco for ; Thu, 18 Mar 2010 16:27:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE93F3A6A3F for ; Thu, 18 Mar 2010 16:27:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsP6x-000FTF-TJ for v6ops-data0@psg.com; Thu, 18 Mar 2010 23:26:43 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsP6u-000FSx-T6 for v6ops@ops.ietf.org; Thu, 18 Mar 2010 23:26:41 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 7EA5C468; Fri, 19 Mar 2010 00:26:39 +0100 (CET) To: Benoit Boissinot Subject: Re: RFC 5006 status MIME-Version: 1.0 Date: Fri, 19 Mar 2010 00:26:39 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Philip Homburg , Gert Doering , IPv6 Operations Organization: Remlab.net In-Reply-To: <20100318205249.GF29515@pirzuine> References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <55ad5ed558fb34e580521f461d21c543@chewa.net> <20100318205249.GF29515@pirzuine> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 18 Mar 2010 21:52:49 +0100, Benoit Boissinot wrote: >> As one of the co-author of rdnssd, I can assure you that this is >> incorrect. >> rdnssd gets the RDNSS information from the Linux kernel via NetLink out >> of the kernel SLAAC code. > > I should have been clearer. There's indeed a forwarding, but no > processing of the DNS information happens in the kernel. Parsing the packet is done in kernel. But it's not nearly as arguable as retaining extra state in the kernel. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From owner-v6ops@ops.ietf.org Thu Mar 18 18:14:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37993A6C61 for ; Thu, 18 Mar 2010 18:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-1.449, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdUKFMZeje0Y for ; Thu, 18 Mar 2010 18:14:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E35C33A6C5C for ; Thu, 18 Mar 2010 18:14:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsQjD-0002kG-MS for v6ops-data0@psg.com; Fri, 19 Mar 2010 01:10:19 +0000 Received: from [74.125.78.25] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsQj8-0002j2-MA for v6ops@ops.ietf.org; Fri, 19 Mar 2010 01:10:14 +0000 Received: by ey-out-2122.google.com with SMTP id 4so262930eyf.53 for ; Thu, 18 Mar 2010 18:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wN+aWga8acNePsMknDr0+pe8yeW3FBreb7orxsAtPIM=; b=lVoQE82xTObBTfm3mNebXkS9zvW6tq7OwJrZxnLQttsO9hPyPAwar7Z2lLg1M7XTfX YnZjR4vI9+JmgULc1rmRqZlxiMLrcTMUA2esXIUgKK0jAQYfsx4HxdQq5If8pDeoPBgY wX49+EchTz6+wTy3A52Xp+EzXqODzWVjOtEd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=MayBbkQ6F++89H6zTyJtu988Se0XKyoMqBTVPw23asMCdhPfBMsunjZcyklHBbgo8+ WYpyW2fMIPsXR1cZVp45RDTux+bKQC1LNRHxZD8tADsVOJJY9b9dvQjXTpWkB8zGUTxP efH9UOkgAz+QjFOXwQ3xk+yCHrlYhZyTuNDX0= Received: by 10.213.1.210 with SMTP id 18mr3132435ebg.18.1268961003633; Thu, 18 Mar 2010 18:10:03 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 15sm457734ewy.4.2010.03.18.18.09.58 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 18:10:02 -0700 (PDT) Message-ID: <4BA2CEDF.2040304@gmail.com> Date: Fri, 19 Mar 2010 14:09:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms CC: Gert Doering , Mark Smith , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops Subject: Overloading RA [Re: RFC 5006 status] References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> In-Reply-To: <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-03-19 11:25, Ralph Droms wrote: > You still miss my point. I don't think sending config info in RAs is > necessarily a bad idea. The IETF has worked from an architectural > guideline of providing one way to carry config. Some network operators > would rather use one protocol to carry config, be that ND or DHCP. It's > just a different philosophy. > > I do think the idea of carrying config info in RAs is being sold with > FUD. I also think the ways in which adding more config info to RAs > ought to be thought through fairly carefully, based on some of the > IETF's relevant experience with DHCP. What I notice is that DHCP has become very heavily loaded with options. Although one can deploy DHCP without using all those options, it has become a complex thing. SLAAC at least has the advantage that it's stayed simple; in fact the only overloading so far is RFC 5006. I think we'd need a very convincing argument to depart from that simplicity, as opposed to simply saying: if you need to convey arbitrary parameters to hosts, use DHCPv6, which is intended for that purpose. A DNS server address is not an arbitrary parameter; along with a default router, it's the second address you *must* know in every host. So adding it to SLAAC seems consistent. Adding arbitrary parameters to SLAAC would be a whole other approach, and I'm not sure I understand the motivation. Brian > > - Ralph > > On Mar 18, 2010, at 1:10 PM 3/18/10, Gert Doering wrote: > >> Hi, >> >> On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: >>> I don't happen to share your opinion that "[t]he IETF has solidly >>> messed up this part of IPv6 by delaying things for 10 years or so," >> >> No need to share any opinion here. Just try to run an IPv6-only network >> with Windows, Linux and MacOS clients, and consider whether the IETF >> might have given vendors better guidance. Or finished one or the other >> RFC 5 years earlier. >> >> As an operational person, this endless bickering between the RA camp and >> the "what do you need RA for that, when DHCP can do this all along" has >> FAIL stamped all over it. >> >> Gert Doering >> -- NetMaster >> -- >> Total number of prefixes smaller than registry allocations: 150584 >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > From owner-v6ops@ops.ietf.org Thu Mar 18 18:45:38 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A6A3A6A4C for ; Thu, 18 Mar 2010 18:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni97qGk6rQLH for ; Thu, 18 Mar 2010 18:45:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 884E63A67E6 for ; Thu, 18 Mar 2010 18:45:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsRFZ-0007aS-VO for v6ops-data0@psg.com; Fri, 19 Mar 2010 01:43:45 +0000 Received: from [202.32.8.206] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsRFX-0007aD-7q for v6ops@ops.ietf.org; Fri, 19 Mar 2010 01:43:43 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o2J1hW4C013416; Fri, 19 Mar 2010 10:43:32 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o2J1hWn14964; Fri, 19 Mar 2010 10:43:32 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o2J1hVKF018424; Fri, 19 Mar 2010 10:43:31 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o2J1hVvD006230; Fri, 19 Mar 2010 10:43:31 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o2J1hVYP015621; Fri, 19 Mar 2010 10:43:31 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o2J1hVA3002123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2010 10:43:31 +0900 Message-ID: <4BA2D6C2.1020800@mesh.ad.jp> Date: Fri, 19 Mar 2010 10:43:30 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian E Carpenter CC: Ralph Droms , Gert Doering , Mark Smith , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops Subject: Re: Overloading RA [Re: RFC 5006 status] References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> In-Reply-To: <4BA2CEDF.2040304@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I fully agree with Brian here. I would choose DHCPv6 inside my ISP/data center network to do any dynamic node configurations where necessary. Traceability is a MUST. But I would like to have SLAAC in other areas specifically services that connect nodes that don't have robust amount of resources. So keeping SLAAC simple, but with the options that are absolutely necessary to get connected(default router and dns) without relying on other protocols or manual configuration, would be the best thing. Regards, Seiichi Brian E Carpenter wrote: > On 2010-03-19 11:25, Ralph Droms wrote: >> You still miss my point. I don't think sending config info in RAs is >> necessarily a bad idea. The IETF has worked from an architectural >> guideline of providing one way to carry config. Some network operators >> would rather use one protocol to carry config, be that ND or DHCP. It's >> just a different philosophy. >> >> I do think the idea of carrying config info in RAs is being sold with >> FUD. I also think the ways in which adding more config info to RAs >> ought to be thought through fairly carefully, based on some of the >> IETF's relevant experience with DHCP. > > What I notice is that DHCP has become very heavily loaded with options. > Although one can deploy DHCP without using all those options, it has > become a complex thing. SLAAC at least has the advantage that it's > stayed simple; in fact the only overloading so far is RFC 5006. I think > we'd need a very convincing argument to depart from that simplicity, > as opposed to simply saying: if you need to convey arbitrary parameters > to hosts, use DHCPv6, which is intended for that purpose. > > A DNS server address is not an arbitrary parameter; along with a default > router, it's the second address you *must* know in every host. So adding > it to SLAAC seems consistent. Adding arbitrary parameters to SLAAC would > be a whole other approach, and I'm not sure I understand the motivation. > > Brian >> - Ralph >> >> On Mar 18, 2010, at 1:10 PM 3/18/10, Gert Doering wrote: >> >>> Hi, >>> >>> On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: >>>> I don't happen to share your opinion that "[t]he IETF has solidly >>>> messed up this part of IPv6 by delaying things for 10 years or so," >>> No need to share any opinion here. Just try to run an IPv6-only network >>> with Windows, Linux and MacOS clients, and consider whether the IETF >>> might have given vendors better guidance. Or finished one or the other >>> RFC 5 years earlier. >>> >>> As an operational person, this endless bickering between the RA camp and >>> the "what do you need RA for that, when DHCP can do this all along" has >>> FAIL stamped all over it. >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> Total number of prefixes smaller than registry allocations: 150584 >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>> Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkui1sEACgkQcrhTYfxyMkLcFgCfYrw8qJBRg1RusLOHtAt6OOfj uH4An0deFXQJJ0X1a/2UJ7ux0a9vkbAn =W/oE -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Mar 18 19:03:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3E13A6C73 for ; Thu, 18 Mar 2010 19:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.778 X-Spam-Level: ** X-Spam-Status: No, score=2.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdycS-zDN6WC for ; Thu, 18 Mar 2010 19:03:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADC3D3A69DE for ; Thu, 18 Mar 2010 19:03:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsRXB-0009tj-Ta for v6ops-data0@psg.com; Fri, 19 Mar 2010 02:01:57 +0000 Received: from [202.112.3.66] (helo=cernet.edu.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsRX9-0009tG-1y for v6ops@ops.ietf.org; Fri, 19 Mar 2010 02:01:55 +0000 Received: from [59.66.24.38]([59.66.24.38]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54ba312e2; Fri, 19 Mar 2010 10:01:51 +0800 Message-ID: <4BA2DB15.3010401@cernet.edu.cn> Date: Fri, 19 Mar 2010 10:01:57 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Seiichi Kawamura CC: Brian E Carpenter , Ralph Droms , Gert Doering , Mark Smith , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops Subject: Re: Overloading RA [Re: RFC 5006 status] References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> <4BA2D6C2.1020800@mesh.ad.jp> In-Reply-To: <4BA2D6C2.1020800@mesh.ad.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 5oF71sXB Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Seiichi Kawamura 写道: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I fully agree with Brian here. > I would choose DHCPv6 inside my ISP/data center > network to do any dynamic node configurations where necessary. > Traceability is a MUST. > But I would like to have SLAAC in other areas specifically > services that connect nodes > that don't have robust amount of resources. > > So keeping SLAAC simple, but with the > options that are absolutely necessary to > get connected(default router and dns) > without relying on other protocols or manual > configuration, would be the best thing. > I second. xing > Regards, > Seiichi > > Brian E Carpenter wrote: > >> On 2010-03-19 11:25, Ralph Droms wrote: >> >>> You still miss my point. I don't think sending config info in RAs is >>> necessarily a bad idea. The IETF has worked from an architectural >>> guideline of providing one way to carry config. Some network operators >>> would rather use one protocol to carry config, be that ND or DHCP. It's >>> just a different philosophy. >>> >>> I do think the idea of carrying config info in RAs is being sold with >>> FUD. I also think the ways in which adding more config info to RAs >>> ought to be thought through fairly carefully, based on some of the >>> IETF's relevant experience with DHCP. >>> >> What I notice is that DHCP has become very heavily loaded with options. >> Although one can deploy DHCP without using all those options, it has >> become a complex thing. SLAAC at least has the advantage that it's >> stayed simple; in fact the only overloading so far is RFC 5006. I think >> we'd need a very convincing argument to depart from that simplicity, >> as opposed to simply saying: if you need to convey arbitrary parameters >> to hosts, use DHCPv6, which is intended for that purpose. >> >> A DNS server address is not an arbitrary parameter; along with a default >> router, it's the second address you *must* know in every host. So adding >> it to SLAAC seems consistent. Adding arbitrary parameters to SLAAC would >> be a whole other approach, and I'm not sure I understand the motivation. >> >> Brian >> >>> - Ralph >>> >>> On Mar 18, 2010, at 1:10 PM 3/18/10, Gert Doering wrote: >>> >>> >>>> Hi, >>>> >>>> On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote: >>>> >>>>> I don't happen to share your opinion that "[t]he IETF has solidly >>>>> messed up this part of IPv6 by delaying things for 10 years or so," >>>>> >>>> No need to share any opinion here. Just try to run an IPv6-only network >>>> with Windows, Linux and MacOS clients, and consider whether the IETF >>>> might have given vendors better guidance. Or finished one or the other >>>> RFC 5 years earlier. >>>> >>>> As an operational person, this endless bickering between the RA camp and >>>> the "what do you need RA for that, when DHCP can do this all along" has >>>> FAIL stamped all over it. >>>> >>>> Gert Doering >>>> -- NetMaster >>>> -- >>>> Total number of prefixes smaller than registry allocations: 150584 >>>> >>>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>>> Grundner-Culemann >>>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>>> >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkui1sEACgkQcrhTYfxyMkLcFgCfYrw8qJBRg1RusLOHtAt6OOfj > uH4An0deFXQJJ0X1a/2UJ7ux0a9vkbAn > =W/oE > -----END PGP SIGNATURE----- > > > From owner-v6ops@ops.ietf.org Fri Mar 19 01:20:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EFC3A6957 for ; Fri, 19 Mar 2010 01:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.42 X-Spam-Level: X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYFeMEd5Si7J for ; Fri, 19 Mar 2010 01:20:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86D023A6778 for ; Fri, 19 Mar 2010 01:20:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsXMp-0005zX-D8 for v6ops-data0@psg.com; Fri, 19 Mar 2010 08:15:39 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsXMn-0005yc-4R for v6ops@ops.ietf.org; Fri, 19 Mar 2010 08:15:37 +0000 Received: (qmail 84704 invoked by uid 1007); 19 Mar 2010 09:15:33 +0100 Date: Fri, 19 Mar 2010 09:15:33 +0100 From: Gert Doering To: "Templin, Fred L" Cc: Gert Doering , Ralph Droms , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Subject: Re: RFC 5006 status Message-ID: <20100319081533.GH69383@Space.Net> References: <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <20100318210941.GG69383@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4n3ekn15JG+S0x0c" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --4n3ekn15JG+S0x0c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 18, 2010 at 02:18:30PM -0700, Templin, Fred L wrote: > > Let me repeat: I'm an operational person, and not a researcher or > > vendor. We funny operational people are not searching for the "most > > religiously perfect" solution for things. We need something that > > *works*, and we need it in a timely fashion. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Where is this pressure for this coming from?=20 The lack of finalized standards has been a topic in many discussions with our customers and with early adopters in the last years. "So if the standardization process is not yet finished, we'll better wait, otherwise me might have to do things twice". I'm not saying that this is *the* reason why IPv6 adoption is slow, but it didn't help either. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --4n3ekn15JG+S0x0c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQCVAwUBS6MypakuBuNlUUl1AQJJegP+LOaoONlhqmRsomPPlgd2nfSd8jWqetP7 RHnvfQZ3CZuMcO8JeVRaog+kmtsOggqXCQ5meS1psdZv28aER6dVGX2aVU0Gpeu3 Cg7BikRQPFe1wsbWf/zNbPPyU4iLVt0nxUpCy5lqeVVcsIYvW+f/BjdZ2xqCMoYa xMXvz41YkFA= =KXOb -----END PGP SIGNATURE----- --4n3ekn15JG+S0x0c-- From owner-v6ops@ops.ietf.org Fri Mar 19 01:55:50 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7604F3A691A for ; Fri, 19 Mar 2010 01:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.87 X-Spam-Level: X-Spam-Status: No, score=-100.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSizkDxPjHqh for ; Fri, 19 Mar 2010 01:55:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B2383A6876 for ; Fri, 19 Mar 2010 01:55:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsXxz-000Bhn-9X for v6ops-data0@psg.com; Fri, 19 Mar 2010 08:54:03 +0000 Received: from [2001:8b0:0:30::51bb:1e35] (helo=auth.c.painless.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsXxw-000BhM-OH for v6ops@ops.ietf.org; Fri, 19 Mar 2010 08:54:01 +0000 Received: from tactless.ec.aaisp.net.uk ([2001:8b0:0:8000:21d:60ff:fedd:9e63]) by c.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NsXxn-0006lo-9n; Fri, 19 Mar 2010 08:53:51 +0000 Message-ID: <4BA33B9F.6010400@aaisp.net.uk> Date: Fri, 19 Mar 2010 08:53:51 +0000 From: Adrian Kennard User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Organization: Kennard family X-Info: Organization Header added by smtp.aaisp.net.uk based on Authenticated ID Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred Baker wrote: > This is a structured question for the community. > > Jari Arkko tells us that he is getting requests from various sources to take RFC 5006 to Proposed Standard. It is now experimental. > > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=26136 bytes) (Status: EXPERIMENTAL) > > (1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops. > > (2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated? Firebrick FB6000 series as of release V0.00.402-Gerald Alpha (9th Mar 2010) supports announcing RDNSS addresses as part of RA. > (3) Operators, enterprise and/or service provider, please advise on deployment experience. We have deployed in our offices and found nothing seems to take any notice of the RDNSS announcement. We found we had to run rdnss on linux to pick up addresses and it has slightly odd handling of the /etc/resolv.conf file when dhcp client also running and only on more recent installations. > I'm adding a brief discussion to the agenda Monday morning with a view to getting a quick thumbs-up/thumbs-down to advise Jari, who can then take that to 6man later in the week if appropriate. > > BTW, I have had a flurry of email related to the agenda. The current agenda may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html From owner-v6ops@ops.ietf.org Fri Mar 19 03:03:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E963A6928 for ; Fri, 19 Mar 2010 03:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PXd2nYpsZfq for ; Fri, 19 Mar 2010 03:03:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E27EB3A68FC for ; Fri, 19 Mar 2010 03:03:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsZ02-000MPl-DB for v6ops-data0@psg.com; Fri, 19 Mar 2010 10:00:14 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsYzz-000MPA-DW for v6ops@ops.ietf.org; Fri, 19 Mar 2010 10:00:12 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0C172E080ED; Fri, 19 Mar 2010 10:59:58 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E551BE080AD; Fri, 19 Mar 2010 10:59:53 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Date: Fri, 19 Mar 2010 10:59:53 +0100 Cc: IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park , Suresh Krishnan , Dan Wing Content-Transfer-Encoding: quoted-printable Message-Id: <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : > http://www.ietf.org/rfc/rfc5006.txt >=20 > (1) Please take a look at the document in the next few days; if you = have comments on it (eg, you think it should be changed in some way), = please comment to v6ops. While supporting in general the idea, there is one improvement I suggest = to make: Rather than a specific RA option for Recursive DNS Servers, standardize = the generic RA option to embed some stateless DHCP options, as proposed = in draft-krishnan-intarea-ra-dhcp-00. This is in my understanding more powerful without being more complex. By giving to routers a general possibility to broadcast stateless DHCP = parameters (in addition to their still being obtainable in DHCPv6), not = only the purpose of RFC50026 is achieved but, in one shot, the same = progress is made for all common parameters that may concern all or most = hosts. =20 Hosts that support the RA DHCP option only have to: (1) process embedded = DHCP options that they understand; (2) skip others; (3) request in = DHCPv6 only options that aren't already received in RAs, if any. Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting = of Wednesday for: "Stateless DHCPv6 and Router Advertisements for propagating = configuration information". I add Suresh to the list, and Dan Wing who is known to support this = approach. RD From owner-v6ops@ops.ietf.org Fri Mar 19 04:10:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267EA3A6802 for ; Fri, 19 Mar 2010 04:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.535 X-Spam-Level: * X-Spam-Status: No, score=1.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q52okpSnCPwn for ; Fri, 19 Mar 2010 04:09:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0F6A3A68B6 for ; Fri, 19 Mar 2010 04:09:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsa21-00074E-Vl for v6ops-data0@psg.com; Fri, 19 Mar 2010 11:06:21 +0000 Received: from [74.125.92.25] (helo=qw-out-2122.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsa1z-00073q-LX for v6ops@ops.ietf.org; Fri, 19 Mar 2010 11:06:19 +0000 Received: by qw-out-2122.google.com with SMTP id 5so168625qwi.65 for ; Fri, 19 Mar 2010 04:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=pAgeHXKE3+RlB5kZQycS7NYvqvqq7443UP/GohkddEs=; b=I5c81z1IwcWS4IkEINX7OaFWu7hKb8z3kDsI9zUYMD/tyYfVWHT+0websGxF2QHSvo zucNjamsYeAQIDtZ29WLLG+qLPnwdP+2eXdyTxUe1CFkyQEewG+CdpxZizCPrRZ1f/ZR +uirdnF+n00CKpJHqzVEeUK/G3oO1Iw2OY6Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wfqmosuM/vN+2ZtOa9Vcpc+vER2sKmcLJkH+XDK65YxnkrYge7fjSlFFxzjLgIY0xu 6usFxxlBkbDjiM5hJy+oi1Rf6TA4h2WtbaOCtb9qHLx4/fFlYvRKbCtFdXczKbMXOfNE ebc+D7N9zQ0Dm2l5lSQQnVAU9IYWsWF6nsS4Q= MIME-Version: 1.0 Received: by 10.229.218.2 with SMTP id ho2mr4021797qcb.51.1268996777779; Fri, 19 Mar 2010 04:06:17 -0700 (PDT) In-Reply-To: <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> From: Syam Madanapalli Date: Fri, 19 Mar 2010 16:35:57 +0530 Message-ID: <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> Subject: Re: RFC 5006 status To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Cc: Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: What's the difference between running Stateless DHCPv6 vs carrying DHCP options in ND messages? If nodes can implement DHCP options in ND messages, I could not understand why cannot they implement Stateless DHCPv6 itself. In case ND option for DHCPv6 options is better than running stateless DHCPv6, then we need to look at whether there exists any other options other the DNS server address for which IETF is looking at defining RA options. Thanks, Syam On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s wr= ote: > > Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : > >> http://www.ietf.org/rfc/rfc5006.txt >> >> (1) Please take a look at the document in the next few days; if you have= comments on it (eg, you think it should be changed in some way), please co= mment to v6ops. > > While supporting in general the idea, there is one improvement I suggest = to make: > Rather than a specific RA option for Recursive DNS Servers, standardize t= he generic RA option to embed some stateless DHCP options, as proposed in d= raft-krishnan-intarea-ra-dhcp-00. > > This is in my understanding more powerful without being more complex. > By giving to routers a general possibility to broadcast stateless DHCP pa= rameters (in addition to their still being obtainable in DHCPv6), not only = the purpose of RFC50026 is achieved but, in one shot, the same progress is = made for all common parameters that may concern all or most hosts. > > Hosts that support the RA DHCP option only have to: (1) process embedded = DHCP options that they understand; (2) skip others; (3) request in DHCPv6 o= nly options that aren't already received in RAs, if any. > > Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting of= Wednesday for: > "Stateless DHCPv6 and Router Advertisements for propagating configuration= information". > > I add Suresh to the list, and Dan Wing who is known to support this appro= ach. > > RD > > From owner-v6ops@ops.ietf.org Fri Mar 19 05:46:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA7A3A69BC for ; Fri, 19 Mar 2010 05:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.48 X-Spam-Level: **** X-Spam-Status: No, score=4.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y91EHEdYgSFP for ; Fri, 19 Mar 2010 05:46:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 017403A68FC for ; Fri, 19 Mar 2010 05:46:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsbZQ-000MyK-Tk for v6ops-data0@psg.com; Fri, 19 Mar 2010 12:44:56 +0000 Received: from [88.198.24.89] (helo=geheimer.internetendpunkt.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsbZO-000Mxr-LI for v6ops@ops.ietf.org; Fri, 19 Mar 2010 12:44:54 +0000 Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id 1E4BCF4413A; Fri, 19 Mar 2010 13:44:52 +0100 (CET) To: IPv6 Operations Subject: Re: RFC 5006 status MIME-Version: 1.0 Date: Fri, 19 Mar 2010 13:44:52 +0100 From: Hagen Paul Pfeifer Cc: Michael Cardell Widerkrantz , Mark Smith Message-ID: <071221e26af3ed9c5fa306b3b1beb211@localhost> X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello Michael, hello Mark, I patched quagga to support RFC 5006 too. Due to a more or less clever maintainership the patches are stalled somewhere[1]. So quagga supports RFC 5006. Cheers, Hagen [1] http://code.quagga.net/cgi-bin/gitweb.cgi?p=people/paul/quagga;a=commit;h=d1590a98215ca8eff9b4061f3a22222f1559338f From owner-v6ops@ops.ietf.org Fri Mar 19 05:46:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451BF3A6850 for ; Fri, 19 Mar 2010 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.93 X-Spam-Level: X-Spam-Status: No, score=-103.93 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iR2Hi-sie52 for ; Fri, 19 Mar 2010 05:46:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 781B63A68FC for ; Fri, 19 Mar 2010 05:46:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsbWD-000MMG-4R for v6ops-data0@psg.com; Fri, 19 Mar 2010 12:41:37 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsbWA-000MLX-KZ for v6ops@ops.ietf.org; Fri, 19 Mar 2010 12:41:35 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1269002491!38860133!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 19475 invoked from network); 19 Mar 2010 12:41:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2010 12:41:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2JCfJug010144; Fri, 19 Mar 2010 08:41:19 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2JCfGAj010099; Fri, 19 Mar 2010 08:41:16 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 08:41:27 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 08:41:27 -0400 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: RFC 5006 status Date: Fri, 19 Mar 2010 08:41:26 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> In-Reply-To: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrG8eu/uiRoQdtERrGMiIGUF2uiDQAbeNAw References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> From: "STARK, BARBARA H (ATTLABS)" To: "james woodyatt" , "IPv6 Operations" Cc: "6man Chairs" <6man-chairs@tools.ietf.org> X-OriginalArrivalTime: 19 Mar 2010 12:41:27.0171 (UTC) FILETIME=[7DE9CD30:01CAC761] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > I can see utility in the *limited* extension of RDNSS to standards > track, because it allows zero-configuration hosts on IPv6 networks > where all the routers advertise O=3D0 to have some hope of resolving > domain names after joining them. They don't get that today, and I > don't see a good way to use DHCP to do anything about that. I'm confused by this O=3D0 proposal. I thought the O flag was intended = to announce that there was a DHCP server available with other (non-IA) configuration info, including NTP, SIP server, DNS, etc. Is this suggesting that the O flag be used exclusively to announce the availability of DNS info in DHCPv6, and not any other config info? Should clients just guess whether DHCPv6 is available for non-IA, non-DNS info? Is it suggesting that if clients do not support RFC5006 for getting DNS info (but do support DHCPv6), that they not be given a hint that a DHCPv6 server is available that might have other config info? Or, with O=3D0, would there be a simultaneous proposal that = support for RFC5006 be mandatory in clients? Just trying to understand this, since I've seen it suggested before, and can't quite figure out the full range of expected behavior in the wild frontier of IPv6 home networks. Barbara From owner-v6ops@ops.ietf.org Fri Mar 19 06:24:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A373A68E5 for ; Fri, 19 Mar 2010 06:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.214 X-Spam-Level: * X-Spam-Status: No, score=1.214 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xicPXavZ-mZB for ; Fri, 19 Mar 2010 06:24:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5B7C3A6849 for ; Fri, 19 Mar 2010 06:23:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsc96-0004qo-LG for v6ops-data0@psg.com; Fri, 19 Mar 2010 13:21:48 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsc8e-0004mR-4N for v6ops@ops.ietf.org; Fri, 19 Mar 2010 13:21:20 +0000 Received: from 219-90-173-191.ip.adam.com.au ([219.90.173.191] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nsc8B-0003SW-KQ; Fri, 19 Mar 2010 23:50:51 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E0A2C4930C; Fri, 19 Mar 2010 23:50:50 +1030 (CST) Date: Fri, 19 Mar 2010 23:50:49 +1030 From: Mark Smith To: Syam Madanapalli Cc: =?ISO-8859-1?B?UultaSBEZXNwculz?= , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Subject: Re: RFC 5006 status Message-ID: <20100319235049.349f5a18@opy.nosense.org> In-Reply-To: <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 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 List-ID: On Fri, 19 Mar 2010 16:35:57 +0530 Syam Madanapalli wrote: > What's the difference between running Stateless DHCPv6 vs carrying > DHCP options in ND messages? >=20 A very small amount of RAM, CPU and a single packet. They way people are persisting with this "we've got to turn RAs in to half-duplex DHCPv6", you'd think those all those things were getting dramatically more expensive. I have a challenge for the RA for everything crowd. Firstly, however, I'd like to quote Yogi Berra, or possibly Jan L. A. van de Snepscheut or Albert Einstein (according to http://en.wikiquote.org/wiki/Yogi_Berra), "In theory there is no difference between theory and practice. In practice there is." I haven't seen anybody justify this RA for everything view by saying, "I deployed RAs + stateless DHCPv6, and I had (one or more of) (a) devices run out of RAM, (b) run out of CPU or (c) run out of network bandwidth" or listed some significant problem they experienced with the existing mechanisms. So as far as I can see, all the arguments are= theoretical, with no practice to support the argument. The existing mechanisms work, both in theory, and in practice. I think that means that the onus is on the RA for everything proponents to *prove* where it doesn't work before anybody should spend valuable time redesigning the existing mechanisms. There are better IPv6 things to spend time on that are far more important to *get* working, rather than spending time on changing the way existing things work. > If nodes can implement DHCP options in ND messages, I could not > understand why cannot they implement Stateless DHCPv6 itself. >=20 > In case ND option for DHCPv6 options is better than running stateless > DHCPv6, then we need to look at whether there exists any other options > other the DNS server address for which IETF is looking at defining RA > options. >=20 > Thanks, > Syam >=20 > On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s = wrote: > > > > Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : > > > >> http://www.ietf.org/rfc/rfc5006.txt > >> > >> (1) Please take a look at the document in the next few days; if you ha= ve comments on it (eg, you think it should be changed in some way), please = comment to v6ops. > > > > While supporting in general the idea, there is one improvement I sugges= t to make: > > Rather than a specific RA option for Recursive DNS Servers, standardize= the generic RA option to embed some stateless DHCP options, as proposed in= draft-krishnan-intarea-ra-dhcp-00. > > > > This is in my understanding more powerful without being more complex. > > By giving to routers a general possibility to broadcast stateless DHCP = parameters (in addition to their still being obtainable in DHCPv6), not onl= y the purpose of RFC50026 is achieved but, in one shot, the same progress i= s made for all common parameters that may concern all or most hosts. > > > > Hosts that support the RA DHCP option only have to: (1) process embedde= d DHCP options that they understand; (2) skip others; (3) request in DHCPv6= only options that aren't already received in RAs, if any. > > > > Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting = of Wednesday for: > > "Stateless DHCPv6 and Router Advertisements for propagating configurati= on information". > > > > I add Suresh to the list, and Dan Wing who is known to support this app= roach. > > > > RD > > > > >=20 From owner-v6ops@ops.ietf.org Fri Mar 19 06:29:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFF93A6984 for ; Fri, 19 Mar 2010 06:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNQlecCVAT69 for ; Fri, 19 Mar 2010 06:29:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77D383A69AD for ; Fri, 19 Mar 2010 06:29:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NscF6-00062C-DY for v6ops-data0@psg.com; Fri, 19 Mar 2010 13:28:00 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NscF3-00061t-MD for v6ops@ops.ietf.org; Fri, 19 Mar 2010 13:27:57 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1269005203!10694770!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 9246 invoked from network); 19 Mar 2010 13:26:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2010 13:26:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2JDQUZ5000773; Fri, 19 Mar 2010 09:26:31 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2JDQNCC000663; Fri, 19 Mar 2010 09:26:24 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 09:26:34 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 09:26:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {7C5CE32D-B76F-4663-989C-6EAE0ACFCE13} x-cr-hashedpuzzle: A5Wn CafL Cgyb ClRi Dlda EXVA Ep2u Fdel HkW4 Ohib PG9h Ph7g QwHm Qwc0 TBnY VgyS;2;NgBtAGEAbgAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAdgA2AG8AcABzAEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcA;Sosha1_v1;7;{7C5CE32D-B76F-4663-989C-6EAE0ACFCE13};YgBzADcANgA1ADIAQABhAHQAdAAuAGMAbwBtAA==;Fri, 19 Mar 2010 13:26:29 GMT;UgBFADoAIABSAEYAQwAgADUAMAAwADYAIABzAHQAYQB0AHUAcwA= Content-class: urn:content-classes:message Subject: RE: RFC 5006 status Date: Fri, 19 Mar 2010 09:26:29 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F12257D79@crexc50p> In-Reply-To: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrG8eu/uiRoQdtERrGMiIGUF2uiDQAcAWfQ References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> From: "STARK, BARBARA H (ATTLABS)" To: "IPv6 Operations" Cc: "6man Chairs" <6man-chairs@tools.ietf.org> X-OriginalArrivalTime: 19 Mar 2010 13:26:34.0632 (UTC) FILETIME=[CBAF9080:01CAC767] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: My sense of what's going on in the industry is that there is a lot of momentum around RFC5006 being used inside home networks. It is widely stated and believed that clients and OSs exist that only support RFC5006 and not DHCPv6 for DNS (v6 server) acquisition. Therefore, most router manufacturers and ISPs seem to be leaning towards putting RFC5006 inside the routers anyway, no matter the status of the RFC.=20 I say acknowledge the inevitable and make it a standard. There's no way to put this genie back in the bottle.=20 Beyond RFC5006, I really, really hope that the IETF doesn't try to duplicate all DHCPv6 stateless config in RA (and I would have preferred not having DNS in RA -- but, like I said, what's done is done, and the inevitability of RFC5006 just has to be accepted).=20 My concerns are centered around operations, testing devices to make sure they work, and troubleshooting customer configuration problems.=20 When clients are given the ability to choose among multiple ways to do the same thing, this means that the router/server has to support *all* of these ways. Even if each is simple on its own, the complexity of supporting all methods is additive (at a minimum). All methods have to be coded, and all have to be tested. This doubles the effort of coding/testing on the routers. When a customer calls to complain that something isn't working, and it turns out something didn't get configured, we'll have to figure out first how it was expecting to get configured. This increases the complexity of troubleshooting. What I need, operationally, is predictability. All this discussion around "let's create half a dozen ways to do the same thing so hosts can choose the one they like best" is a recipe for failure. Every time the IETF creates a new way to do something that can already be easily done, you're introducing complexity and make it that much more likely that things will go wrong for the average consumer. Please, please, please -- Keep It Simple, for every device in the ecosystem. Barbara From owner-v6ops@ops.ietf.org Fri Mar 19 06:58:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DEA3A6A1A for ; Fri, 19 Mar 2010 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZsrFOA2GJNm for ; Fri, 19 Mar 2010 06:58:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45D173A695B for ; Fri, 19 Mar 2010 06:58:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NscfW-000AgN-P6 for v6ops-data0@psg.com; Fri, 19 Mar 2010 13:55:18 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NscfS-000Aem-Km for v6ops@ops.ietf.org; Fri, 19 Mar 2010 13:55:15 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id EB535E080F4; Fri, 19 Mar 2010 14:55:02 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8240EE08010; Fri, 19 Mar 2010 14:54:59 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> Date: Fri, 19 Mar 2010 14:54:58 +0100 Cc: Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> To: Syam Madanapalli X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 12:05, Syam Madanapalli a =E9crit : > What's the difference between running Stateless DHCPv6 vs carrying > DHCP options in ND messages? As noted by Ralph (who was not arguing in favor of RAs, but just stating = a fact): "There is one way in which RAs involve less overhead - they can use = multicast to carry all the options in one message rather than use = individual message exchanges for each host." Other differences can be discussed, but there is at least this one. > If nodes can implement DHCP options in ND messages, I could not > understand why cannot they implement Stateless DHCPv6 itself. This question amounts to: "why to make it simpler when you can afford to keep it complex?" The right answer is IMHO in the sentence of Saint-Exupery quoted by Mark = Smith on this thread: "In anything at all, perfection is finally attained not when there is no = longer anything to add, but when there is no longer anything to take away." > DHCPv6, then we need to look at whether there exists any other options > other the DNS server address for which IETF is looking at defining RA > options. No. Not more than to specify Stateless DHCP servers. (Note incidentally that RFC on Stateless DHCPv6 (RFC 3736) already = mentions SIP-server addresses as useful stateless parameters, without = this closing the list for the future.)=20 The standard needs only to say that: - Routers MAY send RAs containing stateless DNS options - Hosts MAY be ready to receive stateless DNS options in RAs - IF THEY DO, it MUST be with the approved format. (And, for this, the format proposed by Suresh is so obvious and simple = that I doubt there would be any competitive proposals) This being done, one can expect that all vendors of products that send = and/or receive RAs will eventually add this simple capability to their = products, making things more efficient and simpler in many = circumstances.=20 Regards, RD >=20 > Thanks, > Syam >=20 > On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : >>=20 >>> http://www.ietf.org/rfc/rfc5006.txt >>>=20 >>> (1) Please take a look at the document in the next few days; if you = have comments on it (eg, you think it should be changed in some way), = please comment to v6ops. >>=20 >> While supporting in general the idea, there is one improvement I = suggest to make: >> Rather than a specific RA option for Recursive DNS Servers, = standardize the generic RA option to embed some stateless DHCP options, = as proposed in draft-krishnan-intarea-ra-dhcp-00. >>=20 >> This is in my understanding more powerful without being more complex. >> By giving to routers a general possibility to broadcast stateless = DHCP parameters (in addition to their still being obtainable in DHCPv6), = not only the purpose of RFC50026 is achieved but, in one shot, the same = progress is made for all common parameters that may concern all or most = hosts. >>=20 >> Hosts that support the RA DHCP option only have to: (1) process = embedded DHCP options that they understand; (2) skip others; (3) request = in DHCPv6 only options that aren't already received in RAs, if any. >>=20 >> Note that Suresh Krishnan has 15min slot scheduled at the 6man = meeting of Wednesday for: >> "Stateless DHCPv6 and Router Advertisements for propagating = configuration information". >>=20 >> I add Suresh to the list, and Dan Wing who is known to support this = approach. >>=20 >> RD >>=20 >>=20 From owner-v6ops@ops.ietf.org Fri Mar 19 07:09:26 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B8D3A6A47 for ; Fri, 19 Mar 2010 07:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=-1.201, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEH+bbEdIvj3 for ; Fri, 19 Mar 2010 07:09:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEE283A6A41 for ; Fri, 19 Mar 2010 07:09:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nscry-000D4x-9C for v6ops-data0@psg.com; Fri, 19 Mar 2010 14:08:10 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nscrv-000D4O-9g for v6ops@ops.ietf.org; Fri, 19 Mar 2010 14:08:08 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5E7ECE081C6; Fri, 19 Mar 2010 15:07:54 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 46CD7E080A1; Fri, 19 Mar 2010 15:07:51 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100319235049.349f5a18@opy.nosense.org> Date: Fri, 19 Mar 2010 15:07:49 +0100 Cc: Syam Madanapalli , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Content-Transfer-Encoding: quoted-printable Message-Id: <0825C17F-F22C-4E1E-B74D-6340BC79116D@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <20100319235049.349f5a18@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 14:20, Mark Smith a =E9crit : > The existing mechanisms work, both in theory, and in practice. I think > that means that the onus is on the RA for everything proponents to > *prove* where it doesn't work... There is clearly no proof that it doesn't work, but there is a proof = that efficiency can be improved by a very small complement. > ... before anybody should spend valuable time > redesigning the existing mechanisms. There is no "redesign", just an optional complement for which, = contributors who wish to implement it, need an approved common format. Those that don't want to support it are free not to: things will = continue to work for them as before, just less efficiently than for = those who have the complement.=20 > There are better IPv6 things to > spend time on that are far more important to *get* working, rather = than > spending time on changing the way existing things work. Then, please let others doing it (it won't hurt you in any way), and the = discussion will terminate. RD >> On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s = wrote: >>>=20 >>> Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : >>>=20 >>>> http://www.ietf.org/rfc/rfc5006.txt >>>>=20 >>>> (1) Please take a look at the document in the next few days; if you = have comments on it (eg, you think it should be changed in some way), = please comment to v6ops. >>>=20 >>> While supporting in general the idea, there is one improvement I = suggest to make: >>> Rather than a specific RA option for Recursive DNS Servers, = standardize the generic RA option to embed some stateless DHCP options, = as proposed in draft-krishnan-intarea-ra-dhcp-00. >>>=20 >>> This is in my understanding more powerful without being more = complex. >>> By giving to routers a general possibility to broadcast stateless = DHCP parameters (in addition to their still being obtainable in DHCPv6), = not only the purpose of RFC50026 is achieved but, in one shot, the same = progress is made for all common parameters that may concern all or most = hosts. >>>=20 >>> Hosts that support the RA DHCP option only have to: (1) process = embedded DHCP options that they understand; (2) skip others; (3) request = in DHCPv6 only options that aren't already received in RAs, if any. >>>=20 >>> Note that Suresh Krishnan has 15min slot scheduled at the 6man = meeting of Wednesday for: >>> "Stateless DHCPv6 and Router Advertisements for propagating = configuration information". >>>=20 >>> I add Suresh to the list, and Dan Wing who is known to support this = approach. >>>=20 >>> RD >>>=20 >>>=20 >>=20 >=20 From owner-v6ops@ops.ietf.org Fri Mar 19 07:23:43 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0E83A681A for ; Fri, 19 Mar 2010 07:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97HPHY9Osm5W for ; Fri, 19 Mar 2010 07:23:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC9A03A685A for ; Fri, 19 Mar 2010 07:23:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsd5b-000FTM-AU for v6ops-data0@psg.com; Fri, 19 Mar 2010 14:22:15 +0000 Received: from [216.82.250.147] (helo=mail129.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsd55-000FPr-2r for v6ops@ops.ietf.org; Fri, 19 Mar 2010 14:21:43 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-129.messagelabs.com!1269008500!24525364!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28229 invoked from network); 19 Mar 2010 14:21:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2010 14:21:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2JELTBw011344; Fri, 19 Mar 2010 10:21:29 -0400 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2JELJow011088; Fri, 19 Mar 2010 10:21:20 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 10:21:31 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 10:21:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 5006 status Date: Fri, 19 Mar 2010 10:21:29 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F12257DF6@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrHbabK97lisihoS8K31YQIJHdj3gAAPHww References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> From: "STARK, BARBARA H (ATTLABS)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Syam Madanapalli" Cc: "Fred Baker" , "IPv6 Operations" , "Lindqvist Kurt Erik" , "Ralph Droms" , "6man Chairs" <6man-chairs@tools.ietf.org>, "Dave Thaler" , "Jari Arkko" , , , "Daniel Park" , "Suresh Krishnan" , "Dan Wing" X-OriginalArrivalTime: 19 Mar 2010 14:21:30.0503 (UTC) FILETIME=[782D9170:01CAC76F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > The standard needs only to say that: > - Routers MAY send RAs containing stateless DNS options > - Hosts MAY be ready to receive stateless DNS options in RAs > - IF THEY DO, it MUST be with the approved format. > (And, for this, the format proposed by Suresh is so obvious and simple > that I doubt there would be any competitive proposals) >=20 > This being done, one can expect that all vendors of products that send > and/or receive RAs will eventually add this simple capability to their > products, making things more efficient and simpler in many > circumstances. Thus doubling the complexity of the devices that now have to support = *both* DHCPv6 stateless and RAs for receiving/sending that *identical* = info, and greatly increasing the difficulty of troubleshooting problems = (because 2 solutions now exist where there used to just be one). What we = have today is simple. It sounds to me like the question being asked is = "why keep it simple when you can make it more complex?" In my case, "it" = refers to the overall ecosystem of protocols. Barbara From owner-v6ops@ops.ietf.org Fri Mar 19 07:23:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2C83A6AA4 for ; Fri, 19 Mar 2010 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.535 X-Spam-Level: * X-Spam-Status: No, score=1.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkGgBF2o-hAt for ; Fri, 19 Mar 2010 07:23:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 402A03A6A9B for ; Fri, 19 Mar 2010 07:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsd6W-000FY1-G2 for v6ops-data0@psg.com; Fri, 19 Mar 2010 14:23:12 +0000 Received: from [74.125.92.27] (helo=qw-out-2122.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsd6U-000FXi-87 for v6ops@ops.ietf.org; Fri, 19 Mar 2010 14:23:10 +0000 Received: by qw-out-2122.google.com with SMTP id 5so213382qwi.65 for ; Fri, 19 Mar 2010 07:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=fowpLQpeY26O/1LvTwSrpuNnn8XAkpXyUacs5JBD1Vk=; b=cNpWev/E4ic+2341htT+j/QTdZsd1VaCL7HiyaxKskfOzvBiQ1B++c1J153XH7Lry2 Bu1fibNq7QmjThgRFHdYQW6w1N8crBB9BklDqb4qDOmow7pUwN0/zF3sp2ftBj0w0nzB ji2Dm0gjmzrdbrdYizAWpskh7R5BpthBCijls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=GjnwYY/a7K5sLwXa4WvA4eTzbB36JL2frnWOawO/aEOvfAXrxtQHhXdWSnBAyih1FP 3CuPEjfWWOFcjmG5zJ69QSWZ94zKUW5Y5e+EEKnQ0R41+0GCeLt/w39kkv/LB1OyPOEA qTAZS9aprgDhaZ+H0ZW45QSj0o358wfmKkOys= MIME-Version: 1.0 Received: by 10.229.111.81 with SMTP id r17mr1612803qcp.32.1269008588725; Fri, 19 Mar 2010 07:23:08 -0700 (PDT) In-Reply-To: References: <4B9DFC7D.3070704@piuha.net> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> From: Syam Madanapalli Date: Fri, 19 Mar 2010 19:52:47 +0530 Message-ID: <10e14db21003190722q5c88e25cy3969dc0dcb353830@mail.gmail.com> Subject: Re: RFC 5006 status To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Cc: Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, Mar 19, 2010 at 7:24 PM, R=E9mi Despr=E9s wr= ote: > > Le 19 mars 2010 =E0 12:05, Syam Madanapalli a =E9crit : > >> What's the difference between running Stateless DHCPv6 vs carrying >> DHCP options in ND messages? > > As noted by Ralph (who was not arguing in favor of RAs, but just stating = a fact): > "There is one way in which RAs involve less overhead - they can use multi= cast to carry all the options in one message rather than use individual mes= sage exchanges for each host." > > Other differences can be discussed, but there is at least this one. > >> If nodes can implement DHCP options in ND messages, I could not >> understand why cannot they implement Stateless DHCPv6 itself. > > This question amounts to: > "why to make it simpler when you can afford to keep it complex?" Sure, as far as I know that's how things being done at the IETF - If it ain't broke, don't fix it. > The right answer is IMHO in the sentence of Saint-Exupery quoted by Mark = Smith on this thread: > "In anything at all, perfection is finally attained not when there is no = longer anything to add, but when > there is no longer anything to take away." > >> DHCPv6, then we need to look at whether there exists any other options >> other the DNS server address for which IETF is looking at defining RA >> options. > > No. > Not more than to specify Stateless DHCP servers. > (Note incidentally that RFC on Stateless DHCPv6 (RFC 3736) already mentio= ns SIP-server addresses as useful stateless parameters, without this closin= g the list for the future.) > > The standard needs only to say that: > - Routers MAY send RAs containing stateless DNS options > - Hosts MAY be ready to receive stateless DNS options in RAs > - IF THEY DO, it MUST be with the approved format. > (And, for this, the format proposed by Suresh is so obvious and simple th= at I doubt there would be any competitive proposals) > > This being done, one can expect that all vendors of products that send an= d/or receive RAs will eventually add this simple capability to their produc= ts, making things more efficient and simpler in many circumstances. I doubt this. For me this would be a new standard that needs to be implemented new. And if you are proposing the RA DHCP option for DNS server address alone, for the argument sake, this involves one extra step in processing than RFC 5006. I hope there will not be another proposal for RA into DHCP :-) Thanks, Syam > > Regards, > RD > > >> >> Thanks, >> Syam >> >> On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s = wrote: >>> >>> Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : >>> >>>> http://www.ietf.org/rfc/rfc5006.txt >>>> >>>> (1) Please take a look at the document in the next few days; if you ha= ve comments on it (eg, you think it should be changed in some way), please = comment to v6ops. >>> >>> While supporting in general the idea, there is one improvement I sugges= t to make: >>> Rather than a specific RA option for Recursive DNS Servers, standardize= the generic RA option to embed some stateless DHCP options, as proposed in= draft-krishnan-intarea-ra-dhcp-00. >>> >>> This is in my understanding more powerful without being more complex. >>> By giving to routers a general possibility to broadcast stateless DHCP = parameters (in addition to their still being obtainable in DHCPv6), not onl= y the purpose of RFC50026 is achieved but, in one shot, the same progress i= s made for all common parameters that may concern all or most hosts. >>> >>> Hosts that support the RA DHCP option only have to: (1) process embedde= d DHCP options that they understand; (2) skip others; (3) request in DHCPv6= only options that aren't already received in RAs, if any. >>> >>> Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting = of Wednesday for: >>> "Stateless DHCPv6 and Router Advertisements for propagating configurati= on information". >>> >>> I add Suresh to the list, and Dan Wing who is known to support this app= roach. >>> >>> RD >>> >>> > > From owner-v6ops@ops.ietf.org Fri Mar 19 07:40:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C051C3A6914 for ; Fri, 19 Mar 2010 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6lKoiQLES2R for ; Fri, 19 Mar 2010 07:40:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B9C03A6882 for ; Fri, 19 Mar 2010 07:40:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdM0-000IGT-Cy for v6ops-data0@psg.com; Fri, 19 Mar 2010 14:39:12 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdLu-000IFp-FM for v6ops@ops.ietf.org; Fri, 19 Mar 2010 14:39:07 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id CC156E080AA; Fri, 19 Mar 2010 15:39:01 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id DB782E08010; Fri, 19 Mar 2010 15:38:58 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <10e14db21003190722q5c88e25cy3969dc0dcb353830@mail.gmail.com> Date: Fri, 19 Mar 2010 15:38:57 +0100 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <512758AD-01E6-40B6-92AB-378FDD1126B3@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <10e14db21003190722q5c88e25cy3969dc0dcb353830@mail.gmail.com> To: Syam Madanapalli X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 15:22, Syam Madanapalli a =E9crit : > And if you are proposing the RA DHCP option for DNS server address > alone, I am not. Just the opposite. It is RFC 5006 which has this limitation. > I hope there will not be another proposal for RA into DHCP :-) Your job, (in any case not mine ;-). RD From owner-v6ops@ops.ietf.org Fri Mar 19 07:48:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BE33A6823 for ; Fri, 19 Mar 2010 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7QAv7xf2f3L for ; Fri, 19 Mar 2010 07:48:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 931353A6AB8 for ; Fri, 19 Mar 2010 07:48:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdUL-000Jjg-9i for v6ops-data0@psg.com; Fri, 19 Mar 2010 14:47:49 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdUI-000JjK-8M for v6ops@ops.ietf.org; Fri, 19 Mar 2010 14:47:47 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5AEE7E08167; Fri, 19 Mar 2010 15:47:33 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 018A5E08056; Fri, 19 Mar 2010 15:47:30 +0100 (CET) Subject: Stateless DHCP options "authorized" in RAs, in a standard-format container Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F12257DF6@crexc50p> Date: Fri, 19 Mar 2010 15:47:29 +0100 Cc: "Syam Madanapalli" , "Fred Baker" , "IPv6 Operations" , "Lindqvist Kurt Erik" , "Ralph Droms" , "6man Chairs" <6man-chairs@tools.ietf.org>, "Dave Thaler" , "Jari Arkko" , , , "Daniel Park" , "Suresh Krishnan" , "Dan Wing" Content-Transfer-Encoding: quoted-printable Message-Id: <774FD93F-618B-4B5F-B7E7-F7E87263A894@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257DF6@crexc50p> To: "STARK, BARBARA H (ATTLABS)" X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 15:21, STARK, BARBARA H (ATTLABS) a =E9crit : >> The standard needs only to say that: >> - Routers MAY send RAs containing stateless DNS options >> - Hosts MAY be ready to receive stateless DNS options in RAs >> - IF THEY DO, it MUST be with the approved format. >> (And, for this, the format proposed by Suresh is so obvious and = simple >> that I doubt there would be any competitive proposals) >>=20 >> This being done, one can expect that all vendors of products that = send >> and/or receive RAs will eventually add this simple capability to = their >> products, making things more efficient and simpler in many >> circumstances. >=20 > Thus doubling the complexity of the devices that now have to support = *both* DHCPv6 stateless and RAs for receiving/sending that *identical* = info, No. Again, no one is obliged to implement it in any device. But those who do it (to increase efficiency), have a standard format to = do it. Deployment is incremental and can remain partial. The point is that authorizing some DHCP options in RAs is more powerful, = and simpler, than RFC 5006. This way should therefore, IMHO, be preferred. RD= From owner-v6ops@ops.ietf.org Fri Mar 19 08:09:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEB13A6AA6 for ; Fri, 19 Mar 2010 08:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkY14okuo-0U for ; Fri, 19 Mar 2010 08:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AA273A6A2B for ; Fri, 19 Mar 2010 08:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdmR-000NAZ-46 for v6ops-data0@psg.com; Fri, 19 Mar 2010 15:06:31 +0000 Received: from [74.125.92.24] (helo=qw-out-2122.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsdmO-000NAI-W5 for v6ops@ops.ietf.org; Fri, 19 Mar 2010 15:06:29 +0000 Received: by qw-out-2122.google.com with SMTP id 5so225645qwi.65 for ; Fri, 19 Mar 2010 08:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=80PKPuB8GubwuvLLUzQhr4I1PsKkt9wA4ZDCUJutISE=; b=i/rNrfZpUy8VxrRqvhAIHqgJLsIAcLFHEau235hBhB9d6wzJiHxYA98cpD7VsAP1r/ PT8T2jfU6lRo3fBZ8lm0Em02YAw4EVc5xtQl3eouxDOHQslHXqVdGzpaa6cESs3MA5AH CRxaIjyPnEWsnQkwMV/NmTcRIhmQwUS5Rx1dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BTtqPRK955RhrSGlfUDAtADBQZP2igI/8LAPpF4uZ8VUa0HWXCXB19CdeditxDAcCe Hp45cEVOFAHAr8MhcRXN/g7bdAwHZ9qyzQ6WqiCAJ9DPEpcExPqhs2d2Eys1T1K7D8pj +QmQHIKpQ5hUAVJtLequ23r8FouaODv1C90rs= MIME-Version: 1.0 Received: by 10.229.97.147 with SMTP id l19mr4282807qcn.24.1269011186382; Fri, 19 Mar 2010 08:06:26 -0700 (PDT) In-Reply-To: <512758AD-01E6-40B6-92AB-378FDD1126B3@free.fr> References: <4B9DFC7D.3070704@piuha.net> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <10e14db21003190722q5c88e25cy3969dc0dcb353830@mail.gmail.com> <512758AD-01E6-40B6-92AB-378FDD1126B3@free.fr> From: Syam Madanapalli Date: Fri, 19 Mar 2010 20:36:06 +0530 Message-ID: <10e14db21003190806v3bf08262l89fb62dabe568ad9@mail.gmail.com> Subject: Re: RFC 5006 status To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Cc: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: What I understood from your arguments is that you have a solution and we need to find a problem. On Fri, Mar 19, 2010 at 8:08 PM, R=E9mi Despr=E9s wr= ote: > > Le 19 mars 2010 =E0 15:22, Syam Madanapalli a =E9crit : >> And if you are proposing the RA DHCP option for DNS server address >> alone, > > I am not. You can put the list here, and the need for these list to be in RAs. > Just the opposite. > It is RFC 5006 which has this limitation. RFC 5006 has been written for a single and specific option. You seem to be justifying DHCP into RA based on RFC 5006 defining DNS Server Address Option, which in my views is incorrect. > > >> I hope there will not be another proposal for RA into DHCP :-) > > Your job, (in any case not mine ;-). > > RD > > > From owner-v6ops@ops.ietf.org Fri Mar 19 08:32:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3190C3A6A64 for ; Fri, 19 Mar 2010 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbj0TL5AZTPO for ; Fri, 19 Mar 2010 08:32:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62ABE3A6860 for ; Fri, 19 Mar 2010 08:32:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nse9I-0001B7-6v for v6ops-data0@psg.com; Fri, 19 Mar 2010 15:30:08 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nse9C-00019x-F6 for v6ops@ops.ietf.org; Fri, 19 Mar 2010 15:30:03 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 91715E08179; Fri, 19 Mar 2010 16:29:55 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 740F3E0817A; Fri, 19 Mar 2010 16:29:53 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <10e14db21003190806v3bf08262l89fb62dabe568ad9@mail.gmail.com> Date: Fri, 19 Mar 2010 16:29:51 +0100 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <361F32BC-5AD7-4F94-914C-E4D1C26A4E94@free.fr> References: <4B9DFC7D.3070704@piuha.net> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <10e14db21003190722q5c88e25cy3969dc0dcb353830@mail.gmail.com> <512758AD-01E6-40B6-92AB-378FDD1126B3@free.fr> <10e14db21003190806v3bf08262l89fb62dabe568ad9@mail.gmail.com> To: Syam Madanapalli X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 16:06, Syam Madanapalli a =E9crit : > On Fri, Mar 19, 2010 at 8:08 PM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 19 mars 2010 =E0 15:22, Syam Madanapalli a =E9crit : >>> And if you are proposing the RA DHCP option for DNS server address >>> alone, >>=20 >> I am not. >=20 > You can put the list here, and the need for these list to be in RAs. No need for the list. The proposal is just a generic tool. It can be used with any existing or future stateless DNS option, = existing or to be added. >> Just the opposite. >> It is RFC 5006 which has this limitation. >=20 > RFC 5006 has been written for a single and specific option. > You seem to be justifying DHCP into RA based on RFC 5006 > defining DNS Server Address Option, which in my views is > incorrect. That's in fact not how things happened. I had already expressed to Dan Wing, in a previous meeting, my support = for DNS options in RAs, not remembering that the original idea was from = Suresh Krishnan.=20 But now that it is discussed that RFC 5006 could become standard track, = it's an obvious time to suggest a more generic approach. RD From owner-v6ops@ops.ietf.org Fri Mar 19 08:40:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B813A6A7B for ; Fri, 19 Mar 2010 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.469 X-Spam-Level: X-Spam-Status: No, score=-101.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3glaMbCcqgXq for ; Fri, 19 Mar 2010 08:40:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 749C83A6A64 for ; Fri, 19 Mar 2010 08:40:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NseIc-0002zu-5C for v6ops-data0@psg.com; Fri, 19 Mar 2010 15:39:46 +0000 Received: from [2001:4038:0:17::25] (helo=server2.sintact.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NseIa-0002zX-1i for v6ops@ops.ietf.org; Fri, 19 Mar 2010 15:39:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by server2.sintact.nl (Postfix) with ESMTP id 5FC013C06B; Fri, 19 Mar 2010 16:39:43 +0100 (CET) X-Virus-Scanned: amavisd-new at server2.sintact.nl Received: from server2.sintact.nl ([127.0.0.1]) by localhost (server2.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5tNn6hZGf1T; Fri, 19 Mar 2010 16:39:43 +0100 (CET) Received: from [IPv6:2001:610:6ce:1:224:36ff:feef:1d89] (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by server2.sintact.nl (Postfix) with ESMTP id C1BEB3C06C; Fri, 19 Mar 2010 16:39:39 +0100 (CET) Subject: Re: Overloading RA [Re: RFC 5006 status] Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <4BA2CEDF.2040304@gmail.com> Date: Fri, 19 Mar 2010 16:39:39 +0100 Cc: IPv6 v6ops Content-Transfer-Encoding: 7bit Message-Id: <4A911C4A-73DC-45C1-A6F1-0FDCB7A04262@steffann.nl> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, > A DNS server address is not an arbitrary parameter; along with a default > router, it's the second address you *must* know in every host. So adding > it to SLAAC seems consistent. This exactly summarizes my thoughts/feelings about this. I fully agree. Sander From owner-v6ops@ops.ietf.org Fri Mar 19 08:58:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0803A6A62 for ; Fri, 19 Mar 2010 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucAB89Pf60l9 for ; Fri, 19 Mar 2010 08:58:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B56433A6986 for ; Fri, 19 Mar 2010 08:58:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NseXk-0005gF-5B for v6ops-data0@psg.com; Fri, 19 Mar 2010 15:55:24 +0000 Received: from web111414.mail.gq1.yahoo.com ([67.195.15.210]) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NseXe-0005ee-3t for v6ops@ops.ietf.org; Fri, 19 Mar 2010 15:55:18 +0000 Received: (qmail 10593 invoked by uid 60001); 19 Mar 2010 15:55:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269014117; bh=AkTlQ2u/k1VXbifRLXoYg84sbyqbT3qUM9JqCwy7JMc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=t9Vq/Ut1HD/1gs5uhvhgtBPnPSno+o15IWUe50neHdDM/fRdQgUqOUWmALvuqrXU06d4iWwXwqCy6eUoWR9xzE2fp70VZTW6twgYiX5UWs//XjwuuPeEB/Dy7BhGqVTEhMEO4lgWSQnytK7Bn/+vXXoxeLhXBzauDaw1G4BNChQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2/VAW0kTH0YJHZCNS09zDEPNZW4EKe084BHuwJEkJso6CiZAfk82zKCSbgQFupvvksmFyc9ILuMNeWxAIdqh+zaQuUQEdeQuiyGH1DQg9cMsguSdgYgU+nvHWcR6OtAkIlpfm3Ajg9dK+Is06rMJ+c50uqzLOunZJ0m7Vq7BZbc=; Message-ID: <479435.10354.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: TlV9MCkVM1lNtVpAfxaZKZiQYeq4WJpqgSqXg2ud0nQXRBj yg3l0YtyvyQ4HnW8OHq9s3UGENMheS0Wfy5n0jIXIjPrCbMmCzqTTo_OWiW8 QpdoI2X9uaxobMFQSIT5wdEZmJizvBesEm21MkOOx11gQrlrqaX.RtxNydlT Zz2RHifVYawbsfX.Q360NeY.uAmXt4tjPt4rreQzblggGqNkkt6ota5XyBwA fFC82i1MIVQXKHtikYXMQ6SbCmrtf.vw.F4TUo288WWja9_fY8LKIr6YBDih AwbfbcjMNnZJeGI2Hnh9cpIMPSfwRyECNsz6eKoUf Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 19 Mar 2010 08:55:17 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> Date: Fri, 19 Mar 2010 08:55:17 -0700 (PDT) From: Behcet Sarikaya Reply-To: Behcet Sarikaya Subject: Re: RFC 5006 status To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: IPv6 Operations In-Reply-To: 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 List-ID: Hi R=E9mi,=0A=0ALe 19 mars 2010 =E0 12:05, Syam Madanapalli a =E9crit :=0A= =0A> What's the =0A> difference between running Stateless DHCPv6 vs carryin= g=0A> DHCP options in =0A> ND messages?=0A=0AAs noted by Ralph (who was not= arguing in favor of RAs, but =0A> just stating a fact):=0A"There is one wa= y in which RAs involve less overhead - =0A> they can use multicast to carry= all the options in one message rather than use =0A> individual message exc= hanges for each host."=0A=0A> Other differences can be =0A> discussed, but = there is at least this one.=0A=0APlease note that in practice this differen= ce of less overhead goes away if you consider very commonly used point-to-p= oint links.=0A=0A=0A=A0=0ABTW, I removed long cc list and just kept v6ops b= ecause I think everybody is on this list already :-).=0A=0ARegards,=0A=0ABe= hcet=0A=0A=0A From owner-v6ops@ops.ietf.org Fri Mar 19 09:10:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969BE3A6ACD for ; Fri, 19 Mar 2010 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5SzYKYX0Gt4 for ; Fri, 19 Mar 2010 09:10:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF9C13A6ABA for ; Fri, 19 Mar 2010 09:10:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsejC-0007rA-Jx for v6ops-data0@psg.com; Fri, 19 Mar 2010 16:07:14 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsej5-0007qE-TQ for v6ops@ops.ietf.org; Fri, 19 Mar 2010 16:07:08 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 35309E081F6; Fri, 19 Mar 2010 17:07:02 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2E64CE08136; Fri, 19 Mar 2010 17:07:00 +0100 (CET) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <479435.10354.qm@web111414.mail.gq1.yahoo.com> Date: Fri, 19 Mar 2010 17:06:58 +0100 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <683CB604-CDB7-47C3-85CF-17199AD90178@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <479435.10354.qm@web111414.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 19 mars 2010 =E0 16:55, Behcet Sarikaya a =E9crit : > Hi R=E9mi, >=20 > Le 19 mars 2010 =E0 12:05, Syam Madanapalli a =E9crit : >=20 >> What's the=20 >> difference between running Stateless DHCPv6 vs carrying >> DHCP options in=20 >> ND messages? >=20 > As noted by Ralph (who was not arguing in favor of RAs, but=20 >> just stating a fact): > "There is one way in which RAs involve less overhead -=20 >> they can use multicast to carry all the options in one message rather = than use=20 >> individual message exchanges for each host." >=20 >> Other differences can be=20 >> discussed, but there is at least this one. >=20 > Please note that in practice this difference of less overhead goes = away if you consider very commonly used point-to-point links. Well noted. The value of the solution is mainly for "very commonly used" MULTIPOINT = links ;-) RD= From v6ops-archive@megatron.ietf.org Fri Mar 19 09:43:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D403A6ACF for ; Fri, 19 Mar 2010 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.585 X-Spam-Level: X-Spam-Status: No, score=-31.585 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U643H7eFTw4O for ; Fri, 19 Mar 2010 09:43:13 -0700 (PDT) Received: from 189-93-189-62.3g.claro.net.br (189-93-189-62.3g.claro.net.br [189.93.189.62]) by core3.amsl.com (Postfix) with ESMTP id 94C213A6889 for ; Fri, 19 Mar 2010 09:43:03 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@megatron.ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100319164304.94C213A6889@core3.amsl.com> Date: Fri, 19 Mar 2010 09:43:03 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Buk. All rights reserved.
From v6ops-archive@ietf.org Fri Mar 19 09:43:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0F73A6813 for ; Fri, 19 Mar 2010 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.585 X-Spam-Level: X-Spam-Status: No, score=-31.585 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPEyo6rjnB+2 for ; Fri, 19 Mar 2010 09:43:26 -0700 (PDT) Received: from 189-93-189-62.3g.claro.net.br (189-93-189-62.3g.claro.net.br [189.93.189.62]) by core3.amsl.com (Postfix) with ESMTP id D42743A6889 for ; Fri, 19 Mar 2010 09:43:18 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100319164320.D42743A6889@core3.amsl.com> Date: Fri, 19 Mar 2010 09:43:18 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Veh. All rights reserved.
From v6ops-archive@lists.ietf.org Fri Mar 19 09:47:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DB53A6AC7 for ; Fri, 19 Mar 2010 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.585 X-Spam-Level: X-Spam-Status: No, score=-21.585 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+KBG6D3vgOa for ; Fri, 19 Mar 2010 09:47:27 -0700 (PDT) Received: from 189-93-189-62.3g.claro.net.br (189-93-189-62.3g.claro.net.br [189.93.189.62]) by core3.amsl.com (Postfix) with ESMTP id CA1FE3A6859 for ; Fri, 19 Mar 2010 09:47:23 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@lists.ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100319164723.CA1FE3A6859@core3.amsl.com> Date: Fri, 19 Mar 2010 09:47:23 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Jsixiu. All rights reserved.
From owner-v6ops@ops.ietf.org Fri Mar 19 09:51:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376D93A6AE2 for ; Fri, 19 Mar 2010 09:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRbj83Efnktl for ; Fri, 19 Mar 2010 09:51:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E261C3A6AD8 for ; Fri, 19 Mar 2010 09:51:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsfNv-000GDg-PA for v6ops-data0@psg.com; Fri, 19 Mar 2010 16:49:19 +0000 Received: from [2001:1bb8:2004:150::2] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsfNs-000GAM-O6 for v6ops@ops.ietf.org; Fri, 19 Mar 2010 16:49:17 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id o2JGn80V020785 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Mar 2010 16:49:08 GMT (envelope-from nick@inex.ie) Message-ID: <4BA3AB04.4040902@inex.ie> Date: Fri, 19 Mar 2010 16:49:08 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Homburg CC: IPv6 Operations Subject: Re: RFC 5006 status References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <86634tlovt.fsf@brain.hack.org> In-Reply-To: X-Enigmail-Version: 1.0.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18/03/2010 15:02, Philip Homburg wrote: > But I'm not sure why you would want a user land rtsol. [...] > So I'm wondering how smart it is to have part of this processing in user space. > > My person reason for putting it in the kernel is to start DUD as soon as > possible. wut? How are you supposed to easily write /etc/resolv.conf from kernel-land? rtsol belongs in userland, and the more complicated it becomes, the stronger the reason to have it there. If you need to interact with a kernel from userland, you can easily define careful interfaces to do so. On 18/03/2010 20:10, Gert Doering wrote: > As an operational person, this endless bickering between the RA camp and > the "what do you need RA for that, when DHCP can do this all along" has > FAIL stamped all over it. Amen to that. Nick From owner-v6ops@ops.ietf.org Fri Mar 19 10:01:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9153A6AE5 for ; Fri, 19 Mar 2010 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFU4blDLv9ns for ; Fri, 19 Mar 2010 10:01:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 228FD3A6828 for ; Fri, 19 Mar 2010 10:01:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsfXo-000Hpi-67 for v6ops-data0@psg.com; Fri, 19 Mar 2010 16:59:32 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsfXk-000Hmv-Ab for v6ops@ops.ietf.org; Fri, 19 Mar 2010 16:59:29 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NsfXZ-0001cEC; Fri, 19 Mar 2010 17:59 +0100 Message-Id: To: Nick Hilliard Cc: IPv6 Operations Subject: Re: RFC 5006 status From: Philip Homburg References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <86634tlovt.fsf@brain.hack.org> <4BA3AB04.4040902@inex.ie> In-reply-to: Your message of "Fri, 19 Mar 2010 16:49:08 +0000 ." <4BA3AB04.4040902@inex.ie> Date: Fri, 19 Mar 2010 17:59:15 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Fri, 19 Mar 2010 16:49:08 +0000 you wrote: >On 18/03/2010 15:02, Philip Homburg wrote: >> But I'm not sure why you would want a user land rtsol. >[...] >> So I'm wondering how smart it is to have part of this processing in user spa >ce. >> >> My person reason for putting it in the kernel is to start DUD as soon as >> possible. > >wut? How are you supposed to easily write /etc/resolv.conf from kernel-land? > >rtsol belongs in userland, and the more complicated it becomes, the >stronger the reason to have it there. If you need to interact with a >kernel from userland, you can easily define careful interfaces to do so. I'm talking about real RAs, the ones with information about routers, prefixes, and stuff like that. I want that as soon as possible. And all of that stuff needs to be in the kernel anyhow. Moving RA processing to user land just makes things more difficult. Problems start when you start mixing that with information that belongs in /etc/resolv.conf. The easy way out is to just issue another series of router solicitations from user land. I think nobody yet remarked in this thread that RAs tend to be periodic whereas DHCP is not. So you end up broadcasting (officially multicasting, but everybody gets it anyhow) the same DNS entries over and over again. From owner-v6ops@ops.ietf.org Fri Mar 19 10:13:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0428C3A6C20 for ; Fri, 19 Mar 2010 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.427 X-Spam-Level: X-Spam-Status: No, score=-101.427 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98NSHqdBfaQU for ; Fri, 19 Mar 2010 10:13:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2E1C3A6B8A for ; Fri, 19 Mar 2010 10:10:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsfg8-000J76-HW for v6ops-data0@psg.com; Fri, 19 Mar 2010 17:08:08 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsfg4-000J6e-6b for v6ops@ops.ietf.org; Fri, 19 Mar 2010 17:08:05 +0000 Received: (qmail 54090 invoked by uid 1007); 19 Mar 2010 18:08:01 +0100 Date: Fri, 19 Mar 2010 18:08:01 +0100 From: Gert Doering To: Philip Homburg Cc: Nick Hilliard , IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100319170801.GI69383@Space.Net> References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <86634tlovt.fsf@brain.hack.org> <4BA3AB04.4040902@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Fri, Mar 19, 2010 at 05:59:15PM +0100, Philip Homburg wrote: > I think nobody yet remarked in this thread that RAs tend to be periodic > whereas DHCP is not. I did... > So you end up broadcasting (officially multicasting, > but everybody gets it anyhow) the same DNS entries over and over again. Which is good. Because it is the only way to get updated information to clients the moment they are updated, except of waiting for the clients to poll for them. (Less important for DNS, more important for change of on-link prefixes) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Fri Mar 19 10:32:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1903A6929 for ; Fri, 19 Mar 2010 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc0U3yAEt-zH for ; Fri, 19 Mar 2010 10:32:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D821E3A6927 for ; Fri, 19 Mar 2010 10:32:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsg1s-000NXr-V8 for v6ops-data0@psg.com; Fri, 19 Mar 2010 17:30:36 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsg1p-000NXA-Kq for v6ops@ops.ietf.org; Fri, 19 Mar 2010 17:30:33 +0000 Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88633903; Fri, 19 Mar 2010 13:30:18 -0400 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 13:30:18 -0400 Received: from 10.21.80.224 ([10.21.80.224]) by NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Mar 2010 17:30:17 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 19 Mar 2010 13:30:15 -0400 Subject: Re: RFC 5006 status From: John Jason Brzozowski To: Fred Baker , IPv6 Operations CC: Kurt Lindqvist , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , , , , Daniel Park Message-ID: Thread-Topic: RFC 5006 status Thread-Index: AcrF6NoXaCHFhnvoQQa3S/MlEI/uOABoPwAX In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Mar 2010 17:30:18.0148 (UTC) FILETIME=[D7FB0640:01CAC789] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, I would not object to advancing this document. Given the diversity of how hosts are currently configured with configuration information it might be useful have this be a proposed standard. John On 3/17/10 10:18 AM, "Fred Baker" wrote: > (3) Operators, enterprise and/or service provider, please advise on deployment > experience. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From owner-v6ops@ops.ietf.org Fri Mar 19 10:32:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398143A6929 for ; Fri, 19 Mar 2010 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.779 X-Spam-Level: X-Spam-Status: No, score=-8.779 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGzVTKhrA-PA for ; Fri, 19 Mar 2010 10:32:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D34D3A693C for ; Fri, 19 Mar 2010 10:32:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsg2z-000NiJ-4z for v6ops-data0@psg.com; Fri, 19 Mar 2010 17:31:45 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsg2w-000Ni0-Rk for v6ops@ops.ietf.org; Fri, 19 Mar 2010 17:31:43 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,275,1267401600"; d="scan'208";a="102989201" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2010 17:31:42 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2JHVgNY010798; Fri, 19 Mar 2010 17:31:42 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2JHVdY09719; Fri, 19 Mar 2010 10:31:40 -0700 (PDT) Message-ID: <4BA3B4FB.5000407@cisco.com> Date: Fri, 19 Mar 2010 18:31:39 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: Ralph Droms , Gert Doering , Mark Smith , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops Subject: Re: Overloading RA [Re: RFC 5006 status] References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> In-Reply-To: <4BA2CEDF.2040304@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/19/10 2:09 AM, Brian E Carpenter wrote: > What I notice is that DHCP has become very heavily loaded with options. > Although one can deploy DHCP without using all those options, it has > become a complex thing. SLAAC at least has the advantage that it's > stayed simple; in fact the only overloading so far is RFC 5006. I think > we'd need a very convincing argument to depart from that simplicity, > as opposed to simply saying: if you need to convey arbitrary parameters > to hosts, use DHCPv6, which is intended for that purpose. > > A DNS server address is not an arbitrary parameter; along with a default > router, it's the second address you *must* know in every host. Once IPv6 went down the path of redrawing the lines between ARP, ICMP, DHCP, etc. from IPv4, it was bound to have made at least one error. It seems clear to me that this was one of those cases. I agree with Brian: the addresses every host IP stack MUST know to operate should be part of SLAAC. - Mark From owner-v6ops@ops.ietf.org Fri Mar 19 10:43:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D870B3A68FA for ; Fri, 19 Mar 2010 10:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.661 X-Spam-Level: X-Spam-Status: No, score=-8.661 tagged_above=-999 required=5 tests=[AWL=-1.296, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc3UUoXrCnSy for ; Fri, 19 Mar 2010 10:43:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60F803A695A for ; Fri, 19 Mar 2010 10:43:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsgD5-000PPe-1u for v6ops-data0@psg.com; Fri, 19 Mar 2010 17:42:11 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsgD2-000PPP-Sp for v6ops@ops.ietf.org; Fri, 19 Mar 2010 17:42:09 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINUo0urR7H+/2dsb2JhbACbPHOhY5hzhHoE X-IronPort-AV: E=Sophos;i="4.51,275,1267401600"; d="scan'208";a="217664489" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 19 Mar 2010 17:42:08 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2JHg8TN025926; Fri, 19 Mar 2010 17:42:08 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2JHg6Y10280; Fri, 19 Mar 2010 10:42:06 -0700 (PDT) Message-ID: <4BA3B76D.9090802@cisco.com> Date: Fri, 19 Mar 2010 18:42:05 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Gert Doering CC: Philip Homburg , Nick Hilliard , IPv6 Operations Subject: Re: RFC 5006 status References: <20100318090413.GE69383@Space.Net> <40f323d01003180356m77c9bc9ch3308ee14c47bd495@mail.gmail.com> <86634tlovt.fsf@brain.hack.org> <4BA3AB04.4040902@inex.ie> <20100319170801.GI69383@Space.Net> In-Reply-To: <20100319170801.GI69383@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/19/10 6:08 PM, Gert Doering wrote: > Hi, > > On Fri, Mar 19, 2010 at 05:59:15PM +0100, Philip Homburg wrote: > >> I think nobody yet remarked in this thread that RAs tend to be periodic >> whereas DHCP is not. >> > I did... > > >> So you end up broadcasting (officially multicasting, >> but everybody gets it anyhow) the same DNS entries over and over again. >> > Which is good. Because it is the only way to get updated information > to clients the moment they are updated, except of waiting for the > clients to poll for them. > > (Less important for DNS, more important for change of on-link prefixes) > I can think of cases where it could be important for DNS too. But, without going into that rathole here, suffice to say that DNS is so fundamental to IP, particularly in IPv6 where humans loathe typing in raw addresses far more than in IPv4, that I don't mind the client being updated with the latest-greatest DNS servers often. - Mark > Gert Doering > -- NetMaster > From owner-v6ops@ops.ietf.org Fri Mar 19 11:02:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4DE3A6917 for ; Fri, 19 Mar 2010 11:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.561 X-Spam-Level: X-Spam-Status: No, score=-8.561 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F62uTpbOo7kR for ; Fri, 19 Mar 2010 11:02:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D9613A691C for ; Fri, 19 Mar 2010 11:02:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsgVS-0003QO-QV for v6ops-data0@psg.com; Fri, 19 Mar 2010 18:01:10 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsgVP-0003Pz-2t for v6ops@ops.ietf.org; Fri, 19 Mar 2010 18:01:07 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,275,1267401600"; d="scan'208";a="103004339" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2010 18:01:06 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2JI16ia007289; Fri, 19 Mar 2010 18:01:06 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2JI0rY11114; Fri, 19 Mar 2010 11:00:54 -0700 (PDT) Message-ID: <4BA3BBCF.2090903@cisco.com> Date: Fri, 19 Mar 2010 19:00:47 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: IPv6 Operations CC: james woodyatt , "Eric Vyncke (evyncke)" Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: 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 List-ID: I would like to propose some form of "ParanoidOpeness" (Rule #7) from draft-vyncke-advanced-ipv6-security-01 to be brought into the simple-security draft. The basic idea is that rather than blocking otherwise unauthorized inbound connections outright, the CPE rate-limits them according to a variable setting. When that setting is 0, all incoming packets are dropped. When set to its maximum, all packets are permitted (as if the firewall function is configured off). In-between, the CPE rate-limits incoming packets to reduce probing of the home network, but to allow just enough packets through that, if a host inside responds, a pinhole is opened for the communication to occur. Of course, the hard part is what the default setting should be, but I'd like to get a sense first of whether we can bring this function in. James, I think I remember you being warm to the idea in some (jabber?) comments during the meeting in Hiroshima when I presented this first. Thanks, - Mark On 3/4/10 12:06 AM, james woodyatt wrote: > everyone-- > > Once again, I'd like to ask for some discussion and feedback on this draft. Is there any reason this revision of the draft should not proceed to Working Group Last Call at this time? > > > -- > james woodyatt > member of technical staff, communications engineering > > > > > From owner-v6ops@ops.ietf.org Fri Mar 19 12:31:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FAB3A67AE for ; Fri, 19 Mar 2010 12:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-2.039, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuAHLPx5btjq for ; Fri, 19 Mar 2010 12:31:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 534CA3A68EF for ; Fri, 19 Mar 2010 12:31:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nshqf-000J7y-Ls for v6ops-data0@psg.com; Fri, 19 Mar 2010 19:27:09 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nshqb-000J7I-JN for v6ops@ops.ietf.org; Fri, 19 Mar 2010 19:27:06 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id D491D8A3388C; Fri, 19 Mar 2010 12:27:04 -0700 (PDT) X-AuditID: 11807137-b7c50ae0000001dd-a1-4ba3d0088dc7 Received: from il0602b-dhcp111.apple.com (il0602b-dhcp111.apple.com [17.206.24.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id AB.B4.00477.800D3AB4; Fri, 19 Mar 2010 12:27:04 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> Date: Fri, 19 Mar 2010 12:27:04 -0700 Cc: IPv6 Operations , 6man Chairs <6man-chairs@tools.ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> To: "STARK, BARBARA H (ATTLABS)" X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 19, 2010, at 05:41, STARK, BARBARA H (ATTLABS) wrote: > [I wrote:] >>=20 >> I can see utility in the *limited* extension of RDNSS to standards >> track, because it allows zero-configuration hosts on IPv6 networks >> where all the routers advertise O=3D0 to have some hope of resolving >> domain names after joining them. They don't get that today, and I >> don't see a good way to use DHCP to do anything about that. >=20 > I'm confused by this O=3D0 proposal. I thought the O flag was intended = to > announce that there was a DHCP server available with other (non-IA) > configuration info, including NTP, SIP server, DNS, etc. Yes, but O=3D0 does not actually imply that there MUST be no DHCP = service, despite the Note on page 19 of RFC 4861. It merely implies = that there MAY be no DHCP service. Another router on the same link can = assert by advertising to hosts with O=3D1 that there MUST be a DHCP = service. > Is this > suggesting that the O flag be used exclusively to announce the > availability of DNS info in DHCPv6, and not any other config info? Not at all. > Should clients just guess whether DHCPv6 is available for non-IA, > non-DNS info? Right now, the only standard way to configure hosts dynamically with DNS = server addresses is with DHCPv6. Hosts that join networks where no = routers are advertising O=3D1 are either configured with DNS server = addresses manually, or they are forced to start their DHCPv6 clients to = get configured-- despite the fact that all the routers are explicitly = warning that there MAY be no DHCPv6 service available. So. An alternative way forward out of this mess would be to leave RFC = 5006 in experimental category and deprecate the O bit entirely, i.e. = update the router requirements to require all RA to be sent with O=3D1, = and explicitly encourage hosts with DHCPv6 stateless clients to start = them immediately on completion of SLAAC regardless of the state of = AdvOtherConfigFlag. I'd support that too. > Is it suggesting that if clients do not support RFC5006 > for getting DNS info (but do support DHCPv6), that they not be given a > hint that a DHCPv6 server is available that might have other config > info? Or, with O=3D0, would there be a simultaneous proposal that = support > for RFC5006 be mandatory in clients? I don't see a need to revise the host requirements to make support for = processing RDNSS options in router advertisements any more necessary for = conformance than support for processing DHCP. But if we *did*, then that would mean that a certain operating system = I'm thinking about would no longer be able to claim compliance with IPv6 = host requirements while still requiring domesticated primates to type = numeric IPv6 addresses into a squirrelly little text window buried three = layers down in System Preferences before they can watch the special = dancing animation on their favorite IPv6 pr0n site. I'm trying to be careful what else I say about that. > Just trying to understand this, since I've seen it suggested before, = and > can't quite figure out the full range of expected behavior in the wild > frontier of IPv6 home networks. Here's what the IPv6 router on my home network does today: + Advertises with O=3D1 and M=3D0. + Offers stateless DHCP6 service with its own global address as the DNS = server for the link. + Advertises with RFC 5006 its own global address as the DNS server for = the link. - Lifetime is set the same as the prefix lifetime. + Runs a recursive DNS forwarding server (access limited to the LAN = prefix). Currently, all the hosts on my home network that can process RFC 5006 = messages also have DHCPv6 clients in them, so they process both sources = of DNS server address, merge them together and get the single address = that's advertised in both, and they configure themselves appropriately. The interesting part happens when the delegated prefix changes, e.g. = when I switch the WAN uplink from one network to another. The addresses = of the DNS servers available to hosts on the LAN link changes. This = gets reflected quickly in the RDNSS options that the router sends, and = the hosts with RFC 5006 clients updates their DNS resolver = configurations immediately. Since I don't have any hosts with *only* a = DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such = hosts when their DNS server addresses need to be changed away from the = ones they learned from their DHCPv6 lease. I suspect they just keep = using the addresses they were initially offered until their lease = expires, and this will produce suboptimal user experience until they go = to renew. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Mar 19 12:35:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBA83A6929 for ; Fri, 19 Mar 2010 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MpzUhRG9LfZ for ; Fri, 19 Mar 2010 12:35:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CBBB3A68F6 for ; Fri, 19 Mar 2010 12:35:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nshxh-000KPi-RN for v6ops-data0@psg.com; Fri, 19 Mar 2010 19:34:25 +0000 Received: from [209.85.220.228] (helo=mail-fx0-f228.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nshxe-000KPI-Oa for v6ops@ops.ietf.org; Fri, 19 Mar 2010 19:34:23 +0000 Received: by fxm28 with SMTP id 28so1924953fxm.19 for ; Fri, 19 Mar 2010 12:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8NiOM3XMsxj353VgW7W/pFoPavPhT54cVUFVwxIshVI=; b=hThlCvk+3mXYaSVz0UrbUHqPTy8o0QBf6H8ii+QB5KgxvB7A8TayOeLPBdURxr/spb OBauBLkOJXwV2ruWNGfSYelyaEqlMHE5s0luxQAElOwfjcru2oof4KZ+8BdtswM7kUSD EcKFIJyw5wqyPZTWtFelHFGdlL+SVrvHegSDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QJ9D6aHzD6TntxycwUEQjTtUkarZN5AbHIlGGBWFapwHaHty91Yu8DR0S7YR1RTFwN 75bdzG5+07jzNKM8MkpIhG1GBD2tFH8+Z658Lx+Z4A8nkjDoZo1MYR2wrw0D0WdneKy4 VHAzgGj5l5hYm8jp1DJeuBshRIUoSSGLXchcE= Received: by 10.87.38.38 with SMTP id q38mr668768fgj.66.1269027261491; Fri, 19 Mar 2010 12:34:21 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 19sm1979770fkr.39.2010.03.19.12.34.17 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Mar 2010 12:34:20 -0700 (PDT) Message-ID: <4BA3D1B3.4010501@gmail.com> Date: Sat, 20 Mar 2010 08:34:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley CC: IPv6 Operations , james woodyatt , "Eric Vyncke (evyncke)" Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> In-Reply-To: <4BA3BBCF.2090903@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark, I'm not going to reply to your specific question. The one most clear result from the ISP survey I will report on during the IETF is that the biggest gap in products holding up general v6 deployment is CPE. I think it's a matter of great urgency to get this draft out as an RFC; it's a couple of years too late. So I want to say: let's not add *anything*. Let's just push it out in a matter of weeks. The same applies to draft-ietf-v6ops-ipv6-cpe-router of course. Regards Brian Carpenter On 2010-03-20 07:00, Mark Townsley wrote: > > I would like to propose some form of "ParanoidOpeness" (Rule #7) from > draft-vyncke-advanced-ipv6-security-01 to be brought into the > simple-security draft. > > The basic idea is that rather than blocking otherwise unauthorized > inbound connections outright, the CPE rate-limits them according to a > variable setting. When that setting is 0, all incoming packets are > dropped. When set to its maximum, all packets are permitted (as if the > firewall function is configured off). In-between, the CPE rate-limits > incoming packets to reduce probing of the home network, but to allow > just enough packets through that, if a host inside responds, a pinhole > is opened for the communication to occur. Of course, the hard part is > what the default setting should be, but I'd like to get a sense first of > whether we can bring this function in. > > James, I think I remember you being warm to the idea in some (jabber?) > comments during the meeting in Hiroshima when I presented this first. > > Thanks, > > - Mark > > On 3/4/10 12:06 AM, james woodyatt wrote: >> everyone-- >> >> Once again, I'd like to ask for some discussion and feedback on this >> draft. Is there any reason this revision of the draft should not >> proceed to Working Group Last Call at this time? >> >> >> -- >> james woodyatt >> member of technical staff, communications engineering >> >> >> >> >> > > > From owner-v6ops@ops.ietf.org Fri Mar 19 13:14:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6484A3A67B4 for ; Fri, 19 Mar 2010 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.176 X-Spam-Level: X-Spam-Status: No, score=-8.176 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwPzNZd+BiOc for ; Fri, 19 Mar 2010 13:14:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F04F3A677D for ; Fri, 19 Mar 2010 13:14:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsiYd-0001MR-Ko for v6ops-data0@psg.com; Fri, 19 Mar 2010 20:12:35 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsiYY-0001LK-2S for v6ops@ops.ietf.org; Fri, 19 Mar 2010 20:12:30 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,276,1267401600"; d="scan'208";a="103068065" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2010 20:12:29 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2JKCTs9017557; Fri, 19 Mar 2010 20:12:29 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2JKCRY00436; Fri, 19 Mar 2010 13:12:27 -0700 (PDT) Message-ID: <4BA3DAAA.10000@cisco.com> Date: Fri, 19 Mar 2010 21:12:26 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations , james woodyatt , "Eric Vyncke (evyncke)" Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> In-Reply-To: <4BA3D1B3.4010501@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/19/10 8:34 PM, Brian E Carpenter wrote: > Mark, I'm not going to reply to your specific question. > That's too bad. > The one most clear result from the ISP survey I will report > on during the IETF is that the biggest gap in products holding > up general v6 deployment is CPE. > Understood. > I think it's a matter of great urgency to get this draft > out as an RFC; it's a couple of years too late. > It's more the implementations that are late, but I get your point. > So I want to say: let's not add *anything*. Let's just > push it out in a matter of weeks. > All we are doing is talking about allowing what is now a binary on/off in the draft now to be a variable between 0 and some maximum instead. The default could still well be what we have now, 0, though I would like it to be something else. I'm not sure that leaving this out will help advance the draft more quickly. Folks like me, who are quite happy with their native IPv6 service for the past couple of years with no IPv6 firewall, think of cpe-simple-security as a sword in the heart of IPv6 and end-to-end transparency. Including "Rule 7" is something that would go a long way towards at least me stepping back and not making an enormous ruckus when this draft hits last call. We've already talked about the idea in v6ops, it's been documented in a draft for at least a little while, and after Hiroshima I got some indication that this was something people would like to have. The basic concept comes from Dave Oran, who included it in various presentations for years. So, aside of your fears of changing anything in the draft at all, what do you think of the idea? - Mark > The same applies to draft-ietf-v6ops-ipv6-cpe-router > of course. > > Regards > Brian Carpenter > > On 2010-03-20 07:00, Mark Townsley wrote: > >> I would like to propose some form of "ParanoidOpeness" (Rule #7) from >> draft-vyncke-advanced-ipv6-security-01 to be brought into the >> simple-security draft. >> >> The basic idea is that rather than blocking otherwise unauthorized >> inbound connections outright, the CPE rate-limits them according to a >> variable setting. When that setting is 0, all incoming packets are >> dropped. When set to its maximum, all packets are permitted (as if the >> firewall function is configured off). In-between, the CPE rate-limits >> incoming packets to reduce probing of the home network, but to allow >> just enough packets through that, if a host inside responds, a pinhole >> is opened for the communication to occur. Of course, the hard part is >> what the default setting should be, but I'd like to get a sense first of >> whether we can bring this function in. >> >> James, I think I remember you being warm to the idea in some (jabber?) >> comments during the meeting in Hiroshima when I presented this first. >> >> Thanks, >> >> - Mark >> >> On 3/4/10 12:06 AM, james woodyatt wrote: >> >>> everyone-- >>> >>> Once again, I'd like to ask for some discussion and feedback on this >>> draft. Is there any reason this revision of the draft should not >>> proceed to Working Group Last Call at this time? >>> >>> >>> -- >>> james woodyatt >>> member of technical staff, communications engineering >>> >>> >>> >>> >>> >>> >> >> >> > From tewg-archive@lists.ietf.org Fri Mar 19 13:22:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49ADB3A68B6 for ; Fri, 19 Mar 2010 13:22:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 19 Mar 2010 13:22:44 -0700 (PDT) Received: from akcansa.com.tr (lns-bzn-21-82-64-69-249.adsl.proxad.net [82.64.69.249]) by core3.amsl.com (Postfix) with SMTP id 3A4663A688E for ; Fri, 19 Mar 2010 13:22:40 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100319-0, 19/03/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100319202243.3A4663A688E@core3.amsl.com> Date: Fri, 19 Mar 2010 13:22:40 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 91023 Inc. All rights reserved.

From ux@megatron.ietf.org Fri Mar 19 14:19:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0CC3A6926 for ; Fri, 19 Mar 2010 14:19:41 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 19 Mar 2010 14:19:40 -0700 (PDT) Received: from ppp109-111-137-231.tis-dialog.ru (ppp109-111-137-231.tis-dialog.ru [109.111.137.231]) by core3.amsl.com (Postfix) with SMTP id 4F5123A67E5 for ; Fri, 19 Mar 2010 14:19:38 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100319-1, 19.03.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100319211939.4F5123A67E5@core3.amsl.com> Date: Fri, 19 Mar 2010 14:19:38 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 96263 Inc. All rights reserved.

From uk@megatron.ietf.org Fri Mar 19 15:04:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2BD3A6A66 for ; Fri, 19 Mar 2010 15:04:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 19 Mar 2010 15:04:34 -0700 (PDT) Received: from 93-33-12-30.ip42.fastwebnet.it (93-33-12-30.ip42.fastwebnet.it [93.33.12.30]) by core3.amsl.com (Postfix) with SMTP id E39AF3A682A for ; Fri, 19 Mar 2010 15:04:32 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100319220432.E39AF3A682A@core3.amsl.com> Date: Fri, 19 Mar 2010 15:04:32 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 34142 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Fri Mar 19 15:15:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5090E3A6A77 for ; Fri, 19 Mar 2010 15:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.643 X-Spam-Level: X-Spam-Status: No, score=-103.643 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEh8DJ-K+dQu for ; Fri, 19 Mar 2010 15:15:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E34A3A6A69 for ; Fri, 19 Mar 2010 15:15:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NskNq-000MIn-L8 for v6ops-data0@psg.com; Fri, 19 Mar 2010 22:09:34 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NskNl-000MHR-Qp for v6ops@ops.ietf.org; Fri, 19 Mar 2010 22:09:29 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id EC3CC913DD11 for ; Fri, 19 Mar 2010 15:09:28 -0700 (PDT) X-AuditID: 1180711d-b7c97ae00000413c-25-4ba3f61842f6 Received: from il0602b-dhcp111.apple.com (il0602b-dhcp111.apple.com [17.206.24.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 95.30.16700.816F3AB4; Fri, 19 Mar 2010 15:09:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <4BA3D1B3.4010501@gmail.com> Date: Fri, 19 Mar 2010 15:09:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 19, 2010, at 12:34, Brian E Carpenter wrote: >=20 > So I want to say: let's not add *anything*. Let's just push it out in = a matter of weeks. I'm currently sitting on a couple of minor edits: + Cite RFC 4007 to clear up confusion about multicast group scope = boundaries. + Fix some inconsistencies between cpe-simple-security and RFC 4890. I'm planning to post the -10 revision tonight, then start revising my = slides for Monday morning. We shall see if there is a rough consensus = for sending the -10 revision up the stack in the days following the = meeting, or if further wrangling over it in the working group is in = order. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Mar 19 16:50:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D443E3A6A97 for ; Fri, 19 Mar 2010 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.659 X-Spam-Level: *** X-Spam-Status: No, score=3.659 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iNd8w4v92bm for ; Fri, 19 Mar 2010 16:50:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 245BB3A69F7 for ; Fri, 19 Mar 2010 16:50:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsltS-000CUQ-03 for v6ops-data0@psg.com; Fri, 19 Mar 2010 23:46:18 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsltO-000CR0-84 for v6ops@ops.ietf.org; Fri, 19 Mar 2010 23:46:14 +0000 Received: from [122.49.161.36] (helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NsltE-0006Xi-Vc; Sat, 20 Mar 2010 10:16:05 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 36C094930C; Sat, 20 Mar 2010 10:16:04 +1030 (CST) Date: Sat, 20 Mar 2010 10:16:02 +1030 From: Mark Smith To: james woodyatt Cc: "STARK, BARBARA H (ATTLABS)" , IPv6 Operations , 6man Chairs <6man-chairs@tools.ietf.org> Subject: Re: RFC 5006 status Message-ID: <20100320101602.1c695dc1@opy.nosense.org> In-Reply-To: <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt wrote: > On Mar 19, 2010, at 05:41, STARK, BARBARA H (ATTLABS) wrote: > > [I wrote:] > >> > >> I can see utility in the *limited* extension of RDNSS to standards > >> track, because it allows zero-configuration hosts on IPv6 networks > >> where all the routers advertise O=0 to have some hope of resolving > >> domain names after joining them. They don't get that today, and I > >> don't see a good way to use DHCP to do anything about that. > > > > I'm confused by this O=0 proposal. I thought the O flag was intended to > > announce that there was a DHCP server available with other (non-IA) > > configuration info, including NTP, SIP server, DNS, etc. > > Yes, but O=0 does not actually imply that there MUST be no DHCP service, despite the Note on page 19 of RFC 4861. It merely implies that there MAY be no DHCP service. Another router on the same link can assert by advertising to hosts with O=1 that there MUST be a DHCP service. > > > Is this > > suggesting that the O flag be used exclusively to announce the > > availability of DNS info in DHCPv6, and not any other config info? > > Not at all. > > > Should clients just guess whether DHCPv6 is available for non-IA, > > non-DNS info? > > Right now, the only standard way to configure hosts dynamically with DNS server addresses is with DHCPv6. Hosts that join networks where no routers are advertising O=1 are either configured with DNS server addresses manually, or they are forced to start their DHCPv6 clients to get configured-- despite the fact that all the routers are explicitly warning that there MAY be no DHCPv6 service available. > > So. An alternative way forward out of this mess would be to leave RFC 5006 in experimental category and deprecate the O bit entirely, i.e. update the router requirements to require all RA to be sent with O=1, and explicitly encourage hosts with DHCPv6 stateless clients to start them immediately on completion of SLAAC regardless of the state of AdvOtherConfigFlag. I'd support that too. > > > Is it suggesting that if clients do not support RFC5006 > > for getting DNS info (but do support DHCPv6), that they not be given a > > hint that a DHCPv6 server is available that might have other config > > info? Or, with O=0, would there be a simultaneous proposal that support > > for RFC5006 be mandatory in clients? > > I don't see a need to revise the host requirements to make support for processing RDNSS options in router advertisements any more necessary for conformance than support for processing DHCP. > > But if we *did*, then that would mean that a certain operating system I'm thinking about would no longer be able to claim compliance with IPv6 host requirements while still requiring domesticated primates to type numeric IPv6 addresses into a squirrelly little text window buried three layers down in System Preferences before they can watch the special dancing animation on their favorite IPv6 pr0n site. > > I'm trying to be careful what else I say about that. > > > Just trying to understand this, since I've seen it suggested before, and > > can't quite figure out the full range of expected behavior in the wild > > frontier of IPv6 home networks. > > Here's what the IPv6 router on my home network does today: > > + Advertises with O=1 and M=0. > + Offers stateless DHCP6 service with its own global address as the DNS server for the link. > + Advertises with RFC 5006 its own global address as the DNS server for the link. > - Lifetime is set the same as the prefix lifetime. > + Runs a recursive DNS forwarding server (access limited to the LAN prefix). > > Currently, all the hosts on my home network that can process RFC 5006 messages also have DHCPv6 clients in them, so they process both sources of DNS server address, merge them together and get the single address that's advertised in both, and they configure themselves appropriately. > > The interesting part happens when the delegated prefix changes, e.g. when I switch the WAN uplink from one network to another. The addresses of the DNS servers available to hosts on the LAN link changes. This gets reflected quickly in the RDNSS options that the router sends, and the hosts with RFC 5006 clients updates their DNS resolver configurations immediately. Since I don't have any hosts with *only* a DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such hosts when their DNS server addresses need to be changed away from the ones they learned from their DHCPv6 lease. I suspect they just keep using the addresses they were initially offered until their lease expires, and this will produce suboptimal user experience until they go to renew. > I think that issue would be resolved by having your CPE use it's LAN interface ULA addresses to announce it's local DNS resolution service. Doing that isn't explicitly mentioned in the basic CPE draft, however as the CPE's DNs resolution service is an optional 'site local' service, I think using the CPE's LAN interface ULA address to announce it would make sense, and avoid the issue you mention. Regards, Mark. From owner-v6ops@ops.ietf.org Fri Mar 19 16:51:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98A63A69F7 for ; Fri, 19 Mar 2010 16:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW403nXmAwEE for ; Fri, 19 Mar 2010 16:51:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 905213A6767 for ; Fri, 19 Mar 2010 16:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nslxt-000D7U-Vc for v6ops-data0@psg.com; Fri, 19 Mar 2010 23:50:53 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nslxq-000D72-QB for v6ops@ops.ietf.org; Fri, 19 Mar 2010 23:50:50 +0000 Received: by gxk20 with SMTP id 20so138275gxk.18 for ; Fri, 19 Mar 2010 16:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ECAktaAUPXySvpRQTlaTUXl+wYk6nETgvJnLGbzONeE=; b=DkUYL5LM2OACzoydBo5kzWD6sjYeLBBjaqFzwZdmzODd62NUomo8vq6+glJKep5coV e0cpf0eAHiApupz96Ir5PmPyfMmHuYkK10wai1tuYQMZfV4ZdvgUnpg+feyMhnp8i2ug 3TA1cSDXclmLUQOCvMuYfLq1i71i0y9k0pCNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GW5HN2ITRYtZIl4lHwpIW2RiwZzhyRhCR3EIbfIK9JsfWZ8Fsy1mrCfYj6uCgnlrh1 2JWqCjH8k0Nm12bGNN7jy/gssqrMQSfG60fCRL4wmKPfkAN29hyc1Crj8I2XS6ykrTWP SviT9GpKmuGVI+kvSE6M7UQFBahdlU9kKQSzM= Received: by 10.90.14.14 with SMTP id 14mr1163615agn.34.1269042649839; Fri, 19 Mar 2010 16:50:49 -0700 (PDT) Received: from [10.1.1.3] ([121.98.142.15]) by mx.google.com with ESMTPS id 20sm496024ywh.18.2010.03.19.16.50.46 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Mar 2010 16:50:49 -0700 (PDT) Message-ID: <4BA40DD1.7080306@gmail.com> Date: Sat, 20 Mar 2010 12:50:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley CC: IPv6 Operations , james woodyatt , "Eric Vyncke (evyncke)" Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> In-Reply-To: <4BA3DAAA.10000@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark, I dislike 'default deny' as much as anyone. After all, I'm an author of RFC 4864. But I'm afraid that the simplicity of 'default deny' has long ago won the hearts and minds of enterprise network managers. I can see the virtues of rate limiting, but I see it as too contentious to attempt to get it into the *simple* security draft. Sadly. Regards Brian On 2010-03-20 09:12, Mark Townsley wrote: > On 3/19/10 8:34 PM, Brian E Carpenter wrote: >> Mark, I'm not going to reply to your specific question. >> > That's too bad. >> The one most clear result from the ISP survey I will report >> on during the IETF is that the biggest gap in products holding >> up general v6 deployment is CPE. >> > Understood. >> I think it's a matter of great urgency to get this draft >> out as an RFC; it's a couple of years too late. >> > It's more the implementations that are late, but I get your point. >> So I want to say: let's not add *anything*. Let's just >> push it out in a matter of weeks. >> > > All we are doing is talking about allowing what is now a binary on/off > in the draft now to be a variable between 0 and some maximum instead. > The default could still well be what we have now, 0, though I would like > it to be something else. > > I'm not sure that leaving this out will help advance the draft more > quickly. Folks like me, who are quite happy with their native IPv6 > service for the past couple of years with no IPv6 firewall, think of > cpe-simple-security as a sword in the heart of IPv6 and end-to-end > transparency. Including "Rule 7" is something that would go a long way > towards at least me stepping back and not making an enormous ruckus when > this draft hits last call. > > We've already talked about the idea in v6ops, it's been documented in a > draft for at least a little while, and after Hiroshima I got some > indication that this was something people would like to have. The basic > concept comes from Dave Oran, who included it in various presentations > for years. > > So, aside of your fears of changing anything in the draft at all, what > do you think of the idea? > > - Mark >> The same applies to draft-ietf-v6ops-ipv6-cpe-router >> of course. >> >> Regards >> Brian Carpenter >> >> On 2010-03-20 07:00, Mark Townsley wrote: >> >>> I would like to propose some form of "ParanoidOpeness" (Rule #7) from >>> draft-vyncke-advanced-ipv6-security-01 to be brought into the >>> simple-security draft. >>> >>> The basic idea is that rather than blocking otherwise unauthorized >>> inbound connections outright, the CPE rate-limits them according to a >>> variable setting. When that setting is 0, all incoming packets are >>> dropped. When set to its maximum, all packets are permitted (as if the >>> firewall function is configured off). In-between, the CPE rate-limits >>> incoming packets to reduce probing of the home network, but to allow >>> just enough packets through that, if a host inside responds, a pinhole >>> is opened for the communication to occur. Of course, the hard part is >>> what the default setting should be, but I'd like to get a sense first of >>> whether we can bring this function in. >>> >>> James, I think I remember you being warm to the idea in some (jabber?) >>> comments during the meeting in Hiroshima when I presented this first. >>> >>> Thanks, >>> >>> - Mark >>> >>> On 3/4/10 12:06 AM, james woodyatt wrote: >>> >>>> everyone-- >>>> >>>> Once again, I'd like to ask for some discussion and feedback on this >>>> draft. Is there any reason this revision of the draft should not >>>> proceed to Working Group Last Call at this time? >>>> >>>> >>>> -- >>>> james woodyatt >>>> member of technical staff, communications engineering >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> > > From owner-v6ops@ops.ietf.org Fri Mar 19 17:03:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B093A6767 for ; Fri, 19 Mar 2010 17:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.359 X-Spam-Level: *** X-Spam-Status: No, score=3.359 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vHkiMzQMkzn for ; Fri, 19 Mar 2010 17:03:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 308E53A65A6 for ; Fri, 19 Mar 2010 17:03:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsm8R-000EsY-Df for v6ops-data0@psg.com; Sat, 20 Mar 2010 00:01:47 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsm8O-000EsF-KQ for v6ops@ops.ietf.org; Sat, 20 Mar 2010 00:01:45 +0000 Received: from [122.49.161.36] (helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nsm8I-0006uk-Dd; Sat, 20 Mar 2010 10:31:38 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E86814930C; Sat, 20 Mar 2010 10:31:37 +1030 (CST) Date: Sat, 20 Mar 2010 10:31:37 +1030 From: Mark Smith To: "STARK, BARBARA H (ATTLABS)" Cc: "IPv6 Operations" , "6man Chairs" <6man-chairs@tools.ietf.org> Subject: Re: RFC 5006 status Message-ID: <20100320103137.345aa6f1@opy.nosense.org> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F12257D79@crexc50p> References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D79@crexc50p> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Fri, 19 Mar 2010 09:26:29 -0400 "STARK, BARBARA H (ATTLABS)" wrote: > My sense of what's going on in the industry is that there is a lot of > momentum around RFC5006 being used inside home networks. It is widely > stated and believed that clients and OSs exist that only support RFC5006 > and not DHCPv6 for DNS (v6 server) acquisition. Therefore, most router > manufacturers and ISPs seem to be leaning towards putting RFC5006 inside > the routers anyway, no matter the status of the RFC. > One possible explanation is that RAs have been supported by all IPv6 implementations since they were originally released, however DHCPv6 clients, relays and servers have only become available in the last 5 or so years. Now there is at least one implementation available, for all major end-node OSes. However, if people who you're getting opinions from are still making the assumption of the lack of DHCPv6 implementations, then they're quite predictably going to say that RAs should carry everything, because all IPv6 implementations support processing RAs, despite existing RA processing not currently supporting any of the option they'd like to put in RAs. > I say acknowledge the inevitable and make it a standard. There's no way > to put this genie back in the bottle. > > Beyond RFC5006, I really, really hope that the IETF doesn't try to > duplicate all DHCPv6 stateless config in RA (and I would have preferred > not having DNS in RA -- but, like I said, what's done is done, and the > inevitability of RFC5006 just has to be accepted). > > My concerns are centered around operations, testing devices to make sure > they work, and troubleshooting customer configuration problems. > > When clients are given the ability to choose among multiple ways to do > the same thing, this means that the router/server has to support *all* > of these ways. Even if each is simple on its own, the complexity of > supporting all methods is additive (at a minimum). All methods have to > be coded, and all have to be tested. This doubles the effort of > coding/testing on the routers. > > When a customer calls to complain that something isn't working, and it > turns out something didn't get configured, we'll have to figure out > first how it was expecting to get configured. This increases the > complexity of troubleshooting. > > What I need, operationally, is predictability. All this discussion > around "let's create half a dozen ways to do the same thing so hosts can > choose the one they like best" is a recipe for failure. Every time the > IETF creates a new way to do something that can already be easily done, > you're introducing complexity and make it that much more likely that > things will go wrong for the average consumer. Please, please, please > -- Keep It Simple, for every device in the ecosystem. > Barbara > > From owner-v6ops@ops.ietf.org Fri Mar 19 17:25:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC36A3A6954 for ; Fri, 19 Mar 2010 17:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.359 X-Spam-Level: ** X-Spam-Status: No, score=2.359 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-LpuZ8ke9Kw for ; Fri, 19 Mar 2010 17:25:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5174C3A6888 for ; Fri, 19 Mar 2010 17:25:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsmT7-000HoN-9Y for v6ops-data0@psg.com; Sat, 20 Mar 2010 00:23:09 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsmT1-000Hns-6y for v6ops@ops.ietf.org; Sat, 20 Mar 2010 00:23:03 +0000 Received: from [122.49.161.36] (helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NsmSb-0007QI-JQ; Sat, 20 Mar 2010 10:52:37 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 20DA24930C; Sat, 20 Mar 2010 10:52:37 +1030 (CST) Date: Sat, 20 Mar 2010 10:52:37 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Cc: Syam Madanapalli , Fred Baker , IPv6 Operations , Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, Daniel Park , Suresh Krishnan , Dan Wing Subject: Re: RFC 5006 status Message-ID: <20100320105237.4c26d906@opy.nosense.org> In-Reply-To: <0825C17F-F22C-4E1E-B74D-6340BC79116D@free.fr> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <818AC122-7E68-45F7-A167-672F7DE47207@free.fr> <10e14db21003190405p323e9ddaoab4aab650971ae3e@mail.gmail.com> <20100319235049.349f5a18@opy.nosense.org> <0825C17F-F22C-4E1E-B74D-6340BC79116D@free.fr> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 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 List-ID: On Fri, 19 Mar 2010 15:07:49 +0100 R=E9mi Despr=E9s wrote: >=20 > Le 19 mars 2010 =E0 14:20, Mark Smith a =E9crit : >=20 > > The existing mechanisms work, both in theory, and in practice. I think > > that means that the onus is on the RA for everything proponents to > > *prove* where it doesn't work... >=20 > There is clearly no proof that it doesn't work, but there is a proof that= efficiency can be improved by a very small complement. >=20 So it would seem to don't place any value on deployment costs, troubleshooting costs, developer time spent on duplication of functionality that could be spent on new and different functionality or bug fixing existing functionality, functionality interaction and duplicate information arbitration should it not match. They're the biggest costs of new features. Comparatively, the cost of standardising things in the IETF is minuscule. > > ... before anybody should spend valuable time > > redesigning the existing mechanisms. >=20 > There is no "redesign", just an optional complement for which, contributo= rs who wish to implement it, need an approved common format. > Those that don't want to support it are free not to: things will continue= to work for them as before, just less efficiently than for those who have = the complement.=20 >=20 > > There are better IPv6 things to > > spend time on that are far more important to *get* working, rather than > > spending time on changing the way existing things work. >=20 > Then, please let others doing it (it won't hurt you in any way), and the = discussion will terminate. >=20 Yes it will. I'm an operator. See all those costs I mentioned before? I, and the organisation and network end-users I work for, will be forced to wear them either directly day to day, or embedded in the costs of products purchased. The IETF and vendors "force" certain costs upon people like me and my customers/end-users. I'm willing to wear them and defend them to my end-users if I see more value in the benefit than the cost. Partially duplicating DHCPv6 functionality in RAs doesn't satisfy that criteria, and I'd much rather try prevent that unnecessary cost now than have to wear it for a very long period later (either until I die or retire from networking). > RD >=20 >=20 > >> On Fri, Mar 19, 2010 at 3:29 PM, R=E9mi Despr=E9s wrote: > >>>=20 > >>> Le 17 mars 2010 =E0 16:18, Fred Baker a =E9crit : > >>>=20 > >>>> http://www.ietf.org/rfc/rfc5006.txt > >>>>=20 > >>>> (1) Please take a look at the document in the next few days; if you = have comments on it (eg, you think it should be changed in some way), pleas= e comment to v6ops. > >>>=20 > >>> While supporting in general the idea, there is one improvement I sugg= est to make: > >>> Rather than a specific RA option for Recursive DNS Servers, standardi= ze the generic RA option to embed some stateless DHCP options, as proposed = in draft-krishnan-intarea-ra-dhcp-00. > >>>=20 > >>> This is in my understanding more powerful without being more complex. > >>> By giving to routers a general possibility to broadcast stateless DHC= P parameters (in addition to their still being obtainable in DHCPv6), not o= nly the purpose of RFC50026 is achieved but, in one shot, the same progress= is made for all common parameters that may concern all or most hosts. > >>>=20 > >>> Hosts that support the RA DHCP option only have to: (1) process embed= ded DHCP options that they understand; (2) skip others; (3) request in DHCP= v6 only options that aren't already received in RAs, if any. > >>>=20 > >>> Note that Suresh Krishnan has 15min slot scheduled at the 6man meetin= g of Wednesday for: > >>> "Stateless DHCPv6 and Router Advertisements for propagating configura= tion information". > >>>=20 > >>> I add Suresh to the list, and Dan Wing who is known to support this a= pproach. > >>>=20 > >>> RD > >>>=20 > >>>=20 > >>=20 > >=20 >=20 >=20 From secmech-request@lists.ietf.org Fri Mar 19 17:29:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124943A6888 for ; Fri, 19 Mar 2010 17:29:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 19 Mar 2010 17:29:32 -0700 (PDT) Received: from 3mail.com (unknown [201.155.98.127]) by core3.amsl.com (Postfix) with SMTP id AAB493A681C for ; Fri, 19 Mar 2010 17:29:26 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100320002929.AAB493A681C@core3.amsl.com> Date: Fri, 19 Mar 2010 17:29:26 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 25316 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Fri Mar 19 17:33:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164473A685B for ; Fri, 19 Mar 2010 17:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.612 X-Spam-Level: X-Spam-Status: No, score=-103.612 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjEyIrl7GN4V for ; Fri, 19 Mar 2010 17:33:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F9063A672E for ; Fri, 19 Mar 2010 17:33:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsmc8-000J9Q-ND for v6ops-data0@psg.com; Sat, 20 Mar 2010 00:32:28 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsmc3-000J8k-JB for v6ops@ops.ietf.org; Sat, 20 Mar 2010 00:32:23 +0000 Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 4F1BC91426B2 for ; Fri, 19 Mar 2010 17:32:22 -0700 (PDT) X-AuditID: 11807136-b7ccdae0000001ab-39-4ba41796de1f Received: from il0602b-dhcp111.apple.com (il0602b-dhcp111.apple.com [17.206.24.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 85.4F.00427.69714AB4; Fri, 19 Mar 2010 17:32:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <4BA40DD1.7080306@gmail.com> Date: Fri, 19 Mar 2010 17:32:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C168711-6A34-4487-9911-92766513183C@apple.com> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: >=20 > But I'm afraid that the simplicity of 'default deny' has long > ago won the hearts and minds of enterprise network managers. Sadly, enterprise network managers aren't the only people whose = legitimate interests are at stake in the matter under discussion. -- james woodyatt member of technical staff, communications engineering From v6ops-archive@megatron.ietf.org Fri Mar 19 17:45:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09F13A6954 for ; Fri, 19 Mar 2010 17:45:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 19 Mar 2010 17:45:07 -0700 (PDT) Received: from mur78-4-88-174-242-209.fbx.proxad.net (mur78-4-88-174-242-209.fbx.proxad.net [88.174.242.209]) by core3.amsl.com (Postfix) with SMTP id 0E00A3A689A for ; Fri, 19 Mar 2010 17:45:05 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 74% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100320004506.0E00A3A689A@core3.amsl.com> Date: Fri, 19 Mar 2010 17:45:05 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 24328 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Fri Mar 19 18:35:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC7F3A690C for ; Fri, 19 Mar 2010 18:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX8iXq8iNUlB for ; Fri, 19 Mar 2010 18:35:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 054C73A6872 for ; Fri, 19 Mar 2010 18:35:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsnV2-00005Y-QW for v6ops-data0@psg.com; Sat, 20 Mar 2010 01:29:12 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsnRv-000PmZ-0D for v6ops@ops.ietf.org; Sat, 20 Mar 2010 01:27:55 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 547498A3EA0A; Fri, 19 Mar 2010 18:25:38 -0700 (PDT) X-AuditID: 11807134-b7b29ae000001f57-29-4ba4240db534 Received: from [17.151.83.62] (Unknown_Domain [17.151.83.62]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id BC.1E.08023.01424AB4; Fri, 19 Mar 2010 18:25:38 -0700 (PDT) Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <20100320101602.1c695dc1@opy.nosense.org> Date: Fri, 19 Mar 2010 18:25:30 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <15FE33C4-45AC-49D2-B7BB-1AC5829A818A@apple.com> References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> <20100320101602.1c695dc1@opy.nosense.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 19, 2010, at 16:46, Mark Smith wrote: > On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt = wrote: >>=20 >> The interesting part happens when the delegated prefix changes, e.g. = when I switch the WAN uplink from one network to another. The addresses = of the DNS servers available to hosts on the LAN link changes. This = gets reflected quickly in the RDNSS options that the router sends, and = the hosts with RFC 5006 clients updates their DNS resolver = configurations immediately. Since I don't have any hosts with *only* a = DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such = hosts when their DNS server addresses need to be changed away from the = ones they learned from their DHCPv6 lease. I suspect they just keep = using the addresses they were initially offered until their lease = expires, and this will produce suboptimal user experience until they go = to renew. >=20 > I think that issue would be resolved by having your CPE use it's LAN > interface ULA addresses to announce it's local DNS resolution service. > Doing that isn't explicitly mentioned in the basic CPE draft, however = as > the CPE's DNs resolution service is an optional 'site local' service, = I > think using the CPE's LAN interface ULA address to announce it would > make sense, and avoid the issue you mention. That might work fine for routers that are integrated with their own DNS = forwarding servers. The interesting case is routers that *DO NOT* have = integrated DNS servers, which if I recall correctly, the current CPE = router draft implicitly assumes. In those cases, when the service provider moves the DNS servers, or when = the WAN link is dropped and reacquired at a new connection point with a = different delegated prefix and new DNS servers, the hosts on the LAN = need to have their resolver configurations renumbered. The RDNSS option = in router advertisements permits this to happen immediately after = reattaching to the service provider network for every host on the LAN = with a short burst of link-local multicast packets, but DHCP requires a = Reconfiguration message to be unicast to every client, which implies = that all the hosts on the LAN are required to implement not just DHCP6, = but DHCP Authentication. Any hosts that can't do DHCP Authentication = won't get their resolvers reconfigured until they renew their lease. = Bletch. I think RFC 5006 is a much simpler solution for this scenario. But I = recognize that there are people who think that every IPv6 network, = *everywhere*-- even the ones in our own homes-- should have *every* = interface address managed and firewalled six ways to Sunday, in case the = secret police come calling and wish to inspect the premises for evidence = of terrorist activity. I really don't know what to say to those people = anymore. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Mar 19 19:12:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222393A67B1 for ; Fri, 19 Mar 2010 19:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.544 X-Spam-Level: X-Spam-Status: No, score=0.544 tagged_above=-999 required=5 tests=[AWL=-2.691, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQzf8C8e1tO5 for ; Fri, 19 Mar 2010 19:12:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 782D73A6821 for ; Fri, 19 Mar 2010 19:12:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nso8N-0006o6-Kk for v6ops-data0@psg.com; Sat, 20 Mar 2010 02:09:51 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nso8I-0006nF-Pm for v6ops@ops.ietf.org; Sat, 20 Mar 2010 02:09:46 +0000 Received: (qmail 2868 invoked by uid 399); 20 Mar 2010 02:09:44 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Mar 2010 02:09:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BA42E67.2090506@dougbarton.us> Date: Fri, 19 Mar 2010 19:09:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: RFC 5006 status References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> <20100320101602.1c695dc1@opy.nosense.org> <15FE33C4-45AC-49D2-B7BB-1AC5829A818A@apple.com> In-Reply-To: <15FE33C4-45AC-49D2-B7BB-1AC5829A818A@apple.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 03/19/10 18:25, james woodyatt wrote: > On Mar 19, 2010, at 16:46, Mark Smith wrote: >> On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt >> wrote: >>> >>> The interesting part happens when the delegated prefix changes, >>> e.g. when I switch the WAN uplink from one network to another. >>> The addresses of the DNS servers available to hosts on the LAN >>> link changes. This gets reflected quickly in the RDNSS options >>> that the router sends, and the hosts with RFC 5006 clients >>> updates their DNS resolver configurations immediately. Since I >>> don't have any hosts with *only* a DHCPv6 client and no RFC 5006 >>> client, I'm not sure what happens to such hosts when their DNS >>> server addresses need to be changed away from the ones they >>> learned from their DHCPv6 lease. I suspect they just keep using >>> the addresses they were initially offered until their lease >>> expires, and this will produce suboptimal user experience until >>> they go to renew. >> >> I think that issue would be resolved by having your CPE use it's >> LAN interface ULA addresses to announce it's local DNS resolution >> service. Doing that isn't explicitly mentioned in the basic CPE >> draft, however as the CPE's DNs resolution service is an optional >> 'site local' service, I think using the CPE's LAN interface ULA >> address to announce it would make sense, and avoid the issue you >> mention. > > That might work fine for routers that are integrated with their own > DNS forwarding servers. The interesting case is routers that *DO > NOT* have integrated DNS servers, which if I recall correctly, the > current CPE router draft implicitly assumes. Given the large number of problems these forwarders cause for advancement to the DNS protocol (EDNS0, DNSSEC, new RR types, etc.) I think continuing to encourage NOT including them is the best course of action. > In those cases, when the service provider moves the DNS servers, On a rational network this does not happen often enough to be considered a primary design goal. > when the WAN link is dropped and reacquired at a new connection point > with a different delegated prefix and new DNS servers, Both RA and DHCP already handle this case. > The RDNSS option in router advertisements permits this to happen > immediately after reattaching to the service provider network for > every host on the LAN with a short burst of link-local multicast > packets, but DHCP requires a Reconfiguration message to be unicast to > every client, which implies that all the hosts on the LAN are > required to implement not just DHCP6, but DHCP Authentication. See above. > I think RFC 5006 is a much simpler solution for this scenario. But I > recognize that there are people who think that every IPv6 network, > *everywhere*-- even the ones in our own homes-- should have *every* > interface address managed and firewalled six ways to Sunday, in case > the secret police come calling and wish to inspect the premises for > evidence of terrorist activity. I really don't know what to say to > those people anymore. Um, wow. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-v6ops@ops.ietf.org Fri Mar 19 20:08:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9691A3A69EE for ; Fri, 19 Mar 2010 20:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.876 X-Spam-Level: ** X-Spam-Status: No, score=2.876 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdTgtZeg6Pv2 for ; Fri, 19 Mar 2010 20:08:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 009EA3A67F4 for ; Fri, 19 Mar 2010 20:08:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsoyP-000E22-Ne for v6ops-data0@psg.com; Sat, 20 Mar 2010 03:03:37 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsoyF-000Dz3-L4 for v6ops@ops.ietf.org; Sat, 20 Mar 2010 03:03:28 +0000 Received: from [122.49.161.36] (helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NsoyB-0002zD-Sl; Sat, 20 Mar 2010 13:33:23 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 37BAC4930C; Sat, 20 Mar 2010 13:33:23 +1030 (CST) Date: Sat, 20 Mar 2010 13:33:22 +1030 From: Mark Smith To: james woodyatt Cc: IPv6 Operations , 6man Chairs <6man-chairs@tools.ietf.org> Subject: Re: RFC 5006 status Message-ID: <20100320133322.3b9474cf@opy.nosense.org> In-Reply-To: <15FE33C4-45AC-49D2-B7BB-1AC5829A818A@apple.com> References: <80B618A6-699D-429E-A890-E4B73BA2BA84@apple.com> <750BF7861EBBE048B3E648B4BB6E8F4F12257D01@crexc50p> <741F78FD-E6A4-4C48-A018-64ED02828388@apple.com> <20100320101602.1c695dc1@opy.nosense.org> <15FE33C4-45AC-49D2-B7BB-1AC5829A818A@apple.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Fri, 19 Mar 2010 18:25:30 -0700 james woodyatt wrote: > On Mar 19, 2010, at 16:46, Mark Smith wrote: > > On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt wrote: > >> > >> The interesting part happens when the delegated prefix changes, e.g. when I switch the WAN uplink from one network to another. The addresses of the DNS servers available to hosts on the LAN link changes. This gets reflected quickly in the RDNSS options that the router sends, and the hosts with RFC 5006 clients updates their DNS resolver configurations immediately. Since I don't have any hosts with *only* a DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such hosts when their DNS server addresses need to be changed away from the ones they learned from their DHCPv6 lease. I suspect they just keep using the addresses they were initially offered until their lease expires, and this will produce suboptimal user experience until they go to renew. > > > > I think that issue would be resolved by having your CPE use it's LAN > > interface ULA addresses to announce it's local DNS resolution service. > > Doing that isn't explicitly mentioned in the basic CPE draft, however as > > the CPE's DNs resolution service is an optional 'site local' service, I > > think using the CPE's LAN interface ULA address to announce it would > > make sense, and avoid the issue you mention. > > That might work fine for routers that are integrated with their own DNS forwarding servers. The interesting case is routers that *DO NOT* have integrated DNS servers, which if I recall correctly, the current CPE router draft implicitly assumes. > In principle I'm generally against CPE having DNS resolvers in them, as they've caused me enough trouble in the past, however, that's probably fundamentally been caused by implementation issues, not so much an issue with the idea. I'm wondering if it is right for the CPE router draft to assume that, if it is being assumed to be the common case. It seems to be a very common thing for DNS resolvers to be implemented in the CPE, including in some IPv6 capable CPE I've seen. I also think there is a possibility that service providers may start delegating forward and reverse DNS zones to customers' CPE e.g. .cust.example.com and ..in-addr.arpa. That, combination with things like Zeroconf/DNS-Service Discovery, will mean CPE may also become authoritative DNS servers as well as resolvers. > In those cases, when the service provider moves the DNS servers, or when the WAN link is dropped and reacquired at a new connection point with a different delegated prefix and new DNS servers, the hosts on the LAN need to have their resolver configurations renumbered. I'd think service providers changing DNS servers addresses these days would be a rare event. The service providers I've worked at have either implemented anycast DNS or already have it, to avoid having to change DNS addresses. One contributor to this problem is that for some reason one of the troubleshooting steps helpdesks seem to automatically do is get the customer to statically configure the DNS server IP addresses, even though the networking equipment is providing it automatically e.g. via PPP. Usually when that doesn't fix the customers issue, the helpdesk don't get the customer to reverse it, so as time goes on you have more and more customers with static DNS configurations. That makes it pretty much impossible to change DNS IP addresses these days. Even if only 5% of customers have static DNS addresses, with 50K+ customers, your still looking at 2500 additional helpdesk calls within hours of the change if you do it. Because of that, even if you do implement new anycast DNS servers with IPv4 /32s out of a range of addresses reserved for /32s, you will also need to now anycast the old DNS server addresses as /32s even if they formerly out of e.g. a /24 assigned to a LAN. My estimate would be that if you want that /24 back to use as a /24, rather than a new range of 256 /32s, you'll be waiting around 5 years before the customer disruption caused by removing them is small enough. I do agree that updating DNS addresses caused by a change of provider is an issue. > The RDNSS option in router advertisements permits this to happen > immediately after reattaching to the service provider network for > every host on the LAN with a short burst of link-local multicast > packets, but DHCP requires a Reconfiguration message to be unicast to > every client, which implies that all the hosts on the LAN are > required to implement not just DHCP6, but DHCP Authentication. Any > hosts that can't do DHCP Authentication won't get their resolvers > reconfigured until they renew their lease. Bletch. > > I think RFC 5006 is a much simpler solution for this scenario. But I recognize that there are people who think that every IPv6 network, *everywhere*-- even the ones in our own homes-- should have *every* interface address managed and firewalled six ways to Sunday, in case the secret police come calling and wish to inspect the premises for evidence of terrorist activity. I really don't know what to say to those people anymore. > Wind up their paranoia until they completely disconnect from the Internet, and aren't a problem for you anymore :-) David Icke has a few theories that might help with that. The CIA/NSA/etc. would be the least of their worries if they find out about the reptilian humanoids that are controlling the world. ;-) Regards, Mark. From owner-v6ops@ops.ietf.org Fri Mar 19 21:00:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD703A6452 for ; Fri, 19 Mar 2010 21:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.568 X-Spam-Level: *** X-Spam-Status: No, score=3.568 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NieiDqTlMySb for ; Fri, 19 Mar 2010 21:00:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FF0C3A6782 for ; Fri, 19 Mar 2010 21:00:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsppK-000LYv-8c for v6ops-data0@psg.com; Sat, 20 Mar 2010 03:58:18 +0000 Received: from [194.15.141.107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsppH-000LYZ-4T for v6ops@ops.ietf.org; Sat, 20 Mar 2010 03:58:15 +0000 Received: from 207.88.181.169.ptr.us.xo.net (207.88.181.169.ptr.us.xo.net [207.88.181.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 7AA7F2E03C; Sat, 20 Mar 2010 04:34:11 +0100 (CET) Subject: Re: Overloading RA [Re: RFC 5006 status] Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-31528-798256182" From: Lindqvist Kurt Erik In-Reply-To: <4BA2D6C2.1020800@mesh.ad.jp> Date: Fri, 19 Mar 2010 17:22:28 +0100 Cc: Brian E Carpenter , Ralph Droms , Gert Doering , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Content-Transfer-Encoding: 7bit Message-Id: <99B80140-857B-4994-A431-B30922D4A149@kurtis.pp.se> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> <4BA2D6C2.1020800@mesh.ad.jp> To: Seiichi Kawamura X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-31528-798256182 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (not as co-chair but as myself)=20 On 19 mar 2010, at 02.43, Seiichi Kawamura wrote: >=20 > I fully agree with Brian here. > I would choose DHCPv6 inside my ISP/data center > network to do any dynamic node configurations where necessary. > Traceability is a MUST. > But I would like to have SLAAC in other areas specifically > services that connect nodes > that don't have robust amount of resources. >=20 > So keeping SLAAC simple, but with the > options that are absolutely necessary to > get connected(default router and dns) > without relying on other protocols or manual > configuration, would be the best thing. I agree with what others have said. I believe there is a need for for = both configuration options - yes, as Ralph has pointed out there are = still some issues that needs to be clarified, but for me that would be = part of the process of moving to PS. In my day job I often see a use = case for SLAAC and I also see if used, not having the DNS option is = often an issue.=20 Best regards, - kurtis - --Apple-Mail-31528-798256182 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkujpMQACgkQAFdZ6xrc/t71kQCePAfLKtTsOySEV0g6pLQnKGYh j1oAoLm+r/ujYZQgx7loYN/QUGHQ9FCy =fKQI -----END PGP SIGNATURE----- --Apple-Mail-31528-798256182-- From v6ops-archive@ietf.org Fri Mar 19 22:35:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269643A69F0 for ; Fri, 19 Mar 2010 22:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.942 X-Spam-Level: X-Spam-Status: No, score=-19.942 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5DJ4FkHKQjn for ; Fri, 19 Mar 2010 22:35:07 -0700 (PDT) Received: from host21-195-static.15-79-b.business.telecomitalia.it (host21-195-static.15-79-b.business.telecomitalia.it [79.15.195.21]) by core3.amsl.com (Postfix) with ESMTP id 7FC543A6809 for ; Fri, 19 Mar 2010 22:35:04 -0700 (PDT) From: Branded Viagra. Fast delivery To: v6ops-archive@ietf.org Subject: Sale all week, v6ops-archive. 70% or ever bigger MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100320053504.7FC543A6809@core3.amsl.com> Date: Fri, 19 Mar 2010 22:35:04 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click to enter shop immediately
 

c 1999-2009 MUDAEBOL, Inc.
This e-mail was sent to v6ops-archive@ietf.org.

Click here to unsubscribe
From v6ops-archive@lists.ietf.org Fri Mar 19 22:35:13 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988853A69EC for ; Fri, 19 Mar 2010 22:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.942 X-Spam-Level: X-Spam-Status: No, score=-19.942 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSjsmpMVOIJQ for ; Fri, 19 Mar 2010 22:35:12 -0700 (PDT) Received: from host21-195-static.15-79-b.business.telecomitalia.it (host21-195-static.15-79-b.business.telecomitalia.it [79.15.195.21]) by core3.amsl.com (Postfix) with ESMTP id C54803A67DA for ; Fri, 19 Mar 2010 22:35:11 -0700 (PDT) From: Branded Viagra. Fast delivery To: v6ops-archive@lists.ietf.org Subject: Sale all week, v6ops-archive. 70% or ever bigger MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100320053511.C54803A67DA@core3.amsl.com> Date: Fri, 19 Mar 2010 22:35:11 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click to enter shop immediately
 

c 1999-2009 MIP, Inc.
This e-mail was sent to v6ops-archive@lists.ietf.org.

Click here to unsubscribe
From v6ops-archive@megatron.ietf.org Fri Mar 19 22:35:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3043A6809 for ; Fri, 19 Mar 2010 22:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.942 X-Spam-Level: X-Spam-Status: No, score=-39.942 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33DRLWHeaK3U for ; Fri, 19 Mar 2010 22:35:17 -0700 (PDT) Received: from host21-195-static.15-79-b.business.telecomitalia.it (host21-195-static.15-79-b.business.telecomitalia.it [79.15.195.21]) by core3.amsl.com (Postfix) with ESMTP id 0C90C3A67DA for ; Fri, 19 Mar 2010 22:35:16 -0700 (PDT) From: Branded Viagra. Fast delivery To: v6ops-archive@megatron.ietf.org Subject: Sale all week, v6ops-archive. 70% or ever bigger MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100320053517.0C90C3A67DA@core3.amsl.com> Date: Fri, 19 Mar 2010 22:35:16 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click to enter shop immediately
 

c 1999-2009 QYAJANOZ, Inc.
This e-mail was sent to v6ops-archive@megatron.ietf.org.

Click here to unsubscribe
From owner-v6ops@ops.ietf.org Sat Mar 20 00:09:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190343A67C0 for ; Sat, 20 Mar 2010 00:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.082 X-Spam-Level: X-Spam-Status: No, score=-8.082 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulHjOluPGO6g for ; Sat, 20 Mar 2010 00:09:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 131343A684B for ; Sat, 20 Mar 2010 00:09:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NssjQ-000Ju4-JH for v6ops-data0@psg.com; Sat, 20 Mar 2010 07:04:24 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NssjM-000Jrw-UA for v6ops@ops.ietf.org; Sat, 20 Mar 2010 07:04:21 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,278,1267401600"; d="scan'208";a="169514197" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2010 07:04:20 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2K74KLe024688; Sat, 20 Mar 2010 07:04:20 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2K74IY22800; Sat, 20 Mar 2010 00:04:18 -0700 (PDT) Message-ID: <4BA47371.5080802@cisco.com> Date: Sat, 20 Mar 2010 08:04:17 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations , james woodyatt , "Eric Vyncke (evyncke)" Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> In-Reply-To: <4BA40DD1.7080306@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/20/10 12:50 AM, Brian E Carpenter wrote: > Mark, > > I dislike 'default deny' as much as anyone. After all, > I'm an author of RFC 4864. > > But I'm afraid that the simplicity of 'default deny' has long > ago won the hearts and minds of enterprise network managers. > The Enterprise edge is very different than the Residential edge. This draft is targeting the Residential edge. - Mark > I can see the virtues of rate limiting, but I see it as too > contentious to attempt to get it into the *simple* security > draft. Sadly. > > Regards > Brian > > On 2010-03-20 09:12, Mark Townsley wrote: > >> On 3/19/10 8:34 PM, Brian E Carpenter wrote: >> >>> Mark, I'm not going to reply to your specific question. >>> >>> >> That's too bad. >> >>> The one most clear result from the ISP survey I will report >>> on during the IETF is that the biggest gap in products holding >>> up general v6 deployment is CPE. >>> >>> >> Understood. >> >>> I think it's a matter of great urgency to get this draft >>> out as an RFC; it's a couple of years too late. >>> >>> >> It's more the implementations that are late, but I get your point. >> >>> So I want to say: let's not add *anything*. Let's just >>> push it out in a matter of weeks. >>> >>> >> All we are doing is talking about allowing what is now a binary on/off >> in the draft now to be a variable between 0 and some maximum instead. >> The default could still well be what we have now, 0, though I would like >> it to be something else. >> >> I'm not sure that leaving this out will help advance the draft more >> quickly. Folks like me, who are quite happy with their native IPv6 >> service for the past couple of years with no IPv6 firewall, think of >> cpe-simple-security as a sword in the heart of IPv6 and end-to-end >> transparency. Including "Rule 7" is something that would go a long way >> towards at least me stepping back and not making an enormous ruckus when >> this draft hits last call. >> >> We've already talked about the idea in v6ops, it's been documented in a >> draft for at least a little while, and after Hiroshima I got some >> indication that this was something people would like to have. The basic >> concept comes from Dave Oran, who included it in various presentations >> for years. >> >> So, aside of your fears of changing anything in the draft at all, what >> do you think of the idea? >> >> - Mark >> >>> The same applies to draft-ietf-v6ops-ipv6-cpe-router >>> of course. >>> >>> Regards >>> Brian Carpenter >>> >>> On 2010-03-20 07:00, Mark Townsley wrote: >>> >>> >>>> I would like to propose some form of "ParanoidOpeness" (Rule #7) from >>>> draft-vyncke-advanced-ipv6-security-01 to be brought into the >>>> simple-security draft. >>>> >>>> The basic idea is that rather than blocking otherwise unauthorized >>>> inbound connections outright, the CPE rate-limits them according to a >>>> variable setting. When that setting is 0, all incoming packets are >>>> dropped. When set to its maximum, all packets are permitted (as if the >>>> firewall function is configured off). In-between, the CPE rate-limits >>>> incoming packets to reduce probing of the home network, but to allow >>>> just enough packets through that, if a host inside responds, a pinhole >>>> is opened for the communication to occur. Of course, the hard part is >>>> what the default setting should be, but I'd like to get a sense first of >>>> whether we can bring this function in. >>>> >>>> James, I think I remember you being warm to the idea in some (jabber?) >>>> comments during the meeting in Hiroshima when I presented this first. >>>> >>>> Thanks, >>>> >>>> - Mark >>>> >>>> On 3/4/10 12:06 AM, james woodyatt wrote: >>>> >>>> >>>>> everyone-- >>>>> >>>>> Once again, I'd like to ask for some discussion and feedback on this >>>>> draft. Is there any reason this revision of the draft should not >>>>> proceed to Working Group Last Call at this time? >>>>> >>>>> >>>>> -- >>>>> james woodyatt >>>>> member of technical staff, communications engineering >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > From owner-v6ops@ops.ietf.org Sat Mar 20 02:36:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D233A6878 for ; Sat, 20 Mar 2010 02:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.434 X-Spam-Level: X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[AWL=-1.670, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2InynsB2PH3T for ; Sat, 20 Mar 2010 02:35:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2ACC3A67EB for ; Sat, 20 Mar 2010 02:35:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsv1y-000FtP-Iv for v6ops-data0@psg.com; Sat, 20 Mar 2010 09:31:42 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nsv1l-000FsL-1c for v6ops@ops.ietf.org; Sat, 20 Mar 2010 09:31:29 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2K9VPqV027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Mar 2010 02:31:25 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2K9VPjP022421; Sat, 20 Mar 2010 02:31:25 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2K9VO7F022418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 20 Mar 2010 02:31:25 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Sat, 20 Mar 2010 02:31:24 -0700 From: "Templin, Fred L" To: Fred Baker , IPv6 Operations Date: Sat, 20 Mar 2010 02:31:22 -0700 Subject: RE: Proposed agenda for IPv6 Operations - IETF 77 Thread-Topic: Proposed agenda for IPv6 Operations - IETF 77 Thread-Index: AcrFTnXWNKtGUjh9RWCMKvq3SDah5gCv/pfw Message-ID: References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> In-Reply-To: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A64951224D7BXCHNW01Vnwnos_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --_000_E1829B60731D1740BB7A0626B4FAF0A64951224D7BXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fred, The new agenda posted on the webpages does not seem to match the one you posted to the list: http://www.ietf.org/proceedings/10mar/agenda/v6ops.html Seeing that there are new additions, I would like to propose to add the RANGER, VET and SEAL trilogy - preferably as the final session on Friday, as I have two other conflicts for the earlier portion of that sessi= on. The talk would require 15min, and would cover all three documents together (i.e., not as three separate talks). The documents are here: http://www.ietf.org/rfc/rfc5720.txt http://tools.ietf.org/html/draft-templin-intarea-vet http://tools.ietf.org/html/draft-templin-intarea-seal Thanks - Fred fred.l.templin@boeing.com ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of Fred Baker Sent: Tuesday, March 16, 2010 2:06 PM To: IPv6 Operations Subject: Proposed agenda for IPv6 Operations - IETF 77 Comments please... Basically I am putting three security issues and two 3GP= P-relevant drafts on Monday morning and the remainder on Friday morning. Ea= ch discussion gets about half an hour. If time permits in the meeting, I'll= pull agenda items forward from Friday to Monday. I have two drafts on here= that were not marked for v6ops but the authors asked me to include; next t= ime I'd appreciate it if folks used the draft-*-v6ops-* naming convention; = it makes my job easier. If I have missed anything, let me know. IPv6 Operations - IETF 77 Monday 22 March, 9:00 AM Agenda bashing Recommended Simple Security Capabilities in Customer Premises Equipment for= Providing Residential IPv6 Internet Service 18-Feb-10, Advanced Security for IPv6 CPE 8-Mar-10, Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutio= ns 1-Feb-10, IPv6 in 3GPP Evolved Packet System 24-Feb-10, Mobile Networks Considerations for IPv6 Deployment 8-Mar-10, Friday 26 March, 9:00 AM Emerging Service Provider Scenarios for IPv6 Deployment 23-Feb-10, Unicast Transmission of IPv6 Multicast Messages on Link-layer 15-Feb-10, Neighbor Cache Protection in Neighbor Discovery Protocol 2-Mar-10, DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks 16-Feb-10, Advanced Requirements for IPv6 Customer Edge Routers 8-Mar-10, http://www.ipinc.net/IPv4.GIF --_000_E1829B60731D1740BB7A0626B4FAF0A64951224D7BXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 Operations - IETF 77

Fred,

 

The new agenda posted on the webpages = does not seem to match the one

you posted to the list:<= /p>

 

  http://www= .ietf.org/proceedings/10mar/agenda/v6ops.html

 

Seeing that there are new additions, I would like to propose to add the

RANGER, VET and SEAL trilogy – preferably as the final session on

Friday, as I have two other conflicts = for the earlier portion of that session.

The talk would require 15min, and woul= d cover all three documents

together (i.e., not as three separate talks). The documents are here:

 

  http://www.ietf.org/rfc/rfc572= 0.txt

  http://tools.ietf.org/html/draf= t-templin-intarea-vet

  http://tools= .ietf.org/html/draft-templin-intarea-seal

 

Thanks – Fred

fred.l.templin@boeing.com

 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
Sent: Tuesday, March 16, 201= 0 2:06 PM
To: IPv6 Operations
Subject: Proposed agenda for= IPv6 Operations - IETF 77

 

Comments please= ... Basically I am putting three security issues and two 3GPP-relevant drafts o= n Monday morning and the remainder on Friday morning. Each discussion gets ab= out half an hour. If time permits in the meeting, I'll pull agenda items forwar= d from Friday to Monday. I have two drafts on here that were not marked for v6ops = but the authors asked me to include; next time I'd appreciate it if folks used = the draft-*-v6ops-* naming convention; it makes my job easier. If I have missed anything, let me know.

IPv6 Operations - IETF 77

Monday 22 March, 9:00 AM

Agenda bashing

 

Recommended Simple Security Capabilities in Cust= omer Premises Equipment for Providing Residential IPv6 Internet Service

18-Feb-10, <draft-ietf-v6ops-cpe-simple-security-09.txt>

Advanced Security for IPv6 CPE

8-Mar-10, <draft-vyncke-advanced-ipv6-securit= y-01.txt>

Routing Loops using ISATAP and 6to4: Problem Sta= tement and Proposed Solutions

1-Feb-10, <draft-nakibly-v6ops-tunnel-loops-01.txt>

 

IPv6 in 3GPP Evolved Packet System

24-Feb-10, <draft-korhonen-v6ops-3gpp-eps-01.txt>

Mobile Networks Considerations for IPv6 Deployme= nt

8-Mar-10, <draft-koodli-ipv6-in-mobile-networks-01.txt>

Friday 26 March, 9:00 AM

Emerging Service Provider Scenarios for IPv6 Deployment

23-Feb-10, <draft-carpenter-v6ops-isp-scenari= os-01.txt>

Unicast Transmission of IPv6 Multicast Messages = on Link-layer

15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>

Neighbor Cache Protection in Neighbor Discovery Protocol

2-Mar-10, <draft-jiang-v6ops-nc-protection-01.txt>

= DHCPv6 Prefix Delegation as IPv6 Migration Tool = in Cellular Networks

16-Feb-10, <draft-sarikaya-v6ops-prefix-delegation-00.txt>

Advanced Requirements for IPv6 Customer Edge Rou= ters

8-Mar-10, <draft-wbeebee-v6ops-ipv6-cpe-route= r-bis-02.txt>

 

 

 

--_000_E1829B60731D1740BB7A0626B4FAF0A64951224D7BXCHNW01Vnwnos_-- From uk@megatron.ietf.org Sat Mar 20 02:51:17 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B1A3A6826 for ; Sat, 20 Mar 2010 02:51:17 -0700 (PDT) X-Quarantine-ID: <5oEvsp6vwhgn> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 20 Mar 2010 02:51:16 -0700 (PDT) Received: from z-149n.ttelecom.ru (z-149n.ttelecom.ru [194.1.161.149]) by core3.amsl.com (Postfix) with SMTP id EFE513A6805 for ; Sat, 20 Mar 2010 02:51:14 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100320095114.EFE513A6805@core3.amsl.com> Date: Sat, 20 Mar 2010 02:51:14 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 68932 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Sat Mar 20 09:24:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE773A6A71 for ; Sat, 20 Mar 2010 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.456 X-Spam-Level: X-Spam-Status: No, score=-108.456 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm9xy2VeHnV3 for ; Sat, 20 Mar 2010 09:24:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2673E3A684D for ; Sat, 20 Mar 2010 09:24:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt1RA-0002jg-6D for v6ops-data0@psg.com; Sat, 20 Mar 2010 16:22:08 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt1R5-0002it-4I for v6ops@ops.ietf.org; Sat, 20 Mar 2010 16:22:03 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="94651969" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2010 16:22:02 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2KGLwwL010641; Sat, 20 Mar 2010 16:21:59 GMT From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Slides for IETF 77 Date: Sat, 20 Mar 2010 09:21:58 -0700 Message-Id: <25307CEF-5ED7-4E1D-9910-310E37A7A735@cisco.com> Cc: IPv6 Operations To: Jim Hoagland , barbara.stark@att.com, "Basavaraj.Patil@nokia.com Patil" , Chris Donley , Dave Thaler , Eric Vyncke , fltemplin@acm.org, gabor.bajko@nokia.com, Gabi Nakibly , james woodyatt , Soininen Jonne NSN FI/Espoo , jouni.nospam@gmail.com, kaisu.iisakkila@nokia.com, Naoki Matsuhira , Ole Troan , Ole Troan , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Rajeev Koodli , Sri Gundavelli , Hemant Singh , Suresh Krishnan , teemu.savolainen@nokia.com, Mark Townsley , Wes Beebee , Wojciech Dec Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I as yet do not have slides for: draft-ietf-v6ops-cpe-simple-security draft-ietf-v6ops-tunnel-security-concerns draft-vyncke-advanced-ipv6-security draft-korhonen-v6ops-3gpp-eps draft-koodli-ipv6-in-mobile-networks draft-savolainen-stateless-pd draft-nakibly-v6ops-tunnel-loops draft-gundavelli-v6ops-l2-unicast draft-matsuhira-sa46t-spec draft-wbeebee-v6ops-ipv6-cpe-router-bis draft-despres-softwire-sam I need them by Sunday (tomorrow) night to post for remote participants. From owner-v6ops@ops.ietf.org Sat Mar 20 09:24:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F813A6AC4 for ; Sat, 20 Mar 2010 09:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.435 X-Spam-Level: X-Spam-Status: No, score=-107.435 tagged_above=-999 required=5 tests=[AWL=-2.160, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PfoqLWyryPG for ; Sat, 20 Mar 2010 09:24:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCCED3A6A71 for ; Sat, 20 Mar 2010 09:24:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt1LQ-0001qj-Fr for v6ops-data0@psg.com; Sat, 20 Mar 2010 16:16:12 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt1Ky-0001oy-M8 for v6ops@ops.ietf.org; Sat, 20 Mar 2010 16:15:45 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFANqRpEtAZnwM/2dsb2JhbACBQpl8c6Q9mFSEfQSDHg X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208,217";a="94651473" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2010 16:15:43 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2KGFfeL009543; Sat, 20 Mar 2010 16:15:41 GMT Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-436-884248929 From: Fred Baker In-Reply-To: Date: Sat, 20 Mar 2010 09:15:41 -0700 Cc: IPv6 Operations Message-Id: References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-436-884248929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Well, yes. the one I posted to the list was entitled a "proposed" = agenda, and I got several notes after that from people who had not put = the word "v6ops" in their draft monikers asking to be added to it. = That's why I later posted that people could look at the posted agenda. Before I add these, let me ask: are they being discussed in int-area? If = not, I'll add the slot Friday as requested. On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote: > Fred, > =20 > The new agenda posted on the webpages does not seem to match the one > you posted to the list: > =20 > http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > =20 > Seeing that there are new additions, I would like to propose to add = the > RANGER, VET and SEAL trilogy =96 preferably as the final session on > Friday, as I have two other conflicts for the earlier portion of that = session. > The talk would require 15min, and would cover all three documents > together (i.e., not as three separate talks). The documents are here: > =20 > http://www.ietf.org/rfc/rfc5720.txt > http://tools.ietf.org/html/draft-templin-intarea-vet > http://tools.ietf.org/html/draft-templin-intarea-seal > =20 > Thanks =96 Fred > fred.l.templin@boeing.com > =20 > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Fred Baker > Sent: Tuesday, March 16, 2010 2:06 PM > To: IPv6 Operations > Subject: Proposed agenda for IPv6 Operations - IETF 77 > =20 > Comments please... Basically I am putting three security issues and = two 3GPP-relevant drafts on Monday morning and the remainder on Friday = morning. Each discussion gets about half an hour. If time permits in the = meeting, I'll pull agenda items forward from Friday to Monday. I have = two drafts on here that were not marked for v6ops but the authors asked = me to include; next time I'd appreciate it if folks used the = draft-*-v6ops-* naming convention; it makes my job easier. If I have = missed anything, let me know. > IPv6 Operations - IETF 77 >=20 > Monday 22 March, 9:00 AM >=20 > Agenda bashing > =20 > Recommended Simple Security Capabilities in Customer Premises = Equipment for Providing Residential IPv6 Internet Service > 18-Feb-10, > Advanced Security for IPv6 CPE > 8-Mar-10, > Routing Loops using ISATAP and 6to4: Problem Statement and Proposed = Solutions > 1-Feb-10, > =20 > IPv6 in 3GPP Evolved Packet System > 24-Feb-10, > Mobile Networks Considerations for IPv6 Deployment > 8-Mar-10, > Friday 26 March, 9:00 AM >=20 > Emerging Service Provider Scenarios for IPv6 Deployment > 23-Feb-10, > Unicast Transmission of IPv6 Multicast Messages on Link-layer > 15-Feb-10, > Neighbor Cache Protection in Neighbor Discovery Protocol > 2-Mar-10, > DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks > 16-Feb-10, > Advanced Requirements for IPv6 Customer Edge Routers > 8-Mar-10, > =20 > =20 > http://www.ipinc.net/IPv4.GIF > =20 http://www.ipinc.net/IPv4.GIF --Apple-Mail-436-884248929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Well, = yes. the one I posted to the list was entitled a "proposed" agenda, and = I got several notes after that from people who had not put the word = "v6ops" in their draft monikers asking to be added to it. That's why I = later posted that people could look at the posted = agenda.

Before I add these, let me ask: are they = being discussed in int-area? If not, I'll add the slot Friday as = requested.

On Mar 20, 2010, at 2:31 AM, Templin, = Fred L wrote:

Fred,

The new agenda posted on the webpages does not seem to = match the one

you posted to the list:

   

Seeing that there are new additions, I would like to = propose to add the
RANGER, VET and SEAL trilogy =96 preferably as the final = session on
Friday, as I have two other conflicts for the earlier = portion of that session.
The talk would require 15min, and = would cover all three documents
together (i.e., not as three = separate talks). The documents are here:

      Thanks =96 Fred

 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.= org] On Behalf Of Fred = Baker
Sent: Tuesday, March 16, 2010 = 2:06 PM
To: IPv6 Operations
Subject: Proposed agenda for IPv6 = Operations - IETF 77

 

Comments please... Basically I am putting = three security issues and two 3GPP-relevant drafts on Monday morning and = the remainder on Friday morning. Each discussion gets about half an = hour. If time permits in the meeting, I'll pull agenda items forward = from Friday to Monday. I have two drafts on here that were not marked = for v6ops but the authors asked me to include; next time I'd appreciate = it if folks used the draft-*-v6ops-* naming convention; it makes my job = easier. If I have missed anything, let me know.

IPv6 Operations - IETF = 77

Agenda bashing

 

18-Feb-10, = <draft-ietf-v6ops-cpe-simple-security-09.txt>
Advanced Security for IPv6 = CPE
8-Mar-10, = <draft-vyncke-advanced-ipv6-security-01.txt>
Routing Loops using ISATAP and 6to4: = Problem Statement and Proposed = Solutions
1-Feb-10, = <draft-nakibly-v6ops-tunnel-loops-01.txt>

 

24-Feb-10, = <draft-korhonen-v6ops-3gpp-eps-01.txt>
8-Mar-10, = <draft-koodli-ipv6-in-mobile-networks-01.txt>
Friday 26 March, 9:00 = AM
23-Feb-10, = <draft-carpenter-v6ops-isp-scenarios-01.txt>
Unicast Transmission of IPv6 Multicast = Messages on Link-layer
15-Feb-10, = <draft-gundavelli-v6ops-l2-unicast-00.txt>
2-Mar-10, = <draft-jiang-v6ops-nc-protection-01.txt>
16-Feb-10, = <draft-sarikaya-v6ops-prefix-delegation-00.txt>
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: = 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New = Roman'; ">Advanced Requirements for IPv6 Customer = Edge Routers
8-Mar-10, = <draft-wbeebee-v6ops-ipv6-cpe-router-bis-02.txt>
=

 

 
= --Apple-Mail-436-884248929-- From v6ops-archive@megatron.ietf.org Sat Mar 20 11:36:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314AB3A6967 for ; Sat, 20 Mar 2010 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.042 X-Spam-Level: X-Spam-Status: No, score=-23.042 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAphEB4ANXDS for ; Sat, 20 Mar 2010 11:36:13 -0700 (PDT) Received: from a157.sub210.net78.udm.net (a157.sub210.net78.udm.net [78.85.210.157]) by core3.amsl.com (Postfix) with SMTP id 04F5E3A6A1A for ; Sat, 20 Mar 2010 11:36:06 -0700 (PDT) To: Subject: Dear v6ops-archive, 12-15 March 2010 +2441 79% 0FF. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100320183610.04F5E3A6A1A@core3.amsl.com> Date: Sat, 20 Mar 2010 11:36:06 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 86% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-871-681-5704 from the U.S. & Canada or +371-37-6823051in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Sat Mar 20 12:37:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB593A68C6 for ; Sat, 20 Mar 2010 12:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.3 X-Spam-Level: X-Spam-Status: No, score=-8.3 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVItqdRmJ+ri for ; Sat, 20 Mar 2010 12:37:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F41643A6846 for ; Sat, 20 Mar 2010 12:37:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4Pv-000506-EY for v6ops-data0@psg.com; Sat, 20 Mar 2010 19:33:03 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4Pr-0004zn-Pa for v6ops@ops.ietf.org; Sat, 20 Mar 2010 19:33:00 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABHApEurRN+K/2dsb2JhbACbPXOjR5hPglWCKAQ X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="103357800" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 19:32:58 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJWwnG005608; Sat, 20 Mar 2010 19:32:58 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2KJWvY13674; Sat, 20 Mar 2010 12:32:57 -0700 (PDT) Message-ID: <4BA522E8.7050504@cisco.com> Date: Sat, 20 Mar 2010 20:32:56 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> In-Reply-To: <6C168711-6A34-4487-9911-92766513183C@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/20/10 1:32 AM, james woodyatt wrote: > On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: > >> But I'm afraid that the simplicity of 'default deny' has long >> ago won the hearts and minds of enterprise network managers. >> > Sadly, enterprise network managers aren't the only people whose legitimate interests are at stake in the matter under discussion. > This document is clearly scoped in the first sentence of the Introduction to: "gateway devices that enable delivery of Internet services in residential and small office settings." So, I'm not sure why we are even considering enterprise network managers here. The networks themselves, the assets under protection, the types of applications, are quite different between and enterprise network and residential network. - Mark > > -- > james woodyatt > member of technical staff, communications engineering > > > > > From owner-v6ops@ops.ietf.org Sat Mar 20 12:41:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEE63A6903 for ; Sat, 20 Mar 2010 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.245 X-Spam-Level: X-Spam-Status: No, score=-8.245 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mR+T8eHqLoN for ; Sat, 20 Mar 2010 12:41:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2CD2E3A67EE for ; Sat, 20 Mar 2010 12:41:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4XD-00062Z-L5 for v6ops-data0@psg.com; Sat, 20 Mar 2010 19:40:35 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4X9-000627-Ik for v6ops@ops.ietf.org; Sat, 20 Mar 2010 19:40:32 +0000 Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUBAKvBpEuQ/uCWe2dsb2JhbACbPRUBAQsLJAYcoz+YT4R9BA X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="58328134" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2010 19:40:27 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJeQmS012722; Sat, 20 Mar 2010 19:40:27 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2KJePY13883; Sat, 20 Mar 2010 12:40:25 -0700 (PDT) Message-ID: <4BA524A8.9020201@cisco.com> Date: Sat, 20 Mar 2010 20:40:24 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> In-Reply-To: <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/19/10 11:09 PM, james woodyatt wrote: > On Mar 19, 2010, at 12:34, Brian E Carpenter wrote: > >> So I want to say: let's not add *anything*. Let's just push it out in a matter of weeks. >> > I'm currently sitting on a couple of minor edits: > > + Cite RFC 4007 to clear up confusion about multicast group scope boundaries. > + Fix some inconsistencies between cpe-simple-security and RFC 4890. > > I'm planning to post the -10 revision tonight, then start revising my slides for Monday morning. We shall see if there is a rough consensus for sending the -10 revision up the stack in the days following the meeting, or if further wrangling over it in the working group is in order. > Wish I could be at the meeting next week to make my points there, but if I was I would be asking for something along the lines of this: Section 2.3, first paragraph: s/not forwarded into the/rate-limited or discarded before reaching the And a new sentence like this: Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. Thanks, - Mark PS. I have some other clarification suggestions and questions to ask about text I read while reviewing today. I'll wait for -10 before posting these. > > -- > james woodyatt > member of technical staff, communications engineering > > > > > From v6ops-archive@megatron.ietf.org Sat Mar 20 12:50:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDD23A6971 for ; Sat, 20 Mar 2010 12:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.746 X-Spam-Level: X-Spam-Status: No, score=-13.746 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoAURAkWGYxD for ; Sat, 20 Mar 2010 12:50:31 -0700 (PDT) Received: from 109-184-155-216.dynamic.mts-nn.ru (109-184-155-216.dynamic.mts-nn.ru [109.184.155.216]) by core3.amsl.com (Postfix) with SMTP id A3A933A6930 for ; Sat, 20 Mar 2010 12:50:28 -0700 (PDT) To: Subject: Crazy 70% Discount for v6ops-archive From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100320195028.A3A933A6930@core3.amsl.com> Date: Sat, 20 Mar 2010 12:50:28 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 86% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-269-480-9519 from the U.S. & Canada or +311-67-4454031in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Sat Mar 20 12:56:02 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E41D3A6943 for ; Sat, 20 Mar 2010 12:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.014 X-Spam-Level: X-Spam-Status: No, score=-109.014 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYTWNONwNowC for ; Sat, 20 Mar 2010 12:56:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66DC73A680C for ; Sat, 20 Mar 2010 12:56:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4kW-0007xT-2j for v6ops-data0@psg.com; Sat, 20 Mar 2010 19:54:20 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4kO-0007w6-EC for v6ops@ops.ietf.org; Sat, 20 Mar 2010 19:54:12 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="169659899" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2010 19:54:11 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJra54004993; Sat, 20 Mar 2010 19:54:11 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BA522E8.7050504@cisco.com> Date: Sat, 20 Mar 2010 12:54:11 -0700 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I use such a device in my home as part of an enterprise network... On Mar 20, 2010, at 12:32 PM, Mark Townsley wrote: >=20 > On 3/20/10 1:32 AM, james woodyatt wrote: >> On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: >> =20 >>> But I'm afraid that the simplicity of 'default deny' has long >>> ago won the hearts and minds of enterprise network managers. >>> =20 >> Sadly, enterprise network managers aren't the only people whose = legitimate interests are at stake in the matter under discussion. >> =20 > This document is clearly scoped in the first sentence of the = Introduction to: >=20 > "gateway devices that enable delivery of Internet services in = residential and small office settings." >=20 > So, I'm not sure why we are even considering enterprise network = managers here. >=20 > The networks themselves, the assets under protection, the types of = applications, are quite different > between and enterprise network and residential network. >=20 > - Mark >>=20 >> -- >> james woodyatt >> member of technical staff, communications engineering >>=20 >>=20 >>=20 >>=20 >> =20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sat Mar 20 12:56:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A113A6956 for ; Sat, 20 Mar 2010 12:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.849 X-Spam-Level: X-Spam-Status: No, score=-108.849 tagged_above=-999 required=5 tests=[AWL=-1.484, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycDlonu6Grxk for ; Sat, 20 Mar 2010 12:56:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C1F73A6943 for ; Sat, 20 Mar 2010 12:56:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4jw-0007th-9C for v6ops-data0@psg.com; Sat, 20 Mar 2010 19:53:44 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt4jp-0007s5-DT for v6ops@ops.ietf.org; Sat, 20 Mar 2010 19:53:37 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="169659756" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2010 19:53:36 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJra53004993; Sat, 20 Mar 2010 19:53:36 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BA524A8.9020201@cisco.com> Date: Sat, 20 Mar 2010 12:53:36 -0700 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 20, 2010, at 12:40 PM, Mark Townsley wrote: > Rate-limiting unsolicited inbound connections rather than rejecting = them provides greater end-to-end transparency while still providing = protection against address and port scanning attacks as well as = overloading of slow links or devices within the home. SIlly question. Why do you believe that? An address or port scanning = attack is not intended to overload a network, it is intended to find an = address port that can be used or attacked. Making the scan take more = time doesn't prevent it from reaching its target. In what way does rate = limiting an address or port scan provide protection? http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sat Mar 20 15:45:42 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5DB3A6968 for ; Sat, 20 Mar 2010 15:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.196 X-Spam-Level: X-Spam-Status: No, score=-8.196 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ieLZjr9g1jw for ; Sat, 20 Mar 2010 15:45:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 365773A6955 for ; Sat, 20 Mar 2010 15:45:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7JT-0004mb-Jh for v6ops-data0@psg.com; Sat, 20 Mar 2010 22:38:35 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7JO-0004m0-Kl for v6ops@ops.ietf.org; Sat, 20 Mar 2010 22:38:31 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="103388246" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 22:38:29 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2KMcTSN023906; Sat, 20 Mar 2010 22:38:29 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2KMcSY10959; Sat, 20 Mar 2010 15:38:28 -0700 (PDT) Message-ID: <4BA54E63.2020206@cisco.com> Date: Sat, 20 Mar 2010 23:38:27 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> 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 List-ID: On 3/20/10 8:54 PM, Fred Baker wrote: > I use such a device in my home as part of an enterprise network... > The point is that the document is clearly scoped to residential and small office settings. - Mark > On Mar 20, 2010, at 12:32 PM, Mark Townsley wrote: > > >> On 3/20/10 1:32 AM, james woodyatt wrote: >> >>> On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: >>> >>> >>>> But I'm afraid that the simplicity of 'default deny' has long >>>> ago won the hearts and minds of enterprise network managers. >>>> >>>> >>> Sadly, enterprise network managers aren't the only people whose legitimate interests are at stake in the matter under discussion. >>> >>> >> This document is clearly scoped in the first sentence of the Introduction to: >> >> "gateway devices that enable delivery of Internet services in residential and small office settings." >> >> So, I'm not sure why we are even considering enterprise network managers here. >> >> The networks themselves, the assets under protection, the types of applications, are quite different >> between and enterprise network and residential network. >> >> - Mark >> >>> -- >>> james woodyatt >>> member of technical staff, communications engineering >>> >>> >>> >>> >>> >>> >> >> > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Sat Mar 20 15:52:38 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A050C3A68A8 for ; Sat, 20 Mar 2010 15:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.152 X-Spam-Level: X-Spam-Status: No, score=-8.152 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcGw4w60F785 for ; Sat, 20 Mar 2010 15:52:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FA033A6973 for ; Sat, 20 Mar 2010 15:52:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7VQ-0006My-5J for v6ops-data0@psg.com; Sat, 20 Mar 2010 22:50:56 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7VL-0006Mb-GF for v6ops@ops.ietf.org; Sat, 20 Mar 2010 22:50:51 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,280,1267401600"; d="scan'208";a="169696371" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2010 22:50:51 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2KMoosf005146; Sat, 20 Mar 2010 22:50:51 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2KMonY11548; Sat, 20 Mar 2010 15:50:49 -0700 (PDT) Message-ID: <4BA55147.601@cisco.com> Date: Sat, 20 Mar 2010 23:50:47 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> 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 List-ID: On 3/20/10 8:53 PM, Fred Baker wrote: > On Mar 20, 2010, at 12:40 PM, Mark Townsley wrote: > > >> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. >> > SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time. - Mark > Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection? > > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Sat Mar 20 15:57:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C8C3A694C for ; Sat, 20 Mar 2010 15:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.472 X-Spam-Level: X-Spam-Status: No, score=-109.472 tagged_above=-999 required=5 tests=[AWL=-2.107, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW8FNd6mLdiJ for ; Sat, 20 Mar 2010 15:57:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D6A43A6857 for ; Sat, 20 Mar 2010 15:56:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7aI-00070W-L4 for v6ops-data0@psg.com; Sat, 20 Mar 2010 22:55:58 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt7aD-000709-M3 for v6ops@ops.ietf.org; Sat, 20 Mar 2010 22:55:54 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,280,1267401600"; d="scan'208";a="103390388" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 22:55:53 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2KMtqHp024411; Sat, 20 Mar 2010 22:55:53 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BA55147.601@cisco.com> Date: Sat, 20 Mar 2010 15:55:52 -0700 Cc: james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >>> Rate-limiting unsolicited inbound connections rather than rejecting = them provides greater end-to-end transparency while still providing = protection against address and port scanning attacks as well as = overloading of slow links or devices within the home. >>> =20 >> SIlly question. Why do you believe that? An address or port scanning = attack is not intended to overload a network, it is intended to find an = address port that can be used or attacked. > The sentence is referencing two different things. One, the possibility = that uninvited packets might overload some device or slow link = (something I consider unlikely, but has been identified as a concern by = some), the other is, indeed, designed to make blind port and address = scanning less likely to succeed in a given amount of time. >=20 > - Mark >> Making the scan take more time doesn't prevent it from reaching its = target. In what way does rate limiting an address or port scan provide = protection? With all due respect, when I set up security for my home or office, and = when Cisco InfoSec sets up security for its home offices (of which mine = is one), they're not asking about making an attack take ten minutes vs = five. They're asking about preventing an attack from succeeding. Now, we = can discuss the logic of the notion that "the bad guys are out there and = the good guys are in here", but given the assumption, we need to be = rational about the threats we are trying to prevent from succeeding. From owner-v6ops@ops.ietf.org Sat Mar 20 17:05:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9543E3A69A3 for ; Sat, 20 Mar 2010 17:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.107 X-Spam-Level: *** X-Spam-Status: No, score=3.107 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ-YRu9LlnEA for ; Sat, 20 Mar 2010 17:05:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BFFC3A694D for ; Sat, 20 Mar 2010 17:05:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt8Zu-000EvE-0n for v6ops-data0@psg.com; Sat, 20 Mar 2010 23:59:38 +0000 Received: from [64.78.150.133] (helo=dog.tcb.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt8Zp-000Eur-RL for v6ops@ops.ietf.org; Sat, 20 Mar 2010 23:59:33 +0000 Received: by dog.tcb.net (Postfix, from userid 0) id DCBC8268677; Sat, 20 Mar 2010 17:59:32 -0600 (MDT) Received: from mbpw.castlepoint.net (71.215.81.125 [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 20 Mar 2010 17:59:32 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=61397; client-dnsfail=71.215.81.125: name server failure; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Sat, 20 Mar 2010 17:59:16 -0600 Cc: Mark Townsley , james woodyatt , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark, Fred, On Mar 20, 2010, at 16:55 MDT, Fred Baker wrote: >>>> Rate-limiting unsolicited inbound connections rather than rejecting = them provides greater end-to-end transparency while still providing = protection against address and port scanning attacks as well as = overloading of slow links or devices within the home. >>>>=20 >>> SIlly question. Why do you believe that? An address or port scanning = attack is not intended to overload a network, it is intended to find an = address port that can be used or attacked. >> The sentence is referencing two different things. One, the = possibility that uninvited packets might overload some device or slow = link (something I consider unlikely, but has been identified as a = concern by some), the other is, indeed, designed to make blind port and = address scanning less likely to succeed in a given amount of time. >>=20 >> - Mark >>> Making the scan take more time doesn't prevent it from reaching its = target. In what way does rate limiting an address or port scan provide = protection? >=20 > With all due respect, when I set up security for my home or office, = and when Cisco InfoSec sets up security for its home offices (of which = mine is one), they're not asking about making an attack take ten minutes = vs five. They're asking about preventing an attack from succeeding. Now, = we can discuss the logic of the notion that "the bad guys are out there = and the good guys are in here", but given the assumption, we need to be = rational about the threats we are trying to prevent from succeeding. Agreed. This proposal seems like a poor half-measure. IMHO, if a = client/host wants real end-2-end transparency, then it should use = something like NAT-PMP to explicitly signal to the upstream FW that the = client is wise and mature enough to deploy it's own, onboard FW to = protect itself. Although some people may think that's a bad idea, = because a malware-infected PC/device could signal an upstream FW to open = up everything, I personally think that's a very poor argument. Namely, once a PC/device is infected, it's game-over, anyway. = Specifically, remote attackers already have the ability to remotely = control that PC and perform further reconnaissance and attacks both = /inside/ and outside the LAN. Second, if technically savvy people still = don't like the idea of NAT-PMP operating on their FW, then they will be = smart enough to disable it altogether on their (personal) FW's. =20 -shane= From owner-v6ops@ops.ietf.org Sat Mar 20 17:21:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116E53A692F for ; Sat, 20 Mar 2010 17:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ6reK9WeNEw for ; Sat, 20 Mar 2010 17:21:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8093F3A6832 for ; Sat, 20 Mar 2010 17:21:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt8tf-000Hdu-PB for v6ops-data0@psg.com; Sun, 21 Mar 2010 00:20:03 +0000 Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt8tb-000HcA-86 for v6ops@ops.ietf.org; Sun, 21 Mar 2010 00:19:59 +0000 Received: by yxe14 with SMTP id 14so2108217yxe.5 for ; Sat, 20 Mar 2010 17:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qbPIcD0JZ0N2qHUzVmRrcmWu5zazLMqNQatZuO3zZQk=; b=aJbEl+o8tc8hNlJm2XzvqfiuUw/jZkqetctOPwDcU27+gtTzGFuwcdDXLiP52jLBFq 9fyV1VecJAVBVBf3SllPw9SmBnWHrJQrXbcs1DhQRc2QbKeSAl1NsboJ6XMLADqoSzJ2 wGn5snj6l42XAronqcVD/+1U8nsxT5VfB/7BQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nB3eHM+bliWzMaAo4Nrgt8AGsIjQ+/T8lQ/UZvG2IJZ9BVJCz+Mg8xOQYgGnmNED+t pZ91uCTi9xwso++drGIJ6oaLmw7FwAXqgW3khGasBnfCq95+PQy/kikvZQcjKYXmx7iX r5JATTIHY77kvQuD7cV3dVgN8avBP817kY9gY= Received: by 10.101.155.13 with SMTP id h13mr4986501ano.14.1269130798581; Sat, 20 Mar 2010 17:19:58 -0700 (PDT) Received: from [130.129.24.199] ([130.129.24.199]) by mx.google.com with ESMTPS id 20sm960783iwn.5.2010.03.20.17.19.57 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Mar 2010 17:19:57 -0700 (PDT) Message-ID: <4BA56626.20606@gmail.com> Date: Sun, 21 Mar 2010 13:19:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley CC: james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> In-Reply-To: <4BA522E8.7050504@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-03-21 08:32, Mark Townsley wrote: > > On 3/20/10 1:32 AM, james woodyatt wrote: >> On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: >> >>> But I'm afraid that the simplicity of 'default deny' has long >>> ago won the hearts and minds of enterprise network managers. >>> >> Sadly, enterprise network managers aren't the only people whose >> legitimate interests are at stake in the matter under discussion. >> > This document is clearly scoped in the first sentence of the > Introduction to: > > "gateway devices that enable delivery of Internet services in > residential and small office settings." > > So, I'm not sure why we are even considering enterprise network managers > here. Fair enough, but... > > The networks themselves, the assets under protection, the types of > applications, are quite different > between and enterprise network and residential network. Indeed. But ISPs that supply CPE to their customers are going to assume that their customers are running unpatched insecure operating systems at high risk of catching malware. So I think they are just as likely as enterprise IT departments to favour default deny approaches. Brian > > - Mark >> >> -- >> james woodyatt >> member of technical staff, communications engineering >> >> >> >> >> > > > From owner-v6ops@ops.ietf.org Sat Mar 20 18:06:38 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5902C3A6767 for ; Sat, 20 Mar 2010 18:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4u7d6r7TPFI for ; Sat, 20 Mar 2010 18:06:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A1693A672E for ; Sat, 20 Mar 2010 18:06:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt9XA-000N12-Oo for v6ops-data0@psg.com; Sun, 21 Mar 2010 01:00:52 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt9X7-000Mz9-SU for v6ops@ops.ietf.org; Sun, 21 Mar 2010 01:00:50 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nt9Wz-0003uC-OD; Sun, 21 Mar 2010 11:30:41 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 72E984930C; Sun, 21 Mar 2010 11:30:38 +1030 (CST) Date: Sun, 21 Mar 2010 11:30:37 +1030 From: Mark Smith To: Fred Baker Cc: Mark Townsley , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100321113037.13756c12@opy.nosense.org> In-Reply-To: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Sat, 20 Mar 2010 15:55:52 -0700 Fred Baker wrote: > >>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. > >>> > >> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. > > The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time. > > > > - Mark > >> Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection? > > With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding. > One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model. With luck, that sort of list would end up on the outside of the cardboard box the CPE comes in, so that when people buy the CPE, they don't assume the device is taking care of "all security", and therefore don't have to bother with any other security measures. > From owner-v6ops@ops.ietf.org Sat Mar 20 18:55:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287AF3A6829 for ; Sat, 20 Mar 2010 18:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6nqJnpXHG7u for ; Sat, 20 Mar 2010 18:55:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28BF93A67B2 for ; Sat, 20 Mar 2010 18:55:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtAKg-0003Nl-It for v6ops-data0@psg.com; Sun, 21 Mar 2010 01:52:02 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtAKe-0003NX-4Y for v6ops@ops.ietf.org; Sun, 21 Mar 2010 01:52:00 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NtAKY-0005H8-FV; Sun, 21 Mar 2010 12:21:54 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E4EDC4930C; Sun, 21 Mar 2010 12:21:53 +1030 (CST) Date: Sun, 21 Mar 2010 12:21:53 +1030 From: Mark Smith To: Brian E Carpenter Cc: Mark Townsley , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100321122153.0d6c219b@opy.nosense.org> In-Reply-To: <4BA56626.20606@gmail.com> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Sun, 21 Mar 2010 13:19:50 +1300 Brian E Carpenter wrote: > On 2010-03-21 08:32, Mark Townsley wrote: > > > > On 3/20/10 1:32 AM, james woodyatt wrote: > >> On Mar 19, 2010, at 16:50, Brian E Carpenter wrote: > >> > >>> But I'm afraid that the simplicity of 'default deny' has long > >>> ago won the hearts and minds of enterprise network managers. > >>> > >> Sadly, enterprise network managers aren't the only people whose > >> legitimate interests are at stake in the matter under discussion. > >> > > This document is clearly scoped in the first sentence of the > > Introduction to: > > > > "gateway devices that enable delivery of Internet services in > > residential and small office settings." > > > > So, I'm not sure why we are even considering enterprise network managers > > here. > > Fair enough, but... > > > > The networks themselves, the assets under protection, the types of > > applications, are quite different > > between and enterprise network and residential network. > > Indeed. But ISPs that supply CPE to their customers are going to > assume that their customers are running unpatched insecure operating > systems at high risk of catching malware. So I think they are just as > likely as enterprise IT departments to favour default deny approaches. > I can't speak for all ISPs, however the ones I've worked at here in Australia don't make that assumption universally. There will be a percentage of customers who have that issue, however they'll be the minority, and they'll have trouble pretty quickly because of it. One other broader issue with making that assumption is boundaries of responsibility / care. If ISPs universally assume that customers devices are insecure, unmaintained and unpatched, and take active yet limited measures to mitigate that, some customers might then believe that the ISP is taking care of all their Internet security needs. If a customer then suffers a security incident and has a financial loss because if it, they might try to sue the ISP for the loss because they believe the ISP is taking care of all their Internet security. Regards, Mark. From owner-v6ops@ops.ietf.org Sat Mar 20 20:04:26 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEB53A698D for ; Sat, 20 Mar 2010 20:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=-2.824, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t2ZUX5rz3rP for ; Sat, 20 Mar 2010 20:04:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09CC33A6944 for ; Sat, 20 Mar 2010 20:04:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtBOa-000DT1-55 for v6ops-data0@psg.com; Sun, 21 Mar 2010 03:00:08 +0000 Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtBOX-000DSc-Bt for v6ops@ops.ietf.org; Sun, 21 Mar 2010 03:00:05 +0000 Received: by yxe14 with SMTP id 14so2142640yxe.5 for ; Sat, 20 Mar 2010 20:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+D57j6hIGmBajlXdIf6WQCeRrn3rrTT91VVR9oiBuY4=; b=ddcaiK7o4cIeFEpw1uOpMakxnEO3QbqoR5SNRXsqMaSBljSBAvke3IYBxERtIGXdt5 nQZWEJwu9HDuEQZxE67c5eJ9y4+81xqOlhqBsalpNzQw0p12ozj9mQjpR+Pf2gzAlGGt GNhxJDGnkQz3qKtm3EMlfSNKmysNjyFWk/4Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KygxuFY8VczKGz1h4/sycZvlceGI/d+y9rpD4uQbdqvL9m8oRz6nPprxO02n4w3EmL offPQZCqLAgLSBZ4FkPLoLGDaVUoMATn59OVH8zMEns9ptTi/FlPVBBmqhENCkpN1Htk +0XqqQuv4+G8jztHUQ8XMXxgqFXp4P+kR6UxE= MIME-Version: 1.0 Received: by 10.150.47.11 with SMTP id u11mr9663050ybu.140.1269140403436; Sat, 20 Mar 2010 20:00:03 -0700 (PDT) In-Reply-To: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> Date: Sat, 20 Mar 2010 20:00:03 -0700 Message-ID: Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: Cameron Byrne To: Fred Baker Cc: Mark Townsley , james woodyatt , IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, Mar 20, 2010 at 3:55 PM, Fred Baker wrote: >>>> Rate-limiting unsolicited inbound connections rather than rejecting th= em provides greater end-to-end transparency while still providing protectio= n against address and port scanning attacks as well as overloading of slow = links or devices within the home. >>>> >>> SIlly question. Why do you believe that? An address or port scanning at= tack is not intended to overload a network, it is intended to find an addre= ss port that can be used or attacked. >> The sentence is referencing two different things. One, the possibility t= hat uninvited packets might overload some device or slow link (something I = consider unlikely, but has been identified as a concern by some), the other= is, indeed, designed to make blind port and address scanning less likely t= o succeed in a given amount of time. >> >> - Mark >>> =A0Making the scan take more time doesn't prevent it from reaching its = target. In what way does rate limiting an address or port scan provide prot= ection? > > With all due respect, when I set up security for my home or office, and w= hen Cisco InfoSec sets up security for its home offices (of which mine is o= ne), they're not asking about making an attack take ten minutes vs five. Th= ey're asking about preventing an attack from succeeding. Now, we can discus= s the logic of the notion that "the bad guys are out there and the good guy= s are in here", but given the assumption, we need to be rational about the = threats we are trying to prevent from succeeding. > Agreed, rate-limiting does not add value in this scope. We know that IPv6 is hard to scan successfully, and we know that rate limiting it on the CPE won't protect the external link from becoming saturated during an attack. From the service provider perspective, rate limiting causes inconsistency in services (some packets get through in this sample test but not in the next sample test) and thus injects greater complexity for the folks trying to troubleshoot. I prefer consistent and deterministic behavior. I would say the principle of default-deny and least privilege are philosophically correct in general, but i am not sure it needs to be applied in simple CPE. I believe most current host OS software ships these days with default deny, and authorized administrators and applications can open the proper ports when needed. If the trend is default-deny on the host which is "application aware", we do not need default-deny on the simple CPE which is not application aware. Cameron From owner-v6ops@ops.ietf.org Sat Mar 20 22:32:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740A43A686D for ; Sat, 20 Mar 2010 22:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.414 X-Spam-Level: X-Spam-Status: No, score=-108.414 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dc105bPrXSx for ; Sat, 20 Mar 2010 22:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E2BF3A6810 for ; Sat, 20 Mar 2010 22:32:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtDhY-0006Vk-ON for v6ops-data0@psg.com; Sun, 21 Mar 2010 05:27:52 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtDhV-0006VY-Dw for v6ops@ops.ietf.org; Sun, 21 Mar 2010 05:27:49 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD9LpUurR7H+/2dsb2JhbACbOXOgRpgYhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,281,1267401600"; d="scan'208";a="500144537" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2010 05:27:48 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2L5RmsJ018498; Sun, 21 Mar 2010 05:27:48 GMT Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Fred Baker In-Reply-To: Date: Sat, 20 Mar 2010 22:27:47 -0700 Cc: IPv6 Operations , Ron Bonica , Kurt Erik Lindqvist Content-Transfer-Encoding: quoted-printable Message-Id: <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I have a question on these. Per the abstract of VET, "VET can also be considered as version 2 of the = Intra-Site Automatic Tunnel Addressing Protocol (i.e., "ISATAPv2")." I = tend to agree; with routing, next hop determination, and a "Subnetwork = Encapsulation and Adaptation Layer (SEAL)", I don't think this is an = operational description. I think this belongs discussed in rrg, = rtgarea/rtgwg, or *maybe* int-area. How about you and I discuss this Monday and you convince me that this is = within the charter of IPv6 Operations. I think it is that which was = explicitly placed outside the charter - transitional technologies and = protocol development. On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote: > Fred, > =20 > The new agenda posted on the webpages does not seem to match the one > you posted to the list: > =20 > http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > =20 > Seeing that there are new additions, I would like to propose to add = the > RANGER, VET and SEAL trilogy =96 preferably as the final session on > Friday, as I have two other conflicts for the earlier portion of that = session. > The talk would require 15min, and would cover all three documents > together (i.e., not as three separate talks). The documents are here: > =20 > http://www.ietf.org/rfc/rfc5720.txt > http://tools.ietf.org/html/draft-templin-intarea-vet > http://tools.ietf.org/html/draft-templin-intarea-seal > =20 > Thanks =96 Fred > fred.l.templin@boeing.com > =20 > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Fred Baker > Sent: Tuesday, March 16, 2010 2:06 PM > To: IPv6 Operations > Subject: Proposed agenda for IPv6 Operations - IETF 77 > =20 > Comments please... Basically I am putting three security issues and = two 3GPP-relevant drafts on Monday morning and the remainder on Friday = morning. Each discussion gets about half an hour. If time permits in the = meeting, I'll pull agenda items forward from Friday to Monday. I have = two drafts on here that were not marked for v6ops but the authors asked = me to include; next time I'd appreciate it if folks used the = draft-*-v6ops-* naming convention; it makes my job easier. If I have = missed anything, let me know. > IPv6 Operations - IETF 77 >=20 > Monday 22 March, 9:00 AM >=20 > Agenda bashing > =20 > Recommended Simple Security Capabilities in Customer Premises = Equipment for Providing Residential IPv6 Internet Service > 18-Feb-10, > Advanced Security for IPv6 CPE > 8-Mar-10, > Routing Loops using ISATAP and 6to4: Problem Statement and Proposed = Solutions > 1-Feb-10, > =20 > IPv6 in 3GPP Evolved Packet System > 24-Feb-10, > Mobile Networks Considerations for IPv6 Deployment > 8-Mar-10, > Friday 26 March, 9:00 AM >=20 > Emerging Service Provider Scenarios for IPv6 Deployment > 23-Feb-10, > Unicast Transmission of IPv6 Multicast Messages on Link-layer > 15-Feb-10, > Neighbor Cache Protection in Neighbor Discovery Protocol > 2-Mar-10, > DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks > 16-Feb-10, > Advanced Requirements for IPv6 Customer Edge Routers > 8-Mar-10, > =20 > =20 > http://www.ipinc.net/IPv4.GIF > =20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sat Mar 20 23:03:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E263A6838 for ; Sat, 20 Mar 2010 23:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqGYuy426ib1 for ; Sat, 20 Mar 2010 23:03:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AFFA3A68B8 for ; Sat, 20 Mar 2010 23:03:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtEDW-000AZu-8I for v6ops-data0@psg.com; Sun, 21 Mar 2010 06:00:54 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtEDK-000AYN-PL for v6ops@ops.ietf.org; Sun, 21 Mar 2010 06:00:43 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 12DE591697DA for ; Sat, 20 Mar 2010 23:00:42 -0700 (PDT) X-AuditID: 11807137-b7c50ae0000001dd-18-4ba5b60907d7 Received: from [17.151.110.46] (Unknown_Domain [17.151.110.46]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C4.B9.00477.906B5AB4; Sat, 20 Mar 2010 23:00:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <20100321113037.13756c12@opy.nosense.org> Date: Sat, 20 Mar 2010 23:00:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> <20100321113037.13756c12@opy.nosense.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 20, 2010, at 18:00, Mark Smith wrote: >=20 > One thing that does seem to be missing from the draft is a specific = list of threats it is attempting to mitigate i.e. a threat model. RFC 4864 doesn't offer one, and its authors haven't offered much in the = way of specifics to the discussion here or on the design team list. = Perhaps, you'd like to offer a contribution? The Overview contains my best attempt at explaining what considerations = I think are really in play behind the CPE Simple Security = recommendation. Here's what I think is the most relevant excerpt: >> The stateful packet filtering behavior of NAT set user expectations = that persist today with residential IPv6 service. "Local Network = Protection for IPv6" [RFC4864] recommends applying stateful packet = filtering at residential IPv6 gateways that conforms to the user = expectations already in place. In other words, we recommend filtering at the middlebox-- making IPv6 = routers do filtering like IPv4/NAT gateways do-- because "defense in = depth" is a virtue in and of itself, and that Internet users have come = to expect it. Apparently, there's a consensus in IETF that this is = enough reason to do it, and I strongly suspect that an explicit threat = model might be inviting more controversy than anyone wants to endure. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Sun Mar 21 01:13:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E30F3A68A4 for ; Sun, 21 Mar 2010 01:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.583 X-Spam-Level: * X-Spam-Status: No, score=1.583 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjwY3EfdXep5 for ; Sun, 21 Mar 2010 01:13:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3440E3A686E for ; Sun, 21 Mar 2010 01:12:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtGCo-0001Tp-4G for v6ops-data0@psg.com; Sun, 21 Mar 2010 08:08:18 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtGCi-0001Rp-Pm for v6ops@ops.ietf.org; Sun, 21 Mar 2010 08:08:13 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NtGCd-0006PY-Rq; Sun, 21 Mar 2010 18:38:07 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 517BC4930C; Sun, 21 Mar 2010 18:38:07 +1030 (CST) Date: Sun, 21 Mar 2010 18:38:07 +1030 From: Mark Smith To: james woodyatt Cc: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100321183807.76a4e2c8@opy.nosense.org> In-Reply-To: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> <20100321113037.13756c12@opy.nosense.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: Hi James, On Sat, 20 Mar 2010 23:00:40 -0700 james woodyatt wrote: > On Mar 20, 2010, at 18:00, Mark Smith wrote: > > > > One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model. > > RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list. Perhaps, you'd like to offer a contribution? > While threat model is probably the correct term, more broadly I think probably something of a problem statement i.e. what security measures the CPE does provide, and what it doesn't, probably with some justification. I think the role of IPv6 CPE in the residential Internet security model is different to the role IPv4/NAT CPE commonly is or was capable of playing. Stating the obvious, IPv4/NAT provides a much harder boundary between internal and external devices, primarily due to the nature of NAPT. NAPT by it's nature provides a default deny to inbound traffic. That's what breaks end-to-end. Because of that harder boundary, I think end-user expectations are that the IPv4/NAPT CPE can perform much more of a primary security role when it comes to protecting them from the Internet. The nature of the operation of NAPT inherently defined a set of threats that it protected against. With IPv6/CPE security, by trying to restore end-to-end, I think we're inherently reducing the security that people formerly had with IPv4/NAPT CPE. End nodes will now have to play more of a primary security role, with filtering IPv6/CPE providing an assisting/secondary/defence in depth role. Now that IPv6 end-nodes will be "burdened" with more security responsibility, I think it is important to make sure it is clear that the security functions performed in IPv6 CPE aren't exactly the same as as they were in IPv4/NAPT CPE. > The Overview contains my best attempt at explaining what considerations I think are really in play behind the CPE Simple Security recommendation. Here's what I think is the most relevant excerpt: > > >> The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place. > > In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet users have come to expect it. Apparently, there's a consensus in IETF that this is enough reason to do it, and I strongly suspect that an explicit threat model might be inviting more controversy than anyone wants to endure. > > Regards, Mark. From owner-v6ops@ops.ietf.org Sun Mar 21 06:44:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F503A6876 for ; Sun, 21 Mar 2010 06:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9xoLsa7cFMK for ; Sun, 21 Mar 2010 06:44:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD53A3A691B for ; Sun, 21 Mar 2010 06:43:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLMT-000PqU-Uq for v6ops-data0@psg.com; Sun, 21 Mar 2010 13:38:37 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLMR-000Pq6-7o for v6ops@ops.ietf.org; Sun, 21 Mar 2010 13:38:35 +0000 Received: (qmail 9950 invoked by uid 1007); 21 Mar 2010 14:38:32 +0100 Date: Sun, 21 Mar 2010 14:38:31 +0100 From: Gert Doering To: Brian E Carpenter Cc: Mark Townsley , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100321133831.GL69383@Space.Net> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA56626.20606@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Sun, Mar 21, 2010 at 01:19:50PM +1300, Brian E Carpenter wrote: > Indeed. But ISPs that supply CPE to their customers are going to > assume that their customers are running unpatched insecure operating > systems at high risk of catching malware. So I think they are just as > likely as enterprise IT departments to favour default deny approaches. We're not. We provide *Internet* services. Not "walled garden" services. If the customer wants firewall protection, we're happy to sell it to them, but the default package they get is "Internet". Packets transported from A to B and vice versa, and we're not maing their packets unhappy unless they tell us so. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Sun Mar 21 07:04:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07903A691D for ; Sun, 21 Mar 2010 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.407 X-Spam-Level: X-Spam-Status: No, score=-4.407 tagged_above=-999 required=5 tests=[AWL=-1.642, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kslsgJ9JREn0 for ; Sun, 21 Mar 2010 07:04:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BE623A6918 for ; Sun, 21 Mar 2010 07:04:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLk9-0003Nk-RY for v6ops-data0@psg.com; Sun, 21 Mar 2010 14:03:05 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLk6-0003NE-OS for v6ops@ops.ietf.org; Sun, 21 Mar 2010 14:03:02 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2LE2mU3004270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Mar 2010 09:02:48 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2LE2mWQ015439; Sun, 21 Mar 2010 09:02:48 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2LE2l70015436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 21 Mar 2010 09:02:48 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Sun, 21 Mar 2010 07:02:47 -0700 From: "Templin, Fred L" To: Fred Baker CC: IPv6 Operations , Ron Bonica , Kurt Erik Lindqvist Date: Sun, 21 Mar 2010 07:02:44 -0700 Subject: RE: Proposed agenda for IPv6 Operations - IETF 77 Thread-Topic: Proposed agenda for IPv6 Operations - IETF 77 Thread-Index: AcrIt0BvQgb8cyBfS1qIJodhEYPLJwAR6OrQ Message-ID: References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> In-Reply-To: <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, As far as I can tell, the SAM proposal is a new transitional technology and protocol also. RANGER and SAM are addressing very similar problem spaces, and I think their eligibility for inclusion in the v6ops agenda should be considered on equal terms. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Saturday, March 20, 2010 10:28 PM > To: Templin, Fred L > Cc: IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist > Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 >=20 > I have a question on these. >=20 > Per the abstract of VET, "VET can also be considered as version 2 of the = Intra-Site Automatic Tunnel > Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with routing, n= ext hop determination, and a > "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think thi= s is an operational > description. I think this belongs discussed in rrg, rtgarea/rtgwg, or *ma= ybe* int-area. >=20 > How about you and I discuss this Monday and you convince me that this is = within the charter of IPv6 > Operations. I think it is that which was explicitly placed outside the ch= arter - transitional > technologies and protocol development. >=20 >=20 > On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote: >=20 > > Fred, > > > > The new agenda posted on the webpages does not seem to match the one > > you posted to the list: > > > > http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > > > > Seeing that there are new additions, I would like to propose to add the > > RANGER, VET and SEAL trilogy - preferably as the final session on > > Friday, as I have two other conflicts for the earlier portion of that s= ession. > > The talk would require 15min, and would cover all three documents > > together (i.e., not as three separate talks). The documents are here: > > > > http://www.ietf.org/rfc/rfc5720.txt > > http://tools.ietf.org/html/draft-templin-intarea-vet > > http://tools.ietf.org/html/draft-templin-intarea-seal > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Beh= alf Of Fred Baker > > Sent: Tuesday, March 16, 2010 2:06 PM > > To: IPv6 Operations > > Subject: Proposed agenda for IPv6 Operations - IETF 77 > > > > Comments please... Basically I am putting three security issues and two= 3GPP-relevant drafts on > Monday morning and the remainder on Friday morning. Each discussion gets = about half an hour. If time > permits in the meeting, I'll pull agenda items forward from Friday to Mon= day. I have two drafts on > here that were not marked for v6ops but the authors asked me to include; = next time I'd appreciate it > if folks used the draft-*-v6ops-* naming convention; it makes my job easi= er. If I have missed > anything, let me know. > > IPv6 Operations - IETF 77 > > > > Monday 22 March, 9:00 AM > > > > Agenda bashing > > > > Recommended Simple Security Capabilities in Customer Premises Equipment= for Providing Residential > IPv6 Internet Service > > 18-Feb-10, > > Advanced Security for IPv6 CPE > > 8-Mar-10, > > Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Sol= utions > > 1-Feb-10, > > > > IPv6 in 3GPP Evolved Packet System > > 24-Feb-10, > > Mobile Networks Considerations for IPv6 Deployment > > 8-Mar-10, > > Friday 26 March, 9:00 AM > > > > Emerging Service Provider Scenarios for IPv6 Deployment > > 23-Feb-10, > > Unicast Transmission of IPv6 Multicast Messages on Link-layer > > 15-Feb-10, > > Neighbor Cache Protection in Neighbor Discovery Protocol > > 2-Mar-10, > > DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks > > 16-Feb-10, > > Advanced Requirements for IPv6 Customer Edge Routers > > 8-Mar-10, > > > > > > http://www.ipinc.net/IPv4.GIF > > >=20 > http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sun Mar 21 07:05:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765283A691D for ; Sun, 21 Mar 2010 07:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-6.048, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ1dmgR3toF6 for ; Sun, 21 Mar 2010 07:05:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D162B3A6918 for ; Sun, 21 Mar 2010 07:05:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLmF-0003nQ-9C for v6ops-data0@psg.com; Sun, 21 Mar 2010 14:05:15 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtLmC-0003kz-6T for v6ops@ops.ietf.org; Sun, 21 Mar 2010 14:05:12 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,283,1267401600"; d="scan'208";a="4604822" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 21 Mar 2010 13:31:09 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2LE59kv026683; Sun, 21 Mar 2010 14:05:09 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LE56Y07152; Sun, 21 Mar 2010 07:05:07 -0700 (PDT) Message-ID: <4BA62791.2060801@cisco.com> Date: Sun, 21 Mar 2010 15:05:05 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> 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 List-ID: On 3/20/10 11:55 PM, Fred Baker wrote: >>>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. >>>> >>>> >>> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. >>> >> The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time. >> >> - Mark >> >>> Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection? >>> > With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding. > There is nothing irrational about making a hacker's job more difficult. That is the basis behind every measure in the document now. None of them make it impossible for a system to be compromised, just more difficult. Virtually all of the firewall functions in this draft are imposing a certain kind of limited end to end connectivity for the average user on the IPv6 Internet. The tradeoff for this limitation is the promise of security. I have little doubt that a determined hacker will be able to get around each and every measure identified in the document. At best, the bar is simply being raised to make the hacker's job a bit more difficult, perhaps reducing the number which are actually successful. The argument we are having is over how high to raise the bar, and at what cost in terms of transparency. I'd like us to have to possibility of keeping it just a slight bit lower for IPv6 than what we have for IPv4. I don't see why we should set the bar at the same level until there is evidence that the machines running IPv6 (Windows Vista, 7, MACOSX - each which are shipped with update programs and embedded IPv6 personal firewalls) are as vulnerable as the whole gamut of IPv4 systems available today. "Unsolicited" incoming connections are a huge benefit for application simplicity. In various consumer surveys, remote access to devices in the home is listed as one of the most important features that residential subscribers would like to see more of. The various firewall control protocols are far from being completed and add their own complexity - complexity that in a real threat analysis might show just as many security issues as just leaving the door open a crack. And, that's what I am advocating here. A knob that allows the door to be open, shut, or something in-between. - Mark From owner-v6ops@ops.ietf.org Sun Mar 21 07:25:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4CD3A67D4 for ; Sun, 21 Mar 2010 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=-1.760, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-QptELdhmHs for ; Sun, 21 Mar 2010 07:25:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 654F83A6847 for ; Sun, 21 Mar 2010 07:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtM2d-000750-TE for v6ops-data0@psg.com; Sun, 21 Mar 2010 14:22:11 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtM2a-00072P-5i for v6ops@ops.ietf.org; Sun, 21 Mar 2010 14:22:08 +0000 Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,283,1267401600"; d="scan'208";a="58343187" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2010 14:22:06 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2LEM54u028366; Sun, 21 Mar 2010 14:22:05 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LEM2Y12220; Sun, 21 Mar 2010 07:22:02 -0700 (PDT) Message-ID: <4BA62B89.6080604@cisco.com> Date: Sun, 21 Mar 2010 15:22:01 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Shane Amante CC: Fred Baker , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> 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 List-ID: On 3/21/10 12:59 AM, Shane Amante wrote: > Mark, Fred, > > On Mar 20, 2010, at 16:55 MDT, Fred Baker wrote: > >>>>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. >>>>> >>>>> >>>> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. >>>> >>> The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time. >>> >>> - Mark >>> >>>> Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection? >>>> >> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding. >> > Agreed. This proposal seems like a poor half-measure. IMHO, if a client/host wants real end-2-end transparency, then it should use something like NAT-PMP to explicitly signal to the upstream FW that the client is wise and mature enough to deploy it's own, onboard FW to protect itself. Although some people may think that's a bad idea, because a malware-infected PC/device could signal an upstream FW to open up everything, I personally think that's a very poor argument. > If you take most of these types of arguments to their logical end, I think you'll find that the only real defense here is keeping the end-devices secure. Particularly those that travel outside of the home and can be infected while away, etc. Given that there is little or no real data on whether IPv6 residential firewalls actually fend off hackers, we are responding to a lot of hypothetical analysis and conjecture. Much of it is to, in the end, make the user, ISP, or whomever is responsible "feel" more secure (insert analogies of airport security pat-downs here). So, we're probably not going to get very far on technical arguments. What the rate-limiting does is ensure that "only a few per second" packets get on the inside. If you are a valid application trying to make a connection to a valid open port known in advance, then this is all you need. If you are a hacker without that information, you probably need to try a few more times. This, importantly for whether someone "feels" safe, is to give a setting somewhere between "wide open" and "completely closed". I'd say a lot of users fall in that category. > Namely, once a PC/device is infected, it's game-over, anyway. And the attack vectors are often above L4 these days. > Specifically, remote attackers already have the ability to remotely control that PC and perform further reconnaissance and attacks both /inside/ and outside the LAN. Second, if technically savvy people still don't like the idea of NAT-PMP operating on their FW, then they will be smart enough to disable it altogether on their (personal) FW's. > I wish I could conjure up confidence that a single, interoperable, secure, ubiquitously available, FW control protocol will exist for IPv6. Given that we haven't been able to achieve that for IPv4, I find it hard to believe we will for IPv6. Assuming it will happen is little more than wishful thinking at this stage. - Mark > -shane > From secmech-request@lists.ietf.org Sun Mar 21 08:44:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F773A69A4 for ; Sun, 21 Mar 2010 08:44:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 21 Mar 2010 08:44:30 -0700 (PDT) Received: from algorithmics.com (unknown [125.164.130.80]) by core3.amsl.com (Postfix) with SMTP id 267F53A699F for ; Sun, 21 Mar 2010 08:44:11 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Discount 76% for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100321154429.267F53A699F@core3.amsl.com> Date: Sun, 21 Mar 2010 08:44:11 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 06565 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Sun Mar 21 10:33:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591F73A6AF2 for ; Sun, 21 Mar 2010 10:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hEdicHkBD2f for ; Sun, 21 Mar 2010 10:33:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76E3C3A6AF1 for ; Sun, 21 Mar 2010 10:33:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtOxd-000Bfu-Vg for v6ops-data0@psg.com; Sun, 21 Mar 2010 17:29:13 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtOxb-000Bez-9c for v6ops@ops.ietf.org; Sun, 21 Mar 2010 17:29:11 +0000 Received: by gwb17 with SMTP id 17so565420gwb.11 for ; Sun, 21 Mar 2010 10:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=N8K1cnncCD9fsEWY5pXxCUPtEwbWseNGG8jVQxDclgs=; b=n1O7NTolV9Z4NudsA27cR5lxvMQL4UVm4XY6p52ARjFYIz3PcBbn8Js6xeMk5v5OVe L3IQ5w6yJQ3wM1vQ+sP9a3qmXu1QMo/kZ4HyvQGJcbpFURA5BVjygRSh/mdqXXmEjnWj C2HjUYPKINPU9AsAM0ziXyqetXxe9YftJSVfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Wetm5pI8oEabJoXdVBDDB0LlZKquundZVBFYJ3345o39+XY8GqhhvY6ePVQTW92QoF jcBq5lTNfcqvoZVLTIGU307XKAdEw8Lk34mW27QPzFCWbUMpP3kReSzxkT4jjlDKELfA Dj5QeoGyiHoqP3+Kk/AlppVNJjhJaPbf3LbvU= Received: by 10.90.7.13 with SMTP id 13mr3180687agg.75.1269192550344; Sun, 21 Mar 2010 10:29:10 -0700 (PDT) Received: from [130.129.24.199] ([130.129.24.199]) by mx.google.com with ESMTPS id 16sm2510957gxk.1.2010.03.21.10.29.09 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 10:29:09 -0700 (PDT) Message-ID: <4BA6575D.7070300@gmail.com> Date: Mon, 22 Mar 2010 06:29:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering CC: Mark Townsley , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> In-Reply-To: <20100321133831.GL69383@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-03-22 02:38, Gert Doering wrote: > Hi, > > On Sun, Mar 21, 2010 at 01:19:50PM +1300, Brian E Carpenter wrote: >> Indeed. But ISPs that supply CPE to their customers are going to >> assume that their customers are running unpatched insecure operating >> systems at high risk of catching malware. So I think they are just as >> likely as enterprise IT departments to favour default deny approaches. > > We're not. > > We provide *Internet* services. Not "walled garden" services. > > If the customer wants firewall protection, we're happy to sell it to them, > but the default package they get is "Internet". Packets transported from > A to B and vice versa, and we're not maing their packets unhappy unless they > tell us so. I applaud that and it's what I want from my ISP. My comment is that I don't see this as a universal approach. So, I'm wondering what's really wrong with: REC-41 Gateways MUST provide an easily selected configuration option that permits operation in a mode that forwards all unsolicited flows regardless of forwarding direction. - Brian From owner-v6ops@ops.ietf.org Sun Mar 21 11:04:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EDD3A685A for ; Sun, 21 Mar 2010 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.332 X-Spam-Level: * X-Spam-Status: No, score=1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akaRXza-Vq-B for ; Sun, 21 Mar 2010 11:04:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 878573A682E for ; Sun, 21 Mar 2010 11:04:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtPUA-000HcH-Ns for v6ops-data0@psg.com; Sun, 21 Mar 2010 18:02:50 +0000 Received: from [93.17.128.19] (helo=smtp23.services.sfr.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtPU7-000Hc1-GE for v6ops@ops.ietf.org; Sun, 21 Mar 2010 18:02:47 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id CF9867000091; Sun, 21 Mar 2010 19:02:45 +0100 (CET) Received: from [130.129.24.236] (unknown [130.129.24.236]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 8610670000B1; Sun, 21 Mar 2010 19:02:43 +0100 (CET) X-SFR-UUID: 20100321180243549.8610670000B1@msfrf2304.sfr.fr Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sun, 21 Mar 2010 11:02:42 -0700 Cc: Fred Baker , IPv6 Operations , Ron Bonica , Kurt Erik Lindqvist Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, On February 19, I wrote on to Fred, with copy to the v6ops list: <<< Draft-despres-softwire-sam-00, which I will post in a few days, contains = an updated description of SAM, the generic Stateless Address Mapping = mechanism which applies to a variety of scenarios. Among those, one permits ISPs to deliver native IPv6 connectivity across = legacy CPEs that only support NAT44 with port forwarding. This solution is like 6rd in that: - ISPs don't need to change their IPv4 infrastructures - They only need to operate gateways between these and their IPv6 = accesses - These gateways are stateless It is unlike 6rd in that: - Legacy CPEs don't need to be upgraded - To exploit of their IPv6 addresses, hosts have to be upgraded to = support SAM. Operation considerations of this scenario are relevant to v6ops. A time slot for a presentation will be appreciated. >>> Although the agenda of v6ops doesn't specify it, what I will present on = friday is very far from a general SAM presentation like the one I asked = to have in Softwire, but couldn't be scheduled due to the lack of enough = time allocated to Softwire. As initially planned, my presentation will be limited to the "Native = IPv6 across NAT44s" scenario. Regards, RD Le 21 mars 2010 =E0 07:02, Templin, Fred L a =E9crit : > Fred, >=20 > As far as I can tell, the SAM proposal is a new transitional > technology and protocol also. RANGER and SAM are addressing > very similar problem spaces, and I think their eligibility > for inclusion in the v6ops agenda should be considered on > equal terms. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Saturday, March 20, 2010 10:28 PM >> To: Templin, Fred L >> Cc: IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist >> Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 >>=20 >> I have a question on these. >>=20 >> Per the abstract of VET, "VET can also be considered as version 2 of = the Intra-Site Automatic Tunnel >> Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with = routing, next hop determination, and a >> "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think = this is an operational >> description. I think this belongs discussed in rrg, rtgarea/rtgwg, or = *maybe* int-area. >>=20 >> How about you and I discuss this Monday and you convince me that this = is within the charter of IPv6 >> Operations. I think it is that which was explicitly placed outside = the charter - transitional >> technologies and protocol development. >>=20 >>=20 >> On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote: >>=20 >>> Fred, >>>=20 >>> The new agenda posted on the webpages does not seem to match the one >>> you posted to the list: >>>=20 >>> http://www.ietf.org/proceedings/10mar/agenda/v6ops.html >>>=20 >>> Seeing that there are new additions, I would like to propose to add = the >>> RANGER, VET and SEAL trilogy - preferably as the final session on >>> Friday, as I have two other conflicts for the earlier portion of = that session. >>> The talk would require 15min, and would cover all three documents >>> together (i.e., not as three separate talks). The documents are = here: >>>=20 >>> http://www.ietf.org/rfc/rfc5720.txt >>> http://tools.ietf.org/html/draft-templin-intarea-vet >>> http://tools.ietf.org/html/draft-templin-intarea-seal >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Fred Baker >>> Sent: Tuesday, March 16, 2010 2:06 PM >>> To: IPv6 Operations >>> Subject: Proposed agenda for IPv6 Operations - IETF 77 >>>=20 >>> Comments please... Basically I am putting three security issues and = two 3GPP-relevant drafts on >> Monday morning and the remainder on Friday morning. Each discussion = gets about half an hour. If time >> permits in the meeting, I'll pull agenda items forward from Friday to = Monday. I have two drafts on >> here that were not marked for v6ops but the authors asked me to = include; next time I'd appreciate it >> if folks used the draft-*-v6ops-* naming convention; it makes my job = easier. If I have missed >> anything, let me know. >>> IPv6 Operations - IETF 77 >>>=20 >>> Monday 22 March, 9:00 AM >>>=20 >>> Agenda bashing >>>=20 >>> Recommended Simple Security Capabilities in Customer Premises = Equipment for Providing Residential >> IPv6 Internet Service >>> 18-Feb-10, >>> Advanced Security for IPv6 CPE >>> 8-Mar-10, >>> Routing Loops using ISATAP and 6to4: Problem Statement and Proposed = Solutions >>> 1-Feb-10, >>>=20 >>> IPv6 in 3GPP Evolved Packet System >>> 24-Feb-10, >>> Mobile Networks Considerations for IPv6 Deployment >>> 8-Mar-10, >>> Friday 26 March, 9:00 AM >>>=20 >>> Emerging Service Provider Scenarios for IPv6 Deployment >>> 23-Feb-10, >>> Unicast Transmission of IPv6 Multicast Messages on Link-layer >>> 15-Feb-10, >>> Neighbor Cache Protection in Neighbor Discovery Protocol >>> 2-Mar-10, >>> DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks >>> 16-Feb-10, >>> Advanced Requirements for IPv6 Customer Edge Routers >>> 8-Mar-10, >>>=20 >>>=20 >>> http://www.ipinc.net/IPv4.GIF >>>=20 >>=20 >> http://www.ipinc.net/IPv4.GIF >=20 >=20 From owner-v6ops@ops.ietf.org Sun Mar 21 11:42:49 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DC83A68DC for ; Sun, 21 Mar 2010 11:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kMTvy0RpF3s for ; Sun, 21 Mar 2010 11:42:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7610C3A685A for ; Sun, 21 Mar 2010 11:42:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQ3n-000No8-Kw for v6ops-data0@psg.com; Sun, 21 Mar 2010 18:39:39 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQ3l-000Nno-Cl for v6ops@ops.ietf.org; Sun, 21 Mar 2010 18:39:37 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,284,1267401600"; d="scan'208";a="103577869" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2010 18:39:35 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2LIdZwY029296; Sun, 21 Mar 2010 18:39:35 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LIdYY17749; Sun, 21 Mar 2010 11:39:34 -0700 (PDT) Message-ID: <4BA667E5.3020205@cisco.com> Date: Sun, 21 Mar 2010 19:39:33 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Cameron Byrne CC: Fred Baker , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> 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 List-ID: On 3/21/10 4:00 AM, Cameron Byrne wrote: > On Sat, Mar 20, 2010 at 3:55 PM, Fred Baker wrote: > >>>>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home. >>>>> >>>>> >>>> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. >>>> >>> The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time. >>> >>> - Mark >>> >>>> Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection? >>>> >> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding. >> >> > Agreed, rate-limiting does not add value in this scope. We know that > IPv6 is hard to scan successfully, and we know that rate limiting it > on the CPE won't protect the external link from becoming saturated > during an attack. From the service provider perspective, rate > limiting causes inconsistency in services (some packets get through in > this sample test but not in the next sample test) and thus injects > greater complexity for the folks trying to troubleshoot. I prefer > consistent and deterministic behavior. I would say the principle of > default-deny and least privilege are philosophically correct in > general, but i am not sure it needs to be applied in simple CPE. I > believe most current host OS software ships these days with default > deny, and authorized administrators and applications can open the > proper ports when needed. If the trend is default-deny on the host > which is "application aware", we do not need default-deny on the > simple CPE which is not application aware. > I agree with you, Cameron. The idea of rate-limiting is a compromise between this opinion and what is in the draft now. I'd be more than happy with what you propose here. - Mark > Cameron > > From owner-v6ops@ops.ietf.org Sun Mar 21 12:08:17 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B933A690A for ; Sun, 21 Mar 2010 12:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.775 X-Spam-Level: * X-Spam-Status: No, score=1.775 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfXBl1lh7Zvi for ; Sun, 21 Mar 2010 12:08:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED7153A691F for ; Sun, 21 Mar 2010 12:08:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQTw-0002Lw-Hi for v6ops-data0@psg.com; Sun, 21 Mar 2010 19:06:40 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQTt-0002Lf-R3 for v6ops@ops.ietf.org; Sun, 21 Mar 2010 19:06:38 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NtQTi-00009r-2S; Mon, 22 Mar 2010 05:36:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 8FF3C4930C; Mon, 22 Mar 2010 05:36:25 +1030 (CST) Date: Mon, 22 Mar 2010 05:36:25 +1030 From: Mark Smith To: Brian E Carpenter Cc: Gert Doering , Mark Townsley , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100322053625.409b21e6@opy.nosense.org> In-Reply-To: <4BA6575D.7070300@gmail.com> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Mon, 22 Mar 2010 06:29:01 +1300 Brian E Carpenter wrote: > On 2010-03-22 02:38, Gert Doering wrote: > > Hi, > > > > On Sun, Mar 21, 2010 at 01:19:50PM +1300, Brian E Carpenter wrote: > >> Indeed. But ISPs that supply CPE to their customers are going to > >> assume that their customers are running unpatched insecure operating > >> systems at high risk of catching malware. So I think they are just as > >> likely as enterprise IT departments to favour default deny approaches. > > > > We're not. > > > > We provide *Internet* services. Not "walled garden" services. > > > > If the customer wants firewall protection, we're happy to sell it to them, > > but the default package they get is "Internet". Packets transported from > > A to B and vice versa, and we're not maing their packets unhappy unless they > > tell us so. > > I applaud that and it's what I want from my ISP. My comment is that > I don't see this as a universal approach. > > So, I'm wondering what's really wrong with: > > REC-41 Gateways MUST provide an easily selected configuration option > that permits operation in a mode that forwards all unsolicited > flows regardless of forwarding direction. > I don't see anything wrong with it. That the "Vanilla Router" checkbox. In some respects is equivalent to bridge mode on ADSL routers today, which allow end-hosts to terminate the PPPoE/PPP sessions, rather than have the upstream ADSL router do it. Regards, Mark. From v6ops-archive@megatron.ietf.org Sun Mar 21 12:19:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BC43A685A for ; Sun, 21 Mar 2010 12:19:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 21 Mar 2010 12:19:31 -0700 (PDT) Received: from 0018-193-27-72-DYNAMIC-dsl.cwjamaica.com (0018-193-27-72-DYNAMIC-dsl.cwjamaica.com [72.27.193.18]) by core3.amsl.com (Postfix) with SMTP id B72023A694F for ; Sun, 21 Mar 2010 12:19:19 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100321191922.B72023A694F@core3.amsl.com> Date: Sun, 21 Mar 2010 12:19:19 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 30592 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Sun Mar 21 12:20:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845243A68A2 for ; Sun, 21 Mar 2010 12:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.696 X-Spam-Level: X-Spam-Status: No, score=-7.696 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqfPst23-nKH for ; Sun, 21 Mar 2010 12:20:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C6453A6861 for ; Sun, 21 Mar 2010 12:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQf8-0004RV-Ks for v6ops-data0@psg.com; Sun, 21 Mar 2010 19:18:14 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtQf2-0004Q5-Me for v6ops@ops.ietf.org; Sun, 21 Mar 2010 19:18:08 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMYNpkurR7Ht/2dsb2JhbACDCZgxc6BRiDGPK4EsgSmBPmoE X-IronPort-AV: E=Sophos;i="4.51,284,1267401600"; d="scan'208";a="500317938" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2010 19:18:08 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2LJI70N012440; Sun, 21 Mar 2010 19:18:08 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LJI6Y23227; Sun, 21 Mar 2010 12:18:06 -0700 (PDT) Message-ID: <4BA670ED.1020302@cisco.com> Date: Sun, 21 Mar 2010 20:18:05 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: Gert Doering , james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> In-Reply-To: <4BA6575D.7070300@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/21/10 6:29 PM, Brian E Carpenter wrote: > On 2010-03-22 02:38, Gert Doering wrote: > >> Hi, >> >> On Sun, Mar 21, 2010 at 01:19:50PM +1300, Brian E Carpenter wrote: >> >>> Indeed. But ISPs that supply CPE to their customers are going to >>> assume that their customers are running unpatched insecure operating >>> systems at high risk of catching malware. So I think they are just as >>> likely as enterprise IT departments to favour default deny approaches. >>> >> We're not. >> >> We provide *Internet* services. Not "walled garden" services. >> >> If the customer wants firewall protection, we're happy to sell it to them, >> but the default package they get is "Internet". Packets transported from >> A to B and vice versa, and we're not maing their packets unhappy unless they >> tell us so. >> > I applaud that and it's what I want from my ISP. My comment is that > I don't see this as a universal approach. > > So, I'm wondering what's really wrong with: > > REC-41 Gateways MUST provide an easily selected configuration option > that permits operation in a mode that forwards all unsolicited > flows regardless of forwarding direction. > The problem is the default, which is not to permit this. - Mark > - Brian > > From owner-v6ops@ops.ietf.org Sun Mar 21 13:34:59 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811CC3A680C for ; Sun, 21 Mar 2010 13:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUVcqihyUUOd for ; Sun, 21 Mar 2010 13:34:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 881EE3A67F2 for ; Sun, 21 Mar 2010 13:34:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtRmt-000G1L-0S for v6ops-data0@psg.com; Sun, 21 Mar 2010 20:30:19 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtRmp-000G0S-CR for v6ops@ops.ietf.org; Sun, 21 Mar 2010 20:30:15 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id D37D9917BA7A for ; Sun, 21 Mar 2010 13:30:14 -0700 (PDT) X-AuditID: 11807134-b7b29ae000001f57-d6-4ba681d64ca4 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id AD.9E.08023.6D186AB4; Sun, 21 Mar 2010 13:30:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from [10.61.165.165] (166-205-138-157.mobile.mymmode.com [166.205.138.157]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KZN00EHDFMCYG20@elliott.apple.com> for v6ops@ops.ietf.org; Sun, 21 Mar 2010 13:30:14 -0700 (PDT) References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> Message-id: From: james woodyatt To: Mark Townsley In-reply-to: <4BA670ED.1020302@cisco.com> Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Date: Sun, 21 Mar 2010 13:29:50 -0700 Cc: Brian E Carpenter , Gert Doering , IPv6 Operations X-Mailer: iPhone Mail (7E18) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 21, 2010, at 12:18, Mark Townsley wrote: > On 3/21/10 6:29 PM, Brian E Carpenter wrote: >> >> >> So, I'm wondering what's really wrong with: >> >> REC-41 Gateways MUST provide an easily selected configuration >> option >> that permits operation in a mode that forwards all unsolicited >> flows regardless of forwarding direction. >> > The problem is the default, which is not to permit this. >> That problem is inherited from RFC 4864, which this draft is not intended to reverse. -jhw Sent from my phone From owner-v6ops@ops.ietf.org Sun Mar 21 14:15:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4107C3A68C7 for ; Sun, 21 Mar 2010 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=-1.524, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDXHeJg2Wky6 for ; Sun, 21 Mar 2010 14:15:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22DB93A6817 for ; Sun, 21 Mar 2010 14:15:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSS8-000MX8-U3 for v6ops-data0@psg.com; Sun, 21 Mar 2010 21:12:56 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSS4-000MWS-Gx for v6ops@ops.ietf.org; Sun, 21 Mar 2010 21:12:52 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8opkurR7Hu/2dsb2JhbACbOnOgN5dggkaCNwQ X-IronPort-AV: E=Sophos;i="4.51,284,1267401600"; d="scan'208";a="169946146" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2010 21:12:49 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2LLCmEk018737; Sun, 21 Mar 2010 21:12:48 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LLClY07761; Sun, 21 Mar 2010 14:12:47 -0700 (PDT) Message-ID: <4BA68BCE.8040604@cisco.com> Date: Sun, 21 Mar 2010 22:12:46 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> <20100321113037.13756c12@opy.nosense.org> 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 List-ID: On 3/21/10 7:00 AM, james woodyatt wrote: > On Mar 20, 2010, at 18:00, Mark Smith wrote: > >> One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model. >> > RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list. Perhaps, you'd like to offer a contribution? > > The Overview contains my best attempt at explaining what considerations I think are really in play behind the CPE Simple Security recommendation. Here's what I think is the most relevant excerpt: > > >>> The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place. >>> > In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet users have come to expect it. Apparently, there's a consensus in IETF that this is enough reason to do it, and I strongly suspect that an explicit threat model might be inviting more controversy than anyone wants to endure. > So, you are saying there is IETF consensus on a security solution for IPv6 based largely on the status quo of IPv4, but no consensus on what security problem either are actually solving. If we are shooting for status quo and similar user experience, we should go ahead and include NAT. At least then the user gets stable independent addressing, regardless of what the ISP offers. Imagine Los Angeles manages to get everyone to move to electric cars, but the local populace decides that they liked the smog that blocked the sun, the daily pollution indicators, etc. and decides to pump smoke into the atmosphere to ensure that the user expectation of the inhabitants remains unchanged. - Mark > > -- > james woodyatt > member of technical staff, communications engineering > > > > > From owner-v6ops@ops.ietf.org Sun Mar 21 14:27:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329723A6939 for ; Sun, 21 Mar 2010 14:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.621 X-Spam-Level: X-Spam-Status: No, score=-7.621 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRde6IbmUGOt for ; Sun, 21 Mar 2010 14:27:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 783A43A6817 for ; Sun, 21 Mar 2010 14:27:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSeO-000Nqx-Q2 for v6ops-data0@psg.com; Sun, 21 Mar 2010 21:25:36 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSeK-000NqD-EI for v6ops@ops.ietf.org; Sun, 21 Mar 2010 21:25:32 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFkrpkurR7H+/2dsb2JhbACbOnOgNpdihH0E X-IronPort-AV: E=Sophos;i="4.51,284,1267401600"; d="scan'208";a="103591635" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2010 21:25:31 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2LLPVJ6017124; Sun, 21 Mar 2010 21:25:31 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LLPUY11712; Sun, 21 Mar 2010 14:25:30 -0700 (PDT) Message-ID: <4BA68EC9.8050506@cisco.com> Date: Sun, 21 Mar 2010 22:25:29 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mark Smith CC: james woodyatt , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <4BA55147.601@cisco.com> <20100321113037.13756c12@opy.nosense.org> <20100321183807.76a4e2c8@opy.nosense.org> In-Reply-To: <20100321183807.76a4e2c8@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/21/10 9:08 AM, Mark Smith wrote: > Hi James, > > On Sat, 20 Mar 2010 23:00:40 -0700 > james woodyatt wrote: > > >> On Mar 20, 2010, at 18:00, Mark Smith wrote: >> >>> One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model. >>> >> RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list. Perhaps, you'd like to offer a contribution? >> >> > While threat model is probably the correct term, more broadly I think > probably something of a problem statement i.e. what security measures > the CPE does provide, and what it doesn't, probably with some > justification. > > I think the role of IPv6 CPE in the residential Internet security model > is different to the role IPv4/NAT CPE commonly is or was capable of > playing. > > Stating the obvious, IPv4/NAT provides a much harder boundary between > internal and external devices, primarily due to the nature of NAPT. > NAPT by it's nature provides a default deny to inbound traffic. That's > what breaks end-to-end. Because of that harder boundary, I think > end-user expectations are that the IPv4/NAPT CPE can perform much > more of a primary security role when it comes to protecting them from > the Internet. > > The nature of the operation of NAPT inherently defined a set of threats > that it protected against. > > With IPv6/CPE security, by trying to restore end-to-end, I think we're > inherently reducing the security that people formerly had with > IPv4/NAPT CPE. End nodes will now have to play more of a primary > security role, with filtering IPv6/CPE providing an > assisting/secondary/defence in depth role. > Which that vast majority of IPv6-enabled devices already do. - Mark > Now that IPv6 end-nodes will be "burdened" with more security > responsibility, I think it is important to make sure it is clear that > the security functions performed in IPv6 CPE aren't exactly the > same as as they were in IPv4/NAPT CPE. > > > >> The Overview contains my best attempt at explaining what considerations I think are really in play behind the CPE Simple Security recommendation. Here's what I think is the most relevant excerpt: >> >> >>>> The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place. >>>> >> In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet users have come to expect it. Apparently, there's a consensus in IETF that this is enough reason to do it, and I strongly suspect that an explicit threat model might be inviting more controversy than anyone wants to endure. >> >> >> > Regards, > Mark. > > > From owner-v6ops@ops.ietf.org Sun Mar 21 14:28:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FA33A6939 for ; Sun, 21 Mar 2010 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.611 X-Spam-Level: X-Spam-Status: No, score=-7.611 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9r4cJ2JDTGg for ; Sun, 21 Mar 2010 14:28:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9D03A6817 for ; Sun, 21 Mar 2010 14:28:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSgq-000O2Z-Qg for v6ops-data0@psg.com; Sun, 21 Mar 2010 21:28:08 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtSgn-000O1N-98 for v6ops@ops.ietf.org; Sun, 21 Mar 2010 21:28:05 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALcspkurR7Ht/2dsb2JhbACbOnOgO5dihH0E X-IronPort-AV: E=Sophos;i="4.51,284,1267401600"; d="scan'208";a="103592023" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2010 21:28:03 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2LLS3F4024885; Sun, 21 Mar 2010 21:28:03 GMT Received: from ams-townsley-8719.cisco.com (ams-townsley-8719.cisco.com [10.55.233.234]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2LLS2Y11990; Sun, 21 Mar 2010 14:28:02 -0700 (PDT) Message-ID: <4BA68F61.7020005@cisco.com> Date: Sun, 21 Mar 2010 22:28:01 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt CC: Brian E Carpenter , Gert Doering , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> 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 List-ID: On 3/21/10 9:29 PM, james woodyatt wrote: > On Mar 21, 2010, at 12:18, Mark Townsley wrote: >> On 3/21/10 6:29 PM, Brian E Carpenter wrote: >>> >>> >>> So, I'm wondering what's really wrong with: >>> >>> REC-41 Gateways MUST provide an easily selected configuration option >>> that permits operation in a mode that forwards all unsolicited >>> flows regardless of forwarding direction. >>> >> The problem is the default, which is not to permit this. >>> > > > That problem is inherited from RFC 4864, which this draft is not > intended to reverse. Why not, if that is the current consensus? We've reversed the text of IETF standards track documents before, much less Informational documents that are not a standard of any kind. - Mark > > -jhw > > Sent from my phone > From owner-v6ops@ops.ietf.org Sun Mar 21 15:18:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5613A689F for ; Sun, 21 Mar 2010 15:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajxEqiXdGRuv for ; Sun, 21 Mar 2010 15:18:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A9F33A677D for ; Sun, 21 Mar 2010 15:18:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtTPh-0002ED-CR for v6ops-data0@psg.com; Sun, 21 Mar 2010 22:14:29 +0000 Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtTPb-0002Di-BG for v6ops@ops.ietf.org; Sun, 21 Mar 2010 22:14:23 +0000 Received: by yxe14 with SMTP id 14so2382278yxe.5 for ; Sun, 21 Mar 2010 15:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GAWjzcn3Agz2jJI3mLpMxEbTWFNt+X2nZE22YcwJOGk=; b=bPTNnmqOBTl9qM/7cGsioXszUZ1OCdkEApz5O9ZUtfxcmmtUQReU0OpOqYP+Yo1t/T o4B1wWF6j+75GZCoPmDSVw36BmQRcw9ThdmFsw9/0xEqrjevw7s1f/zNvx+2DSS7ggHl a+U3qmA3I1oqnCVQM7/MjIohC7/G47KEFbIXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cg2T4g2AdqP1J930n75UcXLaSYRy2zXwF3VZ9jyzikeCuOssnrq8LBfAuhfciaKfQC Xt5x8214CQrATJkTqZiijhZd6DwMU5iWO1fp5eOc0tOJ7kUd3SoO48FBNwpZy8rqpNi1 HdC3T+Q/x46HMUa5frGmoztXIa6iHAsuqughk= Received: by 10.150.174.9 with SMTP id w9mr3674338ybe.0.1269209662441; Sun, 21 Mar 2010 15:14:22 -0700 (PDT) Received: from [130.129.24.199] ([130.129.24.199]) by mx.google.com with ESMTPS id 7sm306100yxd.44.2010.03.21.15.14.21 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 15:14:21 -0700 (PDT) Message-ID: <4BA69A3D.7@gmail.com> Date: Mon, 22 Mar 2010 11:14:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley CC: james woodyatt , Gert Doering , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> In-Reply-To: <4BA68F61.7020005@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-03-22 10:28, Mark Townsley wrote: > On 3/21/10 9:29 PM, james woodyatt wrote: >> On Mar 21, 2010, at 12:18, Mark Townsley wrote: >>> On 3/21/10 6:29 PM, Brian E Carpenter wrote: >>>> >>>> >>>> So, I'm wondering what's really wrong with: >>>> >>>> REC-41 Gateways MUST provide an easily selected configuration option >>>> that permits operation in a mode that forwards all unsolicited >>>> flows regardless of forwarding direction. >>>> >>> The problem is the default, which is not to permit this. >>>> >> >> >> That problem is inherited from RFC 4864, which this draft is not >> intended to reverse. > Why not, if that is the current consensus? We've reversed the text of > IETF standards track documents before, much less Informational documents > that are not a standard of any kind. As a co-author of 4864, let me agree violently. It's not a BCP. Even if it was, consensus could reverse it. What 4864 says is: NATs weren't designed as security devices but they provide simple security by blocking everything incoming by default. To implement simple security for v6 you should do it with a stateful firewall. It doesn't say that CPEs MUST do this. It leaves that choice open, as an informational document. Brian From owner-v6ops@ops.ietf.org Sun Mar 21 22:27:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9123A6A02 for ; Sun, 21 Mar 2010 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.58 X-Spam-Level: X-Spam-Status: No, score=-101.58 tagged_above=-999 required=5 tests=[AWL=-1.415, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYwoCBXcLXPM for ; Sun, 21 Mar 2010 22:27:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B9903A6954 for ; Sun, 21 Mar 2010 22:26:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nta2w-000BSq-Ai for v6ops-data0@psg.com; Mon, 22 Mar 2010 05:19:27 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nta2s-000BSP-RB for v6ops@ops.ietf.org; Mon, 22 Mar 2010 05:19:23 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 4938E8A76303 for ; Sun, 21 Mar 2010 22:19:22 -0700 (PDT) X-AuditID: 11807130-b7bdcae000007b51-3e-4ba6fdd97638 Received: from [17.151.98.32] (Unknown_Domain [17.151.98.32]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 2B.0D.31569.ADDF6AB4; Sun, 21 Mar 2010 22:19:22 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 From: james woodyatt In-Reply-To: <4BA69A3D.7@gmail.com> Date: Sun, 21 Mar 2010 22:19:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 21, 2010, at 15:14, Brian E Carpenter wrote: > On 2010-03-22 10:28, Mark Townsley wrote: >>=20 >> Why not, if that is the current consensus? We've reversed the text of >> IETF standards track documents before, much less Informational = documents >> that are not a standard of any kind. The design team was directed by the chair to write a draft that detailed = the recommendation in Section 4.2 of RFC 4864 for a stateful filter in = residential IPv6 CPE routers, and we were not instructed that revisiting = the recommendation with an eye toward reversing it was explicitly within = our ambit. > As a co-author of 4864, let me agree violently. It's not a BCP. > Even if it was, consensus could reverse it. >=20 > What 4864 says is: NATs weren't designed as security devices but they > provide simple security by blocking everything incoming by default. > To implement simple security for v6 you should do it with a stateful > firewall. I would have expected an author of RFC 4864 to quote the following = excerpt from Section 4.2 instead: To implement simple security for IPv6 in, for example, a DSL or cable modem-connected home network, the broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). There should also be an easy interface that allows users to create inbound 'pinholes' for specific purposes such as online gaming. That paragraph is the whole reason that = I-D.ietf-v6ops-cpe-simple-security exists today. Note the use of the = word "should" in the verb phrase of the second sentence. It sure looks = to me like it makes a value judgment that IPv6 Simple Security in = unmanaged home routers is considered helpful. When I first read Section 4.2 of the Internet Draft that would become = RFC 4864, just a little over three years ago, I sent = to the V6OPS = list to surface what I thought, at the time, was an oversight. Note = that I was objecting to the use of the word "should" in that paragraph. = I thought RFC 4864 should not be making such a recommendation, and I = believed that the authors must have been mistaken to include it in an = Informational category document. Alas, I later learned that this recommendation was quite deliberate and = *NOT* open for discussion anymore. I withdrew my objection soon = thereafter, after one of the authors expressed "violent" disagreement = with me, because I came to believe my personal misgivings about this = recommendation weren't shared by the majority of IETF participants. I = still think only a small minority of participants agrees with me. > It doesn't say that CPEs MUST do this. It leaves that choice open, as = an informational document. No, it doesn't say that CPE routers MUST do this, but it does go out of = its way to say that CPE routers "should" do this. More importantly, other specifications which reference RFC 4864 as if = it's morally equivalent to a proposed standard *do* say that CPE routers = MUST do this. While categorized as Informational, the language in = I-D.ietf-v6ops-cpe-simple-security is deliberately crafted to be easily = cited by other SDO's in requirement specifications, which are expecting = to describe not just the CPE routers MUST do this, but HOW they will do = this. I am aware of at least two other SDO's that are preparing exactly = that. So, while it's true that neither RFC 4864 nor = I-D.ietf-v6ops-cpe-simple-security say that CPE routers MUST implement a = "default deny" stateful filtering regime, the common law is congealing = around this as a requirement as we speak. So, despite the fact that = this draft is Informational and not BCP or Proposed Standard, what we = say in this document should it be published in the RFC series is very = likely to become the Law of the Internet pretty much overnight, and I = think that pretending otherwise would be awfully na=EFve. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Sun Mar 21 23:09:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F493A67EF for ; Sun, 21 Mar 2010 23:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnbfE1nMoOiD for ; Sun, 21 Mar 2010 23:09:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B531B3A69A3 for ; Sun, 21 Mar 2010 23:09:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtanW-000Gru-SO for v6ops-data0@psg.com; Mon, 22 Mar 2010 06:07:34 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtanT-000Grc-H9 for v6ops@ops.ietf.org; Mon, 22 Mar 2010 06:07:32 +0000 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2M6AHLu030503; Mon, 22 Mar 2010 01:10:17 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 22 Mar 2010 02:06:59 -0400 From: Suresh Krishnan To: Fred Baker , IPv6 Operations CC: Lindqvist Kurt Erik , Ralph Droms , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , "jjeong@cs.umn.edu" , "luc.beloeil@orange-ftgroup.com" , "smadanapalli@gmail.com" , Daniel Park Date: Mon, 22 Mar 2010 02:06:58 -0400 Subject: RE: RFC 5006 status Thread-Topic: RFC 5006 status Thread-Index: AcrF6BzqYbdK6eeXSOm+iC3vARqbUgDnJSCw Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC14E5D13E0F8@EUSAACMS0703.eamcs.ericsson.se> References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Fred, I think this RFC is ready to be moved to Standards track. The one=20 thing I think the document is missing is a domain search list. I would=20 like this to be added into the standards track version of this RFC. Thanks Suresh =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Wednesday, March 17, 2010 8:19 AM > To: IPv6 Operations > Cc: Lindqvist Kurt Erik; Ralph Droms; 6man Chairs; Dave=20 > Thaler; Jari Arkko; jjeong@cs.umn.edu;=20 > luc.beloeil@orange-ftgroup.com; smadanapalli@gmail.com; Daniel Park > Subject: RFC 5006 status >=20 > This is a structured question for the community. >=20 > Jari Arkko tells us that he is getting requests from various=20 > sources to take RFC 5006 to Proposed Standard. It is now experimental. >=20 > http://www.ietf.org/rfc/rfc5006.txt > 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, > Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: > TXT=3D26136 bytes) (Status: EXPERIMENTAL) >=20 > (1) Please take a look at the document in the next few days;=20 > if you have comments on it (eg, you think it should be=20 > changed in some way), please comment to v6ops. >=20 > (2) Vendors, please advise on implementations. Are there any?=20 > Has interoperability been demonstrated? >=20 > (3) Operators, enterprise and/or service provider, please=20 > advise on deployment experience. >=20 >=20 > I'm adding a brief discussion to the agenda Monday morning=20 > with a view to getting a quick thumbs-up/thumbs-down to=20 > advise Jari, who can then take that to 6man later in the week=20 > if appropriate. >=20 >=20 >=20 > BTW, I have had a flurry of email related to the agenda. The=20 > current agenda may be found at=20 > http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > = From owner-v6ops@ops.ietf.org Mon Mar 22 00:47:59 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8ED3A694D for ; Mon, 22 Mar 2010 00:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.602 X-Spam-Level: X-Spam-Status: No, score=-7.602 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gflyT1BBagDC for ; Mon, 22 Mar 2010 00:47:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A71123A67FF for ; Mon, 22 Mar 2010 00:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtcIr-0000Ec-0l for v6ops-data0@psg.com; Mon, 22 Mar 2010 07:44:01 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtcIn-0000EI-Mu for v6ops@ops.ietf.org; Mon, 22 Mar 2010 07:43:57 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANq8pkurR7Hu/2dsb2JhbACDCZgpc6EDiDGPPIEsgmdqBA X-IronPort-AV: E=Sophos;i="4.51,286,1267401600"; d="scan'208";a="103718367" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2010 07:43:56 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2M7hulN020054; Mon, 22 Mar 2010 07:43:56 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2M7hsY15110; Mon, 22 Mar 2010 00:43:54 -0700 (PDT) Message-ID: <4BA71FB9.7020807@cisco.com> Date: Mon, 22 Mar 2010 08:43:53 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: james woodyatt , Gert Doering , IPv6 Operations Subject: Status of RFC 4864 (was Re: I-D.ietf-v6ops-cpe-simple-security-09) References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> In-Reply-To: <4BA69A3D.7@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This exchange highlights a very significant point with respect to the content in v6ops-cpe-simple-security. According to its author, v6ops-cpe-simple-security has been operating under the influence of precedent from RFC 4864, something that was never intended by the authors of the RFC, nor something expected under IETF procedures. - Mark On 3/21/10 11:14 PM, Brian E Carpenter wrote: > On 2010-03-22 10:28, Mark Townsley wrote: > >> On 3/21/10 9:29 PM, james woodyatt wrote: >> >>> On Mar 21, 2010, at 12:18, Mark Townsley wrote: >>> >>>> On 3/21/10 6:29 PM, Brian E Carpenter wrote: >>>> >>>>> So, I'm wondering what's really wrong with: >>>>> >>>>> REC-41 Gateways MUST provide an easily selected configuration option >>>>> that permits operation in a mode that forwards all unsolicited >>>>> flows regardless of forwarding direction. >>>>> >>>> The problem is the default, which is not to permit this. >>>> >>> That problem is inherited from RFC 4864, which this draft is not >>> intended to reverse. >>> >> Why not, if that is the current consensus? We've reversed the text of >> IETF standards track documents before, much less Informational documents >> that are not a standard of any kind. >> > As a co-author of 4864, let me agree violently. It's not a BCP. > Even if it was, consensus could reverse it. > > What 4864 says is: NATs weren't designed as security devices but they > provide simple security by blocking everything incoming by default. > To implement simple security for v6 you should do it with a stateful > firewall. > > It doesn't say that CPEs MUST do this. It leaves that choice open, as > an informational document. > > Brian > > From owner-v6ops@ops.ietf.org Mon Mar 22 01:00:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF60028C0E5 for ; Mon, 22 Mar 2010 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.594 X-Spam-Level: X-Spam-Status: No, score=-7.594 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsP39PIxzq2q for ; Mon, 22 Mar 2010 01:00:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A064328C0CE for ; Mon, 22 Mar 2010 01:00:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtcWf-0001ni-5H for v6ops-data0@psg.com; Mon, 22 Mar 2010 07:58:17 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtcWZ-0001mv-MW for v6ops@ops.ietf.org; Mon, 22 Mar 2010 07:58:11 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKq/pkurR7Hu/2dsb2JhbACDCZgic6ECiDGPPYEsgmdqBA X-IronPort-AV: E=Sophos;i="4.51,286,1267401600"; d="scan'208";a="170113483" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2010 07:58:11 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2M7wBt0029158; Mon, 22 Mar 2010 07:58:11 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2M7w9Y27441; Mon, 22 Mar 2010 00:58:09 -0700 (PDT) Message-ID: <4BA7230E.6020505@cisco.com> Date: Mon, 22 Mar 2010 08:58:06 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brian E Carpenter CC: james woodyatt , Gert Doering , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> In-Reply-To: <4BA69A3D.7@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/21/10 11:14 PM, Brian E Carpenter wrote: > > As a co-author of 4864, let me agree violently. It's not a BCP. > Even if it was, consensus could reverse it. > > What 4864 says is: NATs weren't designed as security devices but they > provide simple security by blocking everything incoming by default. > To implement simple security for v6 you should do it with a stateful > firewall. > Right, NAPTs were invented primarily for address amplification, but also brought simple security and address independence. Address amplification is something that IPv6 currently does not need, and address independence is something that would be quite useful but we haven't been able to design and deploy it without breaking end-to-end. The firewall function in simple-security explicitly damages end-to-end. If we go this route, we might as well toss in NAT too as we will have already paid the price in terms of end-to-end transparency; We might as well get the address independence benefit along with it. I suspect this will be used as an argument in the future if stateful firewall operations become ubiquitous in CPEs: How is NAT *that much* worse than the firewall you already have? - Mark > It doesn't say that CPEs MUST do this. It leaves that choice open, as > an informational document. > > Brian > > From owner-v6ops@ops.ietf.org Mon Mar 22 01:57:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61813A6A21 for ; Mon, 22 Mar 2010 01:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.567 X-Spam-Level: X-Spam-Status: No, score=0.567 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRhZ3V4iUmpR for ; Mon, 22 Mar 2010 01:57:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A45AC28C0FA for ; Mon, 22 Mar 2010 01:57:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtdMf-0008cV-OH for v6ops-data0@psg.com; Mon, 22 Mar 2010 08:52:01 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtdMX-0008bY-HU for v6ops@ops.ietf.org; Mon, 22 Mar 2010 08:51:53 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NtdMP-0000JM-Nn; Mon, 22 Mar 2010 19:21:45 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 1C0C04930C; Mon, 22 Mar 2010 19:21:45 +1030 (CST) Date: Mon, 22 Mar 2010 19:21:44 +1030 From: Mark Smith To: Mark Townsley Cc: Brian E Carpenter , james woodyatt , Gert Doering , IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Message-ID: <20100322192144.07423809@opy.nosense.org> In-Reply-To: <4BA7230E.6020505@cisco.com> References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> <4BA7230E.6020505@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Mon, 22 Mar 2010 08:58:06 +0100 Mark Townsley wrote: > On 3/21/10 11:14 PM, Brian E Carpenter wrote: > > > > As a co-author of 4864, let me agree violently. It's not a BCP. > > Even if it was, consensus could reverse it. > > > > What 4864 says is: NATs weren't designed as security devices but they > > provide simple security by blocking everything incoming by default. > > To implement simple security for v6 you should do it with a stateful > > firewall. > > > Right, NAPTs were invented primarily for address amplification, but also > brought simple security and address independence. > I agree. The security (I'd like to put that in quotes, but there is a fair bit of it) of NAPT wasn't by design, but as a consequence of the nature of it's operation. It is default deny because it is impossible for it not to be. RFC4864, despite it's more politically correct name (can't remember the earlier more accurate, albeit controversial one), is about exactly replicating the security functions of IPv4 NAT that people have come to expect, using IPv6 methods - because they couldn't "expect" anything else. From the 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 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation." IOW, if you really want to exactly replicate IPv4/NAT type security in IPv6, this is how you do it. I think the CPE draft, OTOH, should be saying "this is how you should be doing security in IPv6". I think restoring end-to-end, at least partially or configurably fully, is a key requirement. I think the CPE draft already does that. Arguably, that also already makes it inferior to IPv4/NAPT, because end-nodes will be directly visible over the Internet. However, we also know that end-nodes are much more security aware and capable than they used to be, so we're able to loosen CPE security to help restore end-to-end because we know that modern end-nodes are going to take up the slack. The CPE becomes a security assistant, not a security authority. This is why I've thought a bit more definite problem statement would help. If it is purely to replicate IPv4/NAPT CPE functionality in IPv6, then either RFC4864 would already do, or possibly a slightly more CPE oriented version needs to be produced. If, however, it is to state "this is how IPv6 CPE security should be done", then I think we should leave legacy IPv4/NAPT concepts that aren't appropriate behind. Regards, Mark S. > Address amplification is something that IPv6 currently does not need, > and address independence is something that would be quite useful but we > haven't been able to design and deploy it without breaking end-to-end. > > The firewall function in simple-security explicitly damages end-to-end. > If we go this route, we might as well toss in NAT too as we will have > already paid the price in terms of end-to-end transparency; We might as > well get the address independence benefit along with it. > > I suspect this will be used as an argument in the future if stateful > firewall operations become ubiquitous in CPEs: How is NAT *that much* > worse than the firewall you already have? > > - Mark > > It doesn't say that CPEs MUST do this. It leaves that choice open, as > > an informational document. > > > > > Brian > > > > > > From owner-v6ops@ops.ietf.org Mon Mar 22 03:24:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0080B3A6805 for ; Mon, 22 Mar 2010 03:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZBq-0Gy-Mrq for ; Mon, 22 Mar 2010 03:24:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F00BA28C0FD for ; Mon, 22 Mar 2010 03:22:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntehm-000J1g-Hr for v6ops-data0@psg.com; Mon, 22 Mar 2010 10:17:54 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntehj-000J1J-MK for v6ops@ops.ietf.org; Mon, 22 Mar 2010 10:17:51 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIXgpkurR7Hu/2dsb2JhbACbK3OhcZd2hH0EhiE X-IronPort-AV: E=Sophos;i="4.51,286,1267401600"; d="scan'208";a="170156878" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2010 10:17:50 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2MAHo1Q005547; Mon, 22 Mar 2010 10:17:50 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2MAHmY08829; Mon, 22 Mar 2010 03:17:49 -0700 (PDT) Message-ID: <4BA743CB.2070707@cisco.com> Date: Mon, 22 Mar 2010 11:17:47 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: James, if anyone who suggested to you that RFC 4864 or any Informational document represented the consensus of the IETF, you were sadly misled. However, if it is true what you say that, "this document should it be published in the RFC series is very likely to become the Law of the Internet pretty much overnight" then we better be sure we have consensus on what it says. I do not want to see the IETF recommending a default-deny rule on IPv6 residential gateways, and I regret that RFC 4864 has been interpreted as recommending this with any authority in the past. I've offered one admittedly imperfect compromise, but I find it better than wishing for a pin-hole protocol that doesn't exist and may never in a ubiquitous and interoperable manner. Even if such a protocol did exist, there are very legitimate security concerns about the effectiveness of operating what is essentially a distributed IP-stack between the host and RG vs. using a local firewall on the host. These have been brought up, but not fully discussed in this document or on the list. Bottom line: I think that the IETF should not publish any documents implying a default-deny rule as a recommended practice and default setting for IPv6 residential gateways. I think it is fine to describe how this should work should it be turned on, and that a configuration knob MUST exist, but the default should be set in a way that ensures it is "beneficial" and "not harmful to the Internet as a whole" (RFC 3935, BCP 95). The market always makes the final decision, and if it decides that customers want, or vendors want to sell, equipment with a default setting that breaks end-to-end transparency, there is no stopping this from happening. But, the IETF doesn't have to help it happen. I think the simple-security document, as a whole, doesn't risk being ignored if it leans a bit toward favoring IPv6 end-to-end transparency vs. IPv4 status quo in this one case. - Mark On 3/22/10 6:19 AM, james woodyatt wrote: > On Mar 21, 2010, at 15:14, Brian E Carpenter wrote: > >> On 2010-03-22 10:28, Mark Townsley wrote: >> >>> Why not, if that is the current consensus? We've reversed the text of >>> IETF standards track documents before, much less Informational documents >>> that are not a standard of any kind. >>> > The design team was directed by the chair to write a draft that detailed the recommendation in Section 4.2 of RFC 4864 for a stateful filter in residential IPv6 CPE routers, and we were not instructed that revisiting the recommendation with an eye toward reversing it was explicitly within our ambit. > > >> As a co-author of 4864, let me agree violently. It's not a BCP. >> Even if it was, consensus could reverse it. >> >> What 4864 says is: NATs weren't designed as security devices but they >> provide simple security by blocking everything incoming by default. >> To implement simple security for v6 you should do it with a stateful >> firewall. >> > I would have expected an author of RFC 4864 to quote the following excerpt from Section 4.2 instead: > > To implement simple security for IPv6 in, for example, a DSL or cable > modem-connected home network, the broadband gateway/router should be > equipped with stateful firewall capabilities. These should provide a > default configuration where incoming traffic is limited to return > traffic resulting from outgoing packets (sometimes known as > reflective session state). There should also be an easy interface > that allows users to create inbound 'pinholes' for specific purposes > such as online gaming. > > That paragraph is the whole reason that I-D.ietf-v6ops-cpe-simple-security exists today. Note the use of the word "should" in the verb phrase of the second sentence. It sure looks to me like it makes a value judgment that IPv6 Simple Security in unmanaged home routers is considered helpful. > > When I first read Section 4.2 of the Internet Draft that would become RFC 4864, just a little over three years ago, I sent to the V6OPS list to surface what I thought, at the time, was an oversight. Note that I was objecting to the use of the word "should" in that paragraph. I thought RFC 4864 should not be making such a recommendation, and I believed that the authors must have been mistaken to include it in an Informational category document. > > Alas, I later learned that this recommendation was quite deliberate and *NOT* open for discussion anymore. I withdrew my objection soon thereafter, after one of the authors expressed "violent" disagreement with me, because I came to believe my personal misgivings about this recommendation weren't shared by the majority of IETF participants. I still think only a small minority of participants agrees with me. > > >> It doesn't say that CPEs MUST do this. It leaves that choice open, as an informational document. >> > No, it doesn't say that CPE routers MUST do this, but it does go out of its way to say that CPE routers "should" do this. > > More importantly, other specifications which reference RFC 4864 as if it's morally equivalent to a proposed standard *do* say that CPE routers MUST do this. While categorized as Informational, the language in I-D.ietf-v6ops-cpe-simple-security is deliberately crafted to be easily cited by other SDO's in requirement specifications, which are expecting to describe not just the CPE routers MUST do this, but HOW they will do this. I am aware of at least two other SDO's that are preparing exactly that. > > So, while it's true that neither RFC 4864 nor I-D.ietf-v6ops-cpe-simple-security say that CPE routers MUST implement a "default deny" stateful filtering regime, the common law is congealing around this as a requirement as we speak. So, despite the fact that this draft is Informational and not BCP or Proposed Standard, what we say in this document should it be published in the RFC series is very likely to become the Law of the Internet pretty much overnight, and I think that pretending otherwise would be awfully nave. > > > -- > james woodyatt > member of technical staff, communications engineering > > > > > From owner-v6ops@ops.ietf.org Mon Mar 22 06:10:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87493A6B4C for ; Mon, 22 Mar 2010 06:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyV6F7DlAKyx for ; Mon, 22 Mar 2010 06:10:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB32C3A6A34 for ; Mon, 22 Mar 2010 06:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NthKl-000DeA-Fh for v6ops-data0@psg.com; Mon, 22 Mar 2010 13:06:19 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NthKg-000DdX-3U for v6ops@ops.ietf.org; Mon, 22 Mar 2010 13:06:14 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAFMIp0uQ/uCWe2dsb2JhbACbKxUBAQsLJAYcojGXf4R9BIMe X-IronPort-AV: E=Sophos;i="4.51,287,1267401600"; d="scan'208";a="4640116" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 22 Mar 2010 12:32:06 +0000 Received: from ams3-vpn-dhcp4422.cisco.com (ams3-vpn-dhcp4422.cisco.com [10.61.81.69]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MD6BCj002181; Mon, 22 Mar 2010 13:06:11 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 22 Mar 2010 06:07:55 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: [...] >> It doesn't say that CPEs MUST do this. It leaves that choice open, as = an informational document. >=20 > No, it doesn't say that CPE routers MUST do this, but it does go out = of its way to say that CPE routers "should" do this. >=20 > More importantly, other specifications which reference RFC 4864 as if = it's morally equivalent to a proposed standard *do* say that CPE routers = MUST do this. While categorized as Informational, the language in = I-D.ietf-v6ops-cpe-simple-security is deliberately crafted to be easily = cited by other SDO's in requirement specifications, which are expecting = to describe not just the CPE routers MUST do this, but HOW they will do = this. I am aware of at least two other SDO's that are preparing exactly = that. which SDO's are you thinking of? TR-124i2 references the simple security draft but does not make any = recommendation that the functionality must be enabled by default. same = for the basic IPv6 CE router draft. cheers, Ole= From owner-v6ops@ops.ietf.org Mon Mar 22 07:33:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D9B3A688F for ; Mon, 22 Mar 2010 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOEFv+2pOu59 for ; Mon, 22 Mar 2010 07:33:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EC413A6802 for ; Mon, 22 Mar 2010 07:32:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtieC-000OWM-OE for v6ops-data0@psg.com; Mon, 22 Mar 2010 14:30:28 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntie8-000OVz-NI for v6ops@ops.ietf.org; Mon, 22 Mar 2010 14:30:25 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2MESDe0028772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 07:28:14 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2MESDk7010509; Mon, 22 Mar 2010 07:28:13 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2MESDlD010498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Mar 2010 07:28:13 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 22 Mar 2010 07:28:13 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= CC: Fred Baker , IPv6 Operations , Ron Bonica , Kurt Erik Lindqvist Date: Mon, 22 Mar 2010 07:28:11 -0700 Subject: RE: Proposed agenda for IPv6 Operations - IETF 77 Thread-Topic: Proposed agenda for IPv6 Operations - IETF 77 Thread-Index: AcrJILf8Sd4DmktiSnCr5+LNEp6oqQAqoSYg Message-ID: References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Remi, >From what I could tell, even for the NAT44 case you are describing there is still a need for host modifications. Also a need for DHCP server modifications, and a new type of router in provider networks. That makes SAM a new transition technology and a new protocol. Fred fred.l.templin@boeing.com > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Sunday, March 21, 2010 11:03 AM > To: Templin, Fred L > Cc: Fred Baker; IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist > Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 >=20 > Fred, >=20 > On February 19, I wrote on to Fred, with copy to the v6ops list: > <<< > Draft-despres-softwire-sam-00, which I will post in a few days, contains = an updated description of > SAM, the generic Stateless Address Mapping mechanism which applies to a v= ariety of scenarios. >=20 > Among those, one permits ISPs to deliver native IPv6 connectivity across = legacy CPEs that only > support NAT44 with port forwarding. > This solution is like 6rd in that: > - ISPs don't need to change their IPv4 infrastructures > - They only need to operate gateways between these and their IPv6 accesse= s > - These gateways are stateless > It is unlike 6rd in that: > - Legacy CPEs don't need to be upgraded > - To exploit of their IPv6 addresses, hosts have to be upgraded to suppor= t SAM. >=20 > Operation considerations of this scenario are relevant to v6ops. > A time slot for a presentation will be appreciated. > >>> >=20 > Although the agenda of v6ops doesn't specify it, what I will present on f= riday is very far from a > general SAM presentation like the one I asked to have in Softwire, but co= uldn't be scheduled due to > the lack of enough time allocated to Softwire. >=20 > As initially planned, my presentation will be limited to the "Native IPv6= across NAT44s" scenario. >=20 > Regards, > RD >=20 >=20 >=20 > Le 21 mars 2010 =E0 07:02, Templin, Fred L a =E9crit : >=20 > > Fred, > > > > As far as I can tell, the SAM proposal is a new transitional > > technology and protocol also. RANGER and SAM are addressing > > very similar problem spaces, and I think their eligibility > > for inclusion in the v6ops agenda should be considered on > > equal terms. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com] > >> Sent: Saturday, March 20, 2010 10:28 PM > >> To: Templin, Fred L > >> Cc: IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist > >> Subject: Re: Proposed agenda for IPv6 Operations - IETF 77 > >> > >> I have a question on these. > >> > >> Per the abstract of VET, "VET can also be considered as version 2 of t= he Intra-Site Automatic > Tunnel > >> Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with routing= , next hop determination, > and a > >> "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think = this is an operational > >> description. I think this belongs discussed in rrg, rtgarea/rtgwg, or = *maybe* int-area. > >> > >> How about you and I discuss this Monday and you convince me that this = is within the charter of > IPv6 > >> Operations. I think it is that which was explicitly placed outside the= charter - transitional > >> technologies and protocol development. > >> > >> > >> On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote: > >> > >>> Fred, > >>> > >>> The new agenda posted on the webpages does not seem to match the one > >>> you posted to the list: > >>> > >>> http://www.ietf.org/proceedings/10mar/agenda/v6ops.html > >>> > >>> Seeing that there are new additions, I would like to propose to add t= he > >>> RANGER, VET and SEAL trilogy - preferably as the final session on > >>> Friday, as I have two other conflicts for the earlier portion of that= session. > >>> The talk would require 15min, and would cover all three documents > >>> together (i.e., not as three separate talks). The documents are here: > >>> > >>> http://www.ietf.org/rfc/rfc5720.txt > >>> http://tools.ietf.org/html/draft-templin-intarea-vet > >>> http://tools.ietf.org/html/draft-templin-intarea-seal > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On B= ehalf Of Fred Baker > >>> Sent: Tuesday, March 16, 2010 2:06 PM > >>> To: IPv6 Operations > >>> Subject: Proposed agenda for IPv6 Operations - IETF 77 > >>> > >>> Comments please... Basically I am putting three security issues and t= wo 3GPP-relevant drafts on > >> Monday morning and the remainder on Friday morning. Each discussion ge= ts about half an hour. If > time > >> permits in the meeting, I'll pull agenda items forward from Friday to = Monday. I have two drafts on > >> here that were not marked for v6ops but the authors asked me to includ= e; next time I'd appreciate > it > >> if folks used the draft-*-v6ops-* naming convention; it makes my job e= asier. If I have missed > >> anything, let me know. > >>> IPv6 Operations - IETF 77 > >>> > >>> Monday 22 March, 9:00 AM > >>> > >>> Agenda bashing > >>> > >>> Recommended Simple Security Capabilities in Customer Premises Equipme= nt for Providing Residential > >> IPv6 Internet Service > >>> 18-Feb-10, > >>> Advanced Security for IPv6 CPE > >>> 8-Mar-10, > >>> Routing Loops using ISATAP and 6to4: Problem Statement and Proposed S= olutions > >>> 1-Feb-10, > >>> > >>> IPv6 in 3GPP Evolved Packet System > >>> 24-Feb-10, > >>> Mobile Networks Considerations for IPv6 Deployment > >>> 8-Mar-10, > >>> Friday 26 March, 9:00 AM > >>> > >>> Emerging Service Provider Scenarios for IPv6 Deployment > >>> 23-Feb-10, > >>> Unicast Transmission of IPv6 Multicast Messages on Link-layer > >>> 15-Feb-10, > >>> Neighbor Cache Protection in Neighbor Discovery Protocol > >>> 2-Mar-10, > >>> DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks > >>> 16-Feb-10, > >>> Advanced Requirements for IPv6 Customer Edge Routers > >>> 8-Mar-10, > >>> > >>> > >>> http://www.ipinc.net/IPv4.GIF > >>> > >> > >> http://www.ipinc.net/IPv4.GIF > > > > >=20 From owner-v6ops@ops.ietf.org Mon Mar 22 07:33:06 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837D73A688F for ; Mon, 22 Mar 2010 07:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8AltlbPCu-5 for ; Mon, 22 Mar 2010 07:33:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48F043A681F for ; Mon, 22 Mar 2010 07:32:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntick-000OLI-Lf for v6ops-data0@psg.com; Mon, 22 Mar 2010 14:28:58 +0000 Received: from [72.14.220.157] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntich-000OKu-Vi for v6ops@ops.ietf.org; Mon, 22 Mar 2010 14:28:56 +0000 Received: by fg-out-1718.google.com with SMTP id d23so479790fga.17 for ; Mon, 22 Mar 2010 07:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=C1t4jhglYdL3wBK7fUQoNc5LwP4Z78H/ybkoA41pUBg=; b=ppvXrol/ulh8Pc6vPXSi9y69iJm9fhCG9Ov2Zn6dTi2ymFr3Nnn6UyqEVmlRkUO49r t4KmNDA7cNJYPGUZ+eHHOmBRnRff4vXDwAwHSfWlFX9kfPXHnwXfyQlrHH67zHOa7ab3 vwnV/jknpPwal0b/JDpy9FA7A++pb8aSdjaj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pzptFrqZEmgUloJJ3uuzwR/2cNpDRrm+3WSzMnPPBL44rCiiu/lcL4wvpzdVnExVMc FRMzGiVptVMf++TRUzdX4xMJfEcfu/w21kcqVDaJpjhaPOYL1bKihJscuI6Np9U+jqv6 JfhZJY1qRR7Gb0SiUhpKyS35BgOWp+UguUBIY= Received: by 10.87.47.3 with SMTP id z3mr4066029fgj.70.1269268134642; Mon, 22 Mar 2010 07:28:54 -0700 (PDT) Received: from [130.129.27.105] (dhcp-wireless-open-abg-27-105.meeting.ietf.org [130.129.27.105]) by mx.google.com with ESMTPS id 15sm142223fxm.15.2010.03.22.07.28.52 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 07:28:53 -0700 (PDT) Message-ID: <4BA77EA0.1030706@gmail.com> Date: Tue, 23 Mar 2010 03:28:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt CC: IPv6 Operations Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09 References: <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I don't think we should really be doing textual analysis of an informational document, but since you quoted it: On 2010-03-22 18:19, james woodyatt wrote: ... > I would have expected an author of RFC 4864 to quote the following excerpt from Section 4.2 instead: > > To implement simple security for IPv6 in, for example, a DSL or cable > modem-connected home network, the broadband gateway/router should be > equipped with stateful firewall capabilities. These should provide a > default configuration where incoming traffic is limited to return > traffic resulting from outgoing packets (sometimes known as > reflective session state). There should also be an easy interface > that allows users to create inbound 'pinholes' for specific purposes > such as online gaming. Correct, and (given what was already quoted from the abstract) I have always read that paragraph to start implicitly with the words "If you want to... " and understood "simple security" to refer to the preceding text that describes NATs as providing "simple security" via default deny. And that was because we believed that many network managers wanted exactly that and believed that NAT66 was the way to achieve it. So we wanted to document how to achieve the same effect without NAT. Obviously, if you don't want that effect, don't implement draft-ietf-v6ops-cpe-simple-security, or use its REC-41 option. Brian From owner-v6ops@ops.ietf.org Mon Mar 22 08:29:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A8F28C15D for ; Mon, 22 Mar 2010 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anI1gW40fOmD for ; Mon, 22 Mar 2010 08:29:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0208B28C13B for ; Mon, 22 Mar 2010 08:28:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtjVZ-0007b4-B8 for v6ops-data0@psg.com; Mon, 22 Mar 2010 15:25:37 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtjVS-0007aW-QZ for v6ops@ops.ietf.org; Mon, 22 Mar 2010 15:25:31 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACcpp0urR7Hu/2dsb2JhbACbJHOjAJgQhH0E X-IronPort-AV: E=Sophos;i="4.51,287,1267401600"; d="scan'208";a="170308691" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2010 15:25:30 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2MFPU3S023603 for ; Mon, 22 Mar 2010 15:25:30 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2MFPTY19838 for ; Mon, 22 Mar 2010 08:25:29 -0700 (PDT) Message-ID: <4BA78BE7.6010005@cisco.com> Date: Mon, 22 Mar 2010 16:25:27 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: IPv6 v6ops Subject: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: All, I wish I could be in two places at once. This email will have to suffice. A final plea before the IETF meeting slots begin. I think that most of us on this list would agree with, at the very least, the ideal of end-to-end transparency with IP. Many of us are also realists; Realists that lived through the era of the IETF saying no to IPv4 NAT. Some of us may worry that we are part of a minority that will be overwhelmed by market forces demanding an IPv6 firewall function, even if we would rather not see them widely deployed. Never fear, the market force behind an IPv6 firewall is no where near that of the IPv4 NAT. The benefit simply isn't anywhere near as tangible for the average user. The real sales pitch for IPv4 NAT was letting your home have multiple internet-connected PCs for the price of one. This benefit was pitted against end-to-end transparency, and the advantages of the NAT won. It is still unclear to me whether the purported advantages of an IPv6 firewall would outweigh the costs in terms of complexity and transparency, even by the mass residential market. I say this partly because of all of the comments saying that vendors, SDOs, and SPs are looking to the IETF on what to do here. This is an indication that the market has not yet spoken on this, otherwise no one would really care what recommendation we made. It has been a long road, but it is too early to lose our ideals entirely here. Let's not publish a document that recommends, by default, breaking end-to-end transparency. If the market proves us wrong, know that we are not making the same fatal mistake as we did with IPv4 NAT as we are still defining how to create an IPv6 firewall if one so chooses. Given that the current largest residential IPv6 deployment has no firewall in its CPE, and I have heard others say (on this list and elsewhere) that they would much rather not have to develop, deploy, and manage a firewalled connection, we have a real chance here to let the IPv6 Internet grow up without this additional complexity. I could be completely wrong, and the firewalls may certainly go ahead and ship on by default anyway. If so, what will we have lost? Nothing really, as the functionality of the firewall will still be there to be implemented against in a relatively consistent manner. However, at least it will not have been the IETF that shot its own principles down in the process. Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. Thanks for reading this far, and have a good IETF meeting this week. See you on Jabber when I can. - Mark From owner-v6ops@ops.ietf.org Mon Mar 22 08:37:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EE13A6984 for ; Mon, 22 Mar 2010 08:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.3 X-Spam-Level: X-Spam-Status: No, score=-108.3 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOxlkspOswGp for ; Mon, 22 Mar 2010 08:37:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF08C3A691E for ; Mon, 22 Mar 2010 08:37:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntjck-0008dT-Vd for v6ops-data0@psg.com; Mon, 22 Mar 2010 15:33:03 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtjcP-0008aY-En for v6ops@ops.ietf.org; Mon, 22 Mar 2010 15:32:42 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,287,1267401600"; d="scan'208";a="94890962" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2010 15:32:39 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (rtp-vpn3-484.cisco.com [10.82.217.230]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MFWdHQ008056; Mon, 22 Mar 2010 15:32:39 GMT Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BA78BE7.6010005@cisco.com> Date: Mon, 22 Mar 2010 08:32:38 -0700 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: That will have to be a working group decision. We have your opinion on = the record. On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: > Let's err on the side of our ideals here. Publish = draft-ietf-v6ops-cpe-simple-security, but do so without default-deny = rules on by default. Let's not break end-to-end IPv6 before it even has = a chance to grow up. http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Mon Mar 22 09:05:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDEA53A6946 for ; Mon, 22 Mar 2010 09:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.478 X-Spam-Level: X-Spam-Status: No, score=-7.478 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6P5gYvzxTCb for ; Mon, 22 Mar 2010 09:05:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B67103A67D4 for ; Mon, 22 Mar 2010 09:05:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntk4t-000DVf-Bk for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:02:07 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntk4m-000DUU-5u for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:02:00 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,288,1267401600"; d="scan'208";a="217726228" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2010 16:01:59 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MG1xjf029734; Mon, 22 Mar 2010 16:01:59 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2MG1wY21407; Mon, 22 Mar 2010 09:01:58 -0700 (PDT) Message-ID: <4BA79475.3040708@cisco.com> Date: Mon, 22 Mar 2010 17:01:57 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: IPv6 v6ops Subject: Re: On saving end-to-end transparency References: <4BA78BE7.6010005@cisco.com> 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 List-ID: On 3/22/10 4:32 PM, Fred Baker wrote: > That will have to be a working group decision. We have your opinion on the record. > I'm looking for nothing more and nothing less. - Mark > On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: > > >> Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. >> > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Mon Mar 22 09:11:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B2F3A6886 for ; Mon, 22 Mar 2010 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.333 X-Spam-Level: X-Spam-Status: No, score=-101.333 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8trQt3D9UBBW for ; Mon, 22 Mar 2010 09:11:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A45BC3A695D for ; Mon, 22 Mar 2010 09:11:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkBu-000Ee9-Ch for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:09:22 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkBm-000Ece-Mb for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:09:15 +0000 Received: (qmail 89971 invoked by uid 1007); 22 Mar 2010 17:09:11 +0100 Date: Mon, 22 Mar 2010 17:09:11 +0100 From: Gert Doering To: Fred Baker Cc: Mark Townsley , IPv6 v6ops Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) Message-ID: <20100322160911.GU69383@Space.Net> References: <4BA78BE7.6010005@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: > That will have to be a working group decision. We have your opinion on the record. > > On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: > > > Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. Add another opinion to that. - have firewalling in there - default to "end-to-end communication permitted" Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Mar 22 09:19:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E791F28C11F for ; Mon, 22 Mar 2010 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.764 X-Spam-Level: X-Spam-Status: No, score=-8.764 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt2qevodmGde for ; Mon, 22 Mar 2010 09:19:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB67A28C103 for ; Mon, 22 Mar 2010 09:19:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkHH-000Ffg-Ia for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:14:55 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkHD-000Fer-DG for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:14:51 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANo0p0tAZnwM/2dsb2JhbACbJHOjVpgZhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,288,1267401600"; d="scan'208";a="95042156" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2010 16:14:50 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MGEnn1024343; Mon, 22 Mar 2010 16:14:50 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 11:14:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 5006 status Date: Mon, 22 Mar 2010 11:14:47 -0500 Message-ID: In-Reply-To: <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrF5meRx814ysdKSvKGuW9xf8Ku1QD84Cnw References: <4B9DFC7D.3070704@piuha.net> <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "IPv6 Operations" Cc: "Lindqvist Kurt Erik" , "Ralph Droms (rdroms)" , "6man Chairs" <6man-chairs@tools.ietf.org>, "Dave Thaler" , "Jari Arkko" , , , , "Daniel Park" X-OriginalArrivalTime: 22 Mar 2010 16:14:49.0742 (UTC) FILETIME=[CC145AE0:01CAC9DA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Here is my input. I do not support moving this document to Standards Track. =20 Folks have already asked what if DHCPv6 is also deployed in the IPv6 network and if both ND and DHCPv6 send DNS options who wins? For side note, please note, routers tend to be deployed with load balancing and also one may have more than one default router in the network. What if DNS configuration is fat-fingered on one router but not the other.=20 Hemant From owner-v6ops@ops.ietf.org Mon Mar 22 09:26:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC433A68C8 for ; Mon, 22 Mar 2010 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.024 X-Spam-Level: * X-Spam-Status: No, score=1.024 tagged_above=-999 required=5 tests=[AWL=-2.211, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOcDZsqpWTDT for ; Mon, 22 Mar 2010 09:26:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD5E53A69DF for ; Mon, 22 Mar 2010 09:26:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkRC-000HIG-B4 for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:25:10 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkR9-000HH0-7s for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:25:07 +0000 Received: by gyc15 with SMTP id 15so2873968gyc.11 for ; Mon, 22 Mar 2010 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zE+llcaQt3mcXm8XyuRRfi6zo3yAhwnTG3ZCmUr8HtI=; b=fwwlMmCmzALJIcQrPASuFyWL34Hs2xPIyJCNuJreHi9bINUVkiubngZe4DNAw+wpnT xIxrvTJNd4V8Eeu5ZEymZ6lE2G0jeKsGHlizbxZ9uNITDCshWhcQl87sCA+4stVZaDYw PbmNza9NAWvedbd6RZxz8t4JP0xERjc+unnlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dk8EeFAz/KV0RR7dEvijY/pxmF0OinfNfs2IHqVWO3F3GL5hqoAco4JBXjDaDLO7dM 4h/tMXE4g03BW7kCWo3AK4hJAh5ntDIpG19672H9ZibMAZAvzPipEEE/VcVYOE+o8iEw i+KdiAgGOT+hA3XzO+2jYaGvf2WfvjNIA5wqY= MIME-Version: 1.0 Received: by 10.150.213.21 with SMTP id l21mr11569127ybg.166.1269275106410; Mon, 22 Mar 2010 09:25:06 -0700 (PDT) In-Reply-To: <4BA78BE7.6010005@cisco.com> References: <4BA78BE7.6010005@cisco.com> Date: Mon, 22 Mar 2010 09:25:06 -0700 Message-ID: Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) From: Cameron Byrne To: Mark Townsley Cc: IPv6 v6ops Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, Mar 22, 2010 at 8:25 AM, Mark Townsley wrote: > > All, > > I wish I could be in two places at once. This email will have to suffice. > > A final plea before the IETF meeting slots begin. > > I think that most of us on this list would agree with, at the very least, > the ideal of end-to-end transparency with IP. Many of us are also realists; > Realists that lived through the era of the IETF saying no to IPv4 NAT. Some > of us may worry that we are part of a minority that will be overwhelmed by > market forces demanding an IPv6 firewall function, even if we would rather > not see them widely deployed. > > Never fear, the market force behind an IPv6 firewall is no where near that > of the IPv4 NAT. The benefit simply isn't anywhere near as tangible for the > average user. The real sales pitch for IPv4 NAT was letting your home have > multiple internet-connected PCs for the price of one. This benefit was > pitted against end-to-end transparency, and the advantages of the NAT won. > It is still unclear to me whether the purported advantages of an IPv6 > firewall would outweigh the costs in terms of complexity and transparency, > even by the mass residential market. I say this partly because of all of the > comments saying that vendors, SDOs, and SPs are looking to the IETF on what > to do here. This is an indication that the market has not yet spoken on > this, otherwise no one would really care what recommendation we made. > > It has been a long road, but it is too early to lose our ideals entirely > here. Let's not publish a document that recommends, by default, breaking > end-to-end transparency. If the market proves us wrong, know that we are not > making the same fatal mistake as we did with IPv4 NAT as we are still > defining how to create an IPv6 firewall if one so chooses. > > Given that the current largest residential IPv6 deployment has no firewall > in its CPE, and I have heard others say (on this list and elsewhere) that > they would much rather not have to develop, deploy, and manage a firewalled > connection, we have a real chance here to let the IPv6 Internet grow up > without this additional complexity. I could be completely wrong, and the > firewalls may certainly go ahead and ship on by default anyway. If so, what > will we have lost? Nothing really, as the functionality of the firewall will > still be there to be implemented against in a relatively consistent manner. > However, at least it will not have been the IETF that shot its own > principles down in the process. > > Let's err on the side of our ideals here. Publish > draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules > on by default. Let's not break end-to-end IPv6 before it even has a chance > to grow up. +1. Hosts OSs have matured a lot in the last 10 years, we don't need appliances to protect / handicap them. E2E says put the intelligence in the host, not the network / CPE. Cameron > > Thanks for reading this far, and have a good IETF meeting this week. See you > on Jabber when I can. > > - Mark > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Mar 22 09:29:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585733A6ADD for ; Mon, 22 Mar 2010 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.347 X-Spam-Level: X-Spam-Status: No, score=-101.347 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2l5Be4C3Jd3 for ; Mon, 22 Mar 2010 09:29:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51B1E3A69AA for ; Mon, 22 Mar 2010 09:29:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkTy-000HlB-Gu for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:28:02 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtkTv-000HkM-PC for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:28:00 +0000 Received: (qmail 92936 invoked by uid 1007); 22 Mar 2010 17:27:57 +0100 Date: Mon, 22 Mar 2010 17:27:57 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Cc: "Fred Baker \(fred\)" , IPv6 Operations , Lindqvist Kurt Erik , "Ralph Droms \(rdroms\)" , 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler , Jari Arkko , jjeong@cs.umn.edu, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com, Daniel Park Subject: Re: RFC 5006 status Message-ID: <20100322162757.GV69383@Space.Net> References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Mar 22, 2010 at 11:14:47AM -0500, Hemant Singh (shemant) wrote: > What if > DNS configuration is fat-fingered on one router but not the other. "Things will break if configured wrongly" is a funny argument to me. Regarding the original question, I'd expect client devices to merge multiple different DNS servers into a list, and use that. Ordered by priorities. Clients need to merge DNS server addresses from various sources anyway - there's still v4 around, and for the next 5 years, I expect people to use DNS over IPv4 *and* IPv6. So admins might want to see a v4 and a v6 resolver in their clients' "/etc/resolv.conf"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Mar 22 09:50:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6BE3A69C2 for ; Mon, 22 Mar 2010 09:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.235 X-Spam-Level: *** X-Spam-Status: No, score=3.235 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TS5kGd43ECs for ; Mon, 22 Mar 2010 09:50:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B92363A681C for ; Mon, 22 Mar 2010 09:50:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntkmu-000L8q-6b for v6ops-data0@psg.com; Mon, 22 Mar 2010 16:47:36 +0000 Received: from [206.16.17.220] (helo=usaga03-in.huawei.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntkmp-000L8C-Q7 for v6ops@ops.ietf.org; Mon, 22 Mar 2010 16:47:31 +0000 Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZO007CEZZ58L@usaga03-in.huawei.com> for v6ops@ops.ietf.org; Mon, 22 Mar 2010 11:47:30 -0500 (CDT) Received: from [130.129.25.109] (dhcp-wireless-open-abg-25-109.meeting.ietf.org [130.129.25.109]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZO0030PZZ5RO@usaga03-in.huawei.com> for v6ops@ops.ietf.org; Mon, 22 Mar 2010 11:47:29 -0500 (CDT) Date: Tue, 23 Mar 2010 00:47:28 +0800 From: Sheng Jiang Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) In-reply-to: To: Cameron Byrne Cc: Mark Townsley , IPv6 v6ops Message-id: <4BA79F20.5010502@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 References: <4BA78BE7.6010005@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: +1, too. Network may increase its intelligence as it wants. It will benefit the world. However, e2e transparency is still one of the most important features for internet infrastructure. Efforts on the network side should try the best to maintain it. Sheng 于 2010/3/23 0:25, Cameron Byrne 写道: > On Mon, Mar 22, 2010 at 8:25 AM, Mark Townsley wrote: >> >> All, >> >> I wish I could be in two places at once. This email will have to suffice. >> >> A final plea before the IETF meeting slots begin. >> >> I think that most of us on this list would agree with, at the very least, >> the ideal of end-to-end transparency with IP. Many of us are also realists; >> Realists that lived through the era of the IETF saying no to IPv4 NAT. Some >> of us may worry that we are part of a minority that will be overwhelmed by >> market forces demanding an IPv6 firewall function, even if we would rather >> not see them widely deployed. >> >> Never fear, the market force behind an IPv6 firewall is no where near that >> of the IPv4 NAT. The benefit simply isn't anywhere near as tangible for the >> average user. The real sales pitch for IPv4 NAT was letting your home have >> multiple internet-connected PCs for the price of one. This benefit was >> pitted against end-to-end transparency, and the advantages of the NAT won. >> It is still unclear to me whether the purported advantages of an IPv6 >> firewall would outweigh the costs in terms of complexity and transparency, >> even by the mass residential market. I say this partly because of all of the >> comments saying that vendors, SDOs, and SPs are looking to the IETF on what >> to do here. This is an indication that the market has not yet spoken on >> this, otherwise no one would really care what recommendation we made. >> >> It has been a long road, but it is too early to lose our ideals entirely >> here. Let's not publish a document that recommends, by default, breaking >> end-to-end transparency. If the market proves us wrong, know that we are not >> making the same fatal mistake as we did with IPv4 NAT as we are still >> defining how to create an IPv6 firewall if one so chooses. >> >> Given that the current largest residential IPv6 deployment has no firewall >> in its CPE, and I have heard others say (on this list and elsewhere) that >> they would much rather not have to develop, deploy, and manage a firewalled >> connection, we have a real chance here to let the IPv6 Internet grow up >> without this additional complexity. I could be completely wrong, and the >> firewalls may certainly go ahead and ship on by default anyway. If so, what >> will we have lost? Nothing really, as the functionality of the firewall will >> still be there to be implemented against in a relatively consistent manner. >> However, at least it will not have been the IETF that shot its own >> principles down in the process. >> >> Let's err on the side of our ideals here. Publish >> draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules >> on by default. Let's not break end-to-end IPv6 before it even has a chance >> to grow up. > > +1. Hosts OSs have matured a lot in the last 10 years, we don't need > appliances to protect / handicap them. E2E says put the intelligence > in the host, not the network / CPE. > > Cameron > >> >> Thanks for reading this far, and have a good IETF meeting this week. See you >> on Jabber when I can. >> >> - Mark >> >> >> >> >> >> >> >> >> >> >> >> > > From owner-v6ops@ops.ietf.org Mon Mar 22 11:01:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A623A69DF for ; Mon, 22 Mar 2010 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.589 X-Spam-Level: **** X-Spam-Status: No, score=4.589 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-3Rdtz6S2WN for ; Mon, 22 Mar 2010 11:01:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9194A3A69C7 for ; Mon, 22 Mar 2010 11:01:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntlsg-000590-Fe for v6ops-data0@psg.com; Mon, 22 Mar 2010 17:57:38 +0000 Received: from [66.15.163.216] (helo=smtp.tndh.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntlsd-00058k-H9 for v6ops@ops.ietf.org; Mon, 22 Mar 2010 17:57:35 +0000 Received: from server.tndh.net ([192.168.123.10] helo=eagle) by smtp.tndh.net with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NtlrL-0003KA-5C for v6ops@ops.ietf.org; Mon, 22 Mar 2010 10:56:19 -0700 Reply-To: From: "Tony Hain" To: "'IPv6 Operations'" References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> In-Reply-To: <20100322162757.GV69383@Space.Net> Subject: RE: RFC 5006 status Date: Mon, 22 Mar 2010 10:56:13 -0700 Message-ID: <01a001cac9e8$f703fdb0$e50bf910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJ3QRDSAOvWS8WSdy7z71+5750pAACju4g Content-Language: en-us Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This document needs to be standards track. There is no 'competition' between auto-conf vs. dhcp, they serve different communities and need to stand alone. The historic error in the IETF process was to require both stateful and stateless to have any network operate. Each approach really need to stand alone and be fully functional without dependency on the other. The missing link on the auto-conf side is 5006, and it needs to be standards track asap. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Gert Doering > Sent: Monday, March 22, 2010 9:28 AM > To: Hemant Singh (shemant) > Cc: Fred Baker (fred); IPv6 Operations; Lindqvist Kurt Erik; Ralph > Droms (rdroms); 6man Chairs; Dave Thaler; Jari Arkko; > jjeong@cs.umn.edu; luc.beloeil@orange-ftgroup.com; > smadanapalli@gmail.com; Daniel Park > Subject: Re: RFC 5006 status > > Hi, > > On Mon, Mar 22, 2010 at 11:14:47AM -0500, Hemant Singh (shemant) wrote: > > What if > > DNS configuration is fat-fingered on one router but not the other. > > "Things will break if configured wrongly" is a funny argument to me. > > > Regarding the original question, I'd expect client devices to merge > multiple different DNS servers into a list, and use that. Ordered by > priorities. Clients need to merge DNS server addresses from various > sources anyway - there's still v4 around, and for the next 5 years, > I expect people to use DNS over IPv4 *and* IPv6. So admins might want > to see a v4 and a v6 resolver in their clients' "/etc/resolv.conf"... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Mar 22 11:05:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0ABD3A68B6 for ; Mon, 22 Mar 2010 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltWVsWJ0ffa for ; Mon, 22 Mar 2010 11:05:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A46643A6822 for ; Mon, 22 Mar 2010 11:05:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntlzg-0006M9-EF for v6ops-data0@psg.com; Mon, 22 Mar 2010 18:04:52 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntlzd-0006Li-QJ for v6ops@ops.ietf.org; Mon, 22 Mar 2010 18:04:50 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIBAKNOp0uQ/uCWe2dsb2JhbACbJBUBAQsLJAYcpCOYK4R9BIMe X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208";a="4653906" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 22 Mar 2010 17:30:37 +0000 Received: from sjc-vpn3-1190.cisco.com (sjc-vpn3-1190.cisco.com [10.21.68.166]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MI4hLd019335; Mon, 22 Mar 2010 18:04:43 GMT Subject: Re: RFC 5006 status Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <01a001cac9e8$f703fdb0$e50bf910$@net> Date: Mon, 22 Mar 2010 11:06:25 -0700 Cc: "'IPv6 Operations'" Content-Transfer-Encoding: quoted-printable Message-Id: <41EC3C33-36EE-48C9-9617-404F0A7847F9@cisco.com> References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> To: X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Tony, > This document needs to be standards track. There is no 'competition' = between > auto-conf vs. dhcp, they serve different communities and need to stand > alone. The historic error in the IETF process was to require both = stateful > and stateless to have any network operate. Each approach really need = to > stand alone and be fully functional without dependency on the other. = The > missing link on the auto-conf side is 5006, and it needs to be = standards > track asap. if that's your argument, why shouldn't every DHCP option be possible to = encode in an ND message? is DNS _that_ special? cheers, Ole= From owner-v6ops@ops.ietf.org Mon Mar 22 11:34:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC0B3A6986 for ; Mon, 22 Mar 2010 11:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz506uXGk6CY for ; Mon, 22 Mar 2010 11:34:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F92C3A659A for ; Mon, 22 Mar 2010 11:34:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtmPh-0009cs-VL for v6ops-data0@psg.com; Mon, 22 Mar 2010 18:31:46 +0000 Received: from [171.67.219.81] (helo=smtp.stanford.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtmPO-0009bM-Vh for v6ops@ops.ietf.org; Mon, 22 Mar 2010 18:31:27 +0000 Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 540A51782FA; Mon, 22 Mar 2010 11:31:26 -0700 (PDT) Received: from networking.stanford.edu (networking.Stanford.EDU [171.64.20.23]) by smtp.stanford.edu (Postfix) with ESMTP id 2BD3D178174; Mon, 22 Mar 2010 11:31:25 -0700 (PDT) Received: from networking.stanford.edu (localhost.localdomain [127.0.0.1]) by networking.stanford.edu (Postfix) with SMTP id 9E8CDE7C0C5; Mon, 22 Mar 2010 11:31:24 -0700 (PDT) Received: by networking.stanford.edu (Postfix, from userid 9759) id 5F856E7C0D0; Mon, 22 Mar 2010 11:31:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by networking.stanford.edu (Postfix) with ESMTP id 4EFF5E7C0C5; Mon, 22 Mar 2010 11:31:24 -0700 (PDT) Date: Mon, 22 Mar 2010 11:31:24 -0700 (PDT) From: Lea Roberts X-X-Sender: rgr@networking.stanford.edu To: Ole Troan cc: 'IPv6 Operations' Subject: Re: RFC 5006 status In-Reply-To: <41EC3C33-36EE-48C9-9617-404F0A7847F9@cisco.com> Message-ID: References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> <41EC3C33-36EE-48C9-9617-404F0A7847F9@cisco.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 22 Mar 2010, Ole Troan wrote: >> This document needs to be standards track. There is no 'competition' between >> auto-conf vs. dhcp, they serve different communities and need to stand >> alone. The historic error in the IETF process was to require both stateful >> and stateless to have any network operate. Each approach really need to >> stand alone and be fully functional without dependency on the other. The >> missing link on the auto-conf side is 5006, and it needs to be standards >> track asap. > > if that's your argument, why shouldn't every DHCP option be possible to encode in an ND message? > is DNS _that_ special? I believe DNS is _that_ special! :-) in all the various IPv6-only adventures in which I've participated (Internet2 Joint Techs, NANOG and ARIN), auto-conf works great but the network usefulness is rather limited without a DNS server. /Lea From owner-v6ops@ops.ietf.org Mon Mar 22 11:43:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3048B3A6945 for ; Mon, 22 Mar 2010 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9IvECTkUHVB for ; Mon, 22 Mar 2010 11:43:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 408623A682E for ; Mon, 22 Mar 2010 11:43:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtmaJ-000B2V-I9 for v6ops-data0@psg.com; Mon, 22 Mar 2010 18:42:43 +0000 Received: from [216.82.253.115] (helo=mail161.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtmaD-000B1V-TC for v6ops@ops.ietf.org; Mon, 22 Mar 2010 18:42:38 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-10.tower-161.messagelabs.com!1269283355!22629321!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6333 invoked from network); 22 Mar 2010 18:42:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Mar 2010 18:42:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2MIgNwT013814; Mon, 22 Mar 2010 14:42:24 -0400 Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2MIgI5X013711; Mon, 22 Mar 2010 14:42:18 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 14:42:29 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 14:42:30 -0400 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: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) Date: Mon, 22 Mar 2010 14:41:45 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F123E068F@crexc50p> In-Reply-To: <4BA78BE7.6010005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) Thread-Index: AcrJ1q36wZny8/d2S4OdxmlxL6WN0gAFkTuw References: <4BA78BE7.6010005@cisco.com> From: "STARK, BARBARA H (ATTLABS)" To: "Mark Townsley" , "IPv6 v6ops" X-OriginalArrivalTime: 22 Mar 2010 18:42:30.0033 (UTC) FILETIME=[6D397810:01CAC9EF] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The real decision, IMO, is whether the IETF intends to provide an RFC that describes *how* to do the reflective session state firewall thing that is described in RFC 4864 Section 4.2. There really just needs to be a decision, one way or another. - If no, that's fine. But make that decision! And understand the consequences: Other SDOs/documents that are referencing simple-security will revert to a RFC 4864 Section 4.2 reference; the reflective session state firewall will be widely implemented, but there will be little to no consistency among those implementations. - If yes, that's great. But make that decision, and move forward! And don't try to play some sort of bait and switch game, like keep the simple-security name but change it from describing a reflective session state firewall to describing something else (like rate limiting). If the IETF doesn't want to describe how to do reflective session state firewalls, then kill simple-security and use a different name for describing something different -- like easy-security. The default discussion is irrelevant. Simple-security is being seen as a how-to guide for doing a reflective session state IPv6 firewall. Implementers will decide for themselves whether they want it on or off, by default. So, please, decide! Either let simple-security go forward, as a how-to for a reflective session state IPv6 firewall (and nothing else), or kill it. Barbara From owner-v6ops@ops.ietf.org Mon Mar 22 12:42:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783C63A67F0 for ; Mon, 22 Mar 2010 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.474 X-Spam-Level: X-Spam-Status: No, score=-7.474 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCMhXtTj-SE3 for ; Mon, 22 Mar 2010 12:42:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C22833A688C for ; Mon, 22 Mar 2010 12:42:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtnS4-000Hhj-IC for v6ops-data0@psg.com; Mon, 22 Mar 2010 19:38:16 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtnS1-000HhO-OH for v6ops@ops.ietf.org; Mon, 22 Mar 2010 19:38:13 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNkp0urRN+K/2dsb2JhbACbJXOkRJhChH0E X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208";a="500889415" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2010 19:38:13 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2MJcDsD012591; Mon, 22 Mar 2010 19:38:13 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2MJcBY24983; Mon, 22 Mar 2010 12:38:12 -0700 (PDT) Message-ID: <4BA7C722.4030908@cisco.com> Date: Mon, 22 Mar 2010 20:38:10 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "STARK, BARBARA H (ATTLABS)" CC: IPv6 v6ops Subject: Re: On saving end-to-end transparency References: <4BA78BE7.6010005@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F123E068F@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F123E068F@crexc50p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For my part, I have no problem with a group of people defining how to build some rendition of an IPv6 firewall, as long as the reader understands that it is some sort of "best guess" between what IPv6 was designed to be and what IPv4 has become to be. What I do have a problem with is the IETF making a recommendation that residential IPv6 users should sit behind such a firewall by default. Despite anyone's interpretation of it, RFC 4864 was not intended to make this kind of proclamation (I think Brian has made that substantially clear of late). And, above all, that's what I am trying to clear up. Both for the simple-security draft, and RFC 4864. - Mark On 3/22/10 7:41 PM, STARK, BARBARA H (ATTLABS) wrote: > The real decision, IMO, is whether the IETF intends to provide an RFC > that describes *how* to do the reflective session state firewall thing > that is described in RFC 4864 Section 4.2. There really just needs to be > a decision, one way or another. > > - If no, that's fine. But make that decision! And understand the > consequences: Other SDOs/documents that are referencing simple-security > will revert to a RFC 4864 Section 4.2 reference; the reflective session > state firewall will be widely implemented, but there will be little to > no consistency among those implementations. > > - If yes, that's great. But make that decision, and move forward! And > don't try to play some sort of bait and switch game, like keep the > simple-security name but change it from describing a reflective session > state firewall to describing something else (like rate limiting). If the > IETF doesn't want to describe how to do reflective session state > firewalls, then kill simple-security and use a different name for > describing something different -- like easy-security. > > The default discussion is irrelevant. Simple-security is being seen as a > how-to guide for doing a reflective session state IPv6 firewall. > Implementers will decide for themselves whether they want it on or off, > by default. > > So, please, decide! Either let simple-security go forward, as a how-to > for a reflective session state IPv6 firewall (and nothing else), or kill > it. > Barbara > > From v6ops-archive@megatron.ietf.org Mon Mar 22 13:24:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FDF3A6A3B for ; Mon, 22 Mar 2010 13:24:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 22 Mar 2010 13:24:48 -0700 (PDT) Received: from ahss.org (unknown [201.229.177.108]) by core3.amsl.com (Postfix) with SMTP id 177633A6A18 for ; Mon, 22 Mar 2010 13:24:39 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 78% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100322202440.177633A6A18@core3.amsl.com> Date: Mon, 22 Mar 2010 13:24:39 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 13245 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 22 13:55:01 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2C93A67E1 for ; Mon, 22 Mar 2010 13:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.564 X-Spam-Level: X-Spam-Status: No, score=-8.564 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2vCWKcam8AE for ; Mon, 22 Mar 2010 13:55:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12D533A680C for ; Mon, 22 Mar 2010 13:54:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtoZT-0000XY-Uh for v6ops-data0@psg.com; Mon, 22 Mar 2010 20:49:59 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtoZR-0000XJ-Ji for v6ops@ops.ietf.org; Mon, 22 Mar 2010 20:49:57 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE51p0tAZnwM/2dsb2JhbACbJ3OkKJhMhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208";a="95125032" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2010 20:49:56 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MKnuSh024508; Mon, 22 Mar 2010 20:49:56 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 15:49:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 5006 status Date: Mon, 22 Mar 2010 15:49:54 -0500 Message-ID: In-Reply-To: <01a001cac9e8$f703fdb0$e50bf910$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrJ3QRDSAOvWS8WSdy7z71+5750pAACju4gAAYuEQA= References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> From: "Hemant Singh (shemant)" To: , "IPv6 Operations" X-OriginalArrivalTime: 22 Mar 2010 20:49:55.0160 (UTC) FILETIME=[3A134580:01CACA01] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: If DHCPv6 and ND do not work together in the deployment, I hear ya, Tony. However where is text of "use one at a time" in any RFC to warn users? Further, then see my text about multiple default routers in the network. The more than one default router case is same as when DHCPv6 and ND run in the same network. What does one do there? I am also replying to Gert here. The simple problem is that what if a host queries two DNS servers and gets back two different responses - which one does the client use? RFC5006 has further inertia towards becoming a standard because now DNS64 is coming about and we have one more systems one will screw up. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tony Hain Sent: Monday, March 22, 2010 10:56 AM To: 'IPv6 Operations' Subject: RE: RFC 5006 status This document needs to be standards track. There is no 'competition' between auto-conf vs. dhcp, they serve different communities and need to stand alone. The historic error in the IETF process was to require both stateful and stateless to have any network operate. Each approach really need to stand alone and be fully functional without dependency on the other. The missing link on the auto-conf side is 5006, and it needs to be standards track asap. Tony From owner-v6ops@ops.ietf.org Mon Mar 22 14:45:36 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E583A3A6813 for ; Mon, 22 Mar 2010 14:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMf6dFOYqyR0 for ; Mon, 22 Mar 2010 14:45:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EB0A3A680C for ; Mon, 22 Mar 2010 14:45:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtpPc-0005xk-Jd for v6ops-data0@psg.com; Mon, 22 Mar 2010 21:43:52 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtpPZ-0005xO-SX for v6ops@ops.ietf.org; Mon, 22 Mar 2010 21:43:50 +0000 Received: (qmail 17384 invoked by uid 1007); 22 Mar 2010 22:43:43 +0100 Date: Mon, 22 Mar 2010 22:43:43 +0100 From: Gert Doering To: "Hemant Singh \(shemant\)" Cc: alh-ietf@tndh.net, IPv6 Operations Subject: Re: RFC 5006 status Message-ID: <20100322214343.GY69383@Space.Net> References: <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Mar 22, 2010 at 03:49:54PM -0500, Hemant Singh (shemant) wrote: > The simple problem is that what if a host queries two DNS servers and > gets back two different responses - which one does the client use? Typically, hosts don't do that today. They query the first DNS recursor in their list (=priority) and if that one is too slow, they will go and query the next one. But in any case, if a network admin announces the addresses of two different DNS resolvers that return *different* answers (and only one of them is working), well, I'd consider that configuration broken by human error. > RFC5006 has further inertia towards becoming a > standard because now DNS64 is coming about and we have one more systems > one will screw up. What does a specific DNS translation technology have anything to do with the method that we use to tell the clients which DNS recursor to use? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Mon Mar 22 16:38:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DFE3A686A for ; Mon, 22 Mar 2010 16:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSeH9R1Kt8uf for ; Mon, 22 Mar 2010 16:38:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37CE23A6861 for ; Mon, 22 Mar 2010 16:38:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntr8v-000HMX-0o for v6ops-data0@psg.com; Mon, 22 Mar 2010 23:34:45 +0000 Received: from [209.85.222.187] (helo=mail-pz0-f187.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ntr8t-000HMK-7G for v6ops@ops.ietf.org; Mon, 22 Mar 2010 23:34:43 +0000 Received: by pzk17 with SMTP id 17so6806pzk.5 for ; Mon, 22 Mar 2010 16:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1prW4psRVtuWucoFIeWbJaH6yi+NkxsTQuMi9/nE1fA=; b=PxWvL08Y3LEm6k67a0utTwUq1vWDN+ab0No9E5zmqo88EfNU8EzHVHsGgg4bYm3oee BM/MdemfN/kTq3nHNbrE6GbhmWVO53K5PBlQCisW0MLhDyq+gPQYCySLPkNIEswj7liY JNoD9nFPcwgmMimpu7Jepz+LAhtDYPA+5uj1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=irxgH48AwiRU+IUz1efezzpWVU7IfWYvbp3ajHTCe0Yl5dOdRmFQR0yEgfDYKD0zBF 88LFz0C9cukkxjYPFjlFkUq3DHZrgnfK+E41hHWk4QC2eSejWitVOQUco1JmyUbBNSQf g/DawwiUngmxleol97wQB2NvBqexmvsVzsjWg= Received: by 10.115.26.4 with SMTP id d4mr1748105waj.116.1269300882729; Mon, 22 Mar 2010 16:34:42 -0700 (PDT) Received: from [130.129.27.105] (dhcp-wireless-open-abg-27-105.meeting.ietf.org [130.129.27.105]) by mx.google.com with ESMTPS id 20sm1333463pzk.15.2010.03.22.16.34.41 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 16:34:41 -0700 (PDT) Message-ID: <4BA7FE90.1090006@gmail.com> Date: Tue, 23 Mar 2010 12:34:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" CC: alh-ietf@tndh.net, IPv6 Operations Subject: Re: RFC 5006 status References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-03-23 09:49, Hemant Singh (shemant) wrote: > If DHCPv6 and ND do not work together in the deployment, I hear ya, > Tony. However where is text of "use one at a time" in any RFC to warn > users? Further, then see my text about multiple default routers in the > network. The more than one default router case is same as when DHCPv6 > and ND run in the same network. What does one do there? I am also > replying to Gert here. The simple problem is that what if a host > queries two DNS servers and gets back two different responses - which > one does the client use? RFC5006 has further inertia towards becoming a > standard because now DNS64 is coming about and we have one more systems > one will screw up. I really think you are worrying about things that won't happen in a simple unmanaged network where only SLAAC is used. In a managed network, surely we can assume consistent management, and fairly rapid action when inconsistency arises. We can't design solutions that are 100% immune to fat fingers. Brian From w4@megatron.ietf.org Mon Mar 22 16:56:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494D83A68AE for ; Mon, 22 Mar 2010 16:56:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 22 Mar 2010 16:56:22 -0700 (PDT) Received: from agedwards.com (unknown [148.233.150.147]) by core3.amsl.com (Postfix) with SMTP id EF7CB3A690C for ; Mon, 22 Mar 2010 16:56:11 -0700 (PDT) From: Approved VIAGRA® Store Subject: Electronic Discount Code 70% for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100322235615.EF7CB3A690C@core3.amsl.com> Date: Mon, 22 Mar 2010 16:56:11 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 64897 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 22 20:14:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029493A69E6 for ; Mon, 22 Mar 2010 20:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-dV7NszTOMk for ; Mon, 22 Mar 2010 20:14:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA36F3A69DA for ; Mon, 22 Mar 2010 20:14:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtuUx-000Auy-LD for v6ops-data0@psg.com; Tue, 23 Mar 2010 03:09:43 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NtuUu-000AuP-QN for v6ops@ops.ietf.org; Tue, 23 Mar 2010 03:09:41 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF/Op0utJV2d/2dsb2JhbACDC5c4ZnOjZYgxkEKBLIJnagSDHg X-IronPort-AV: E=Sophos;i="4.51,292,1267401600"; d="scan'208";a="95193999" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 23 Mar 2010 03:09:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o2N39cTF011348; Tue, 23 Mar 2010 03:09:38 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 22:09:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Bbry B06v J01V KC1p MJ2v NDBm Oddi OeI8 QjIf SW7l S7tk a4hn bcYE fzG4 f+G1 irPr;3;YQBsAGgALQBpAGUAdABmAEAAdABuAGQAaAAuAG4AZQB0ADsAYgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwB2ADYAbwBwAHMAQABvAHAAcwAuAGkAZQB0AGYALgBvAHIAZwA=;Sosha1_v1;7;{08FE1257-DD6C-4E2F-9597-466AB93099C9};cwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA==;Tue, 23 Mar 2010 03:08:36 GMT;UgBFADoAIABSAEYAQwAgADUAMAAwADYAIABzAHQAYQB0AHUAcwA= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-cr-puzzleid: {08FE1257-DD6C-4E2F-9597-466AB93099C9} Content-class: urn:content-classes:message Subject: RE: RFC 5006 status Date: Mon, 22 Mar 2010 22:08:36 -0500 Message-ID: In-Reply-To: <4BA7FE90.1090006@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5006 status Thread-Index: AcrKGE2rrGZkzc9hRFiAgsjqp+D6yAAG18+g References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> <4BA7FE90.1090006@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" Cc: , "IPv6 Operations" X-OriginalArrivalTime: 23 Mar 2010 03:09:38.0489 (UTC) FILETIME=[45FF6290:01CACA36] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21h aWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KPlNlbnQ6IE1vbmRheSwgTWFyY2gg MjIsIDIwMTAgNDozNSBQTQ0KPlRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQo+Q2M6IGFsaC1p ZXRmQHRuZGgubmV0OyBJUHY2IE9wZXJhdGlvbnMNCj5TdWJqZWN0OiBSZTogUkZDIDUwMDYgc3Rh dHVzDQoNCj5JIHJlYWxseSB0aGluayB5b3UgYXJlIHdvcnJ5aW5nIGFib3V0IHRoaW5ncyB0aGF0 IHdvbid0IGhhcHBlbiBpbiBhIHNpbXBsZQ0KPnVubWFuYWdlZCBuZXR3b3JrIHdoZXJlIG9ubHkg U0xBQUMgaXMgdXNlZC4NCg0KPkluIGEgbWFuYWdlZCBuZXR3b3JrLCBzdXJlbHkgd2UgY2FuIGFz c3VtZSBjb25zaXN0ZW50IG1hbmFnZW1lbnQsDQo+YW5kIGZhaXJseSByYXBpZCBhY3Rpb24gd2hl biBpbmNvbnNpc3RlbmN5IGFyaXNlcy4gV2UgY2FuJ3QgZGVzaWduDQo+c29sdXRpb25zIHRoYXQg YXJlIDEwMCUgaW1tdW5lIHRvIGZhdCBmaW5nZXJzLg0KDQpGYXQtZmluZ2VyaW5nIGNvbmZpZ3Vy YXRpb24gb2YgdGhlIFJBIHdhcyBpY2luZyBvbiB0aGUgY2FrZSBmb3IgdHdvIGJpZ2dlciBwcm9i bGVtIEkgcmFpc2VkIGluIG15IGVtYWlscy4gIFN0aWxsIGZhdC1maW5nZXJpbmcgaXMgYSByZWNv Z25pemVkIHByb2JsZW0gaW4gdjZvcHMgd2l0aCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi12Nm9wcy1yb2d1ZS1yYS0wMCkuIFNuaXBwZWQgZnJvbSB0aGUgQWJzdHJhY3Qg b2YgdGhpcyBkcmFmdCBpcyB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCltIb3dldmVyLCB1bmludGVu ZGVkIG1pc2NvbmZpZ3VyYXRpb25zIGJ5IHVzZXJzIG9yIGFkbWluaXN0cmF0b3JzLCBvciBwb3Nz aWJseSBtYWxpY2lvdXMgYXR0YWNrcyBvbiB0aGUgbmV0d29yaywgbWF5IGxlYWQgdG8gYm9ndXMg UkFzIGJlaW5nIHByZXNlbnQsIHdoaWNoIGluIHR1cm4gY2FuIGNhdXNlIG9wZXJhdGlvbmFsIHBy b2JsZW1zIGZvciBob3N0cyBvbiB0aGUgbmV0d29yay5dDQoNClRoZSB0d28gYmlnZ2VyIHByb2Js ZW1zIHdlcmUgKGEpIERIQ1B2NiBhbmQgTkQgYmVpbmcgdXNlZCB0b2dldGhlciBpbiBvbmUgbmV0 d29yayBhbmQgKGIpIHdoaWNoIHdhcyB0aGF0IGZvbGtzIHNvbWV0aW1lcyBtaXNzIHRoYXQgdGhl IE5EIFJGQyA0ODYxIGFsd2F5cyByZWZlcnMgdG8gZGVmYXVsdCByb3V0ZXIocykgd2l0aCBhIHBs dXJhbC4gIEluIGJvdGggKGEpIGFuZCAoYikgd2hvIHdpbnMgaWYgYSBjbGllbnQgcmVjZWl2ZXMg aW5mb3JtYXRpb24gZnJvbSB0d28gYXV0aG9yaXRhdGl2ZSBzb3VyY2VzPyAgSSB3b3VsZCBjZXJ0 YWlubHkgbGlrZSBzdWNoIGEgUkZDIHRvIGJlIG9uIFN0YW5kYXJkcyBUcmFjayBpZiB0aGUgY29t bXVuaXR5IGRlc2lyZXMgaXQuICBCdXQgdW5sZXNzIHBvdGVudGlhbCBwaXRmYWxscyBhcmUgZG9j dW1lbnRlZCwgcGVyaGFwcyB3aXRoIGEgbmV3IHBhcmFncmFwaCB0byBSRkMgNTAwNiwgYW5kIHRo ZW4gdGhlIGRvY3VtZW50IGdvZXMgdGhydSBhIElFVEYgcmV2aWV3IGFuZCBnZXRzIGEgbmV3IFJG QyBudW1iZXIsIEkgYW0gbm90IGNvbWZvcnRhYmxlIHdpdGggUkZDIDUwMDYgZm9yIFN0YW5kYXJk cyBUcmFjayBqdXN0IHlldC4gIEFwcCBiZWhhdmlvciBjYW5ub3QgYmUgYXNzdXJlZC4gIEFnYWlu LCB1bmxlc3MgSSBzZWUgZG9jdW1lbnRzIGluIEJFSEFWRSBvciBvdGhlciBSRkNzIGZvciBETlM2 NCBsb29rdXAgZXRjLiB3aXRoIHNwZWNpZmljIHRleHQgZm9yIGFwcCBiZWhhdmlvciwgSSBhbSBu b3QgY29udmluY2VkIGFwcCBiZWhhdmlvciBjYW4gYnJlYWsgZG9tYWluIGxvb2t1cC4gIE15IGFw b2xvZ2llcyBpbiBhZHZhbmNlIGlmIEkgaGF2ZSBtaXNzZWQgYW55IGV4aXN0aW5nIHRleHQgaW4g dGhpcyByZWdhcmQgZm9yIGFwcCBiZWhhdmlvci4NCg0KSGVtYW50DQo= From sigtran-archive@lists.ietf.org Tue Mar 23 03:58:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8BE3A6BE3 for ; Tue, 23 Mar 2010 03:58:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 23 Mar 2010 03:58:20 -0700 (PDT) Received: from aimpowergen.com (unknown [212.156.94.74]) by core3.amsl.com (Postfix) with SMTP id 8BF0A3A6C05 for ; Tue, 23 Mar 2010 03:49:11 -0700 (PDT) From: Approved VIAGRA® Store Subject: New Private Message for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100323104915.8BF0A3A6C05@core3.amsl.com> Date: Tue, 23 Mar 2010 03:49:11 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 96520 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 23 04:01:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDE83A6C15 for ; Tue, 23 Mar 2010 04:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.869 X-Spam-Level: X-Spam-Status: No, score=-99.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqmuQkiVXJnZ for ; Tue, 23 Mar 2010 04:01:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 878EA3A6C25 for ; Tue, 23 Mar 2010 03:52:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu1be-0004kA-68 for v6ops-data0@psg.com; Tue, 23 Mar 2010 10:45:06 +0000 Received: from [2001:1888:0:1:202:b3ff:fe1d:6b98] (helo=outgoing03.lava.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu1bY-0004ht-OR for v6ops@ops.ietf.org; Tue, 23 Mar 2010 10:45:00 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTPS id 7B12610186; Tue, 23 Mar 2010 00:44:59 -1000 (HST) Date: Tue, 23 Mar 2010 00:44:59 -1000 (HST) From: Antonio Querubin To: Mark Townsley cc: IPv6 v6ops Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) In-Reply-To: <4BA78BE7.6010005@cisco.com> Message-ID: References: <4BA78BE7.6010005@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 22 Mar 2010, Mark Townsley wrote: > Let's err on the side of our ideals here. Publish > draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on > by default. Let's not break end-to-end IPv6 before it even has a chance to > grow up. +1 Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From owner-v6ops@ops.ietf.org Tue Mar 23 04:03:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF293A69F6 for ; Tue, 23 Mar 2010 04:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.869 X-Spam-Level: X-Spam-Status: No, score=-99.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2wqPDkTawLU for ; Tue, 23 Mar 2010 04:03:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 616923A688B for ; Tue, 23 Mar 2010 03:54:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu1k5-0005jf-6L for v6ops-data0@psg.com; Tue, 23 Mar 2010 10:53:49 +0000 Received: from [2001:1888:0:1:202:b3ff:fe1d:6b98] (helo=outgoing03.lava.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu1k2-0005jO-QQ for v6ops@ops.ietf.org; Tue, 23 Mar 2010 10:53:47 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTPS id E71A710186; Tue, 23 Mar 2010 00:53:45 -1000 (HST) Date: Tue, 23 Mar 2010 00:53:45 -1000 (HST) From: Antonio Querubin To: Ole Troan cc: alh-ietf@tndh.net, 'IPv6 Operations' Subject: Re: RFC 5006 status In-Reply-To: <41EC3C33-36EE-48C9-9617-404F0A7847F9@cisco.com> Message-ID: References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> <41EC3C33-36EE-48C9-9617-404F0A7847F9@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 22 Mar 2010, Ole Troan wrote: > if that's your argument, why shouldn't every DHCP option be possible to encode in an ND message? > is DNS _that_ special? Yes. DNS info is required for any host to operate. Without it SLAAC is really incomplete. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From v6ops-archive@megatron.ietf.org Tue Mar 23 05:35:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFBD3A6BC0 for ; Tue, 23 Mar 2010 05:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.995 X-Spam-Level: X-Spam-Status: No, score=-29.995 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxCyh-Lr48t0 for ; Tue, 23 Mar 2010 05:35:18 -0700 (PDT) Received: from 93-41-190-91.ip82.fastwebnet.it (93-41-190-91.ip82.fastwebnet.it [93.41.190.91]) by core3.amsl.com (Postfix) with ESMTP id 914903A6827 for ; Tue, 23 Mar 2010 05:33:06 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@megatron.ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100323123306.914903A6827@core3.amsl.com> Date: Tue, 23 Mar 2010 05:33:06 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Bjfobom. All rights reserved.
From v6ops-archive@ietf.org Tue Mar 23 05:35:27 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD403A6BCB for ; Tue, 23 Mar 2010 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.995 X-Spam-Level: X-Spam-Status: No, score=-29.995 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt+-c5LWlrbV for ; Tue, 23 Mar 2010 05:35:26 -0700 (PDT) Received: from 93-41-190-91.ip82.fastwebnet.it (93-41-190-91.ip82.fastwebnet.it [93.41.190.91]) by core3.amsl.com (Postfix) with ESMTP id E62013A6B01 for ; Tue, 23 Mar 2010 05:33:10 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100323123310.E62013A6B01@core3.amsl.com> Date: Tue, 23 Mar 2010 05:33:10 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Nosovu. All rights reserved.
From v6ops-archive@lists.ietf.org Tue Mar 23 05:37:13 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FDE3A659C for ; Tue, 23 Mar 2010 05:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.995 X-Spam-Level: X-Spam-Status: No, score=-29.995 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdXww1Xsl+ME for ; Tue, 23 Mar 2010 05:37:12 -0700 (PDT) Received: from 93-41-190-91.ip82.fastwebnet.it (93-41-190-91.ip82.fastwebnet.it [93.41.190.91]) by core3.amsl.com (Postfix) with ESMTP id 763AA3A6BB9 for ; Tue, 23 Mar 2010 05:35:17 -0700 (PDT) From: Leading Viagra Shop To: v6ops-archive@lists.ietf.org Subject: User, v6ops-archive! 70% better Sale prices! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100323123517.763AA3A6BB9@core3.amsl.com> Date: Tue, 23 Mar 2010 05:35:17 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Please click to enter shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Avihudux. All rights reserved.
From v6ops-archive@megatron.ietf.org Tue Mar 23 06:17:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110923A6A6E for ; Tue, 23 Mar 2010 06:17:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 23 Mar 2010 06:17:16 -0700 (PDT) Received: from alperservices.com (unknown [190.191.139.155]) by core3.amsl.com (Postfix) with SMTP id A30063A6A36 for ; Tue, 23 Mar 2010 06:17:11 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 75% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100323131711.A30063A6A36@core3.amsl.com> Date: Tue, 23 Mar 2010 06:17:11 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 00856 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Tue Mar 23 06:33:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDEBD3A6961 for ; Tue, 23 Mar 2010 06:33:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 23 Mar 2010 06:32:56 -0700 (PDT) Received: from aiptek.com.cn (unknown [202.86.203.108]) by core3.amsl.com (Postfix) with SMTP id 040933A67B2 for ; Tue, 23 Mar 2010 06:32:53 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100323133255.040933A67B2@core3.amsl.com> Date: Tue, 23 Mar 2010 06:32:53 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 07053 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 23 06:36:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5816C3A6B3F for ; Tue, 23 Mar 2010 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.869 X-Spam-Level: X-Spam-Status: No, score=-98.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v23rpyLXnKl for ; Tue, 23 Mar 2010 06:36:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61A0E3A6B2F for ; Tue, 23 Mar 2010 06:36:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4Dl-0001tP-6f for v6ops-data0@psg.com; Tue, 23 Mar 2010 13:32:37 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4Dj-0001sn-7S for v6ops@ops.ietf.org; Tue, 23 Mar 2010 13:32:35 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 90D8586CC6; Tue, 23 Mar 2010 14:32:32 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sCuzbKkRkFYC; Tue, 23 Mar 2010 14:32:30 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 02C1E86CD1; Tue, 23 Mar 2010 14:32:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id F31EF86CC7; Tue, 23 Mar 2010 14:32:29 +0100 (CET) Date: Tue, 23 Mar 2010 14:32:29 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Gert Doering cc: Fred Baker , Mark Townsley , IPv6 v6ops Subject: Re: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09) In-Reply-To: <20100322160911.GU69383@Space.Net> Message-ID: References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 22 Mar 2010, Gert Doering wrote: > Hi, > > On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >> That will have to be a working group decision. We have your opinion on the record. >> >> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >> >>> Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. > > Add another opinion to that. > > - have firewalling in there > - default to "end-to-end communication permitted" Yes to have the firewalling capabilities in CPE (reflective session state if you like) Yes to be default end-to-end communication permitted - but could be switched to default to deny by the end users, if he or she prefers NAT like behaviour. Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Mar 23 06:44:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE4C3A6B1E for ; Tue, 23 Mar 2010 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.569 X-Spam-Level: X-Spam-Status: No, score=-98.569 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2+xxB1p2yWI for ; Tue, 23 Mar 2010 06:43:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4823D3A6B48 for ; Tue, 23 Mar 2010 06:43:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4Na-0003TD-Vw for v6ops-data0@psg.com; Tue, 23 Mar 2010 13:42:46 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4NY-0003Sb-C2 for v6ops@ops.ietf.org; Tue, 23 Mar 2010 13:42:44 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 7A91F86CB4; Tue, 23 Mar 2010 14:42:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U9LefOuhqt+K; Tue, 23 Mar 2010 14:42:39 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 64C3F86CAD; Tue, 23 Mar 2010 14:42:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6266986C39; Tue, 23 Mar 2010 14:42:39 +0100 (CET) Date: Tue, 23 Mar 2010 14:42:39 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Hemant Singh (shemant)" cc: Brian E Carpenter , alh-ietf@tndh.net, IPv6 Operations Subject: RE: RFC 5006 status In-Reply-To: Message-ID: References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> <4BA7FE90.1090006@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 22 Mar 2010, Hemant Singh (shemant) wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, March 22, 2010 4:35 PM >> To: Hemant Singh (shemant) >> Cc: alh-ietf@tndh.net; IPv6 Operations >> Subject: Re: RFC 5006 status > >> I really think you are worrying about things that won't happen in a simple >> unmanaged network where only SLAAC is used. > >> In a managed network, surely we can assume consistent management, >> and fairly rapid action when inconsistency arises. We can't design >> solutions that are 100% immune to fat fingers. > > Fat-fingering configuration of the RA was icing on the cake for two > bigger problem I raised in my emails. Still fat-fingering is a > recognized problem in v6ops with > (http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00). Snipped from > the Abstract of this draft is the following text: > > [However, unintended misconfigurations by users or administrators, or > possibly malicious attacks on the network, may lead to bogus RAs being > present, which in turn can cause operational problems for hosts on the > network.] So as rogue dhcp server. Rogue-RA draft does not cope with rogue dhcp servers, but similar problem can happen... > > The two bigger problems were (a) DHCPv6 and ND being used together in > one network and (b) which was that folks sometimes miss that the ND RFC > 4861 always refers to default router(s) with a plural. In both (a) and > (b) who wins if a client receives information from two authoritative > sources? I would certainly like such a RFC to be on Standards Track if > the community desires it. But unless potential pitfalls are documented, > perhaps with a new paragraph to RFC 5006, and then the document goes > thru a IETF review and gets a new RFC number, I am not comfortable with > RFC 5006 for Standards Track just yet. App behavior cannot be assured. It can be assured with consistent configuration. Don't configure differently. > Again, unless I see documents in BEHAVE or other RFCs for DNS64 lookup > etc. with specific text for app behavior, I am not convinced app > behavior can break domain lookup. My apologies in advance if I have > missed any existing text in this regard for app behavior. I think BEHAVE and other DNS64 users has to be asked if they are confortable with the RFC 5006 style DNS propagation or not. Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Mar 23 07:05:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162463A6B92 for ; Tue, 23 Mar 2010 07:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.663 X-Spam-Level: *** X-Spam-Status: No, score=3.663 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaR7cZSV1jZn for ; Tue, 23 Mar 2010 07:05:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCD3D3A6B48 for ; Tue, 23 Mar 2010 07:05:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4gn-0007Ij-MV for v6ops-data0@psg.com; Tue, 23 Mar 2010 14:02:37 +0000 Received: from [216.37.94.58] (helo=hiltonsmtp.worldspice.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu4gk-0007I1-Kb for v6ops@ops.ietf.org; Tue, 23 Mar 2010 14:02:34 +0000 Received: (qmail 18786 invoked by uid 0); 23 Mar 2010 14:02:29 -0000 Received: by simscan 1.4.0 ppid: 18722, pid: 18769, t: 1.0883s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO HDC00027112) (lee@asgard.org@207.88.181.2) by hiltoncluster01.worldspice.net with ESMTPA; 23 Mar 2010 14:02:28 -0000 From: "Lee Howard" To: Subject: simple security Date: Tue, 23 Mar 2010 07:02:18 -0700 Message-ID: <001501caca91$769511b0$63bf3510$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CACA56.CA3639B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKkXMIZHpKzmkZT2y0LKM0FMKZhQ== Content-Language: en-us Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0016_01CACA56.CA3639B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The simple-security draft represents the best practice we know of for securing home networks. It describes the behavior that should be the default for all home networking gateways. Advanced users who know what they're getting into can change those default rules. Some people argued that a stateful firewall is no longer needed because attackers no longer use vectors that a firewall protects against. This sounds like circular reasoning to me, as if you no longer need a roof because rain hasn't fallen on your head for years. It was also argued that attacks of this kind simply don't exist in IPv6. That sounds like the argument that faults in the space shuttle o-ring haven't caused explosions before, so it's safe. I'll also point out that OSes with smaller market share have fewer exploits written for them because they are a smaller target; as IPv6 exceeds 50%, there will be more attacks. I disagreed at the mike with the argument that ISPs should be doing this kind of filtering themselves. I'd like to understand that argument better. If ISPs should be providing stateful firewall service, then doesn't that support the need for a draft documenting what ISPs should do? Yes, hosts should provide better security for themselves. In some regions, users install three or four security packages on their computers, but even their almost 50% of machines are infected. Blocking the easiest paths to exploits using perimeter security is current best practice, and should be documented as such. Lee ------=_NextPart_000_0016_01CACA56.CA3639B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The simple-security draft represents the best practice we = know of for securing home networks.  It describes the behavior that should = be the default for all home networking gateways.  Advanced users who know = what they're getting into can change those default = rules.

 

Some people argued that a stateful firewall is no longer = needed because attackers no longer use vectors that a firewall protects = against.  This sounds like circular reasoning to me, as if you no longer need a = roof because rain hasn't fallen on your head  for = years.

 

It was also argued that attacks of this kind simply don't = exist in IPv6.   That sounds like the argument that faults in the space shuttle o-ring haven't caused explosions before, so it's safe.  = I'll also point out that OSes with smaller market share have fewer exploits = written for them because they are a smaller target; as IPv6 exceeds 50%, there will = be more attacks.

 

I disagreed at the mike with the argument that ISPs should = be doing this kind of filtering themselves.  I'd like to understand = that argument better.  If ISPs should be providing stateful firewall = service, then doesn't that support the need for a draft documenting what ISPs = should do?  

 

Yes, hosts should provide better security for = themselves.  In some regions, users install three or four security packages on their = computers, but even their almost 50% of machines are infected.  Blocking the = easiest paths to exploits using perimeter security is current best practice, and = should be documented as such.

 

Lee

------=_NextPart_000_0016_01CACA56.CA3639B0-- From owner-v6ops@ops.ietf.org Tue Mar 23 07:37:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1493A6A36 for ; Tue, 23 Mar 2010 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.68 X-Spam-Level: **** X-Spam-Status: No, score=4.68 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Slov7u9NlmB for ; Tue, 23 Mar 2010 07:37:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEE923A6835 for ; Tue, 23 Mar 2010 07:37:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5Bc-000CLS-IM for v6ops-data0@psg.com; Tue, 23 Mar 2010 14:34:28 +0000 Received: from [194.109.24.27] (helo=smtp-vbr7.xs4all.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5BZ-000CKg-VD for v6ops@ops.ietf.org; Tue, 23 Mar 2010 14:34:26 +0000 Received: from ghb.xs4all.nl (ghb.xs4all.nl [194.109.0.42]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id o2NEVfPn013819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Mar 2010 15:31:41 +0100 (CET) (envelope-from marcoh@marcoh.net) Subject: Re: Overloading RA [Re: RFC 5006 status] Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marco Hogewoning In-Reply-To: <99B80140-857B-4994-A431-B30922D4A149@kurtis.pp.se> Date: Tue, 23 Mar 2010 15:31:41 +0100 Cc: Seiichi Kawamura , Brian E Carpenter , Ralph Droms , Gert Doering , Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <2AF030CE-99F4-4723-AA1B-C0DFE17FF216@marcoh.net> References: <20100318081445.GC69383@Space.Net> <20100318.101539.74725695.sthaug@nethelp.no> <20100318092556.GF69383@Space.Net> <0A06FD06-FE22-4D5A-A440-1349C03E39A3@free.fr> <20100318225058.3c5ebb76@opy.nosense.org> <20100318193036.GD69383@Space.Net> <20100318201025.GE69383@Space.Net> <731C50B2-DBC9-43D3-9A2E-B2C4B2CF1BC3@cisco.com> <4BA2CEDF.2040304@gmail.com> <4BA2D6C2.1020800@mesh.ad.jp> <99B80140-857B-4994-A431-B30922D4A149@kurtis.pp.se> To: Lindqvist Kurt Erik X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> So keeping SLAAC simple, but with the >> options that are absolutely necessary to >> get connected(default router and dns) >> without relying on other protocols or manual >> configuration, would be the best thing. >=20 > I agree with what others have said. I believe there is a need for for = both configuration options - yes, as Ralph has pointed out there are = still some issues that needs to be clarified, but for me that would be = part of the process of moving to PS. In my day job I often see a use = case for SLAAC and I also see if used, not having the DNS option is = often an issue.=20 Having real users on a real network I can confirm this is the case. In = general my residentials don't even check, they hook up their machine and = browse to ipv6.google.com to test wether it works, they don't look or = care how things are done so in general just keep using the IPv4 = nameservers. I agree SLAAC should offer the basics to operate and DNS is one of those = items you can't do without. Groet, MarcoH From owner-v6ops@ops.ietf.org Tue Mar 23 07:40:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6D13A6BE9 for ; Tue, 23 Mar 2010 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpP+Pus6jEUL for ; Tue, 23 Mar 2010 07:40:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E87A03A6919 for ; Tue, 23 Mar 2010 07:40:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5GO-000DNy-7S for v6ops-data0@psg.com; Tue, 23 Mar 2010 14:39:24 +0000 Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5GJ-000DMu-SY for v6ops@ops.ietf.org; Tue, 23 Mar 2010 14:39:20 +0000 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2NEdIGs005573 for ; Tue, 23 Mar 2010 10:39:19 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2NEdIQ9005566; Tue, 23 Mar 2010 10:39:18 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 23 Mar 2010 10:39:19 -0400 From: "Dunn, Jeffrey H." To: Lee Howard CC: "v6ops@ops.ietf.org" , "Dunn, Jeffrey H." Date: Tue, 23 Mar 2010 10:39:17 -0400 Subject: RE: simple security Thread-Topic: simple security Thread-Index: AcrKkXMIZHpKzmkZT2y0LKM0FMKZhQAA/OfA Message-ID: <3C6F21684E7C954193E6C7C4573B762703A8F5CAD1@IMCMBX1.MITRE.ORG> References: <001501caca91$769511b0$63bf3510$@org> In-Reply-To: <001501caca91$769511b0$63bf3510$@org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3C6F21684E7C954193E6C7C4573B762703A8F5CAD1IMCMBX1MITREO_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --_000_3C6F21684E7C954193E6C7C4573B762703A8F5CAD1IMCMBX1MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lee, I agree. To amplify on your position, I offer the following. Many jurisdict= ions have draconian statues defining illicit Internet activity, e.g., child= pornography, and associated stringent penalties, e.g., lengthy incarcerati= on. If there is a perception that the use of IPv6 unique globally routable = unicast addresses (UGA) increases a consumer's risk of inadvertently violat= ing one of the statute because a compromise of their home systems or networ= k, adoption of IPv6 by consumers will be minimal. In addition, applying simple security controls such as least functionality = is both sound and responsible. Specifically, if home networks are not suppo= rting servers, e.g., web sites, then there is no need to allows sessions as= sociated with servers to be initiated by Internet hosts. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of Lee Howard Sent: Tuesday, March 23, 2010 10:02 AM To: v6ops@ops.ietf.org Subject: simple security The simple-security draft represents the best practice we know of for secur= ing home networks. It describes the behavior that should be the default fo= r all home networking gateways. Advanced users who know what they're getti= ng into can change those default rules. Some people argued that a stateful firewall is no longer needed because att= ackers no longer use vectors that a firewall protects against. This sounds= like circular reasoning to me, as if you no longer need a roof because rai= n hasn't fallen on your head for years. It was also argued that attacks of this kind simply don't exist in IPv6. = That sounds like the argument that faults in the space shuttle o-ring haven= 't caused explosions before, so it's safe. I'll also point out that OSes w= ith smaller market share have fewer exploits written for them because they = are a smaller target; as IPv6 exceeds 50%, there will be more attacks. I disagreed at the mike with the argument that ISPs should be doing this ki= nd of filtering themselves. I'd like to understand that argument better. = If ISPs should be providing stateful firewall service, then doesn't that su= pport the need for a draft documenting what ISPs should do? Yes, hosts should provide better security for themselves. In some regions,= users install three or four security packages on their computers, but even= their almost 50% of machines are infected. Blocking the easiest paths to = exploits using perimeter security is current best practice, and should be d= ocumented as such. Lee --_000_3C6F21684E7C954193E6C7C4573B762703A8F5CAD1IMCMBX1MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=

From:= owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Lee Howard
Sent: Tuesday, March 23, 201= 0 10:02 AM
To: v6ops@ops.ietf.org
Subject: simple security

 

=

=

=

=

= X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BBB3A6C24 for ; Tue, 23 Mar 2010 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.443 X-Spam-Level: X-Spam-Status: No, score=0.443 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRYwL9-i7FRh for ; Tue, 23 Mar 2010 08:01:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E50B83A6C14 for ; Tue, 23 Mar 2010 08:01:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5aS-000Gwx-8o for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:00:08 +0000 Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5aP-000GvS-OO for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:00:05 +0000 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2NF041p005736 for ; Tue, 23 Mar 2010 11:00:05 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2NF04dk005723; Tue, 23 Mar 2010 11:00:04 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 23 Mar 2010 11:00:05 -0400 From: "Dunn, Jeffrey H." To: Gert Doering CC: Lee Howard , "v6ops@ops.ietf.org" , "Dunn, Jeffrey H." Date: Tue, 23 Mar 2010 11:00:04 -0400 Subject: RE: simple security Thread-Topic: simple security Thread-Index: AcrKl+2RVy5PcBZZROO0dALdHYkvDwAAGafw Message-ID: <3C6F21684E7C954193E6C7C4573B762703A8F5CB14@IMCMBX1.MITRE.ORG> References: <001501caca91$769511b0$63bf3510$@org> <3C6F21684E7C954193E6C7C4573B762703A8F5CAD1@IMCMBX1.MITRE.ORG> <20100323144838.GK69383@Space.Net> In-Reply-To: <20100323144838.GK69383@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gert, I am not sure that denying incoming server sessions be default will inhibit= all of those activities. It will inhibit unwanted file sharing, e.g., turn= ing my machine into a child pornography web host. My wireless router has th= ese filters on by default now. IMHO, it makes sense to provide the consumer= with the same level of security they have with IPv4.=20 As to home users accessing professionally developed web servers, you are co= rrect that we do not need IPv6 for that; however, we do need UGA to allow t= hose users to employ advanced security features, e.g., DNS SEC. Best Regards,=20 =A0=20 Jeffrey Dunn=20 Info Systems Eng., Lead=20 MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: Gert Doering [mailto:gert@Space.Net]=20 Sent: Tuesday, March 23, 2010 10:49 AM To: Dunn, Jeffrey H. Cc: Lee Howard; v6ops@ops.ietf.org Subject: Re: simple security Hi, On Tue, Mar 23, 2010 at 10:39:17AM -0400, Dunn, Jeffrey H. wrote: > Specifically, if home networks are not supporting servers, e.g., > web sites, then there is no need to allows sessions associated with > servers to be initiated by Internet hosts. Have you heard the term "peer-to-peer networking" mentioned before? If all we want is "people can go from their home to web servers run by professionals!!" then we don't need IPv6. The whole point of having a new protocol is to restore end-to-end communication - and that includes "people in their home" - VoIP, file sharing, online gaming (without a server run in someone's data centre), etc. - and if you put a deny-by-default firewall in their way, all this won't work. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Tue Mar 23 08:01:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2593A6C24 for ; Tue, 23 Mar 2010 08:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.332 X-Spam-Level: *** X-Spam-Status: No, score=3.332 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voOLDy00KLBF for ; Tue, 23 Mar 2010 08:01:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29EA73A6C14 for ; Tue, 23 Mar 2010 08:01:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5b0-000H0v-9W for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:00:42 +0000 Received: from [93.17.128.22] (helo=smtp23.services.sfr.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5ay-000H0M-6X for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:00:40 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 2B0EB700009D; Tue, 23 Mar 2010 16:00:39 +0100 (CET) Received: from dhcp-wireless-open-abg-24-236.meeting.ietf.org (dhcp-wireless-open-abg-24-236.meeting.ietf.org [130.129.24.236]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id BC103700009F; Tue, 23 Mar 2010 16:00:37 +0100 (CET) X-SFR-UUID: 20100323150037770.BC103700009F@msfrf2316.sfr.fr Subject: Re: On saving end-to-end transparency Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 23 Mar 2010 08:00:36 -0700 Cc: Gert Doering , Fred Baker , Mark Townsley , Mohacsi Janos Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> To: IPv6 v6ops X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For information: the IPv6 we have here is WITHOUT any filter (confirmed = by the IETF NOC). Does anyone report a security problem ;-) ? RD =20 Le 23 mars 2010 =E0 06:32, Mohacsi Janos a =E9crit : >=20 >=20 >=20 > On Mon, 22 Mar 2010, Gert Doering wrote: >=20 >> Hi, >>=20 >> On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >>> That will have to be a working group decision. We have your opinion = on the record. >>>=20 >>> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >>>=20 >>>> Let's err on the side of our ideals here. Publish = draft-ietf-v6ops-cpe-simple-security, but do so without default-deny = rules on by default. Let's not break end-to-end IPv6 before it even has = a chance to grow up. >>=20 >> Add another opinion to that. >>=20 >> - have firewalling in there >> - default to "end-to-end communication permitted" >=20 > Yes to have the firewalling capabilities in CPE (reflective session = state if you like) > Yes to be default end-to-end communication permitted - but could be = switched to default to deny by the end users, if he or she prefers NAT = like behaviour. >=20 > Best Regards, > Janos Mohacsi >=20 >=20 From owner-v6ops@ops.ietf.org Tue Mar 23 08:23:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50853A68BF for ; Tue, 23 Mar 2010 08:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.569 X-Spam-Level: X-Spam-Status: No, score=-98.569 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjmh12E04WdS for ; Tue, 23 Mar 2010 08:23:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36C6C3A6847 for ; Tue, 23 Mar 2010 08:23:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5ut-000KYq-J5 for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:21:15 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5ur-000KYQ-Ep for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:21:13 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1C22F86CD1; Tue, 23 Mar 2010 16:21:11 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id J7ik2Yo-aXsp; Tue, 23 Mar 2010 16:21:04 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 0E77886CB4; Tue, 23 Mar 2010 16:21:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id F275986C3C; Tue, 23 Mar 2010 16:21:03 +0100 (CET) Date: Tue, 23 Mar 2010 16:21:03 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= cc: IPv6 v6ops , Gert Doering , Fred Baker , Mark Townsley Subject: Re: On saving end-to-end transparency In-Reply-To: Message-ID: References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1595825774-1269357663=:74067" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1595825774-1269357663=:74067 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > For information: the IPv6 we have here is WITHOUT any filter (confirmed by the IETF NOC). > Does anyone report a security problem ;-) ? Are there any possiblity to report security problems? You know, IETF folks are more technically competent than the average home users. They know what they are doing on their computers. I think there is still some needs to hide home network devices: - no longer supported but know to be vulnerable devices, servers - devices without access control - etc. Best Regards, Janos Mohacsi > > > Le 23 mars 2010 ? 06:32, Mohacsi Janos a crit : > >> >> >> >> On Mon, 22 Mar 2010, Gert Doering wrote: >> >>> Hi, >>> >>> On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >>>> That will have to be a working group decision. We have your opinion on the record. >>>> >>>> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >>>> >>>>> Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. >>> >>> Add another opinion to that. >>> >>> - have firewalling in there >>> - default to "end-to-end communication permitted" >> >> Yes to have the firewalling capabilities in CPE (reflective session state if you like) >> Yes to be default end-to-end communication permitted - but could be switched to default to deny by the end users, if he or she prefers NAT like behaviour. >> >> Best Regards, >> Janos Mohacsi >> >> > > > --0-1595825774-1269357663=:74067-- From owner-v6ops@ops.ietf.org Tue Mar 23 08:26:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E263A68D1 for ; Tue, 23 Mar 2010 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.514 X-Spam-Level: X-Spam-Status: No, score=0.514 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsjHKOa22Dfv for ; Tue, 23 Mar 2010 08:26:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3C243A66B4 for ; Tue, 23 Mar 2010 08:26:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5z7-000LIM-SZ for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:25:37 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu5z5-000LHO-TJ for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:25:35 +0000 Received: from [130.129.24.69] (dhcp-wireless-open-abg-24-69.meeting.ietf.org [130.129.24.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o2NFPNIR088140 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 15:25:24 GMT (envelope-from joelja@bogus.com) Message-ID: <4BA8DD63.3050605@bogus.com> Date: Tue, 23 Mar 2010 08:25:23 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100316 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= CC: IPv6 v6ops , Gert Doering , Fred Baker , Mark Townsley , Mohacsi Janos Subject: Re: On saving end-to-end transparency References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 23 Mar 2010 15:25:24 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: you've got ipv4 without a filter... also there's about 2000 unmanaged devices inside the perimeter. On 03/23/2010 08:00 AM, Rémi Després wrote: > For information: the IPv6 we have here is WITHOUT any filter (confirmed by the IETF NOC). > Does anyone report a security problem ;-) ? > RD > > > Le 23 mars 2010 à 06:32, Mohacsi Janos a écrit : > >> >> >> >> On Mon, 22 Mar 2010, Gert Doering wrote: >> >>> Hi, >>> >>> On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >>>> That will have to be a working group decision. We have your opinion on the record. >>>> >>>> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >>>> >>>>> Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up. >>> >>> Add another opinion to that. >>> >>> - have firewalling in there >>> - default to "end-to-end communication permitted" >> >> Yes to have the firewalling capabilities in CPE (reflective session state if you like) >> Yes to be default end-to-end communication permitted - but could be switched to default to deny by the end users, if he or she prefers NAT like behaviour. >> >> Best Regards, >> Janos Mohacsi >> >> > > > From owner-v6ops@ops.ietf.org Tue Mar 23 08:29:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B383A6C02 for ; Tue, 23 Mar 2010 08:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.593 X-Spam-Level: X-Spam-Status: No, score=0.593 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quo6dUA97C1D for ; Tue, 23 Mar 2010 08:29:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 468F93A68D1 for ; Tue, 23 Mar 2010 08:29:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu62T-000Lwf-Tb for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:29:05 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu62Q-000Lvp-UV for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:29:03 +0000 Received: from [130.129.24.69] (dhcp-wireless-open-abg-24-69.meeting.ietf.org [130.129.24.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o2NFSqEr088160 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 15:28:53 GMT (envelope-from joelja@bogus.com) Message-ID: <4BA8DE34.4070901@bogus.com> Date: Tue, 23 Mar 2010 08:28:52 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100316 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mohacsi Janos CC: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 v6ops , Gert Doering , Fred Baker , Mark Townsley Subject: Re: On saving end-to-end transparency References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 23 Mar 2010 15:28:53 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 03/23/2010 08:21 AM, Mohacsi Janos wrote: > > > > >> For information: the IPv6 we have here is WITHOUT any filter >> (confirmed by the IETF NOC). >> Does anyone report a security problem ;-) ? > > Are there any possiblity to report security problems? You know, IETF > folks are more technically competent than the average home users. They > know what they are doing on their computers. hah you're funny. No they don't. > I think there is still some needs to hide home network devices: > - no longer supported but know to be vulnerable devices, servers > - devices without access control > - etc. > > > Best Regards, > Janos Mohacsi > >> >> >> Le 23 mars 2010 ? 06:32, Mohacsi Janos a écrit : >> >>> >>> >>> >>> On Mon, 22 Mar 2010, Gert Doering wrote: >>> >>>> Hi, >>>> >>>> On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >>>>> That will have to be a working group decision. We have your opinion >>>>> on the record. >>>>> >>>>> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >>>>> >>>>>> Let's err on the side of our ideals here. Publish >>>>>> draft-ietf-v6ops-cpe-simple-security, but do so without >>>>>> default-deny rules on by default. Let's not break end-to-end IPv6 >>>>>> before it even has a chance to grow up. >>>> >>>> Add another opinion to that. >>>> >>>> - have firewalling in there >>>> - default to "end-to-end communication permitted" >>> >>> Yes to have the firewalling capabilities in CPE (reflective session >>> state if you like) >>> Yes to be default end-to-end communication permitted - but could be >>> switched to default to deny by the end users, if he or she prefers >>> NAT like behaviour. >>> >>> Best Regards, >>> Janos Mohacsi >>> >>> >> >> >> From owner-v6ops@ops.ietf.org Tue Mar 23 08:49:42 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0343A6C71 for ; Tue, 23 Mar 2010 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.569 X-Spam-Level: X-Spam-Status: No, score=-98.569 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bw7MAHNJAq4 for ; Tue, 23 Mar 2010 08:49:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DDD03A6BFD for ; Tue, 23 Mar 2010 08:49:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6LK-000074-HG for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:48:34 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6LH-00006I-GY for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:48:31 +0000 Received: from leon.remlab.net (72-254-90-242.client.stsn.net [72.254.90.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id D37BCEE for ; Tue, 23 Mar 2010 16:48:29 +0100 (CET) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: v6ops@ops.ietf.org Subject: Re: simple security Date: Tue, 23 Mar 2010 17:48:22 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.32.9; KDE/4.3.5; i686; ; ) References: <001501caca91$769511b0$63bf3510$@org> In-Reply-To: <001501caca91$769511b0$63bf3510$@org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201003231748.22841.remi@remlab.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tuesday 23 March 2010 16:02:18 Lee Howard, you wrote: > The simple-security draft represents the best practice we know of for > securing home networks. It describes the behavior that should be the > default for all home networking gateways. Advanced users who know what > they're getting into can change those default rules. I've kept saying the same thing for three years now. But anyway. This=20 assertion raises the a much more systematic question: What's the use of IPv6 (then)? IPv6 with a stateful firewall is essentially= =20 just as bad as IPv4 with a NAT in terms of connectivity. Also IPv6 has=20 fundamentally higher overhead (both in terms of packet header size and of=20 router processing). So the simple security draft seems highly paradoxical to me. A "solution"=20 would be to specify a functional hole punching mechanism. But that key part= =20 part is missing. I am not comfortable with having the simple security docum= ent=20 without a hole punching document too. Some people will doubtless argue that there should not be a hole punching=20 mechanism. But then, I would like them to answer the question above...=20 (Standardization engineer job security is not a good reason for IPv6 to me) > Some people argued that a stateful firewall is no longer needed because > attackers no longer use vectors that a firewall protects against. This > sounds like circular reasoning to me, as if you no longer need a roof > because rain hasn't fallen on your head for years. Do you take vaccinations for illenesses that don't exist anymore? Most peop= le=20 don't even take vaccinations for some that do exist but not where they live. Why would you protect IPv6 systems for old (now fixed) vulnerabilities in I= Pv4=20 systems? > It was also argued that attacks of this kind simply don't exist in IPv6. Which is true. > That sounds like the argument that faults in the space shuttle o-ring > haven't caused explosions before, so it's safe. No. It's just an argument that operating systems have already been fixed=20 *before* they implemented IPv6. Common attack vectors are in different=20 (higher) parts of the software stack, against which stateful firewalls are= =20 totally helpless. > I'll also point out that > OSes with smaller market share have fewer exploits written for them becau= se > they are a smaller target; as IPv6 exceeds 50%, there will be more attack= s. That is a severe misrepresentation of reality. You will find exploits writt= en=20 for very obscure vulnerabilities. Of course, they are not commonly (mis)use= d,=20 but they are available. =2D-=20 R=E9mi Denis-Courmont Nokia Corporation / Maemo Devices R&D From owner-v6ops@ops.ietf.org Tue Mar 23 08:49:51 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF5E3A6C81 for ; Tue, 23 Mar 2010 08:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.83 X-Spam-Level: **** X-Spam-Status: No, score=4.83 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIGh3wN2LIdK for ; Tue, 23 Mar 2010 08:49:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FF1F3A6C75 for ; Tue, 23 Mar 2010 08:49:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6JE-000PnY-JM for v6ops-data0@psg.com; Tue, 23 Mar 2010 15:46:24 +0000 Received: from [194.109.24.35] (helo=smtp-vbr15.xs4all.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6JB-000Pmw-Od for v6ops@ops.ietf.org; Tue, 23 Mar 2010 15:46:22 +0000 Received: from ghb.xs4all.nl (ghb.xs4all.nl [194.109.0.42]) (authenticated bits=0) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id o2NFjumq080643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Mar 2010 16:45:56 +0100 (CET) (envelope-from marcoh@marcoh.net) Subject: Re: On saving end-to-end transparency Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Marco Hogewoning In-Reply-To: Date: Tue, 23 Mar 2010 16:45:56 +0100 Cc: IPv6 v6ops , Gert Doering , Fred Baker , Mark Townsley , Mohacsi Janos Content-Transfer-Encoding: quoted-printable Message-Id: <5C44A45B-B6DF-486E-9210-C44A72049E50@marcoh.net> References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 23 mrt 2010, at 16:00, R=E9mi Despr=E9s wrote: > For information: the IPv6 we have here is WITHOUT any filter = (confirmed by the IETF NOC). > Does anyone report a security problem ;-) ? I guess time will tell. After all in the old days dialin with built-in = modems also worked without NAT and usually without firewalls and nobody = seemed to care. Guess that with NAT acting as a firewall people got lazy = and spoiled :( =46rom an operational perspective there is only so much you can prevent = by introducing a default deny policy. =46rom what I see and hear a lot, = even most of the problems are caused by trojans downloaded by people. = Then again, earlier worm outbreaks do prove it might be handy to have = something in place and for us this is the main driver. We can go all religious about end-to-end connectivity being the one true = internet and trust me I work for a company that does care and exists = long enough to remember what it was like. Reality with a couple of = hundred thousands residentials is that we do want some form of 'nat = like' behavior by default on IPv6, simply beacuse people expect it to = work that way. We keep trying to convince them they should run regular = updates for scanners and software, we even offer courses on it, but in = practice they don't. So for now dropping all inbound connections feels good, expecially if we = want the masses to start using IPv6 fast. And yes there should be an = easy button in that CPE/RG to disable that firewall and yes it should = come with a BIG warning about the risks they just took. Groet, MarcoH From owner-v6ops@ops.ietf.org Tue Mar 23 09:02:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224023A6C6C for ; Tue, 23 Mar 2010 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.765 X-Spam-Level: X-Spam-Status: No, score=-104.765 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H-mt+JfDYNd for ; Tue, 23 Mar 2010 09:02:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F38CE3A6C14 for ; Tue, 23 Mar 2010 09:01:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6Wr-0002Tf-1w for v6ops-data0@psg.com; Tue, 23 Mar 2010 16:00:29 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu6Wo-0002TJ-Q6 for v6ops@ops.ietf.org; Tue, 23 Mar 2010 16:00:26 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACOCqEurRN+J/2dsb2JhbACbKXOjVYsNCI4OgmMIghIEgx4 X-IronPort-AV: E=Sophos;i="4.51,295,1267401600"; d="scan'208";a="501482959" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 16:00:26 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn6-996.cisco.com [10.21.123.228]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2NG0P2h014465 for ; Tue, 23 Mar 2010 16:00:26 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: On filibusters as a mode of technical discussion From: Fred Baker In-Reply-To: <4BA78BE7.6010005@cisco.com> Date: Tue, 23 Mar 2010 09:00:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> To: IPv6 v6ops X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'd like to bring this discussion back to a place of a little less = fervor and a little more engineering, if I may. I have been staying out = of it as much as anything because people really do need to be allowed to = say what they think. But... At the microphone yesterday, I had to cut the discussion off. My reasons = were two-fold. One was that we were in the first discussion of several = and the meeting time had to be preserved. The other was that successive = speakers were saying the same thing, and spending a lot of time saying = it. It had the effect of a filibuster, and I'm not in favor of = filibusters as a means of getting technical work done. It comes down to this. We as a community have two views. We would like a = free and open Internet in which applications can be designed with an = expectation that they can communicate amongst themselves freely. We = would also like to have, and have a business need to provide for = ourselves, the ability to communicate only with peer applications that = have our best interests at heart. The history of humanity says that = altruism is not a pervasive trait, and the history of the Internet says = that we behave on the Internet the same way we do at home. My corporate IT folks tell me they drop something on the order of 98% of = the email sent to my account, because only 2% behaves in a manner = consistent with good etiquette. At the firewall in front of my home I = measure a 30 message per second standing load of messages from systems = that I have no reason to allow into my home. For me, it comes down to = the reason I have a door on my home and it is equipped with a lock. = Someone who has a legitimate reason to be in my home also has the = manners to knock on my door. If we don't see this on IPv6, it is for the = same reason that I don't see viruses on my Mac - it's a sufficiently low = value target that nobody is bothering to attack it. As soon as it = becomes an interesting target, we can expect folks to attack it. The = fact that it is not raining now is not proof that I will not need a roof = at any time in the future. Non sequitor. This draft was commissioned to describe a simple stateful default-deny = firewall. What we decided yesterday that it would continue to describe = is a simple stateful default-deny firewall. Everyone doesn't have to = install one, and we decided as a group that we would have no = recommendation whether they should. But for those that choose to install = a simple stateful default-deny firewall, this note indicates how that = should behave. If we want to change the intent of the note, that's one thing. But we = didn't yesterday decide to change the intent of the note. What we = decided yesterday was to permit a second note, perhaps based on = draft-vyncke-advanced-ipv6-security, that would describe an alternative = security procedure. I would invite that note, and I would invite = demonstration of the effectiveness of the mechanisms proposed in = providing security. Let's drop the filibuster. Please. Let's channel all this fervor into = making the alternative a really good, and really honestly accurate, = note.= From owner-v6ops@ops.ietf.org Tue Mar 23 09:44:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA093A6993 for ; Tue, 23 Mar 2010 09:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRcai3ppWh5E for ; Tue, 23 Mar 2010 09:44:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE8E93A694D for ; Tue, 23 Mar 2010 09:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7BY-0009ai-V4 for v6ops-data0@psg.com; Tue, 23 Mar 2010 16:42:32 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7BW-0009ZF-QC for v6ops@ops.ietf.org; Tue, 23 Mar 2010 16:42:30 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="104455664" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2010 16:42:30 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2NGgUoc016473; Tue, 23 Mar 2010 16:42:30 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2NGgSY19349; Tue, 23 Mar 2010 09:42:28 -0700 (PDT) Message-ID: <4BA8EF73.3050907@cisco.com> Date: Tue, 23 Mar 2010 17:42:27 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mohacsi Janos CC: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 v6ops , Gert Doering , Fred Baker Subject: Re: On saving end-to-end transparency References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/23/10 4:21 PM, Mohacsi Janos wrote: > > > > >> For information: the IPv6 we have here is WITHOUT any filter >> (confirmed by the IETF NOC). >> Does anyone report a security problem ;-) ? > > Are there any possiblity to report security problems? You know, IETF > folks are more technically competent than the average home users. They > know what they are doing on their computers. You give us *way* more credit than we deserve :-) - Mark > > I think there is still some needs to hide home network devices: > - no longer supported but know to be vulnerable devices, servers > - devices without access control > - etc. > > > Best Regards, > Janos Mohacsi > >> >> >> Le 23 mars 2010 ? 06:32, Mohacsi Janos a crit : >> >>> >>> >>> >>> On Mon, 22 Mar 2010, Gert Doering wrote: >>> >>>> Hi, >>>> >>>> On Mon, Mar 22, 2010 at 08:32:38AM -0700, Fred Baker wrote: >>>>> That will have to be a working group decision. We have your >>>>> opinion on the record. >>>>> >>>>> On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote: >>>>> >>>>>> Let's err on the side of our ideals here. Publish >>>>>> draft-ietf-v6ops-cpe-simple-security, but do so without >>>>>> default-deny rules on by default. Let's not break end-to-end IPv6 >>>>>> before it even has a chance to grow up. >>>> >>>> Add another opinion to that. >>>> >>>> - have firewalling in there >>>> - default to "end-to-end communication permitted" >>> >>> Yes to have the firewalling capabilities in CPE (reflective session >>> state if you like) >>> Yes to be default end-to-end communication permitted - but could be >>> switched to default to deny by the end users, if he or she prefers >>> NAT like behaviour. >>> >>> Best Regards, >>> Janos Mohacsi >>> >>> >> >> >> From owner-v6ops@ops.ietf.org Tue Mar 23 09:54:26 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570953A6CF6 for ; Tue, 23 Mar 2010 09:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.593 X-Spam-Level: * X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0F11wwfmAw7 for ; Tue, 23 Mar 2010 09:54:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52DBC3A68C8 for ; Tue, 23 Mar 2010 09:54:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7KL-000Asg-9n for v6ops-data0@psg.com; Tue, 23 Mar 2010 16:51:37 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7KI-000Art-3c for v6ops@ops.ietf.org; Tue, 23 Mar 2010 16:51:35 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Nu7KF-0001dEC; Tue, 23 Mar 2010 17:51 +0100 Message-Id: To: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Cc: v6ops@ops.ietf.org Subject: Re: simple security From: Philip Homburg References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> In-reply-to: Your message of "Tue, 23 Mar 2010 17:48:22 +0200 ." <201003231748.22841.remi@remlab.net> Date: Tue, 23 Mar 2010 17:51:29 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Tue, 23 Mar 2010 17:48:22 +0200 you wrote: >> Some people argued that a stateful firewall is no longer needed because >> attackers no longer use vectors that a firewall protects against. This >> sounds like circular reasoning to me, as if you no longer need a roof >> because rain hasn't fallen on your head for years. > >Do you take vaccinations for illenesses that don't exist anymore? Most people >don't even take vaccinations for some that do exist but not where they live. >Why would you protect IPv6 systems for old (now fixed) vulnerabilities in >IPv4 systems? Maybe I'm misunderstanding your argument. But are you trying to say that in, say, the past 5 years, there have been no remote holes in any commonly used system? Or are you trying to say to because remote holes are not exploited over IPv6 at the moment, it is not worth having protection for them. Just wait until it is too late, and router vendors once again get a bad rep for offering no security. From owner-v6ops@ops.ietf.org Tue Mar 23 10:01:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24B93A6C17 for ; Tue, 23 Mar 2010 10:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.915 X-Spam-Level: X-Spam-Status: No, score=-105.915 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0noMMStETddC for ; Tue, 23 Mar 2010 10:01:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4A503A6D5F for ; Tue, 23 Mar 2010 10:01:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7SF-000C0a-0T for v6ops-data0@psg.com; Tue, 23 Mar 2010 16:59:47 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7SC-000C01-Le for v6ops@ops.ietf.org; Tue, 23 Mar 2010 16:59:44 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD2QqEurRN+K/2dsb2JhbACbKXOkEZkwhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="311026066" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2010 16:59:44 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn6-692.cisco.com [10.21.122.180]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2NGxcTo001540; Tue, 23 Mar 2010 16:59:42 GMT Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Fred Baker In-Reply-To: <201003231748.22841.remi@remlab.net> Date: Tue, 23 Mar 2010 09:59:33 -0700 Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2CDA4B54-12CE-4D23-8ABC-BCD0A7ABA206@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 23, 2010, at 8:48 AM, R=E9mi Denis-Courmont wrote: > Do you take vaccinations for illenesses that don't exist anymore? Most = people=20 > don't even take vaccinations for some that do exist but not where they = live. Yes, and as a result we are seeing a resurgence of polio and other = diseases. I think the analogy applies perfectly. http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Tue Mar 23 10:15:43 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E0D3A6C18 for ; Tue, 23 Mar 2010 10:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m66OddzY97Mt for ; Tue, 23 Mar 2010 10:15:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C78F3A68C3 for ; Tue, 23 Mar 2010 10:15:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7ew-000EeC-1B for v6ops-data0@psg.com; Tue, 23 Mar 2010 17:12:54 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7es-000Edl-Ng for v6ops@ops.ietf.org; Tue, 23 Mar 2010 17:12:50 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 6921AA9B; Tue, 23 Mar 2010 18:12:49 +0100 (CET) To: Philip Homburg Subject: Re: simple security MIME-Version: 1.0 Date: Tue, 23 Mar 2010 18:12:49 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> Message-ID: <8cce4ee19c92e696c40fdd57371981c0@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 23 Mar 2010 17:51:29 +0100, Philip Homburg wrote: > In your letter dated Tue, 23 Mar 2010 17:48:22 +0200 you wrote: >>> Some people argued that a stateful firewall is no longer needed because >>> attackers no longer use vectors that a firewall protects against. This >>> sounds like circular reasoning to me, as if you no longer need a roof >>> because rain hasn't fallen on your head for years. >> >>Do you take vaccinations for illenesses that don't exist anymore? Most >> people don't even take vaccinations for some that do exist but not >> where they live. >>Why would you protect IPv6 systems for old (now fixed) vulnerabilities in >>IPv4 systems? > > Maybe I'm misunderstanding your argument. But are you trying to say that > in, say, the past 5 years, there have been no remote holes in any commonly > used system? There are remote holes in old unpatched systems (which are generally so old that they don't support IPv6 anyway). Oh sure, there are plenty of holes in modern systems (that do support IPv6) but not the kind that stateful firewalls protect against. Last time I checked stateful firewalls did not protect from browser and web server bugs nor from harmful email. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From owner-v6ops@ops.ietf.org Tue Mar 23 10:26:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6BC3A6CBC for ; Tue, 23 Mar 2010 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.593 X-Spam-Level: * X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkjGrnU6ltc7 for ; Tue, 23 Mar 2010 10:26:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B14E63A6CBF for ; Tue, 23 Mar 2010 10:26:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7qL-000GzN-U6 for v6ops-data0@psg.com; Tue, 23 Mar 2010 17:24:41 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7qI-000Gyt-3H for v6ops@ops.ietf.org; Tue, 23 Mar 2010 17:24:39 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Nu7qH-0001dSC; Tue, 23 Mar 2010 18:24 +0100 Message-Id: To: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops@ops.ietf.org Subject: Re: simple security From: Philip Homburg References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> <8cce4ee19c92e696c40fdd57371981c0@chewa.net> In-reply-to: Your message of "Tue, 23 Mar 2010 18:12:49 +0100 ." <8cce4ee19c92e696c40fdd57371981c0@chewa.net> Date: Tue, 23 Mar 2010 18:24:35 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Tue, 23 Mar 2010 18:12:49 +0100 you wrote: >There are remote holes in old unpatched systems (which are generally so old >that they don't support IPv6 anyway). Oh sure, there are plenty of holes in >modern systems (that do support IPv6) but not the kind that stateful >firewalls protect against. Last time I checked stateful firewalls did not >protect from browser and web server bugs nor from harmful email. So you are saying that the kinds of holes that stateful firewalls protect against are only to be found in old systems, and somehow in the past years the state of the art has advanced enough that new software has absolute none of those holes? Somehow, bugtraq seems to be full of all kinds of remote holes in current systems. A quote from just a random post: "A remote attacker can read, list and retrieve nearly all files on "the System remotely. Required is a valid samba account for a share "which is writeable OR a writeable share which is configured to be "a guest account share, in this case this is a preauth exploit. From owner-v6ops@ops.ietf.org Tue Mar 23 10:28:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FD33A6993 for ; Tue, 23 Mar 2010 10:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.57 X-Spam-Level: X-Spam-Status: No, score=-99.57 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czv-jfRxTP6y for ; Tue, 23 Mar 2010 10:28:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D2EC3A6984 for ; Tue, 23 Mar 2010 10:28:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7t5-000HPS-Pe for v6ops-data0@psg.com; Tue, 23 Mar 2010 17:27:31 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu7t2-000HOp-Ro for v6ops@ops.ietf.org; Tue, 23 Mar 2010 17:27:29 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id BE1A2196; Tue, 23 Mar 2010 18:27:27 +0100 (CET) To: IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion MIME-Version: 1.0 Date: Tue, 23 Mar 2010 18:27:27 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: References: <4BA78BE7.6010005@cisco.com> Message-ID: <6204173481567b7e39bc759ddee930d7@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 23 Mar 2010 09:00:21 -0700, Fred Baker wrote: > It comes down to this. We as a community have two views. We would like a > free and open Internet in which applications can be designed with an > expectation that they can communicate amongst themselves freely. We would > also like to have, and have a business need to provide for ourselves, the > ability to communicate only with peer applications that have our best > interests at heart. The history of humanity says that altruism is not a > pervasive trait, and the history of the Internet says that we behave on the > Internet the same way we do at home. > > My corporate IT folks tell me they drop something on the order of 98% of > the email sent to my account, 98% of which approximately 0% are filtered by a stateful firewall. > because only 2% behaves in a manner > consistent with good etiquette. > At the firewall in front of my home I > measure a 30 message per second standing load of messages from systems that > I have no reason to allow into my home. 30 messages of which 0 would actually hit an open port on the target system? (not to mention the extra entropy of IPv6 addresses) Otherwise I would reconsider my choice of software vendors if I were you... > For me, it comes down to the reason > I have a door on my home and it is equipped with a lock. But the garden in front of your house is hardly protected at all, unless you are really rich and/or a major potential target. You'll only check the guy's identity once he rings your door bell. Nobody said that you should let attackers deep into your computers. The point is, the IP stack and/or the host-local firewall is typically better at deciding what should and shouldn't go in than the CPE. Analogies will only get you that far. And then that's more state to be replicated into the (cheap small) CPE than is anyway already on the end system. (...) > This draft was commissioned to describe a simple stateful default-deny > firewall. What we decided yesterday that it would continue to describe is a > simple stateful default-deny firewall. Everyone doesn't have to install > one, and we decided as a group that we would have no recommendation whether > they should. But for those that choose to install a simple stateful > default-deny firewall, this note indicates how that should behave. That might be what the draft says and does not say. But lets face it. Vendors will interpret it as IETF recommends default-deny. I just need to check the position of most Cisco dudes here, and the job description of the main draft author (working on Apple Airport) to make myself confident about this. So. I am still left wondering what the point of IPv6 is if we have default-deny? Wouldn't it be simpler to keep IPv4 + NAT then? Three years after this draft came up and I raised this question, I am still lingering from an answer from the "default-deny" camp. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From owner-v6ops@ops.ietf.org Tue Mar 23 10:52:34 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17723A6D4D for ; Tue, 23 Mar 2010 10:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.333 X-Spam-Level: ** X-Spam-Status: No, score=2.333 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dElbfRK+jr5 for ; Tue, 23 Mar 2010 10:52:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A868B3A6D45 for ; Tue, 23 Mar 2010 10:52:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8G4-000LIm-Rz for v6ops-data0@psg.com; Tue, 23 Mar 2010 17:51:16 +0000 Received: from [72.14.220.157] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8G0-000LHs-Pg for v6ops@ops.ietf.org; Tue, 23 Mar 2010 17:51:13 +0000 Received: by fg-out-1718.google.com with SMTP id d23so1119940fga.17 for ; Tue, 23 Mar 2010 10:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=V5KLtuyPQqFZI1wko68f7xEk319mAhHwog59tom6LS0=; b=qrWy0XT5oRHGIbh+zJRiEgMdEtE6aJAuF4yapq5b0gtVLWHytehDiPAVE/fXpy1cLg YIAu5UEurKfrq2HsMT/u0CQPeIOYwziwDS2YrlDhu9VD6d+ZB7kehOgdbktWsxryeBeD aSO1WrxM2lCsnSN5CZJTkOJ5POOyw6OmCJh7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lOAP65lAV6u8YITB1whsp1JFepyVwQPZeczw8iZqEvB/oIiBuLj+Ag5+gSnV+V4v2q dicj5mfxB66dSepoQ8QJRdS8OBIVG3oRLoZUo1t4UGAqgPqNQ5VmxC8aC2+VLstmhjOA jP9qL84dyf34xM45m4/CSQfIIFlQGi8FRKimU= Received: by 10.87.2.15 with SMTP id e15mr7078917fgi.22.1269366671135; Tue, 23 Mar 2010 10:51:11 -0700 (PDT) Received: from [130.129.27.105] ([130.129.27.105]) by mx.google.com with ESMTPS id 3sm741243fge.20.2010.03.23.10.51.09 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 10:51:10 -0700 (PDT) Message-ID: <4BA8FF8C.1080708@gmail.com> Date: Wed, 24 Mar 2010 06:51:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: IPv6 Operations Subject: Re: On filibusters as a mode of technical discussion References: <4BA78BE7.6010005@cisco.com> <6204173481567b7e39bc759ddee930d7@chewa.net> In-Reply-To: <6204173481567b7e39bc759ddee930d7@chewa.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: R=C3=A9mi, Fred asked us to stop the discussion and move on. There are two views, and the next version of the draft will make it clear, as agreed yesterday, that this is the case. Having two views in the IETF is not unusual. Brian From owner-v6ops@ops.ietf.org Tue Mar 23 10:57:46 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8103C3A6CBF for ; Tue, 23 Mar 2010 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.332 X-Spam-Level: *** X-Spam-Status: No, score=3.332 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au4D0c+hsINa for ; Tue, 23 Mar 2010 10:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 516DC3A6C49 for ; Tue, 23 Mar 2010 10:43:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu86m-000Jb3-JB for v6ops-data0@psg.com; Tue, 23 Mar 2010 17:41:40 +0000 Received: from [93.17.128.19] (helo=smtp23.services.sfr.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu86k-000JaU-6B for v6ops@ops.ietf.org; Tue, 23 Mar 2010 17:41:38 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 4C8AA7000093; Tue, 23 Mar 2010 18:41:37 +0100 (CET) Received: from dhcp-wireless-open-abg-24-236.meeting.ietf.org (dhcp-wireless-open-abg-24-236.meeting.ietf.org [130.129.24.236]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 4C72D700008D; Tue, 23 Mar 2010 18:41:33 +0100 (CET) X-SFR-UUID: 20100323174134313.4C72D700008D@msfrf2302.sfr.fr Subject: Re: On saving end-to-end transparency Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5C44A45B-B6DF-486E-9210-C44A72049E50@marcoh.net> Date: Tue, 23 Mar 2010 10:41:31 -0700 Cc: IPv6 v6ops , Gert Doering , Fred Baker , Mark Townsley , Mohacsi Janos Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> <20100322160911.GU69383@Space.Net> <5C44A45B-B6DF-486E-9210-C44A72049E50@marcoh.net> To: Marco Hogewoning X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le 23 mars 2010 =E0 08:45, Marco Hogewoning a =E9crit : > So for now dropping all inbound connections feels good, expecially if = we want the masses to start using IPv6 fast. The fastest IPv6 deployment for masses took place 2 years ago (RFC 5569) The main perceivable advantage of enabling IPv6, in addition to IPv4, = was and still is direct inbound connectivity (used in particular with = BitTorrent). Purposely eliminating this advantage would create a legitimate reason to = remain IPv4-only. =20 > And yes there should be an easy button in that CPE/RG to disable that = firewall and yes it should come with a BIG warning about the risks they = just took. The conclusion has been in my understanding that vendors will chose = which is their default mode. Regards, RD= From owner-v6ops@ops.ietf.org Tue Mar 23 11:27:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FC13A6A2C for ; Tue, 23 Mar 2010 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.535 X-Spam-Level: *** X-Spam-Status: No, score=3.535 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyJTh2OtWtbS for ; Tue, 23 Mar 2010 11:27:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 219B43A6C65 for ; Tue, 23 Mar 2010 11:27:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8ip-0000Yc-64 for v6ops-data0@psg.com; Tue, 23 Mar 2010 18:20:59 +0000 Received: from [209.85.220.219] (helo=mail-fx0-f219.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8ii-0000V8-E9 for v6ops@ops.ietf.org; Tue, 23 Mar 2010 18:20:53 +0000 Received: by fxm19 with SMTP id 19so1033776fxm.19 for ; Tue, 23 Mar 2010 11:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=p39hg7QYPCjoMDH4QdaGvmhjKYrrip/exmT5U+KYPzo=; b=wCXxUTTcwddg9aaVxud1drPCD1yLyomARZhba60tz59JHViIbt0Tmxl7GI6oLHlldk a5wzQWHv5VAOcf4PkA+yEkJo2qMYp8oSzB6vD5xCD8M6HX9nUaRXr8QCMibVTTCpy34a IWjISkuIasU7E1WrWqko6IVf4V4i2SOnoDkRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Bfle98VHhmBgb7vqlOBBDlC6xuVTMnnFjIKKAcSPXpCQp4RhGIRkRMRpA7M6fwFfXC pW+AO7yT9FEb4bZlourGADUvEOsWmGnTFMLEbHx3rU/ysetXveP4SkjyTLv8z/xzK8SH Tx+I/QNsb1h5zBtkJUNkQjAYLCp56L0ZrOlW8= Received: by 10.223.132.197 with SMTP id c5mr5265489fat.35.1269368052279; Tue, 23 Mar 2010 11:14:12 -0700 (PDT) Received: from [130.129.27.127] ([130.129.27.127]) by mx.google.com with ESMTPS id d13sm2208677fka.32.2010.03.23.11.14.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 11:14:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 23 Mar 2010 11:14:00 -0700 Subject: Re: simple security From: Victor Kuarsingh To: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , Message-ID: Thread-Topic: simple security Thread-Index: AcrKtJxgcPICJhWVw0mWYneSjvJrWw== In-Reply-To: <201003231748.22841.remi@remlab.net> 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 List-ID: I would tend to agree with Jeffery and Lee Putting in baseline security from the outset would help protect the general user base as they move to IPv6. From an operators perspective, the average person has no idea how networks operate, how to secure them, and frankly don't care. They expect things to work - i.e. Buy a PC, buy a home gateway= , pug it in and go. I wish this was not the case, but wishful thinking gets me nowhere. I think that it's premature to assume the "home" network is ready for unrestricted connectivity. The dynamics of the "home" networks are changin= g so fast, that the risks of this environment are not known. Just because we have not seen IPv6 based penetration and attacks as we have in the IPv4 space does not mean it won't happen (just give is time). As an example, it took a while from the inception of mass broadband connectivity (90s-2000s) to finally see attackers lock on and begin to expose home environments base= d on "always" on connectivity. (in the early days, many did not have home firewalls or protective gateways) Protecting the average person, with an option to "open" the cpe/gateway up after provides a much safer framework. Someone who decides to "open" up th= e gateway after the fact would do so knowingly and be prepared (in theory) to protect their network (OS patching etc). No one has robbed me in my current house, but that does not mean I will sto= p locking my door. Sure they can come in through the window (which the few robberies in my area have been though) - but if I stop locking my door, the= y they will come in that way (much easier). Victor K On 23/03/10 8:48 AM, "R=E9mi Denis-Courmont" wrote: > On Tuesday 23 March 2010 16:02:18 Lee Howard, you wrote: >> The simple-security draft represents the best practice we know of for >> securing home networks. It describes the behavior that should be the >> default for all home networking gateways. Advanced users who know what >> they're getting into can change those default rules. >=20 > I've kept saying the same thing for three years now. But anyway. This > assertion raises the a much more systematic question: >=20 > What's the use of IPv6 (then)? IPv6 with a stateful firewall is essential= ly > just as bad as IPv4 with a NAT in terms of connectivity. Also IPv6 has > fundamentally higher overhead (both in terms of packet header size and of > router processing). >=20 > So the simple security draft seems highly paradoxical to me. A "solution" > would be to specify a functional hole punching mechanism. But that key pa= rt > part is missing. I am not comfortable with having the simple security doc= ument > without a hole punching document too. >=20 > Some people will doubtless argue that there should not be a hole punching > mechanism. But then, I would like them to answer the question above... > (Standardization engineer job security is not a good reason for IPv6 to m= e) >=20 >> Some people argued that a stateful firewall is no longer needed because >> attackers no longer use vectors that a firewall protects against. This >> sounds like circular reasoning to me, as if you no longer need a roof >> because rain hasn't fallen on your head for years. >=20 > Do you take vaccinations for illenesses that don't exist anymore? Most pe= ople > don't even take vaccinations for some that do exist but not where they li= ve. >=20 > Why would you protect IPv6 systems for old (now fixed) vulnerabilities in= IPv4 > systems? >=20 >> It was also argued that attacks of this kind simply don't exist in IPv6. >=20 > Which is true. >=20 >> That sounds like the argument that faults in the space shuttle o-ring >> haven't caused explosions before, so it's safe. >=20 > No. It's just an argument that operating systems have already been fixed > *before* they implemented IPv6. Common attack vectors are in different > (higher) parts of the software stack, against which stateful firewalls ar= e > totally helpless. >=20 >> I'll also point out that >> OSes with smaller market share have fewer exploits written for them beca= use >> they are a smaller target; as IPv6 exceeds 50%, there will be more attac= ks. >=20 > That is a severe misrepresentation of reality. You will find exploits wri= tten > for very obscure vulnerabilities. Of course, they are not commonly (mis)u= sed, > but they are available. From owner-v6ops@ops.ietf.org Tue Mar 23 11:30:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404AD3A6CA2 for ; Tue, 23 Mar 2010 11:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.07 X-Spam-Level: X-Spam-Status: No, score=-99.07 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beEV7ab39oCO for ; Tue, 23 Mar 2010 11:30:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A1853A6CB8 for ; Tue, 23 Mar 2010 11:30:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8rK-0001Uy-Ps for v6ops-data0@psg.com; Tue, 23 Mar 2010 18:29:46 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu8rI-0001UX-52 for v6ops@ops.ietf.org; Tue, 23 Mar 2010 18:29:44 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 1A026A9B; Tue, 23 Mar 2010 19:29:43 +0100 (CET) To: Philip Homburg Subject: Re: simple security MIME-Version: 1.0 Date: Tue, 23 Mar 2010 19:29:43 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> <8cce4ee19c92e696c40fdd57371981c0@chewa.net> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 23 Mar 2010 18:24:35 +0100, Philip Homburg wrote: > So you are saying that the kinds of holes that stateful firewalls protect > against are only to be found in old systems, and somehow in the past years > the state of the art has advanced enough that new software has absolute > none of those holes? So you are saying that IPv6 is useless? (yes, I am also able to leverage selective quoting to my own advantage) Why would I want to deploy IPv6 to my home if it's just like IPv4 but slower and more expensive? -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From owner-v6ops@ops.ietf.org Tue Mar 23 11:44:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC65C3A686C for ; Tue, 23 Mar 2010 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.765 X-Spam-Level: X-Spam-Status: No, score=-100.765 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV0nyXOPvQcd for ; Tue, 23 Mar 2010 11:44:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 719F63A67E3 for ; Tue, 23 Mar 2010 11:44:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu94D-0003lm-1l for v6ops-data0@psg.com; Tue, 23 Mar 2010 18:43:05 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu94A-0003jF-WA for v6ops@ops.ietf.org; Tue, 23 Mar 2010 18:43:03 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 950278AB2C8D for ; Tue, 23 Mar 2010 11:43:02 -0700 (PDT) X-AuditID: 11807130-b7bdcae000007b51-6b-4ba90bb65eab Received: from [17.151.100.185] (Unknown_Domain [17.151.100.185]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 8B.2B.31569.6BB09AB4; Tue, 23 Mar 2010 11:43:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: On filibusters as a mode of technical discussion From: james woodyatt In-Reply-To: <4BA8FF8C.1080708@gmail.com> Date: Tue, 23 Mar 2010 11:43:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> <6204173481567b7e39bc759ddee930d7@chewa.net> <4BA8FF8C.1080708@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 23, 2010, at 10:51, Brian E Carpenter wrote: >=20 > Fred asked us to stop the discussion and move on. There are two > views, and the next version of the draft will make it clear, as > agreed yesterday, that this is the case. Having two views in the > IETF is not unusual. I'm confident that the draft we will take to WGLC will make it clear to = everyone that IETF is not making any recommendation about whether IPv6 = residential gateways should or should not have Simple Security = capabilities enabled in their DEFAULT modal configuration. What it will = say is that *if* a gateway has Simple Security capabilities, then here = is what applications may expect those capabilities to be if our = recommendations are followed by gateway vendors. I'm quite comfortable with this outcome to our efforts. I'll be posting = the -10 revision on Friday before I return home to San Francisco. If = anyone has new technical issues to bring to the working group, then you = are invited to surface them now. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Tue Mar 23 12:14:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11D93A6B77 for ; Tue, 23 Mar 2010 12:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.903 X-Spam-Level: X-Spam-Status: No, score=-98.903 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAVIubo3Ej8n for ; Tue, 23 Mar 2010 12:14:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70EAA3A6A2E for ; Tue, 23 Mar 2010 12:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu9Wd-000AcW-NA for v6ops-data0@psg.com; Tue, 23 Mar 2010 19:12:27 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nu9Wb-000Abf-11 for v6ops@ops.ietf.org; Tue, 23 Mar 2010 19:12:25 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 9453CAC4; Tue, 23 Mar 2010 20:12:21 +0100 (CET) To: Victor Kuarsingh Subject: Re: simple security MIME-Version: 1.0 Date: Tue, 23 Mar 2010 20:12:21 +0100 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: References: Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 23 Mar 2010 11:14:00 -0700, Victor Kuarsingh wrote: > I think that it's premature to assume the "home" network is ready for > unrestricted connectivity. The dynamics of the "home" networks are > changing so fast, that the risks of this environment are not known. I said we need a ***hole punching*** mechanism. Without hole punching application programmers will be stuck with UDP for peer-to-peer use cases. And that's not good (I'd expect the IETF Transport Area not be very happy with that, but IANAAD). No connection semantics, no error correction, no flow/congestion control. If my memory is not failing too badly, James Woodyatt also had a companion draft for that purpose. But it's now defunct a document. Then there is the proven issue that battery powered devices cannot cope with stateful firewalling too well, unless the timeouts are long and _known_. Typically they are short (especially for UDP). And with stateful firewalling they aren't known. If the timeouts are not known, the application ends up making the most pessimistic assumption (i.e. less than 30 seconds). That's not sustainable with the current battery technology, and won't be for years to come if the experts of that domain are to be trusted. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From uo@megatron.ietf.org Tue Mar 23 20:17:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A894F3A6C24 for ; Tue, 23 Mar 2010 20:17:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 23 Mar 2010 20:17:02 -0700 (PDT) Received: from alcoa.com.au (unknown [186.80.81.183]) by core3.amsl.com (Postfix) with SMTP id A9C963A6C19 for ; Tue, 23 Mar 2010 20:16:59 -0700 (PDT) From: Approved VIAGRA® Store Subject: New Private Message for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100324031701.A9C963A6C19@core3.amsl.com> Date: Tue, 23 Mar 2010 20:16:59 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78868 Inc. All rights reserved.

From urn-archive@ietf.org Tue Mar 23 22:04:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962263A6CFC for ; Tue, 23 Mar 2010 22:04:32 -0700 (PDT) X-Quarantine-ID: <6iwdyNUAAfjm> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 23 Mar 2010 22:04:26 -0700 (PDT) Received: from alicante-ayto.es (unknown [122.163.26.186]) by core3.amsl.com (Postfix) with SMTP id C82FA3A6860 for ; Tue, 23 Mar 2010 22:03:05 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Discount 76% for v6ops-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100324050310.C82FA3A6860@core3.amsl.com> Date: Tue, 23 Mar 2010 22:03:05 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 93119 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 23 22:51:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677983A6CC6 for ; Tue, 23 Mar 2010 22:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.406 X-Spam-Level: ** X-Spam-Status: No, score=2.406 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkCw+XPLEqRr for ; Tue, 23 Mar 2010 22:51:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2AE3E3A6CBE for ; Tue, 23 Mar 2010 22:51:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuJQa-0009R3-ER for v6ops-data0@psg.com; Wed, 24 Mar 2010 05:46:52 +0000 Received: from [194.15.141.107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuJQU-0009QY-C3 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 05:46:46 +0000 Received: from dhcp-wireless-open-abg-25-51.meeting.ietf.org (unknown [130.129.25.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 2A1842E027; Wed, 24 Mar 2010 06:16:29 +0100 (CET) Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2140--964528249" From: Lindqvist Kurt Erik In-Reply-To: <201003231748.22841.remi@remlab.net> Date: Wed, 24 Mar 2010 04:14:07 +0100 Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <65D91B6D-FFC5-4183-892C-307708B4E1F6@kurtis.pp.se> References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2140--964528249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 23 mar 2010, at 16.48, R=E9mi Denis-Courmont wrote: >>=20 >> It was also argued that attacks of this kind simply don't exist in = IPv6. >=20 > Which is true. >=20 >> That sounds like the argument that faults in the space shuttle o-ring >> haven't caused explosions before, so it's safe. >=20 > No. It's just an argument that operating systems have already been = fixed=20 > *before* they implemented IPv6. Common attack vectors are in different=20= > (higher) parts of the software stack, against which stateful firewalls = are=20 > totally helpless. If we believe that the attacks that today exist in IPv4 won't exist in = IPv6 I think we are highly underestimating the investments in the = underground economy. I am convinced we will see the same level of = attacks and exploits for IPv6 as for IPv4. That said, I am not convinced = that any security in the CPE will protect against that, just as NAT = didn't protect in IPv4. However, I don't think that is the issue that we = are trying to address with the simple security draft.=20 Best regards, - kurtis - --Apple-Mail-2140--964528249 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkupg38ACgkQAFdZ6xrc/t7o8ACgqgSNe4QYFPJnhGSjf/Z0orSG UVMAoMWdVEBxl3PaR2SNy79L5cQorwpz =AiXS -----END PGP SIGNATURE----- --Apple-Mail-2140--964528249-- From owner-v6ops@ops.ietf.org Tue Mar 23 22:52:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B5F3A6CC6 for ; Tue, 23 Mar 2010 22:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.719 X-Spam-Level: ** X-Spam-Status: No, score=2.719 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc5Ztamc6Lnt for ; Tue, 23 Mar 2010 22:52:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E059F3A6CBE for ; Tue, 23 Mar 2010 22:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuJVU-000A6P-5y for v6ops-data0@psg.com; Wed, 24 Mar 2010 05:51:56 +0000 Received: from [194.15.141.107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuJVR-000A63-Sp for v6ops@ops.ietf.org; Wed, 24 Mar 2010 05:51:54 +0000 Received: from dhcp-wireless-open-abg-25-51.meeting.ietf.org (unknown [130.129.25.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 2EBDA2E039; Wed, 24 Mar 2010 06:17:52 +0100 (CET) Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2142--960872742" From: Lindqvist Kurt Erik In-Reply-To: Date: Wed, 24 Mar 2010 05:15:03 +0100 Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Content-Transfer-Encoding: 7bit Message-Id: References: To: Victor Kuarsingh X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2142--960872742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 mar 2010, at 19.14, Victor Kuarsingh wrote: >=20 > I think that it's premature to assume the "home" network is ready for > unrestricted connectivity. The dynamics of the "home" networks are = changing > so fast, that the risks of this environment are not known. Just = because we > have not seen IPv6 based penetration and attacks as we have in the = IPv4 > space does not mean it won't happen (just give is time). As an = example, it > took a while from the inception of mass broadband connectivity = (90s-2000s) > to finally see attackers lock on and begin to expose home environments = based > on "always" on connectivity. (in the early days, many did not have = home > firewalls or protective gateways) And here I think we have the core of the issue. I think we all agree = that the advantages of IPv6 is more address space, and hence we can = again restore end-to-end connectivity. However, at the same time we know = that some network services are inherently insecure - IPv4 or IPV6. I = would for example not run rsh on IPv6 just as little as I would over = IPv4. =46rom what I remember us discussing back in Philadelphia (I think = it was) was that we need to agree on a minimum of these services that we = believe should be filtered out. I'd like us to refocuse to that = discussion - which services are we convinced we can block, and will = provide additional security for the end-user (like rsh6) and at the same = time not limiting future services for the end-user.=20 So, as I see this - the entire discussion seems to have focused on the = inbound traffic capability, where three options exists 1) Leave open and allow any traffic (that is not filtered on port) in 2) Only allow traffic that has been initiated from the inside to be = passed through 3) Some hole-punching mechanism + 2) Now, James said the next draft will make it clear this is not an IETF = recommendation, just an outline of what you want to filter when you do = advertise simple CPE security.=20 Best regards, - kurtis -= --Apple-Mail-2142--960872742 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkupkccACgkQAFdZ6xrc/t7FfACgtmnUgEUKeEdETfmZ2mcFBFzA 9+4AoMCkMp8Sws2ff1gqt2XaeCtPgIF1 =QeJb -----END PGP SIGNATURE----- --Apple-Mail-2142--960872742-- From owner-v6ops@ops.ietf.org Tue Mar 23 23:40:19 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADE53A67B0 for ; Tue, 23 Mar 2010 23:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.593 X-Spam-Level: *** X-Spam-Status: No, score=3.593 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKVu3at8G+X1 for ; Tue, 23 Mar 2010 23:40:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1B4F3A67EA for ; Tue, 23 Mar 2010 23:40:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuKFa-000FwM-Fw for v6ops-data0@psg.com; Wed, 24 Mar 2010 06:39:34 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuKFY-000Fw5-FQ for v6ops@ops.ietf.org; Wed, 24 Mar 2010 06:39:32 +0000 Received: from [165.228.63.69] (helo=[192.168.1.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1NuKFO-0005Mu-Df; Wed, 24 Mar 2010 17:39:22 +1100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 24 Mar 2010 17:39:08 +1100 Subject: Re: simple security From: Hesham Soliman To: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , Victor Kuarsingh CC: Message-ID: Thread-Topic: simple security Thread-Index: AcrLHLRs7e0SCGMb7UywSvSGGXUtCw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 24/03/10 6:12 AM, "R=E9mi Denis-Courmont" wrote: >=20 > On Tue, 23 Mar 2010 11:14:00 -0700, Victor Kuarsingh >=20 > wrote: >=20 >> I think that it's premature to assume the "home" network is ready for >=20 >> unrestricted connectivity. The dynamics of the "home" networks are >=20 >> changing so fast, that the risks of this environment are not known. >=20 >=20 >=20 > I said we need a ***hole punching*** mechanism. >=20 >=20 >=20 > Without hole punching application programmers will be stuck with UDP for >=20 > peer-to-peer use cases. And that's not good (I'd expect the IETF Transpor= t >=20 > Area not be very happy with that, but IANAAD). No connection semantics, n= o >=20 > error correction, no flow/congestion control. If my memory is not failing >=20 > too badly, James Woodyatt also had a companion draft for that purpose. Bu= t >=20 > it's now defunct a document. =3D> FYI We tried this in: http://tools.ietf.org/id/draft-soliman-firewall-control-01.txt There might be other proposals but I belief the strength of this proposal i= s the effective plug n play security feature of CGAs. Hesham >=20 >=20 >=20 > Then there is the proven issue that battery powered devices cannot cope >=20 > with stateful firewalling too well, unless the timeouts are long and >=20 > _known_. Typically they are short (especially for UDP). And with stateful >=20 > firewalling they aren't known. If the timeouts are not known, the >=20 > application ends up making the most pessimistic assumption (i.e. less tha= n >=20 > 30 seconds). That's not sustainable with the current battery technology, >=20 > and won't be for years to come if the experts of that domain are to be >=20 > trusted. >=20 >=20 From owner-v6ops@ops.ietf.org Tue Mar 23 23:40:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF753A67EA for ; Tue, 23 Mar 2010 23:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.059 X-Spam-Level: *** X-Spam-Status: No, score=3.059 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz4c8p50Us0D for ; Tue, 23 Mar 2010 23:40:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C8EB3A67F7 for ; Tue, 23 Mar 2010 23:40:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuKEU-000Fpz-Hr for v6ops-data0@psg.com; Wed, 24 Mar 2010 06:38:26 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuKER-000Fpc-Je for v6ops@ops.ietf.org; Wed, 24 Mar 2010 06:38:24 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NuKEG-0000cD-6l; Wed, 24 Mar 2010 17:08:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A55184930C; Wed, 24 Mar 2010 17:08:11 +1030 (CST) Date: Wed, 24 Mar 2010 17:08:11 +1030 From: Mark Smith To: Victor Kuarsingh Cc: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , Subject: Re: simple security Message-ID: <20100324170811.7c88cd64@opy.nosense.org> In-Reply-To: References: <201003231748.22841.remi@remlab.net> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 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 List-ID: On Tue, 23 Mar 2010 11:14:00 -0700 Victor Kuarsingh wrote: > I would tend to agree with Jeffery and Lee >=20 > Putting in baseline security from the outset would help protect the gener= al > user base as they move to IPv6. From an operators perspective, the avera= ge > person has no idea how networks operate, how to secure them, and frankly > don't care. They expect things to work - i.e. Buy a PC, buy a home gatew= ay, > pug it in and go. I wish this was not the case, but wishful thinking gets > me nowhere. >=20 And that is exactly why all end-node OSes have been shipped with firewalls in the last 5+ years, enabled by default. That is exactly why smart mobile phones haven't been widely exploited when they've been directly attached to the Internet. They're shipped with firewalls, enabled by default. Laptops are outselling desktops. Laptops can and are directly attached to foreign networks, including the Internet, without security consideration. People plug 3G dongles and similar straight into their laptops, without any security consideration, and then straight into the Internet. Put your hand up if you have a smart mobile phone. Now put it down if you checked it had a firewall and it was enabled before you attached it to a foreign untrusted network (like the IETF one). Hand still up? The CPE/perimeter firewall model is based on an assumption of constraints on mobility - your desktop PC stays on your desk, and stays attached to the same home or work network. That assumption is rapidly becoming less valid - people are going mobile, and therefore, security models like the upstream CPE doing everything are becoming both less valid and less reliable. Vendors have reacted by making the devices themselves protect themselves. That trend is only going to continue. > I think that it's premature to assume the "home" network is ready for > unrestricted connectivity. The dynamics of the "home" networks are chang= ing > so fast, that the risks of this environment are not known. Just because = we > have not seen IPv6 based penetration and attacks as we have in the IPv4 > space does not mean it won't happen (just give is time). As an example, = it > took a while from the inception of mass broadband connectivity (90s-2000s) > to finally see attackers lock on and begin to expose home environments ba= sed > on "always" on connectivity. (in the early days, many did not have home > firewalls or protective gateways) >=20 > Protecting the average person, with an option to "open" the cpe/gateway up > after provides a much safer framework. Someone who decides to "open" up = the > gateway after the fact would do so knowingly and be prepared (in theory) = to > protect their network (OS patching etc). >=20 > No one has robbed me in my current house, but that does not mean I will s= top > locking my door. Sure they can come in through the window (which the few > robberies in my area have been though) - but if I stop locking my door, t= hey > they will come in that way (much easier). >=20 > Victor K >=20 >=20 > On 23/03/10 8:48 AM, "R=E9mi Denis-Courmont" wrote: >=20 > > On Tuesday 23 March 2010 16:02:18 Lee Howard, you wrote: > >> The simple-security draft represents the best practice we know of for > >> securing home networks. It describes the behavior that should be the > >> default for all home networking gateways. Advanced users who know what > >> they're getting into can change those default rules. > >=20 > > I've kept saying the same thing for three years now. But anyway. This > > assertion raises the a much more systematic question: > >=20 > > What's the use of IPv6 (then)? IPv6 with a stateful firewall is essenti= ally > > just as bad as IPv4 with a NAT in terms of connectivity. Also IPv6 has > > fundamentally higher overhead (both in terms of packet header size and = of > > router processing). > >=20 > > So the simple security draft seems highly paradoxical to me. A "solutio= n" > > would be to specify a functional hole punching mechanism. But that key = part > > part is missing. I am not comfortable with having the simple security d= ocument > > without a hole punching document too. > >=20 > > Some people will doubtless argue that there should not be a hole punchi= ng > > mechanism. But then, I would like them to answer the question above... > > (Standardization engineer job security is not a good reason for IPv6 to= me) > >=20 > >> Some people argued that a stateful firewall is no longer needed because > >> attackers no longer use vectors that a firewall protects against. This > >> sounds like circular reasoning to me, as if you no longer need a roof > >> because rain hasn't fallen on your head for years. > >=20 > > Do you take vaccinations for illenesses that don't exist anymore? Most = people > > don't even take vaccinations for some that do exist but not where they = live. > >=20 > > Why would you protect IPv6 systems for old (now fixed) vulnerabilities = in IPv4 > > systems? > >=20 > >> It was also argued that attacks of this kind simply don't exist in IPv= 6. > >=20 > > Which is true. > >=20 > >> That sounds like the argument that faults in the space shuttle o-ring > >> haven't caused explosions before, so it's safe. > >=20 > > No. It's just an argument that operating systems have already been fixed > > *before* they implemented IPv6. Common attack vectors are in different > > (higher) parts of the software stack, against which stateful firewalls = are > > totally helpless. > >=20 > >> I'll also point out that > >> OSes with smaller market share have fewer exploits written for them be= cause > >> they are a smaller target; as IPv6 exceeds 50%, there will be more att= acks. > >=20 > > That is a severe misrepresentation of reality. You will find exploits w= ritten > > for very obscure vulnerabilities. Of course, they are not commonly (mis= )used, > > but they are available. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Mar 24 01:45:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA19D3A68BD for ; Wed, 24 Mar 2010 01:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYJvwlsHqC62 for ; Wed, 24 Mar 2010 01:45:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1F553A676A for ; Wed, 24 Mar 2010 01:45:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuM9o-0008Cd-PW for v6ops-data0@psg.com; Wed, 24 Mar 2010 08:41:44 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuM9m-0008CI-LC for v6ops@ops.ietf.org; Wed, 24 Mar 2010 08:41:42 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,300,1267401600"; d="scan'208";a="501963543" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2010 08:41:42 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2O8fg0W027401; Wed, 24 Mar 2010 08:41:42 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2O8fYY23317; Wed, 24 Mar 2010 01:41:34 -0700 (PDT) Message-ID: <4BA9D03C.1010204@cisco.com> Date: Wed, 24 Mar 2010 09:41:32 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mohacsi Janos CC: "Hemant Singh (shemant)" , Brian E Carpenter , alh-ietf@tndh.net, IPv6 Operations Subject: Re: RFC 5006 status References: <4B9E96E2.10108@piuha.net> <1315FBDA-12A2-4C16-B66F-CBD4802E6766@cisco.com> <4BA089F9.5010006@piuha.net> <65B6B54D-98AD-4772-B2E0-6E2CA8DE76C0@cisco.com> <419DB14D-BFDC-4118-BB3E-F4D9570D927D@kurtis.pp.se> <4BA0EC66.3010403@piuha.net> <308C7176-40DF-4F82-AC2D-A4EAC6E2766B@cisco.com> <20100322162757.GV69383@Space.Net> <01a001cac9e8$f703fdb0$e50bf910$@net> <4BA7FE90.1090006@gmail.com> 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 List-ID: On 3/23/10 2:42 PM, Mohacsi Janos wrote: > > I think BEHAVE and other DNS64 users has to be asked if they are > confortable with the RFC 5006 style DNS propagation or not. And since 5006 is implemented, they'd be wise to take this into account regardless of what its status as an IETF document remains. The running code is already there, DNS64 needs to deal with it. - Mark > > Best Regards, > Janos Mohacsi > > > From owner-v6ops@ops.ietf.org Wed Mar 24 02:53:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8D33A686E for ; Wed, 24 Mar 2010 02:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.61 X-Spam-Level: X-Spam-Status: No, score=-99.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GDJk5asIupn for ; Wed, 24 Mar 2010 02:53:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA8E03A6B0E for ; Wed, 24 Mar 2010 02:53:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuNDa-000ILO-KA for v6ops-data0@psg.com; Wed, 24 Mar 2010 09:49:42 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuNDY-000IE9-Q1 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 09:49:40 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o2O9mxxf008465; Wed, 24 Mar 2010 09:48:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o2O9mx1j008464; Wed, 24 Mar 2010 09:48:59 GMT Date: Wed, 24 Mar 2010 09:48:59 +0000 From: bmanning@vacation.karoshi.com To: Fred Baker Cc: IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion Message-ID: <20100324094859.GC6391@vacation.karoshi.com.> References: <4BA78BE7.6010005@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, Mar 23, 2010 at 09:00:21AM -0700, Fred Baker wrote: > > This draft was commissioned to describe a simple stateful default-deny firewall. What we decided yesterday that it would continue to describe is a simple stateful default-deny firewall. Everyone doesn't have to install one, and we decided as a group that we would have no recommendation whether they should. But for those that choose to install a simple stateful default-deny firewall, this note indicates how that should behave. > if i may, if this draft was commissioned (by whom?) then it seems prudent to also have a draft to descrbe a simple, stateful default-accept firewall if only to provide a balanced choice. Otherwise we (the IETF) end up with only a single choice defined and after all, if there is only a single choice, what choice is there? --bill From owner-v6ops@ops.ietf.org Wed Mar 24 04:19:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FD93A6B2B for ; Wed, 24 Mar 2010 04:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPgG43SwD67q for ; Wed, 24 Mar 2010 04:19:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2AADE3A6B4B for ; Wed, 24 Mar 2010 04:19:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOZ1-0004ds-3U for v6ops-data0@psg.com; Wed, 24 Mar 2010 11:15:55 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOYy-0004dc-Fo for v6ops@ops.ietf.org; Wed, 24 Mar 2010 11:15:52 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE6RqUurRN+K/2dsb2JhbACbInOlWZkThH4E X-IronPort-AV: E=Sophos;i="4.51,300,1267401600"; d="scan'208";a="104884702" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 11:15:51 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OBFpE1023077; Wed, 24 Mar 2010 11:15:51 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OBFoY07329; Wed, 24 Mar 2010 04:15:50 -0700 (PDT) Message-ID: <4BA9F465.8060608@cisco.com> Date: Wed, 24 Mar 2010 12:15:49 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Lee Howard CC: v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> In-Reply-To: <001501caca91$769511b0$63bf3510$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/23/10 3:02 PM, Lee Howard wrote: > > The simple-security draft represents the best practice we know of for > securing home networks. > It's not a best-practice, it's a best-guess. Simple-security is being not being practiced at all on the vast majority of IPv6 residential connections today. > It describes the behavior that should be the default for all home > networking gateways. Advanced users who know what they're getting > into can change those default rules. > I'll argue the contrary. Advanced users know how to manually poke holes in firewalls, run the right version of UPnP or NAT-PMP running, etc. Non-advanced users do not. It's the non-advanced users that need protocols to "just work". Firewalls make networking more frustrating, particularly for the non-advanced users. > > Some people argued that a stateful firewall is no longer needed > because attackers no longer use vectors that a firewall protects > against. This sounds like circular reasoning to me, as if you no > longer need a roof because rain hasn't fallen on your head for years. > If everyone has an umbrella and rain-suit anyway, what good is the roof doing? Yes, I know there are still OSes that will be compromised in a matter of seconds on the open Internet. These, however, do not run IPv6. With IPv6, we are really talking about Vista, Win 7, linux, and macosx. All ship with IPv6 firewalls (except linux I suppose), and far more secure IP stacks vs. that of ten years ago. All have tethers back home for updates, in the event that a new exploit is found. These firewalls are far more adaptive and secure than the "IPv6 simple-security" firewall. I don't want any of these new IPv6-enabled OSes to think for a moment that they can let their guard down just because they are plugged into a firewalled residential gateway "most of the time". > > It was also argued that attacks of this kind simply don't exist in > IPv6. That sounds like the argument that faults in the space shuttle > o-ring haven't caused explosions before, so it's safe. > Bad analogy. The O-ring problem wasn't because of a hacker, it was human/engineering error in a complex system. A bug. Rather than protecting against bugs, firewalls increase the possibility of having more bugs. > I'll also point out that OSes with smaller market share have fewer > exploits written for them because they are a smaller target; as IPv6 > exceeds 50%, there will be more attacks. > Simple-security loses its effectiveness considerably for a home with no roaming devices. By the time IPv6 exceeds 50%, what do you think home networks will look like? The perimeter is getting very porous, and a "simple" firewall designed around the idea of a fixed home with stationary devices and a hard perimeter will be ineffective and obsolete. This is why the only "firewall" I can consider for a moment to help with security is one that actively detects whether hosts inside the home as well as traffic coming from outside the home constitutes a security breach. The "security cop" on the edge isn't so much a device trying to black-hole traffic initiated from one direction or another, it is watching the traffic to see if devices in your home network are compromised or being attacked. This even works when the attack vector comes in via an email attachment, because it can watch the traffic patterns of an infected host connecting back to its lair and shut it down accordingly. "simple-security" is "simple-minded". It is based on a security-model that is rapidly becoming obsolete, and comes at the cost of complexity in both the RG, the host, and the applications that have to try and work despite all the various rules for having their packets dropped. > I disagreed at the mike with the argument that ISPs should be doing > this kind of filtering themselves. I'd like to understand that > argument better. If ISPs should be providing stateful firewall > service, then doesn't that support the need for a draft documenting > what ISPs should do? > The problem with any draft defining what kind of security an ISP or a gateway should do is that it is by definition a moving target. Security is, always has been, an arms race. Which is why I think that if we should define anything it should be the base rules and interfaces for updating those rules in response to the threats. Any static document is going to be obsolete to the hackers before it is even becomes an RFC. > Yes, hosts should provide better security for themselves. > One reason the older ones don't, is that nat-firewalls have provided protection for them during a time when hosts were mostly stationary and not updated regularly. Today, hosts must be able to deal with operating in a multitude of environments. The idea that I have a home with no roaming clients, or can sell an OS that cannot exist with or without a firewall protect it, is very much a 10-year-old reality. If there is one advantage IPv6 does give us, is that it lets us draw a line between old IP stacks and the OSes they are attached to and new ones. It wouldn't be sensible for us not to exploit that. > In some regions, users install three or four security packages on > their computers, but even their almost 50% of machines are infected. > Blocking the easiest paths to exploits using perimeter security is > current best practice, and should be documented as such. > Those regions probably need advanced-security, not simple-security. Simple-security with IPv6 probably isn't going to help that much, the hackers will still find their way in, as is clear from the infection rate. - Mark From owner-v6ops@ops.ietf.org Wed Mar 24 04:27:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B6E3A67B5 for ; Wed, 24 Mar 2010 04:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.028 X-Spam-Level: X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvj06l+6F1sv for ; Wed, 24 Mar 2010 04:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 038F93A6405 for ; Wed, 24 Mar 2010 04:27:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOj8-0005xG-9U for v6ops-data0@psg.com; Wed, 24 Mar 2010 11:26:22 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOj5-0005wn-Ri for v6ops@ops.ietf.org; Wed, 24 Mar 2010 11:26:19 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB6UqUurRN+K/2dsb2JhbACbIXOlcYsYCY1xgkUmghME X-IronPort-AV: E=Sophos;i="4.51,300,1267401600"; d="scan'208";a="171392851" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 11:26:19 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OBQJGB026632; Wed, 24 Mar 2010 11:26:19 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OBQHY24494; Wed, 24 Mar 2010 04:26:17 -0700 (PDT) Message-ID: <4BA9F6D8.50207@cisco.com> Date: Wed, 24 Mar 2010 12:26:16 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Dunn, Jeffrey H." CC: Lee Howard , "v6ops@ops.ietf.org" Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <3C6F21684E7C954193E6C7C4573B762703A8F5CAD1@IMCMBX1.MITRE.ORG> In-Reply-To: <3C6F21684E7C954193E6C7C4573B762703A8F5CAD1@IMCMBX1.MITRE.ORG> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/23/10 3:39 PM, Dunn, Jeffrey H. wrote: > > Lee, > > I agree. To amplify on your position, I offer the following. Many > jurisdictions have draconian statues defining illicit Internet > activity, e.g., child pornography, and associated stringent penalties, > e.g., lengthy incarceration. If there is a perception that the use of > IPv6 unique globally routable unicast addresses (UGA) increases a > consumers risk of inadvertently violating one of the statute because > a compromise of their home systems or network, adoption of IPv6 by > consumers will be minimal. > Someone would have to create the perception that UGA == increased threat of hosting child pornography. > > In addition, applying simple security controls such as least > functionality is both sound and responsible. Specifically, if home > networks are not supporting servers, e.g., web sites, then there is no > need to allows sessions associated with servers to be initiated by > Internet hosts. > The idea that the simple-security mechanism denies willing or protects unwilling users from hosting pornography would not be grounded in technical reality. The IETF should not for a second help create this incorrect perception. - Mark PS. We have a SHOULD in the simple-security document for implementation of a protocol that allows a host to open a pinhole in the firewall on demand. If that comes into existence, running a web server is as readily possible with the firewall as without. > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > > (301) 448-6965 (mobile) > > *From:* owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] *On > Behalf Of *Lee Howard > *Sent:* Tuesday, March 23, 2010 10:02 AM > *To:* v6ops@ops.ietf.org > *Subject:* simple security > > The simple-security draft represents the best practice we know of for > securing home networks. It describes the behavior that should be the > default for all home networking gateways. Advanced users who know what > they're getting into can change those default rules. > > Some people argued that a stateful firewall is no longer needed > because attackers no longer use vectors that a firewall protects > against. This sounds like circular reasoning to me, as if you no > longer need a roof because rain hasn't fallen on your head for years. > > It was also argued that attacks of this kind simply don't exist in > IPv6. That sounds like the argument that faults in the space shuttle > o-ring haven't caused explosions before, so it's safe. I'll also point > out that OSes with smaller market share have fewer exploits written > for them because they are a smaller target; as IPv6 exceeds 50%, there > will be more attacks. > > I disagreed at the mike with the argument that ISPs should be doing > this kind of filtering themselves. I'd like to understand that > argument better. If ISPs should be providing stateful firewall > service, then doesn't that support the need for a draft documenting > what ISPs should do? > > Yes, hosts should provide better security for themselves. In some > regions, users install three or four security packages on their > computers, but even their almost 50% of machines are infected. > Blocking the easiest paths to exploits using perimeter security is > current best practice, and should be documented as such. > > Lee > From owner-v6ops@ops.ietf.org Wed Mar 24 04:35:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5203A688B for ; Wed, 24 Mar 2010 04:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6OEuukGSwj6 for ; Wed, 24 Mar 2010 04:35:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB65B3A6877 for ; Wed, 24 Mar 2010 04:35:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOqy-0006vd-9N for v6ops-data0@psg.com; Wed, 24 Mar 2010 11:34:28 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuOqw-0006uY-Bk for v6ops@ops.ietf.org; Wed, 24 Mar 2010 11:34:26 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIaVqUurRN+K/2dsb2JhbACbIXOlapkShH4E X-IronPort-AV: E=Sophos;i="4.51,300,1267401600"; d="scan'208";a="502047064" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2010 11:34:25 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OBYPqx029477; Wed, 24 Mar 2010 11:34:25 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OBYOY06980; Wed, 24 Mar 2010 04:34:24 -0700 (PDT) Message-ID: <4BA9F8BF.3070503@cisco.com> Date: Wed, 24 Mar 2010 12:34:23 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Victor Kuarsingh CC: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Subject: Re: simple security References: 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 List-ID: On 3/23/10 7:14 PM, Victor Kuarsingh wrote: > I would tend to agree with Jeffery and Lee > > Putting in baseline security from the outset would help protect the general > user base as they move to IPv6. From an operators perspective, the average > person has no idea how networks operate, how to secure them, and frankly > don't care. They expect things to work - i.e. Buy a PC, buy a home gateway, > pug it in and go. I wish this was not the case, but wishful thinking gets > me nowhere. > Understand that firewalls make it *more* difficult for protocols to work over the Internet for the average user. - Mark From owner-v6ops@ops.ietf.org Wed Mar 24 04:51:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846003A6877 for ; Wed, 24 Mar 2010 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyMTRbpNHxUi for ; Wed, 24 Mar 2010 04:50:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F3CE3A67A5 for ; Wed, 24 Mar 2010 04:50:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuP5V-0009Lc-2K for v6ops-data0@psg.com; Wed, 24 Mar 2010 11:49:29 +0000 Received: from [2001:1bb8:2004:150::2] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuP5S-0009KH-Hc for v6ops@ops.ietf.org; Wed, 24 Mar 2010 11:49:27 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id o2OBnEnB006637 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 11:49:14 GMT (envelope-from nick@inex.ie) Message-ID: <4BA9FC3A.4070803@inex.ie> Date: Wed, 24 Mar 2010 11:49:14 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Fred Baker , IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion References: <4BA78BE7.6010005@cisco.com> <20100324094859.GC6391@vacation.karoshi.com.> In-Reply-To: <20100324094859.GC6391@vacation.karoshi.com.> X-Enigmail-Version: 1.0.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 24/03/2010 09:48, bmanning@vacation.karoshi.com wrote: > if i may, if this draft was commissioned (by whom?) then it seems > prudent to also have a draft to descrbe a simple, stateful > default-accept firewall if only to provide a balanced choice. Otherwise > we (the IETF) end up with only a single choice defined and after all, if > there is only a single choice, what choice is there? On this basis, could I suggest you rewrite the entire body of RFCs to include balanced choices where relevant? E.g. we could have a BGP which by default wouldn't exchange any prefixes unless the PLEASE_EXCHANGE_PREFIXES_NO_REALLY capability was negotiated. Or we have a TCP protocol which gave the option of not being able to transfer any data whatever (hey, don't criticise those people who don't want to transfer data - they have a legitimate point). We could have an MPLS which came with the default option of forwarding tags to random next-hops, and a DNS specification which defaulted to answering NXDOMAIN to everything. All balanced choices, and all as useful as providing a recommendation for default-accept stateful CPE firewalls. Folks, can we apply the slightest shred of common sense to this discussion? Nick From owner-v6ops@ops.ietf.org Wed Mar 24 05:25:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAC13A6359 for ; Wed, 24 Mar 2010 05:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.096 X-Spam-Level: *** X-Spam-Status: No, score=3.096 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, J_CHICKENPOX_26=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTaRS4bKvECA for ; Wed, 24 Mar 2010 05:25:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3798C3A65A6 for ; Wed, 24 Mar 2010 05:25:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPcJ-000EKT-Tp for v6ops-data0@psg.com; Wed, 24 Mar 2010 12:23:23 +0000 Received: from [195.170.0.29] (helo=noc.otenet.gr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPcH-000EK1-St for v6ops@ops.ietf.org; Wed, 24 Mar 2010 12:23:22 +0000 Received: from loco.otenet.gr (loco.otenet.gr [212.205.221.32]) by noc.otenet.gr (Postfix) with ESMTP id B601E8B81EF; Wed, 24 Mar 2010 14:23:20 +0200 (EET) Received: from loco.otenet.gr (localhost.localdomain [127.0.0.1]) by loco.otenet.gr (8.14.3/8.14.3) with ESMTP id o2OCNKid020006; Wed, 24 Mar 2010 14:23:20 +0200 Received: (from yanodd@localhost) by loco.otenet.gr (8.14.3/8.14.3/Submit) id o2OCNIYS020005; Wed, 24 Mar 2010 14:23:18 +0200 Date: Wed, 24 Mar 2010 14:23:18 +0200 From: Yannis Nikolopoulos To: Mark Townsley Cc: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security Message-ID: <20100324122318.GA19463@otenet.gr> Mail-Followup-To: Mark Townsley , Lee Howard , v6ops@ops.ietf.org References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA9F465.8060608@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, Mar 24, 2010 at 12:15:49PM +0100, Mark Townsley wrote: > > Yes, I know there are still OSes that will be compromised in a matter of > seconds on the open Internet. These, however, do not run IPv6. With > IPv6, we are really talking about Vista, Win 7, linux, and macosx. All > ship with IPv6 firewalls (except linux I suppose) what about ip6tables? Other than that, I think that the paragraph below sums up my feelings for the matter > "simple-security" is "simple-minded". It is based on a security-model > that is rapidly becoming obsolete, and comes at the cost of complexity > in both the RG, the host, and the applications that have to try and work > despite all the various rules for having their packets dropped. > > - Mark Yannis From owner-v6ops@ops.ietf.org Wed Mar 24 05:25:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8120F3A67B5 for ; Wed, 24 Mar 2010 05:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-4.309, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyIO-04fVgEM for ; Wed, 24 Mar 2010 05:25:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34F243A65A6 for ; Wed, 24 Mar 2010 05:25:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPbI-000EEy-Ti for v6ops-data0@psg.com; Wed, 24 Mar 2010 12:22:20 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPbF-000EEN-II for v6ops@ops.ietf.org; Wed, 24 Mar 2010 12:22:18 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAMegqUuQ/uCWe2dsb2JhbACbHRUBAQsLJAYcpgWZEIR+BA X-IronPort-AV: E=Sophos;i="4.51,300,1267401600"; d="scan'208";a="4736069" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 24 Mar 2010 11:48:00 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OCME5e029083; Wed, 24 Mar 2010 12:22:14 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OCMCY10160; Wed, 24 Mar 2010 05:22:12 -0700 (PDT) Message-ID: <4BAA03F3.2000302@cisco.com> Date: Wed, 24 Mar 2010 13:22:11 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Lindqvist Kurt Erik CC: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> <65D91B6D-FFC5-4183-892C-307708B4E1F6@kurtis.pp.se> In-Reply-To: <65D91B6D-FFC5-4183-892C-307708B4E1F6@kurtis.pp.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 4:14 AM, Lindqvist Kurt Erik wrote: > On 23 mar 2010, at 16.48, Rmi Denis-Courmont wrote: > > >>> It was also argued that attacks of this kind simply don't exist in IPv6. >>> >> Which is true. >> >> >>> That sounds like the argument that faults in the space shuttle o-ring >>> haven't caused explosions before, so it's safe. >>> >> No. It's just an argument that operating systems have already been fixed >> *before* they implemented IPv6. Common attack vectors are in different >> (higher) parts of the software stack, against which stateful firewalls are >> totally helpless. >> > If we believe that the attacks that today exist in IPv4 won't exist in IPv6 I think we are highly underestimating the investments in the underground economy. I am convinced we will see the same level of attacks and exploits for IPv6 as for IPv4. That said, I am not convinced that any security in the CPE will protect against that, just as NAT didn't protect in IPv4. However, I don't think that is the issue that we are trying to address with the simple security draft. > Application level attacks will surely be the same. L3/L4 attacks will match the vulnerabilities of the OSes under attack. 90s and early-2000 era IPv4-only stacks are different than today's IPv6 (and IPv4) stacks. There will definitely be overlap in both vulnerabilities and attack methods, but I still think it will be a subset of what we saw in yesteryear. I do think that CPE security could protect against future attacks, just not the CPE security defined in draft-ietf-v6ops-simple-security... - Mark > Best regards, > > - kurtis - > > > > > From owner-v6ops@ops.ietf.org Wed Mar 24 05:39:38 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D06E3A67B5 for ; Wed, 24 Mar 2010 05:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.059 X-Spam-Level: *** X-Spam-Status: No, score=3.059 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2eAyhJC-gpH for ; Wed, 24 Mar 2010 05:39:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A40CB3A6781 for ; Wed, 24 Mar 2010 05:39:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPqq-000G5n-Ub for v6ops-data0@psg.com; Wed, 24 Mar 2010 12:38:24 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuPqn-000G5I-KI for v6ops@ops.ietf.org; Wed, 24 Mar 2010 12:38:22 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NuPqe-0004J0-Az; Wed, 24 Mar 2010 23:08:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BB91C4930C; Wed, 24 Mar 2010 23:08:11 +1030 (CST) Date: Wed, 24 Mar 2010 23:08:11 +1030 From: Mark Smith To: Mark Townsley Cc: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security Message-ID: <20100324230811.66dd9622@opy.nosense.org> In-Reply-To: <4BA9F465.8060608@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Wed, 24 Mar 2010 12:15:49 +0100 Mark Townsley wrote: > On 3/23/10 3:02 PM, Lee Howard wrote: > > > > The simple-security draft represents the best practice we know of for > > securing home networks. > > > It's not a best-practice, it's a best-guess. > > Simple-security is being not being practiced at all on the vast majority > of IPv6 residential connections today. > Is that really the case? What is the current situation with IPv6 firewalls on mainstream OSes like OS X and Vista/Windows 7? This Linux desktop is directly attached to the Internet, and I've been running an IPv6 firewall on it for about 3 or 4 years. The initial Linux implementation was a basic packet filter, however it became stateful at least 18 months to 2 years ago. > > It describes the behavior that should be the default for all home > > networking gateways. Advanced users who know what they're getting > > into can change those default rules. > > > I'll argue the contrary. > > Advanced users know how to manually poke holes in firewalls, run the > right version of UPnP or NAT-PMP running, etc. Non-advanced users do > not. It's the non-advanced users that need protocols to "just work". > > Firewalls make networking more frustrating, particularly for the > non-advanced users. > > > > Some people argued that a stateful firewall is no longer needed > > because attackers no longer use vectors that a firewall protects > > against. This sounds like circular reasoning to me, as if you no > > longer need a roof because rain hasn't fallen on your head for years. > > > If everyone has an umbrella and rain-suit anyway, what good is the roof > doing? > > Yes, I know there are still OSes that will be compromised in a matter of > seconds on the open Internet. These, however, do not run IPv6. With > IPv6, we are really talking about Vista, Win 7, linux, and macosx. All > ship with IPv6 firewalls (except linux I suppose), and far more secure > IP stacks vs. that of ten years ago. All have tethers back home for > updates, in the event that a new exploit is found. These firewalls are > far more adaptive and secure than the "IPv6 simple-security" firewall. > > I don't want any of these new IPv6-enabled OSes to think for a moment > that they can let their guard down just because they are plugged into a > firewalled residential gateway "most of the time". > > > > It was also argued that attacks of this kind simply don't exist in > > IPv6. That sounds like the argument that faults in the space shuttle > > o-ring haven't caused explosions before, so it's safe. > > > Bad analogy. The O-ring problem wasn't because of a hacker, it was > human/engineering error in a complex system. A bug. Rather than > protecting against bugs, firewalls increase the possibility of having > more bugs. > > > I'll also point out that OSes with smaller market share have fewer > > exploits written for them because they are a smaller target; as IPv6 > > exceeds 50%, there will be more attacks. > > > Simple-security loses its effectiveness considerably for a home with no > roaming devices. By the time IPv6 exceeds 50%, what do you think home > networks will look like? The perimeter is getting very porous, and a > "simple" firewall designed around the idea of a fixed home with > stationary devices and a hard perimeter will be ineffective and obsolete. > > This is why the only "firewall" I can consider for a moment to help with > security is one that actively detects whether hosts inside the home as > well as traffic coming from outside the home constitutes a security > breach. The "security cop" on the edge isn't so much a device trying to > black-hole traffic initiated from one direction or another, it is > watching the traffic to see if devices in your home network are > compromised or being attacked. This even works when the attack vector > comes in via an email attachment, because it can watch the traffic > patterns of an infected host connecting back to its lair and shut it > down accordingly. > > "simple-security" is "simple-minded". It is based on a security-model > that is rapidly becoming obsolete, and comes at the cost of complexity > in both the RG, the host, and the applications that have to try and work > despite all the various rules for having their packets dropped. > > > I disagreed at the mike with the argument that ISPs should be doing > > this kind of filtering themselves. I'd like to understand that > > argument better. If ISPs should be providing stateful firewall > > service, then doesn't that support the need for a draft documenting > > what ISPs should do? > > > > The problem with any draft defining what kind of security an ISP or a > gateway should do is that it is by definition a moving target. Security > is, always has been, an arms race. > > Which is why I think that if we should define anything it should be the > base rules and interfaces for updating those rules in response to the > threats. Any static document is going to be obsolete to the hackers > before it is even becomes an RFC. > > > Yes, hosts should provide better security for themselves. > > > One reason the older ones don't, is that nat-firewalls have provided > protection for them during a time when hosts were mostly stationary and > not updated regularly. Today, hosts must be able to deal with operating > in a multitude of environments. The idea that I have a home with no > roaming clients, or can sell an OS that cannot exist with or without a > firewall protect it, is very much a 10-year-old reality. > > If there is one advantage IPv6 does give us, is that it lets us draw a > line between old IP stacks and the OSes they are attached to and new > ones. It wouldn't be sensible for us not to exploit that. > > > In some regions, users install three or four security packages on > > their computers, but even their almost 50% of machines are infected. > > Blocking the easiest paths to exploits using perimeter security is > > current best practice, and should be documented as such. > > > Those regions probably need advanced-security, not simple-security. > Simple-security with IPv6 probably isn't going to help that much, the > hackers will still find their way in, as is clear from the infection rate. > > - Mark > > From owner-v6ops@ops.ietf.org Wed Mar 24 06:00:30 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B144F3A697A for ; Wed, 24 Mar 2010 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPUx37RJgZl4 for ; Wed, 24 Mar 2010 06:00:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 384D33A68E3 for ; Wed, 24 Mar 2010 06:00:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuQ9W-000IRR-9y for v6ops-data0@psg.com; Wed, 24 Mar 2010 12:57:42 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuQ9U-000IQn-27 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 12:57:40 +0000 Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAADypqUuQ/uCWe2dsb2JhbACbHRUBAQsLJAYcpiGZEoR+BA X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="58488308" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2010 12:57:38 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OCvaAi011603; Wed, 24 Mar 2010 12:57:37 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OCvZY00004; Wed, 24 Mar 2010 05:57:35 -0700 (PDT) Message-ID: <4BAA0C3E.4040803@cisco.com> Date: Wed, 24 Mar 2010 13:57:34 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mark Smith CC: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <20100324230811.66dd9622@opy.nosense.org> In-Reply-To: <20100324230811.66dd9622@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 1:38 PM, Mark Smith wrote: > On Wed, 24 Mar 2010 12:15:49 +0100 > Mark Townsley wrote: > > >> On 3/23/10 3:02 PM, Lee Howard wrote: >> >>> The simple-security draft represents the best practice we know of for >>> securing home networks. >>> >>> >> It's not a best-practice, it's a best-guess. >> >> Simple-security is being not being practiced at all on the vast majority >> of IPv6 residential connections today. >> > Is that really the case? What is the current situation with IPv6 > firewalls on mainstream OSes like OS X and Vista/Windows 7? > By "simple-security" I was referring to the draft's scope, which is for residential gateways. > This Linux desktop is directly attached to the Internet, and I've been > running an IPv6 firewall on it for about 3 or 4 years. The initial > Linux implementation was a basic packet filter, however it became > stateful at least 18 months to 2 years ago. > Fully agree that most IPv6-enabled hosts are either running with some sort of firewall either enabled or at least available. - Mark From owner-v6ops@ops.ietf.org Wed Mar 24 06:30:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2CD3A67D1 for ; Wed, 24 Mar 2010 06:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.443 X-Spam-Level: ** X-Spam-Status: No, score=2.443 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUjlB2qrxofV for ; Wed, 24 Mar 2010 06:30:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6F853A69CA for ; Wed, 24 Mar 2010 06:29:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuQaP-000Lyo-Ix for v6ops-data0@psg.com; Wed, 24 Mar 2010 13:25:29 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuQaI-000LwB-4s for v6ops@ops.ietf.org; Wed, 24 Mar 2010 13:25:22 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NuQa9-0001dlC; Wed, 24 Mar 2010 14:25 +0100 Message-Id: To: Mark Townsley Cc: v6ops@ops.ietf.org Subject: Re: simple security From: Philip Homburg References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> In-reply-to: Your message of "Wed, 24 Mar 2010 12:15:49 +0100 ." <4BA9F465.8060608@cisco.com> Date: Wed, 24 Mar 2010 14:25:12 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Wed, 24 Mar 2010 12:15:49 +0100 Mark Townsley wrote: >Yes, I know there are still OSes that will be compromised in a matter of >seconds on the open Internet. These, however, do not run IPv6. With >IPv6, we are really talking about Vista, Win 7, linux, and macosx. All >ship with IPv6 firewalls (except linux I suppose), and far more secure >IP stacks vs. that of ten years ago. All have tethers back home for >updates, in the event that a new exploit is found. These firewalls are >far more adaptive and secure than the "IPv6 simple-security" firewall. I think it is ironic that in one thread we are discussing devices that are so resource constrained that they can't even afford to implement DHCPv6, and have to rely on RFC-5006 to get the locations of DNS servers. And in the next thread it is assumed that all devices have stateful firewalls and automatically update themselves whenever a new bug is discovered. Somehow that doesn't seem to add up. Is it really that case that all that will be connected to the IPv6 internet are Windows, Linux, and MacOS systems? No printers, no multi-media devices, no light switches or other home automation systems? Or is every light switch expected to come with it's own host-based firewall solution? From owner-v6ops@ops.ietf.org Wed Mar 24 07:24:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97363A6B10 for ; Wed, 24 Mar 2010 07:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.776 X-Spam-Level: X-Spam-Status: No, score=-4.776 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SvlexNsl6m9 for ; Wed, 24 Mar 2010 07:24:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79D0F3A6B6C for ; Wed, 24 Mar 2010 07:19:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuROp-0005XY-Pg for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:17:35 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuROn-0005XC-KY for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:17:33 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH+7qUurRN+K/2dsb2JhbACbHXOmGZkMhH4E X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="104995590" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 14:17:33 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OEHWLo026619; Wed, 24 Mar 2010 14:17:32 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OEHVY12273; Wed, 24 Mar 2010 07:17:31 -0700 (PDT) Message-ID: <4BAA1EFA.60108@cisco.com> Date: Wed, 24 Mar 2010 15:17:30 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Homburg CC: v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> 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 List-ID: On 3/24/10 2:25 PM, Philip Homburg wrote: > Wed, 24 Mar 2010 12:15:49 +0100 Mark Townsley wrote: > >> Yes, I know there are still OSes that will be compromised in a matter of >> seconds on the open Internet. These, however, do not run IPv6. With >> IPv6, we are really talking about Vista, Win 7, linux, and macosx. All >> ship with IPv6 firewalls (except linux I suppose), and far more secure >> IP stacks vs. that of ten years ago. All have tethers back home for >> updates, in the event that a new exploit is found. These firewalls are >> far more adaptive and secure than the "IPv6 simple-security" firewall. >> > I think it is ironic that in one thread we are discussing devices that are > so resource constrained that they can't even afford to implement DHCPv6, > and have to rely on RFC-5006 to get the locations of DNS servers. And in > the next thread it is assumed that all devices have stateful firewalls and > automatically update themselves whenever a new bug is discovered. > Or simple-security for that matter. I'm actually of the belief that the "dumb" RGs are on their way out anyway (and given uptick of actively SP-managed RGs in the world, I think there is evidence to support this claim). For my part, the reason I support RFC 5006 moving to PS is because there is already running code that I see no intent of people turning off, coupled with the fact that architecturally I think DNS should have fallen in the SLAAC bucket of "the bare minimum to get IP off the ground" from the beginning. Nothing to do with CPU or Memory resources. > Somehow that doesn't seem to add up. > > Is it really that case that all that will be connected to the IPv6 internet > are Windows, Linux, and MacOS systems? No printers, no multi-media devices, > no light switches or other home automation systems? Or is every light switch > expected to come with it's own host-based firewall solution? > If any of these devices get a global IPv6 address, I think they should be expected to operate on the Global IPv6 Internet in a secure manner. If they want to operate with link-locals or ULAs, they can expect that they are not part of the Global IPv6 Internet and act accordingly. Otherwise, they are all stuck thinking that they "might or might not" be on the Global IPv6 Internet. No way to know, really. - Mark From v6ops-archive@megatron.ietf.org Wed Mar 24 07:29:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132053A6B1E for ; Wed, 24 Mar 2010 07:29:33 -0700 (PDT) X-Quarantine-ID: <5rQJXL23k8gq> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 24 Mar 2010 07:29:27 -0700 (PDT) Received: from acocurvas.com.br (unknown [122.174.166.84]) by core3.amsl.com (Postfix) with SMTP id 512E23A6A45 for ; Wed, 24 Mar 2010 07:29:24 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 77% for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100324142925.512E23A6A45@core3.amsl.com> Date: Wed, 24 Mar 2010 07:29:24 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 24209 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Wed Mar 24 07:36:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CB53A6B21 for ; Wed, 24 Mar 2010 07:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.33 X-Spam-Level: X-Spam-Status: No, score=-5.33 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtMc9D-G4rwR for ; Wed, 24 Mar 2010 07:36:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FB583A684B for ; Wed, 24 Mar 2010 07:36:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRdz-0007gc-6J for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:33:15 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRdw-0007gG-Jm for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:33:12 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="171522984" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 14:33:12 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OEXCU3004010; Wed, 24 Mar 2010 14:33:12 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OEXAY14114; Wed, 24 Mar 2010 07:33:10 -0700 (PDT) Message-ID: <4BAA22A5.4080500@cisco.com> Date: Wed, 24 Mar 2010 15:33:09 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion References: <4BA78BE7.6010005@cisco.com> 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 List-ID: Just getting to this, Fred. What I see is people stating their honest, technical, opinion. It's coming out so rapidly, I believe, because there is a new realization by some and pent-up unspoken opinion by others that this document, along with the misunderstanding of RFC 4864's original intent, are in danger of together taking IPv6 in a way that at least a significant number of IETF members do not want to have their name behind. - Mark On 3/23/10 5:00 PM, Fred Baker wrote: > I'd like to bring this discussion back to a place of a little less fervor and a little more engineering, if I may. I have been staying out of it as much as anything because people really do need to be allowed to say what they think. But... > > At the microphone yesterday, I had to cut the discussion off. My reasons were two-fold. One was that we were in the first discussion of several and the meeting time had to be preserved. The other was that successive speakers were saying the same thing, and spending a lot of time saying it. It had the effect of a filibuster, and I'm not in favor of filibusters as a means of getting technical work done. > > It comes down to this. We as a community have two views. We would like a free and open Internet in which applications can be designed with an expectation that they can communicate amongst themselves freely. We would also like to have, and have a business need to provide for ourselves, the ability to communicate only with peer applications that have our best interests at heart. The history of humanity says that altruism is not a pervasive trait, and the history of the Internet says that we behave on the Internet the same way we do at home. > > My corporate IT folks tell me they drop something on the order of 98% of the email sent to my account, because only 2% behaves in a manner consistent with good etiquette. At the firewall in front of my home I measure a 30 message per second standing load of messages from systems that I have no reason to allow into my home. For me, it comes down to the reason I have a door on my home and it is equipped with a lock. Someone who has a legitimate reason to be in my home also has the manners to knock on my door. If we don't see this on IPv6, it is for the same reason that I don't see viruses on my Mac - it's a sufficiently low value target that nobody is bothering to attack it. As soon as it becomes an interesting target, we can expect folks to attack it. The fact that it is not raining now is not proof that I will not need a roof at any time in the future. Non sequitor. > > This draft was commissioned to describe a simple stateful default-deny firewall. What we decided yesterday that it would continue to describe is a simple stateful default-deny firewall. Everyone doesn't have to install one, and we decided as a group that we would have no recommendation whether they should. But for those that choose to install a simple stateful default-deny firewall, this note indicates how that should behave. > > If we want to change the intent of the note, that's one thing. But we didn't yesterday decide to change the intent of the note. What we decided yesterday was to permit a second note, perhaps based on draft-vyncke-advanced-ipv6-security, that would describe an alternative security procedure. I would invite that note, and I would invite demonstration of the effectiveness of the mechanisms proposed in providing security. > > Let's drop the filibuster. Please. Let's channel all this fervor into making the alternative a really good, and really honestly accurate, note. > > From owner-v6ops@ops.ietf.org Wed Mar 24 07:37:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DBD3A6B1F for ; Wed, 24 Mar 2010 07:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.719 X-Spam-Level: X-Spam-Status: No, score=-98.719 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqCPjTJIval3 for ; Wed, 24 Mar 2010 07:37:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CF573A6B1D for ; Wed, 24 Mar 2010 07:37:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRhW-00087v-Q1 for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:36:54 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRhT-00087G-W8 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:36:52 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id B2CE686CEE; Wed, 24 Mar 2010 15:36:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f+7TcPsQrXBn; Wed, 24 Mar 2010 15:36:42 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 9086686CF3; Wed, 24 Mar 2010 15:36:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8982A86CEF; Wed, 24 Mar 2010 15:36:42 +0100 (CET) Date: Wed, 24 Mar 2010 15:36:42 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Mark Townsley cc: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security In-Reply-To: <4BA9F465.8060608@cisco.com> Message-ID: References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 24 Mar 2010, Mark Townsley wrote: > On 3/23/10 3:02 PM, Lee Howard wrote: >> >> The simple-security draft represents the best practice we know of for >> securing home networks. >> > It's not a best-practice, it's a best-guess. > > Simple-security is being not being practiced at all on the vast majority of > IPv6 residential connections today. I experience is different. The IPv6 capable CPEs mostly supporting some form of firewalling. The dumb one's (only with 6to4) are not. > > Advanced users know how to manually poke holes in firewalls, run the right > version of UPnP or NAT-PMP running, etc. Non-advanced users do not. It's the > non-advanced users that need protocols to "just work". > > Firewalls make networking more frustrating, particularly for the non-advanced > users. Non-firewalling might cause even more frustration. You might remember case of pre SP2 Windows XP: you cannot update win XP without firewall since by the time you started to download SP ar patches your operating system was already compromised.... You might expect something similar in the future over IPv6 also.. There is a need for firewalling! The location of the firewall is a different story. > > Yes, I know there are still OSes that will be compromised in a matter of > seconds on the open Internet. These, however, do not run IPv6. With IPv6, we > are really talking about Vista, Win 7, linux, and macosx. All ship with IPv6 > firewalls (except linux I suppose), and far more secure IP stacks vs. that of > ten years ago. All have tethers back home for updates, in the event that a > new exploit is found. These firewalls are far more adaptive and secure than > the "IPv6 simple-security" firewall. > > I don't want any of these new IPv6-enabled OSes to think for a moment that > they can let their guard down just because they are plugged into a firewalled > residential gateway "most of the time". I think differently. I wrote one of my previous e-mail. Think about ipv6 capable, but somehow limited or crap devices: - no longer supported but know to be vulnerable devices, servers - devices without access control You need firewalling on these case at the CPE or with dedicated firewall. >> > Bad analogy. The O-ring problem wasn't because of a hacker, it was > human/engineering error in a complex system. A bug. Rather than protecting > against bugs, firewalls increase the possibility of having more bugs. No. Firewall can give time and possibility to fix some bugs later (unfortunately sometimes this time-window is infinite...) > > "simple-security" is "simple-minded". It is based on a security-model that is > rapidly becoming obsolete, and comes at the cost of complexity in both the > RG, the host, and the applications that have to try and work despite all the > various rules for having their packets dropped. As simple minded as the current CPE. The residential gateway users are familiar with the the current IPv4 NAT behaviour. What they usuaally expecting - something similar for IPv6: 1. longer IP address? - understandable, but I don't care. 2. No NAT? - ok I get reasonable amount of subnet from my provider - If CPE copes with it, I don't mind. 3. No firewall? - what a hell? what will protect my extra-precious-hacked NAS? - They will sell a separate firewall for me? - No thanks! Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Wed Mar 24 07:46:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B4A3A6B35 for ; Wed, 24 Mar 2010 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.569 X-Spam-Level: X-Spam-Status: No, score=-98.569 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0SV2U-2Gkfb for ; Wed, 24 Mar 2010 07:46:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 191BA3A6B41 for ; Wed, 24 Mar 2010 07:46:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRp3-0009YB-94 for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:44:41 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRox-0009XP-Ah for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:44:35 +0000 Received: from leon.remlab.net (72-254-58-15.client.stsn.net [72.254.58.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id A08EE1A9; Wed, 24 Mar 2010 15:44:33 +0100 (CET) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: Philip Homburg Subject: Re: simple security Date: Wed, 24 Mar 2010 16:44:44 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.32.9; KDE/4.3.5; i686; ; ) Cc: Mark Townsley , v6ops@ops.ietf.org References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201003241644.44652.remi@remlab.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wednesday 24 March 2010 15:25:12 Philip Homburg, you wrote: > I think it is ironic that in one thread we are discussing devices that are > so resource constrained that they can't even afford to implement DHCPv6, > and have to rely on RFC-5006 to get the locations of DNS servers. And in > the next thread it is assumed that all devices have stateful firewalls and > automatically update themselves whenever a new bug is discovered. Any mobile device today could implement DHCPv6. Those are more powerful tha= n=20 the computers upon which IPv6 was trialed in the early days. But anyway. A host-based firewall is most trivial to implement. Just don't= =20 send TCP/RST and ICMP port unreachable errors and you're done. In fact, it= =20 takes less resources to have a firewall than not to have one, in that respe= ct. Oh yeah, if you have a port open it will let traffic through. But that's wh= y=20 the port is open... to let traffic through. My 3G operator provides public = IP=20 addresses without inbound firewalling. My mobile phone has no open ports (o= r=20 it had none until I explicitly installed SSH on it). From security point of= =20 view, the firewall would have no effect. To be fair, the firewall would have one positive effect: my device would no= t=20 need to wake up its radio interface when receiving bogus packets from the=20 Internet. Those packets would be dropped before they get to the air radio=20 interface. Personnally, I would in fact prefer firewall with hole punching= =20 either to firewall without hole punching or to no firewall at all. > Somehow that doesn't seem to add up. > Is it really that case that all that will be connected to the IPv6 intern= et > are Windows, Linux, and MacOS systems? No printers, no multi-media device= s, > no light switches or other home automation systems? Or is every light > switch expected to come with it's own host-based firewall solution? That goes the other way too: if those device can be connected to the Intern= et,=20 we cannot assume they are firewalled because: - the firewall may be disabled (with your all-or-nothing firewall switch), - there may be no firewall (e.g. direct connection). So those devices will have to protect themselves. =46or things like printer and UPnP devices, ignoring connections *not* from= =20 private address space (e.g. fc00::/8) seems like a reasonable option. It do= es=20 not hamper the connectivity of *OTHER* devices. Also it won't make the printer suddenly vulnerable because *another* device= =20 needed the firewall disabled for the entire home network. That's what will= =20 happen if CPE ship with a "turn off the firewall" button on the HTTP=20 interface. From a security perspective, having a firewall with: - a hole punching system (=E0 la NAT-PMPv6), and/or - a non-routed ULA prefix inside the home, seems a hell of a lot more secure than just a plain firewall in that respec= t. =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Mar 24 07:56:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BD53A6A51 for ; Wed, 24 Mar 2010 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkOZA28h6OTx for ; Wed, 24 Mar 2010 07:56:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61FED3A6982 for ; Wed, 24 Mar 2010 07:56:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRyN-000BD8-72 for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:54:19 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuRyK-000BCD-QD for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:54:16 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN7EqUurR7Ht/2dsb2JhbACbHXOmL5kJhH4Egx4 X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="105024346" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 14:54:16 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn7-670.cisco.com [10.21.146.158]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OEs9sY014295; Wed, 24 Mar 2010 14:54:16 GMT Subject: Re: On filibusters as a mode of technical discussion Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <20100324094859.GC6391@vacation.karoshi.com.> Date: Wed, 24 Mar 2010 07:54:15 -0700 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <52FB84AF-A544-4291-BA3D-A54CC4998EBD@cisco.com> References: <4BA78BE7.6010005@cisco.com> <20100324094859.GC6391@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Bill: I don't think you read my note very carefully. The paragraph after the = one you quoted was: > If we want to change the intent of the note, that's one thing. But we = didn't yesterday decide to change the intent of the note. What we = decided yesterday was to permit a second note, perhaps based on = draft-vyncke-advanced-ipv6-security, that would describe an alternative = security procedure. I would invite that note, and I would invite = demonstration of the effectiveness of the mechanisms proposed in = providing security. That *is* a default-accept firewall. By the way, I spoke with Eric last night suggesting that he pull = together people of like mind and turn the document into something that = we can consider a working group draft in Maastricht this summer. The = burden of proof will be on him, Mark, and whoever collaborates with them = to show that the technology they describe in fact prevents attacks; we = have already heard expert commentary in the working group meeting on = Monday that the premise of the service is difficult to support based on = present experience. That said, this draft was accepted by the working group as a working = group draft and initially posted in June 2007, and was by design a = description of a stateful firewall, which is to say, a firewall that = prevents unsolicited inbound traffic. There was discussion at the time = from some who didn't want a firewall described, but there was not at = that time *any* discussion of anything one might call a "firewall" that = by default didn't stop anything. On Mar 24, 2010, at 2:48 AM, bmanning@vacation.karoshi.com wrote: > On Tue, Mar 23, 2010 at 09:00:21AM -0700, Fred Baker wrote: >>=20 >> This draft was commissioned to describe a simple stateful = default-deny firewall. What we decided yesterday that it would continue = to describe is a simple stateful default-deny firewall. Everyone doesn't = have to install one, and we decided as a group that we would have no = recommendation whether they should. But for those that choose to install = a simple stateful default-deny firewall, this note indicates how that = should behave. >>=20 >=20 > if i may, if this draft was commissioned (by whom?) then it = seems prudent to also > have a draft to descrbe a simple, stateful default-accept = firewall if only to provide > a balanced choice. Otherwise we (the IETF) end up with only a = single choice defined > and after all, if there is only a single choice, what choice is = there? >=20 > --bill http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Mar 24 07:57:46 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B425B3A6B1E for ; Wed, 24 Mar 2010 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=1.733, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqZUe8vLqJus for ; Wed, 24 Mar 2010 07:57:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D19263A6B52 for ; Wed, 24 Mar 2010 07:57:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuS0v-000C6a-Lr for v6ops-data0@psg.com; Wed, 24 Mar 2010 14:56:57 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuS0s-000C5u-9o for v6ops@ops.ietf.org; Wed, 24 Mar 2010 14:56:55 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NuS0m-0001dWC; Wed, 24 Mar 2010 15:56 +0100 Message-Id: To: Mark Townsley Cc: v6ops@ops.ietf.org Subject: Re: simple security From: Philip Homburg References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <4BAA1EFA.60108@cisco.com> In-reply-to: Your message of "Wed, 24 Mar 2010 15:17:30 +0100 ." <4BAA1EFA.60108@cisco.com> Date: Wed, 24 Mar 2010 15:56:48 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Wed, 24 Mar 2010 15:17:30 +0100 you wrote: >If any of these devices get a global IPv6 address, I think they should >be expected to operate on the Global IPv6 Internet in a secure manner. I don't think anyone in the security community would find it reasonable to expect all devices with global IPv6 address to operate in a secure manner. There is more than enough evidence to suggest that in practice it will be exactly the opposite. And remember, in the typical SLAAC scenario any device that understands RAs will automatically get a global IPv6 address, there is not much you can do about it. From owner-v6ops@ops.ietf.org Wed Mar 24 08:14:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB113A6B3E for ; Wed, 24 Mar 2010 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.918 X-Spam-Level: X-Spam-Status: No, score=-4.918 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1JZBpOdPULg for ; Wed, 24 Mar 2010 08:14:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF1E43A679C for ; Wed, 24 Mar 2010 08:14:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSGT-000Exc-54 for v6ops-data0@psg.com; Wed, 24 Mar 2010 15:13:01 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSGQ-000Ewd-7C for v6ops@ops.ietf.org; Wed, 24 Mar 2010 15:12:58 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKjIqUtAZnwM/2dsb2JhbACbHnOmNpkIhH4E X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="95790159" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2010 15:12:57 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OFCuHR007989; Wed, 24 Mar 2010 15:12:56 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OFCsY17096; Wed, 24 Mar 2010 08:12:54 -0700 (PDT) Message-ID: <4BAA2BF5.20400@cisco.com> Date: Wed, 24 Mar 2010 16:12:53 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mohacsi Janos CC: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> 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 List-ID: On 3/24/10 3:36 PM, Mohacsi Janos wrote: > > > > On Wed, 24 Mar 2010, Mark Townsley wrote: > >> On 3/23/10 3:02 PM, Lee Howard wrote: >>> >>> The simple-security draft represents the best practice we know of >>> for securing home networks. >>> >> It's not a best-practice, it's a best-guess. >> >> Simple-security is being not being practiced at all on the vast >> majority of IPv6 residential connections today. > > I experience is different. The IPv6 capable CPEs mostly supporting > some form of firewalling. The dumb one's (only with 6to4) are not. At least according to Google's stats, the majority of users they see are from from Free Telecom, none of which are behind a firewall. >> Advanced users know how to manually poke holes in firewalls, run the >> right version of UPnP or NAT-PMP running, etc. Non-advanced users do >> not. It's the non-advanced users that need protocols to "just work". >> >> Firewalls make networking more frustrating, particularly for the >> non-advanced users. > > Non-firewalling might cause even more frustration. You might remember > case of pre SP2 Windows XP: you cannot update win XP without firewall > since by the time you started to download SP ar patches your operating > system was already compromised.... You might expect something similar > in the future over IPv6 also.. There is a need for firewalling! The > location of the firewall is a different story. Firewalls drop packets that legitimate applications would otherwise expect to be sent. They try also to drop packets from hackers. You can't expect them to always get it right. So, by definition there is a tradeoff here. As is the case for pretty much every security measure in the world. Boarding a plane with or without the shoe inspection, etc. Sure, you could say that not being blown up is a feature in usability so we should thank the TSP for making our traveling in the airport so much easier ;-) > >> >> Yes, I know there are still OSes that will be compromised in a matter >> of seconds on the open Internet. These, however, do not run IPv6. >> With IPv6, we are really talking about Vista, Win 7, linux, and >> macosx. All ship with IPv6 firewalls (except linux I suppose), and >> far more secure IP stacks vs. that of ten years ago. All have tethers >> back home for updates, in the event that a new exploit is found. >> These firewalls are far more adaptive and secure than the "IPv6 >> simple-security" firewall. >> >> I don't want any of these new IPv6-enabled OSes to think for a moment >> that they can let their guard down just because they are plugged into >> a firewalled residential gateway "most of the time". > > I think differently. I wrote one of my previous e-mail. Think about > ipv6 capable, but somehow limited or crap devices: > > - no longer supported but know to be vulnerable devices, servers > - devices without access control > > You need firewalling on these case at the CPE or with dedicated firewall. Turn one on for those or don't put them on the global Ipv6 Internet. But, don't turn it on for every device in the world in the process. That's what I have been saying. >> >> "simple-security" is "simple-minded". It is based on a security-model >> that is rapidly becoming obsolete, and comes at the cost of >> complexity in both the RG, the host, and the applications that have >> to try and work despite all the various rules for having their >> packets dropped. > > > As simple minded as the current CPE. The residential gateway users are > familiar with the the current IPv4 NAT behaviour. What they usuaally > expecting - something similar for IPv6: > 1. longer IP address? - understandable, but I don't care. > 2. No NAT? - ok I get reasonable amount of subnet from my provider - > If CPE copes with it, I don't mind. > 3. No firewall? - what a hell? what will protect my > extra-precious-hacked NAS? - They will sell a separate firewall for > me? - No thanks! Your NAS should run link-local or ULA if you don't want it to reach the outside world. If it needs a UGA for fetching its own updates, it shouldn't allow any incoming connections on it. If you are an expert user and want to setup accessing your NAS from the internet, you had better be sure it can handle being on the Internet because you'll be doing that anyway if you open a pinhole to it from your firewall. - Mark > > > Best Regards, > Janos Mohacsi > From owner-v6ops@ops.ietf.org Wed Mar 24 08:21:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF073A68F9 for ; Wed, 24 Mar 2010 08:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueA+ddZPQqwG for ; Wed, 24 Mar 2010 08:21:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93C753A6802 for ; Wed, 24 Mar 2010 08:20:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSNC-000G6x-3z for v6ops-data0@psg.com; Wed, 24 Mar 2010 15:19:58 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSN9-000G5R-Ul for v6ops@ops.ietf.org; Wed, 24 Mar 2010 15:19:56 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfKqUtAZnwN/2dsb2JhbACbHnOmPpkJhH4E X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="95656877" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2010 15:19:54 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2OFJsbW006866; Wed, 24 Mar 2010 15:19:54 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OFJqY18326; Wed, 24 Mar 2010 08:19:52 -0700 (PDT) Message-ID: <4BAA2D97.5000405@cisco.com> Date: Wed, 24 Mar 2010 16:19:51 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: =?ISO-8859-15?Q?R=E9mi_Denis-Courmont?= CC: Philip Homburg , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <201003241644.44652.remi@remlab.net> In-Reply-To: <201003241644.44652.remi@remlab.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 3:44 PM, Rmi Denis-Courmont wrote: > > To be fair, the firewall would have one positive effect: my device would not > need to wake up its radio interface when receiving bogus packets from the > Internet. Those packets would be dropped before they get to the air radio > interface. Personnally, I would in fact prefer firewall with hole punching > either to firewall without hole punching or to no firewall at all. > This use of a firewall is perfectly legitimate because it is the link and interface itself that you are protecting. This is also illustrates how the hole punching method of operation begins to look essentially like a distributed IP stack between two devices. Gosh, I wish we had one (and only one) of those hole-punching protocols ready to go at the time of publishing this document. Anyway, good technical point. Unfortunately, I don't see any discussion of this type in the current draft. - Mark From owner-v6ops@ops.ietf.org Wed Mar 24 08:25:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E12A3A6B56 for ; Wed, 24 Mar 2010 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.24 X-Spam-Level: X-Spam-Status: No, score=-99.24 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8OcfIlgIr6V for ; Wed, 24 Mar 2010 08:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE3B73A6949 for ; Wed, 24 Mar 2010 08:25:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSR3-000GgH-N6 for v6ops-data0@psg.com; Wed, 24 Mar 2010 15:23:57 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSR1-000Gaa-6O for v6ops@ops.ietf.org; Wed, 24 Mar 2010 15:23:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o2OFMJxf011308; Wed, 24 Mar 2010 15:22:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o2OFMGwv011306; Wed, 24 Mar 2010 15:22:16 GMT Date: Wed, 24 Mar 2010 15:22:16 +0000 From: bmanning@vacation.karoshi.com To: Nick Hilliard Cc: bmanning@vacation.karoshi.com, Fred Baker , IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion Message-ID: <20100324152216.GA11142@vacation.karoshi.com.> References: <4BA78BE7.6010005@cisco.com> <20100324094859.GC6391@vacation.karoshi.com.> <4BA9FC3A.4070803@inex.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA9FC3A.4070803@inex.ie> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, Mar 24, 2010 at 11:49:14AM +0000, Nick Hilliard wrote: > On 24/03/2010 09:48, bmanning@vacation.karoshi.com wrote: > > if i may, if this draft was commissioned (by whom?) then it seems > > prudent to also have a draft to descrbe a simple, stateful > > default-accept firewall if only to provide a balanced choice. Otherwise > > we (the IETF) end up with only a single choice defined and after all, if > > there is only a single choice, what choice is there? > > On this basis, could I suggest you rewrite the entire body of RFCs to > include balanced choices where relevant? E.g. we could have a BGP which by > default wouldn't exchange any prefixes unless the > PLEASE_EXCHANGE_PREFIXES_NO_REALLY capability was negotiated. Or we have a > TCP protocol which gave the option of not being able to transfer any data > whatever (hey, don't criticise those people who don't want to transfer data > - they have a legitimate point). We could have an MPLS which came with the > default option of forwarding tags to random next-hops, and a DNS > specification which defaulted to answering NXDOMAIN to everything. All > balanced choices, and all as useful as providing a recommendation for > default-accept stateful CPE firewalls. > > Folks, can we apply the slightest shred of common sense to this discussion? > > Nick Nick, that is silly. There is precident here for publishing two varients; e.g. ISIS and OSPF. As Fred pointed out, there are two camps, one which is passionate about default-deny as a means to protect the great unwashed from bad things, and the other which sees default-deny as a capstone to stifle inovation and advancement. Personally, I have tools to run an IPsec VPN through both DNS and HTTP, so I don't really care if the IETF decides to lockdown and discard any traffic not on port 53 or port 80. GoGo DPI!!! But I'd rather see a wider field open for inovation and development than stuffing everything into HTTP or DNS. Just my 0.02 though. My point being made... I repsect Freds closing of the virtual mic. --bill From owner-v6ops@ops.ietf.org Wed Mar 24 08:29:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D183A6B88 for ; Wed, 24 Mar 2010 08:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.211 X-Spam-Level: X-Spam-Status: No, score=-7.211 tagged_above=-999 required=5 tests=[AWL=2.154, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCWiuQKe0+vI for ; Wed, 24 Mar 2010 08:29:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE3D93A6B91 for ; Wed, 24 Mar 2010 08:29:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSUm-000HKN-Rf for v6ops-data0@psg.com; Wed, 24 Mar 2010 15:27:48 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuSUk-000HJy-K7 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 15:27:46 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACPMqUtAZnwM/2dsb2JhbACbHnOmPJkJhH4E X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="95660239" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2010 15:27:45 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OFRiLX014918; Wed, 24 Mar 2010 15:27:45 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OFRhY19238; Wed, 24 Mar 2010 08:27:43 -0700 (PDT) Message-ID: <4BAA2F6E.8030702@cisco.com> Date: Wed, 24 Mar 2010 16:27:42 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Homburg CC: v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <4BAA1EFA.60108@cisco.com> 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 List-ID: On 3/24/10 3:56 PM, Philip Homburg wrote: > In your letter dated Wed, 24 Mar 2010 15:17:30 +0100 you wrote: > >> If any of these devices get a global IPv6 address, I think they should >> be expected to operate on the Global IPv6 Internet in a secure manner. >> > I don't think anyone in the security community would find it reasonable > to expect all devices with global IPv6 address to operate in a secure manner. > "Secure" is a relative term. Let me rephrase this to be that any device that configures a global IPv6 address should expect that it may be connected to the global IPv6 Internet and act accordingly. > There is more than enough evidence to suggest that in practice it will be > exactly the opposite. > Perhaps if more devices were exposed to the Internet, they would operate in a more secure manner. > And remember, in the typical SLAAC scenario any device that understands RAs > will automatically get a global IPv6 address, there is not much you can > do about it. > But you don't have to open sockets that listen on that global address. - Mark From owner-v6ops@ops.ietf.org Wed Mar 24 09:37:04 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDBA3A6BC9 for ; Wed, 24 Mar 2010 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.85 X-Spam-Level: X-Spam-Status: No, score=-98.85 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9P8C5yPPUCT for ; Wed, 24 Mar 2010 09:37:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F40343A6BA4 for ; Wed, 24 Mar 2010 09:37:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuTVg-0001ko-I7 for v6ops-data0@psg.com; Wed, 24 Mar 2010 16:32:48 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuTVd-0001kG-PN for v6ops@ops.ietf.org; Wed, 24 Mar 2010 16:32:45 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id D4DD986CC7; Wed, 24 Mar 2010 17:32:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YEzHcmpyN5e7; Wed, 24 Mar 2010 17:32:35 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id DFC4386CF8; Wed, 24 Mar 2010 17:32:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id DE5FD86CF7; Wed, 24 Mar 2010 17:32:35 +0100 (CET) Date: Wed, 24 Mar 2010 17:32:35 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Mark Townsley cc: Lee Howard , v6ops@ops.ietf.org Subject: Re: simple security In-Reply-To: <4BAA2BF5.20400@cisco.com> Message-ID: References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <4BAA2BF5.20400@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 24 Mar 2010, Mark Townsley wrote: >>> "simple-security" is "simple-minded". It is based on a security-model that >>> is rapidly becoming obsolete, and comes at the cost of complexity in both >>> the RG, the host, and the applications that have to try and work despite >>> all the various rules for having their packets dropped. >> >> >> As simple minded as the current CPE. The residential gateway users are >> familiar with the the current IPv4 NAT behaviour. What they usually >> expecting - something similar for IPv6: >> 1. longer IP address? - understandable, but I don't care. >> 2. No NAT? - ok I get reasonable amount of subnet from my provider - If CPE >> copes with it, I don't mind. >> 3. No firewall? - what a hell? what will protect my extra-precious-hacked >> NAS? - They will sell a separate firewall for me? - No thanks! > Your NAS should run link-local or ULA if you don't want it to reach the > outside world. How to configure the NAS for such a setup? - If I use SLAAC? Do I have to prevent RAs with global prefix to be arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I get ULA via SLAAC? This requires a pretty complex setup. - If I use DHCPv6? I have to configure DHCPv6 server not to distribute global address to NAS - only ULA...uh oh. Do we expect residential users to configure such a things in DHCPv6? in IPv4 they did not configure anything on DHCP..... Can I use DHCPv6 in every situation (if I use Mac OS X)? - Do I have to put a different subnet the NAS than the computers to have separate address distribution policy? What happens to the discovery protocols - most of the NAS devices using some form of on-link discovery for setup applications? Do I have to go thru the CPE in order to transfer files? The performance will be horrific....CPEs was not designed for such a task - packet forwarding between LAN and WAN side is done by a few 100 Mhz processor - CPU power was selected by the limitation of broadband speed.... What setup do you think is working? Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Wed Mar 24 10:17:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8653A6C6F for ; Wed, 24 Mar 2010 10:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8JTvwigEj0S for ; Wed, 24 Mar 2010 10:17:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C98033A6C8A for ; Wed, 24 Mar 2010 10:17:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuUAy-0007ix-OM for v6ops-data0@psg.com; Wed, 24 Mar 2010 17:15:28 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuUAw-0007ic-DG for v6ops@ops.ietf.org; Wed, 24 Mar 2010 17:15:26 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id B02198AD861F for ; Wed, 24 Mar 2010 10:15:25 -0700 (PDT) X-AuditID: 11807137-b7c50ae0000001dd-c6-4baa48addc12 Received: from [17.151.121.18] (Unknown_Domain [17.151.121.18]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 55.14.00477.DA84AAB4; Wed, 24 Mar 2010 10:15:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: simple security From: james woodyatt In-Reply-To: Date: Wed, 24 Mar 2010 10:15:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <156A3E2B-E4B5-48F8-881D-35F2F04B5DD2@apple.com> References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <4BAA1EFA.60108@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 24, 2010, at 07:56, Philip Homburg wrote: >=20 > And remember, in the typical SLAAC scenario any device that = understands RAs > will automatically get a global IPv6 address, there is not much you = can > do about it. It doesn't have to be that way. Just because the RA contains a PIO with = A=3D1 it does not mean that hosts MUST assign themselves an address in = the prefix. They certainly don't need to assign themselves a = *persistent* address if they don't offer services in any directories. = Client-only hosts could restrict themselves to temporary global = addresses on an as-needed basis. So, you see, it's perfectly reasonable to say that minidevices that = assign themselves persistent addresses with SLAAC unnecessarily and = without being secured properly are in error. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Mar 24 10:53:53 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B0C3A6A56 for ; Wed, 24 Mar 2010 10:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPZOXgDA1-nK for ; Wed, 24 Mar 2010 10:53:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2236E3A68F1 for ; Wed, 24 Mar 2010 10:53:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuUid-000Cfc-8T for v6ops-data0@psg.com; Wed, 24 Mar 2010 17:50:15 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuUia-000Cew-H1 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 17:50:13 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1NuUiU-0001dpC; Wed, 24 Mar 2010 18:50 +0100 Message-Id: To: james woodyatt Cc: IPv6 Operations Subject: Re: simple security From: Philip Homburg References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <4BAA1EFA.60108@cisco.com> <156A3E2B-E4B5-48F8-881D-35F2F04B5DD2@apple.com> In-reply-to: Your message of "Wed, 24 Mar 2010 10:15:24 -0700 ." <156A3E2B-E4B5-48F8-881D-35F2F04B5DD2@apple.com> Date: Wed, 24 Mar 2010 18:50:04 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > And remember, in the typical SLAAC scenario any device that understands RAs > > will automatically get a global IPv6 address, there is not much you can > > do about it. > > It doesn't have to be that way. Just because the RA contains a > PIO with A=1 it does not mean that hosts MUST assign themselves an > address in the prefix. They certainly don't need to assign themselves > a *persistent* address if they don't offer services in any directories. > Client-only hosts could restrict themselves to temporary global > addresses on an as-needed basis. > > So, you see, it's perfectly reasonable to say that minidevices that > assign themselves persistent addresses with SLAAC unnecessarily > and without being secured properly are in error. You seem to assume that devices like printers, multi media devices, light switches, etc. are client-only device that have no need to communicate unless prompted by the user. In my experience, most of those devices tend to have server functionality that is always on. From owner-v6ops@ops.ietf.org Wed Mar 24 11:14:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115B63A68F1 for ; Wed, 24 Mar 2010 11:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.632 X-Spam-Level: X-Spam-Status: No, score=-105.632 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIIFI194tD8K for ; Wed, 24 Mar 2010 11:14:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAFEF3A68EB for ; Wed, 24 Mar 2010 11:14:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuV4B-000GB5-EY for v6ops-data0@psg.com; Wed, 24 Mar 2010 18:12:31 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuV47-000G8g-AW for v6ops@ops.ietf.org; Wed, 24 Mar 2010 18:12:27 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="105189472" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 18:12:26 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn7-1343.cisco.com [10.21.149.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2OICQOP015983; Wed, 24 Mar 2010 18:12:26 GMT Subject: Re: On filibusters as a mode of technical discussion Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BAA22A5.4080500@cisco.com> Date: Wed, 24 Mar 2010 11:12:26 -0700 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <34F53906-55DB-474E-A948-3A9DF3AD6B92@cisco.com> References: <4BA78BE7.6010005@cisco.com> <4BAA22A5.4080500@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Two comments, Mark. First, if you're trying to prevent the Internet from having IPv6 = firewalls, you're late. That horse left the barn in 2004, with = Checkpoint announcing that it was "the first to secure IPv6". Per a 2007 = ICANN study "at least 30% of the 42 [firewall] vendors surveyed, had = IPv6 support" (http://www.icann.org/committees/security/sac021.pdf); = those vendors include at least Checkpoint, Cisco, and Juniper from a = very quick search on google, and consider the list in = http://www.getipv6.info/index.php/IPv6_Firewalls. I can see removing any = IETF recommendation that firewalls be deployed, which we agreed to = Monday. I see value is specifying what, if one chooses to implement a = default-deny firewall, that means. Second, in this discussion, I use the word "filibuster" in accordance = with its dictionary definition: "an action such as a prolonged speech = that obstructs progress in a legislative assembly while not technically = contravening the required procedures". At the mike on Monday, we had a = succession of people who lined up to comment on the draft that in = essence passionately repeated each other and each individually took a = long-winded approach to doing so, and in so doing prevented other = opinions from being expressed and consumed the available time to discuss = the comments on the draft - and there were important comments on its = recommendations. On the list in the last 48 hours, consider what has = happened. YTD, speaking at 10:04 AM PDT on 24 March, we have had 502 = comments on the v6ops list. More than half of those have come in since = 11 March, related to the agenda of this meeting and the question = regarding RFC 5006 (and much of that off-topic, on the question of a = proposal I expect to receive from Remi for a container for DHCP options = to be carried in an RA, and which I expect to refer to 6man as 6man is = chartered to handle such questions) and this question. 78, or about one = in six YTD, have been on this topic, phrasing it either as a comment on = the draft, a plea for end to end transparency, or this thread. The = message count has been: 1 shengjiang@huawei.com 6 remi@remlab.net 1 ot@cisco.com 1 marcoh@marcoh.net 3 Fred.L.Templin@boeing.com 2 jdunn@mitre.org 1 lee@asgard.org 3 remi.despres@free.fr 1 nick@inex.ie 2 bmanning@vacation.karoshi.com 7 fred@cisco.com 3 jhw@apple.com 2 kurtis@kurtis.pp.se 1 cb.list6@gmail.com 3 brian.e.carpenter@gmail.com 2 joelja@bogus.com 1 bs7652@att.com 1 victor.kuarsingh@gmail.com 2 gert@space.net 1 tony@lava.net 1 hesham@elevatemobile.com 4 ipng@69706e6720323030352d30312d31340a.nosense.org 19 townsley@cisco.com 1 yanodd@otenet.gr 4 mohacsi@niif.hu 1 matsuhira@jp.fujitsu.com 4 pch-v6ops@u-1.phicoh.com The tenor has been pretty loud from certain quarters. I would like to distinguish between volume of mailing, both in message = count and tone, and technical discourse. "I'm agin it, it disagrees with = my preferred view of the world, and I will shout it down if I can" is = not "honest technical opinion". If you review the discussion, I think = you will find that there are some on each side of the debate, and the = decision we came to Monday, to describe firewalls but make no comment = recommending for or against them, and to invite an alternative solution = if it passes security muster, is supported. On Mar 24, 2010, at 7:33 AM, Mark Townsley wrote: >=20 > Just getting to this, Fred. >=20 > What I see is people stating their honest, technical, opinion. >=20 > It's coming out so rapidly, I believe, because there is a new = realization by some and pent-up unspoken opinion by others that this = document, along with the misunderstanding of RFC 4864's original intent, = are in danger of together taking IPv6 in a way that at least a = significant number of IETF members do not want to have their name = behind. >=20 > - Mark >=20 >=20 >=20 > On 3/23/10 5:00 PM, Fred Baker wrote: >> I'd like to bring this discussion back to a place of a little less = fervor and a little more engineering, if I may. I have been staying out = of it as much as anything because people really do need to be allowed to = say what they think. But... >>=20 >> At the microphone yesterday, I had to cut the discussion off. My = reasons were two-fold. One was that we were in the first discussion of = several and the meeting time had to be preserved. The other was that = successive speakers were saying the same thing, and spending a lot of = time saying it. It had the effect of a filibuster, and I'm not in favor = of filibusters as a means of getting technical work done. >>=20 >> It comes down to this. We as a community have two views. We would = like a free and open Internet in which applications can be designed with = an expectation that they can communicate amongst themselves freely. We = would also like to have, and have a business need to provide for = ourselves, the ability to communicate only with peer applications that = have our best interests at heart. The history of humanity says that = altruism is not a pervasive trait, and the history of the Internet says = that we behave on the Internet the same way we do at home. >>=20 >> My corporate IT folks tell me they drop something on the order of 98% = of the email sent to my account, because only 2% behaves in a manner = consistent with good etiquette. At the firewall in front of my home I = measure a 30 message per second standing load of messages from systems = that I have no reason to allow into my home. For me, it comes down to = the reason I have a door on my home and it is equipped with a lock. = Someone who has a legitimate reason to be in my home also has the = manners to knock on my door. If we don't see this on IPv6, it is for the = same reason that I don't see viruses on my Mac - it's a sufficiently low = value target that nobody is bothering to attack it. As soon as it = becomes an interesting target, we can expect folks to attack it. The = fact that it is not raining now is not proof that I will not need a roof = at any time in the future. Non sequitor. >>=20 >> This draft was commissioned to describe a simple stateful = default-deny firewall. What we decided yesterday that it would continue = to describe is a simple stateful default-deny firewall. Everyone doesn't = have to install one, and we decided as a group that we would have no = recommendation whether they should. But for those that choose to install = a simple stateful default-deny firewall, this note indicates how that = should behave. >>=20 >> If we want to change the intent of the note, that's one thing. But we = didn't yesterday decide to change the intent of the note. What we = decided yesterday was to permit a second note, perhaps based on = draft-vyncke-advanced-ipv6-security, that would describe an alternative = security procedure. I would invite that note, and I would invite = demonstration of the effectiveness of the mechanisms proposed in = providing security. >>=20 >> Let's drop the filibuster. Please. Let's channel all this fervor into = making the alternative a really good, and really honestly accurate, = note. >>=20 >> =20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Mar 24 11:44:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D3B3A68EB for ; Wed, 24 Mar 2010 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGw-6zWH4CTE for ; Wed, 24 Mar 2010 11:44:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 196973A67D3 for ; Wed, 24 Mar 2010 11:44:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuVVX-000KPo-BE for v6ops-data0@psg.com; Wed, 24 Mar 2010 18:40:47 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuVVU-000KPU-Kv for v6ops@ops.ietf.org; Wed, 24 Mar 2010 18:40:44 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="217907746" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2010 18:40:43 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2OIehrI020880; Wed, 24 Mar 2010 18:40:43 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OIegY09076; Wed, 24 Mar 2010 11:40:42 -0700 (PDT) Message-ID: <4BAA5CA9.9030602@cisco.com> Date: Wed, 24 Mar 2010 19:40:41 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion References: <4BA78BE7.6010005@cisco.com> <4BAA22A5.4080500@cisco.com> <34F53906-55DB-474E-A948-3A9DF3AD6B92@cisco.com> In-Reply-To: <34F53906-55DB-474E-A948-3A9DF3AD6B92@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 7:12 PM, Fred Baker wrote: > Two comments, Mark. > > First, if you're trying to prevent the Internet from having IPv6 firewalls, you're late. That horse left the barn in 2004, with Checkpoint announcing that it was "the first to secure IPv6". Per a 2007 ICANN study "at least 30% of the 42 [firewall] vendors surveyed, had IPv6 support" (http://www.icann.org/committees/security/sac021.pdf); those vendors include at least Checkpoint, Cisco, and Juniper from a very quick search on google, and consider the list in http://www.getipv6.info/index.php/IPv6_Firewalls. I can see removing any IETF recommendation that firewalls be deployed, which we agreed to Monday. I see value is specifying what, if one chooses to implement a default-deny firewall, that means. > All of the data above are with respect to firewalls for IPv6-enabled businesses, not residential consumer networks. In my discussion, I am very much separating the issue of enterprise IT-managed firewalls vs. residential "consumer" firewalls, since the draft is only targeting residential or "small business" sites. I have no problem with enterprise managed IPv6 firewalls. The assets being protected, the management staff operating the equipment, and the types of applications being run are all very different than the typical residential site. There is some overlap, for telecommuting workers such as yourself, but by and large these are very different use-cases. The v6ops draft is *not* targeting enterprise firewalls at all. If it was, we wouldn't be agonizing over well-defined defaults, for one. > I would like to distinguish between volume of mailing, both in message count and tone, and technical discourse. "I'm agin it, it disagrees with my preferred view of the world, and I will shout it down if I can" is not "honest technical opinion". If you review the discussion, I think you will find that there are some on each side of the debate, and the decision we came to Monday, to describe firewalls but make no comment recommending for or against them, and to invite an alternative solution if it passes security muster, is supported. > Then consider much of the discussion as a prelude to what kind of alternative solution we need. If we are to have an alternative, those that do not agree with the current status quo need to be able to state why. On "filibustering" and the number of messages you are seeing from me, I suppose you are seeing what happens on email when I don't get a chance to speak at the mic in person. Apologies, it doesn't happen often. - Mark > > > On Mar 24, 2010, at 7:33 AM, Mark Townsley wrote: > > >> Just getting to this, Fred. >> >> What I see is people stating their honest, technical, opinion. >> >> It's coming out so rapidly, I believe, because there is a new realization by some and pent-up unspoken opinion by others that this document, along with the misunderstanding of RFC 4864's original intent, are in danger of together taking IPv6 in a way that at least a significant number of IETF members do not want to have their name behind. >> >> - Mark >> >> >> >> On 3/23/10 5:00 PM, Fred Baker wrote: >> >>> I'd like to bring this discussion back to a place of a little less fervor and a little more engineering, if I may. I have been staying out of it as much as anything because people really do need to be allowed to say what they think. But... >>> >>> At the microphone yesterday, I had to cut the discussion off. My reasons were two-fold. One was that we were in the first discussion of several and the meeting time had to be preserved. The other was that successive speakers were saying the same thing, and spending a lot of time saying it. It had the effect of a filibuster, and I'm not in favor of filibusters as a means of getting technical work done. >>> >>> It comes down to this. We as a community have two views. We would like a free and open Internet in which applications can be designed with an expectation that they can communicate amongst themselves freely. We would also like to have, and have a business need to provide for ourselves, the ability to communicate only with peer applications that have our best interests at heart. The history of humanity says that altruism is not a pervasive trait, and the history of the Internet says that we behave on the Internet the same way we do at home. >>> >>> My corporate IT folks tell me they drop something on the order of 98% of the email sent to my account, because only 2% behaves in a manner consistent with good etiquette. At the firewall in front of my home I measure a 30 message per second standing load of messages from systems that I have no reason to allow into my home. For me, it comes down to the reason I have a door on my home and it is equipped with a lock. Someone who has a legitimate reason to be in my home also has the manners to knock on my door. If we don't see this on IPv6, it is for the same reason that I don't see viruses on my Mac - it's a sufficiently low value target that nobody is bothering to attack it. As soon as it becomes an interesting target, we can expect folks to attack it. The fact that it is not raining now is not proof that I will not need a roof at any time in the future. Non sequitor. >>> >>> This draft was commissioned to describe a simple stateful default-deny firewall. What we decided yesterday that it would continue to describe is a simple stateful default-deny firewall. Everyone doesn't have to install one, and we decided as a group that we would have no recommendation whether they should. But for those that choose to install a simple stateful default-deny firewall, this note indicates how that should behave. >>> >>> If we want to change the intent of the note, that's one thing. But we didn't yesterday decide to change the intent of the note. What we decided yesterday was to permit a second note, perhaps based on draft-vyncke-advanced-ipv6-security, that would describe an alternative security procedure. I would invite that note, and I would invite demonstration of the effectiveness of the mechanisms proposed in providing security. >>> >>> Let's drop the filibuster. Please. Let's channel all this fervor into making the alternative a really good, and really honestly accurate, note. >>> >>> >>> >> > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Wed Mar 24 11:46:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FCF3A6B53 for ; Wed, 24 Mar 2010 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.33 X-Spam-Level: X-Spam-Status: No, score=-107.33 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYGhCXqkZRG6 for ; Wed, 24 Mar 2010 11:46:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 511733A68EB for ; Wed, 24 Mar 2010 11:46:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuVaa-000L82-2t for v6ops-data0@psg.com; Wed, 24 Mar 2010 18:46:00 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuVaY-000L7k-6b for v6ops@ops.ietf.org; Wed, 24 Mar 2010 18:45:58 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="171725491" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 18:45:25 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn7-1343.cisco.com [10.21.149.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2OIjPMk026515; Wed, 24 Mar 2010 18:45:25 GMT Subject: Re: On filibusters as a mode of technical discussion Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BAA5CA9.9030602@cisco.com> Date: Wed, 24 Mar 2010 11:45:24 -0700 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA78BE7.6010005@cisco.com> <4BAA22A5.4080500@cisco.com> <34F53906-55DB-474E-A948-3A9DF3AD6B92@cisco.com> <4BAA5CA9.9030602@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 24, 2010, at 11:40 AM, Mark Townsley wrote: > Then consider much of the discussion as a prelude to what kind of = alternative solution we need. If we are to have an alternative, those = that do not agree with the current status quo need to be able to state = why. As I said a couple of messages back, I suggested to Eric last night that = he collect a group of like-minded individuals and describe that = alternative. Yes, I would expect that the proposal would contain = discussion of the philosophy behind it. I suspect that your+his draft is = a start at that, although I won't hold you (collectively) to it, and I = would suggest an early security directorate review. http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Mar 24 13:25:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF913A6891 for ; Wed, 24 Mar 2010 13:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5kVNHHASUks for ; Wed, 24 Mar 2010 13:25:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 093BA3A6358 for ; Wed, 24 Mar 2010 13:25:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuX4q-0007wL-0u for v6ops-data0@psg.com; Wed, 24 Mar 2010 20:21:20 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuX4n-0007vb-L1 for v6ops@ops.ietf.org; Wed, 24 Mar 2010 20:21:17 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NuX4i-000530-CE; Thu, 25 Mar 2010 06:51:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A1C274930C; Thu, 25 Mar 2010 06:51:11 +1030 (CST) Date: Thu, 25 Mar 2010 06:51:11 +1030 From: Mark Smith To: Philip Homburg Cc: Mark Townsley , v6ops@ops.ietf.org Subject: Re: simple security Message-ID: <20100325065111.59bb4b72@opy.nosense.org> In-Reply-To: References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Wed, 24 Mar 2010 14:25:12 +0100 Philip Homburg wrote: > Wed, 24 Mar 2010 12:15:49 +0100 Mark Townsley wrote: > >Yes, I know there are still OSes that will be compromised in a matter of > >seconds on the open Internet. These, however, do not run IPv6. With > >IPv6, we are really talking about Vista, Win 7, linux, and macosx. All > >ship with IPv6 firewalls (except linux I suppose), and far more secure > >IP stacks vs. that of ten years ago. All have tethers back home for > >updates, in the event that a new exploit is found. These firewalls are > >far more adaptive and secure than the "IPv6 simple-security" firewall. > > I think it is ironic that in one thread we are discussing devices that are > so resource constrained that they can't even afford to implement DHCPv6, > and have to rely on RFC-5006 to get the locations of DNS servers. And in > the next thread it is assumed that all devices have stateful firewalls and > automatically update themselves whenever a new bug is discovered. > > Somehow that doesn't seem to add up. > > Is it really that case that all that will be connected to the IPv6 internet > are Windows, Linux, and MacOS systems? No printers, no multi-media devices, > no light switches or other home automation systems? Or is every light switch > expected to come with it's own host-based firewall solution? > > A host based firewall can be a simple as a packet filter. For embedded devices, an extremely simple yet fairly effective firewall would be to only accept traffic from ULA source addresses. > From owner-v6ops@ops.ietf.org Wed Mar 24 13:32:45 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E103A6C3D for ; Wed, 24 Mar 2010 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.256 X-Spam-Level: X-Spam-Status: No, score=-105.256 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhP073jNVZXg for ; Wed, 24 Mar 2010 13:32:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C57C83A699F for ; Wed, 24 Mar 2010 13:32:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXF0-000A7l-BG for v6ops-data0@psg.com; Wed, 24 Mar 2010 20:31:50 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXEy-000A7N-7K for v6ops@ops.ietf.org; Wed, 24 Mar 2010 20:31:48 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="171790707" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 20:31:47 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn5-1077.cisco.com [10.21.92.53]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2OKVlvj024848; Wed, 24 Mar 2010 20:31:47 GMT Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <20100325065111.59bb4b72@opy.nosense.org> Date: Wed, 24 Mar 2010 13:31:47 -0700 Cc: Philip Homburg , Mark Townsley , v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <20100325065111.59bb4b72@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 24, 2010, at 1:21 PM, Mark Smith wrote: >> is every light switch >> expected to come with it's own host-based firewall solution? Speaking as the chair of the Security Subcommittee of the SGIP's Smart = Grid Architecture Committee, my inclination would be to have the light = controller be able to authenticate and authorize messages instructing it = to modify the state of its light bulb, and determine whether they are = from a switch that is authorized to initiate such messages. Absent that, = I submit that the 21st century equivalent to TP'ing the house of the = cute person-of-opposite-gender down the street might be to have their = lights making statements using Morse Code. http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Mar 24 13:37:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34803A6D8A for ; Wed, 24 Mar 2010 13:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.295 X-Spam-Level: X-Spam-Status: No, score=-107.295 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v38OcuEoh4M for ; Wed, 24 Mar 2010 13:37:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2670B3A682E for ; Wed, 24 Mar 2010 13:36:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXJU-000AmI-DN for v6ops-data0@psg.com; Wed, 24 Mar 2010 20:36:28 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXJS-000Al7-5O for v6ops@ops.ietf.org; Wed, 24 Mar 2010 20:36:26 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="105267897" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 24 Mar 2010 20:36:25 +0000 Received: from dhcp-wireless-open-abg-27-51.meeting.ietf.org (sjc-vpn5-1077.cisco.com [10.21.92.53]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2OKaP3c011250; Wed, 24 Mar 2010 20:36:25 GMT Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> Date: Wed, 24 Mar 2010 13:36:25 -0700 Cc: Philip Homburg , Mark Townsley , IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <20100325065111.59bb4b72@opy.nosense.org> <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> To: Mark Smith X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: By the way, I didn't invent this. Echelon, which is a company that is = big in building automation, tells me that they do something along these = lines today. On Mar 24, 2010, at 1:31 PM, Fred Baker wrote: > On Mar 24, 2010, at 1:21 PM, Mark Smith wrote: >=20 >>> is every light switch >>> expected to come with it's own host-based firewall solution? >=20 > Speaking as the chair of the Security Subcommittee of the SGIP's Smart = Grid Architecture Committee, my inclination would be to have the light = controller be able to authenticate and authorize messages instructing it = to modify the state of its light bulb, and determine whether they are = from a switch that is authorized to initiate such messages. Absent that, = I submit that the 21st century equivalent to TP'ing the house of the = cute person-of-opposite-gender down the street might be to have their = lights making statements using Morse Code. From owner-v6ops@ops.ietf.org Wed Mar 24 13:49:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A4E3A6DCC for ; Wed, 24 Mar 2010 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj40TbpDJUyi for ; Wed, 24 Mar 2010 13:49:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1D623A67D6 for ; Wed, 24 Mar 2010 13:49:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXVL-000CNv-Ec for v6ops-data0@psg.com; Wed, 24 Mar 2010 20:48:43 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXVJ-000CNd-Ir for v6ops@ops.ietf.org; Wed, 24 Mar 2010 20:48:41 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 8AD749201034 for ; Wed, 24 Mar 2010 13:48:40 -0700 (PDT) X-AuditID: 1180711d-b7c97ae00000413c-66-4baa7aa8b3db Received: from [17.151.81.103] (Unknown_Domain [17.151.81.103]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 42.14.16700.8AA7AAB4; Wed, 24 Mar 2010 13:48:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: simple security From: james woodyatt In-Reply-To: Date: Wed, 24 Mar 2010 13:48:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0175C826-67FF-44B2-865E-8DDFC00C9C32@apple.com> References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <20100325065111.59bb4b72@opy.nosense.org> <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> To: IPv6 v6ops X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mar 24, 2010, at 13:36, Fred Baker wrote: > I submit that the 21st century equivalent to TP'ing the house of the = cute person-of-opposite-gender down the street might be to have their = lights making statements using Morse Code. > [...] > By the way, I didn't invent this. Echelon, which is a company that is = big in building automation, tells me that they do something along these = lines today. Which reminds me of a YouTube video that might lighten some hearts: -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Mar 24 14:06:58 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F573A6D02 for ; Wed, 24 Mar 2010 14:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvg4mDE9kIpk for ; Wed, 24 Mar 2010 14:06:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C3B93A685A for ; Wed, 24 Mar 2010 14:06:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXlq-000ElL-R2 for v6ops-data0@psg.com; Wed, 24 Mar 2010 21:05:46 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuXlo-000Eky-Fp for v6ops@ops.ietf.org; Wed, 24 Mar 2010 21:05:44 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,303,1267401600"; d="scan'208";a="502324014" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2010 21:05:44 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OL5hNH013871; Wed, 24 Mar 2010 21:05:43 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2OL5fY24137; Wed, 24 Mar 2010 14:05:42 -0700 (PDT) Message-ID: <4BAA7EA4.5080407@cisco.com> Date: Wed, 24 Mar 2010 22:05:40 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Fred Baker CC: Mark Smith , Philip Homburg , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <4BA9F465.8060608@cisco.com> <20100325065111.59bb4b72@opy.nosense.org> <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> In-Reply-To: <183AF79F-EADC-4307-8A7E-1A1E4F78FFA7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 9:31 PM, Fred Baker wrote: > On Mar 24, 2010, at 1:21 PM, Mark Smith wrote: > > >>> is every light switch >>> expected to come with it's own host-based firewall solution? >>> > Speaking as the chair of the Security Subcommittee of the SGIP's Smart Grid Architecture Committee, my inclination would be to have the light controller be able to authenticate and authorize messages instructing it to modify the state of its light bulb, and determine whether they are from a switch that is authorized to initiate such messages. Absent that, I submit that the 21st century equivalent to TP'ing the house of the cute person-of-opposite-gender down the street might be to have their lights making statements using Morse Code. > As such, you wouldn't rely on firewall between the two to secure the light controller. The security needs to be between the controller and switch, not policed by a middlebox function dropping packets it thinks might be from a rogue source without *really* knowing. I agree wholeheartedly with this security model. - Mark > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Wed Mar 24 16:27:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584E93A6946 for ; Wed, 24 Mar 2010 16:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.268 X-Spam-Level: ** X-Spam-Status: No, score=2.268 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPcE5AqHEBiC for ; Wed, 24 Mar 2010 16:27:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 688283A6A58 for ; Wed, 24 Mar 2010 16:26:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuZtP-0004d7-OB for v6ops-data0@psg.com; Wed, 24 Mar 2010 23:21:43 +0000 Received: from [194.15.141.107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuZtN-0004cv-MA for v6ops@ops.ietf.org; Wed, 24 Mar 2010 23:21:41 +0000 Received: from dhcp-wireless-open-a-40-56.meeting.ietf.org (unknown [130.129.40.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 0B7D62E039; Wed, 24 Mar 2010 19:02:51 +0100 (CET) Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3176--909770924" From: Lindqvist Kurt Erik In-Reply-To: <4BAA03F3.2000302@cisco.com> Date: Wed, 24 Mar 2010 19:26:44 +0100 Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2812C8B6-3A7A-4509-BF01-92EC514C2FEA@kurtis.pp.se> References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> <65D91B6D-FFC5-4183-892C-307708B4E1F6@kurtis.pp.se> <4BAA03F3.2000302@cisco.com> To: Mark Townsley X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3176--909770924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 mar 2010, at 13.22, Mark Townsley wrote: >>> =20 >> If we believe that the attacks that today exist in IPv4 won't exist = in IPv6 I think we are highly underestimating the investments in the = underground economy. I am convinced we will see the same level of = attacks and exploits for IPv6 as for IPv4. That said, I am not convinced = that any security in the CPE will protect against that, just as NAT = didn't protect in IPv4. However, I don't think that is the issue that we = are trying to address with the simple security draft. >> =20 > Application level attacks will surely be the same. >=20 > L3/L4 attacks will match the vulnerabilities of the OSes under attack. = 90s and early-2000 era IPv4-only stacks are different than today's IPv6 = (and IPv4) stacks. There will definitely be overlap in both = vulnerabilities and attack methods, but I still think it will be a = subset of what we saw in yesteryear. I would agree with this, but I also think that the current simple = security draft does address that overlap.=20 > I do think that CPE security could protect against future attacks, = just not the CPE security defined in draft-ietf-v6ops-simple-security... Could you elaborate in more detail what you think should change?=20 Best regards, - kurtis - --Apple-Mail-3176--909770924 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEUEARECAAYFAkuqWWUACgkQAFdZ6xrc/t6lwACUCD/DtqWbTIQf+65qbaIeEKS8 ggCfVCK+H1nwx+trdVMyx14y5pmxNnc= =8dH5 -----END PGP SIGNATURE----- --Apple-Mail-3176--909770924-- From sigtran-archive@lists.ietf.org Wed Mar 24 18:39:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7843A6BD6 for ; Wed, 24 Mar 2010 18:39:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 24 Mar 2010 18:39:31 -0700 (PDT) Received: from absincorp.com (unknown [190.22.110.132]) by core3.amsl.com (Postfix) with SMTP id ADC0C3A6B8E for ; Wed, 24 Mar 2010 18:39:16 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 75% for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100325013920.ADC0C3A6B8E@core3.amsl.com> Date: Wed, 24 Mar 2010 18:39:16 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 57944 Inc. All rights reserved.

From secmech-request@lists.ietf.org Wed Mar 24 19:09:57 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC403A6BA0 for ; Wed, 24 Mar 2010 19:09:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 24 Mar 2010 19:09:50 -0700 (PDT) Received: from acu.edu (unknown [186.56.158.172]) by core3.amsl.com (Postfix) with SMTP id 67B133A6BAB for ; Wed, 24 Mar 2010 19:09:45 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 73% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100325020949.67B133A6BAB@core3.amsl.com> Date: Wed, 24 Mar 2010 19:09:45 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 57155 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Thu Mar 25 01:05:35 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44A83A67B6 for ; Thu, 25 Mar 2010 01:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0XK2o1Ampu0 for ; Thu, 25 Mar 2010 01:05:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E3333A69D6 for ; Thu, 25 Mar 2010 01:05:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nuhyg-0003bE-5f for v6ops-data0@psg.com; Thu, 25 Mar 2010 07:59:42 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nuhye-0003al-2u for v6ops@ops.ietf.org; Thu, 25 Mar 2010 07:59:40 +0000 Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKO0qkurR7Ht/2dsb2JhbACbIHOkepkVhHwE X-IronPort-AV: E=Sophos;i="4.51,306,1267401600"; d="scan'208";a="248031807" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2010 07:59:39 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2P7xdtj009051; Thu, 25 Mar 2010 07:59:39 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2P7xbY27972; Thu, 25 Mar 2010 00:59:38 -0700 (PDT) Message-ID: <4BAB17E8.4080800@cisco.com> Date: Thu, 25 Mar 2010 08:59:36 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Lindqvist Kurt Erik CC: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , v6ops@ops.ietf.org Subject: Re: simple security References: <001501caca91$769511b0$63bf3510$@org> <201003231748.22841.remi@remlab.net> <65D91B6D-FFC5-4183-892C-307708B4E1F6@kurtis.pp.se> <4BAA03F3.2000302@cisco.com> <2812C8B6-3A7A-4509-BF01-92EC514C2FEA@kurtis.pp.se> In-Reply-To: <2812C8B6-3A7A-4509-BF01-92EC514C2FEA@kurtis.pp.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/24/10 7:26 PM, Lindqvist Kurt Erik wrote: > On 24 mar 2010, at 13.22, Mark Townsley wrote: > > >>>> >>>> >>> If we believe that the attacks that today exist in IPv4 won't exist in IPv6 I think we are highly underestimating the investments in the underground economy. I am convinced we will see the same level of attacks and exploits for IPv6 as for IPv4. That said, I am not convinced that any security in the CPE will protect against that, just as NAT didn't protect in IPv4. However, I don't think that is the issue that we are trying to address with the simple security draft. >>> >>> >> Application level attacks will surely be the same. >> >> L3/L4 attacks will match the vulnerabilities of the OSes under attack. 90s and early-2000 era IPv4-only stacks are different than today's IPv6 (and IPv4) stacks. There will definitely be overlap in both vulnerabilities and attack methods, but I still think it will be a subset of what we saw in yesteryear. >> > I would agree with this, but I also think that the current simple security draft does address that overlap. > > It mimicks IPv4, so addresses quite a bit more than just the overlap. >> I do think that CPE security could protect against future attacks, just not the CPE security defined in draft-ietf-v6ops-simple-security... >> > Could you elaborate in more detail what you think should change? draft-vyncke-advanced-ipv6-security-01 is a start. Also, simply letting people know that running without an IPv6 firewall, today, is not as dangerous as running without an IPv4 firewall, today. - Mark > Best regards, > > - kurtis - > > > > > From v6ops-archive@megatron.ietf.org Thu Mar 25 04:13:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AED3A6A8B for ; Thu, 25 Mar 2010 04:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.745 X-Spam-Level: X-Spam-Status: No, score=-38.745 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fprTiR1xi34P for ; Thu, 25 Mar 2010 04:13:10 -0700 (PDT) Received: from hfu28.internetdsl.tpnet.pl (hfu28.internetdsl.tpnet.pl [79.187.150.28]) by core3.amsl.com (Postfix) with ESMTP id 4FE553A6AB3 for ; Thu, 25 Mar 2010 04:12:50 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@megatron.ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325111250.4FE553A6AB3@core3.amsl.com> Date: Thu, 25 Mar 2010 04:12:50 -0700 (PDT) Newsletter

Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Dif. All rights reserved.
From v6ops-archive@ietf.org Thu Mar 25 04:13:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAFD3A6A8B for ; Thu, 25 Mar 2010 04:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.745 X-Spam-Level: X-Spam-Status: No, score=-38.745 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8jsiS6rxSvm for ; Thu, 25 Mar 2010 04:13:40 -0700 (PDT) Received: from hfu28.internetdsl.tpnet.pl (hfu28.internetdsl.tpnet.pl [79.187.150.28]) by core3.amsl.com (Postfix) with ESMTP id 49E3B3A6AA6 for ; Thu, 25 Mar 2010 04:13:31 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325111332.49E3B3A6AA6@core3.amsl.com> Date: Thu, 25 Mar 2010 04:13:31 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Uyfjpicy. All rights reserved.
From v6ops-archive@lists.ietf.org Thu Mar 25 04:16:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29A93A6A76 for ; Thu, 25 Mar 2010 04:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.745 X-Spam-Level: X-Spam-Status: No, score=-38.745 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_SBL=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANYhyM5Mwy57 for ; Thu, 25 Mar 2010 04:16:41 -0700 (PDT) Received: from hfu28.internetdsl.tpnet.pl (hfu28.internetdsl.tpnet.pl [79.187.150.28]) by core3.amsl.com (Postfix) with ESMTP id BBFB03A6AF5 for ; Thu, 25 Mar 2010 04:15:53 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@lists.ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325111553.BBFB03A6AF5@core3.amsl.com> Date: Thu, 25 Mar 2010 04:15:53 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Qvuu. All rights reserved.
From v6ops-archive@ietf.org Thu Mar 25 08:01:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FEB3A6990 for ; Thu, 25 Mar 2010 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.737 X-Spam-Level: X-Spam-Status: No, score=-40.737 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuP9knazzu0H for ; Thu, 25 Mar 2010 08:01:17 -0700 (PDT) Received: from rev-184-29.ramtel.pl (rev-184-29.ramtel.pl [91.90.184.29]) by core3.amsl.com (Postfix) with ESMTP id 80CF13A691E for ; Thu, 25 Mar 2010 08:01:16 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is 78239A8 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325150116.80CF13A691E@core3.amsl.com> Date: Thu, 25 Mar 2010 08:01:16 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 OVIFAS, Inc.
This e-mail was sent to v6ops-archive@ietf.org.

Click here to unsubscribe
From v6ops-archive@lists.ietf.org Thu Mar 25 08:02:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A26E3A69D1 for ; Thu, 25 Mar 2010 08:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.737 X-Spam-Level: X-Spam-Status: No, score=-18.737 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYIp8hWXA4Ax for ; Thu, 25 Mar 2010 08:02:20 -0700 (PDT) Received: from rev-184-29.ramtel.pl (rev-184-29.ramtel.pl [91.90.184.29]) by core3.amsl.com (Postfix) with ESMTP id 8D6F33A699C for ; Thu, 25 Mar 2010 08:02:19 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@lists.ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is 62278F36 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325150219.8D6F33A699C@core3.amsl.com> Date: Thu, 25 Mar 2010 08:02:19 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 AEVA, Inc.
This e-mail was sent to v6ops-archive@lists.ietf.org.

Click here to unsubscribe
From v6ops-archive@megatron.ietf.org Thu Mar 25 08:02:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7423F3A699C for ; Thu, 25 Mar 2010 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.736 X-Spam-Level: X-Spam-Status: No, score=-38.736 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv65Z+dreJFx for ; Thu, 25 Mar 2010 08:02:24 -0700 (PDT) Received: from rev-184-29.ramtel.pl (rev-184-29.ramtel.pl [91.90.184.29]) by core3.amsl.com (Postfix) with ESMTP id 854BF3A6A39 for ; Thu, 25 Mar 2010 08:02:20 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@megatron.ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is 6CC2F9F MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100325150220.854BF3A6A39@core3.amsl.com> Date: Thu, 25 Mar 2010 08:02:20 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 YUVI, Inc.
This e-mail was sent to v6ops-archive@megatron.ietf.org.

Click here to unsubscribe
From failurekx45@sibstyle.ru Thu Mar 25 13:43:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A793A6B97; Thu, 25 Mar 2010 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.375 X-Spam-Level: X-Spam-Status: No, score=-22.375 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, DOS_OE_TO_MX=2.75, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0MomcSO-RLO; Thu, 25 Mar 2010 13:43:13 -0700 (PDT) Received: from pra69-d104.gd.dial-up.cz (pra8-b104.adsl.dial-up.cz [193.85.69.104]) by core3.amsl.com (Postfix) with ESMTP id 06D9D3A6823; Thu, 25 Mar 2010 13:43:04 -0700 (PDT) Message-ID: <000d01cacc5b$c0529bd0$6400a8c0@failurekx45> From: "Internal Revenue Service" To: Subject: Underreported Income Notice Date: Thu, 25 Mar 2010 21:42:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CACC5B.C0529BD0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CACC5B.C0529BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: wgchairs-request-00000243133992US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: wgchairs-request-00000243133992US Internal Revenue Service ------=_NextPart_000_0007_01CACC5B.C0529BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: wgchairs-reques= t-00000243133992US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: wgchairs-request-00000243133992US

Internal Revenue Service

------=_NextPart_000_0007_01CACC5B.C0529BD0-- From owner-v6ops@ops.ietf.org Thu Mar 25 14:55:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0833F3A6C88 for ; Thu, 25 Mar 2010 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P303eaXt8DOC for ; Thu, 25 Mar 2010 14:55:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72E6B3A682E for ; Thu, 25 Mar 2010 14:55:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nuuvz-0000BM-Sb for v6ops-data0@psg.com; Thu, 25 Mar 2010 21:49:47 +0000 Received: from [2001:1bb8:2004:150::2] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nuuvt-000080-Kp for v6ops@ops.ietf.org; Thu, 25 Mar 2010 21:49:42 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from crumpet.foobar.org (crumpet.foobar.org [10.230.100.249]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id o2PLlgwW049175 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Mar 2010 21:47:50 GMT (envelope-from nick@inex.ie) Message-ID: <4BABD9FD.8050809@inex.ie> Date: Thu, 25 Mar 2010 21:47:41 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Fred Baker , IPv6 v6ops Subject: Re: On filibusters as a mode of technical discussion References: <4BA78BE7.6010005@cisco.com> <20100324094859.GC6391@vacation.karoshi.com.> <4BA9FC3A.4070803@inex.ie> <20100324152216.GA11142@vacation.karoshi.com.> In-Reply-To: <20100324152216.GA11142@vacation.karoshi.com.> X-Enigmail-Version: 1.0.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 24/03/2010 15:22, bmanning@vacation.karoshi.com wrote: > My point being made... I repsect Freds closing of the virtual mic. likewise, I apologise to all for shouting so loudly about what the colour of the bikeshed ought to be. Nick /relurk From urn-archive@ietf.org Fri Mar 26 05:18:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4A43A6AFB for ; Fri, 26 Mar 2010 05:18:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 26 Mar 2010 05:18:24 -0700 (PDT) Received: from 93-47-115-222.ip112.fastwebnet.it (93-47-115-222.ip112.fastwebnet.it [93.47.115.222]) by core3.amsl.com (Postfix) with SMTP id 1E53E3A6AFC for ; Fri, 26 Mar 2010 05:17:28 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100326121732.1E53E3A6AFC@core3.amsl.com> Date: Fri, 26 Mar 2010 05:17:28 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 66672 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Fri Mar 26 07:41:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B153A68A0 for ; Fri, 26 Mar 2010 07:41:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 26 Mar 2010 07:41:11 -0700 (PDT) Received: from adt.com (unknown [122.167.4.164]) by core3.amsl.com (Postfix) with SMTP id 225343A690B for ; Fri, 26 Mar 2010 07:41:06 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 74% for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100326144107.225343A690B@core3.amsl.com> Date: Fri, 26 Mar 2010 07:41:06 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 73266 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Fri Mar 26 08:41:08 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23BF3A695A for ; Fri, 26 Mar 2010 08:41:08 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 26 Mar 2010 08:41:07 -0700 (PDT) Received: from 147.Red-88-28-5.staticIP.rima-tde.net (12.Red-88-29-102.staticIP.rima-tde.net [88.29.102.12]) by core3.amsl.com (Postfix) with SMTP id D130D3A691C for ; Fri, 26 Mar 2010 08:41:05 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 77% off To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100325-1, 25/03/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100326154105.D130D3A691C@core3.amsl.com> Date: Fri, 26 Mar 2010 08:41:05 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 49208 Inc. All rights reserved.

From argotni877@sanantonio.school.nz Fri Mar 26 10:17:16 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930413A6BAB; Fri, 26 Mar 2010 10:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.811 X-Spam-Level: X-Spam-Status: No, score=-22.811 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_PH_SURBL=1.787, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+iYBCwbF+rq; Fri, 26 Mar 2010 10:17:16 -0700 (PDT) Received: from 80-235-68-231-dsl.trt.estpak.ee (80-235-68-231-dsl.trt.estpak.ee [80.235.68.231]) by core3.amsl.com (Postfix) with ESMTP id 6149A3A6BEA; Fri, 26 Mar 2010 10:16:56 -0700 (PDT) Received: from 80.235.68.231 by sanantonio.school.nz; Fri, 26 Mar 2010 19:16:36 +0200 From: "Internal Revenue Service" To: Subject: the CP2000 notice (Underreported Income Notice) Date: Fri, 26 Mar 2010 19:16:36 +0200 Message-ID: <000d01cacd08$17267830$6400a8c0@argotni877> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CACD08.17267830" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2244.8 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000E_01CACD08.17267830 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Taxpayer ID: tls-00000653625313US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: tls-00000653625313US Internal Revenue Service ------=_NextPart_000_000E_01CACD08.17267830 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: tls-00000653625= 313US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review tax statement = for taxpayer id: tls-00000653625313US

Internal Revenue Service

------=_NextPart_000_000E_01CACD08.17267830-- From owner-v6ops@ops.ietf.org Fri Mar 26 10:29:32 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ED53A6B22 for ; Fri, 26 Mar 2010 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.276 X-Spam-Level: X-Spam-Status: No, score=-7.276 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvAX+DZh8vz6 for ; Fri, 26 Mar 2010 10:29:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C1A73A6A37 for ; Fri, 26 Mar 2010 10:29:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDH1-000OP8-AL for v6ops-data0@psg.com; Fri, 26 Mar 2010 17:24:43 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDGy-000ON5-Az for v6ops@ops.ietf.org; Fri, 26 Mar 2010 17:24:40 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFABaKrEutJV2a/2dsb2JhbACBRZlhc6Z6iyQJjWgCgmmCEwSDHg X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208,217";a="96477348" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 26 Mar 2010 17:24:38 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o2QHOc4X005180 for ; Fri, 26 Mar 2010 17:24:38 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 12:24:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACD09.365027B9" Subject: draft-jiang-v6ops-nc-protection-01.txt Date: Fri, 26 Mar 2010 12:24:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jiang-v6ops-nc-protection-01.txt Thread-Index: AcrNCTYzc7uPGsnsRGeerlBz6FPHLw== From: "Hemant Singh (shemant)" To: "IPv6 Operations" X-OriginalArrivalTime: 26 Mar 2010 17:24:38.0623 (UTC) FILETIME=[367FDEF0:01CACD09] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CACD09.365027B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem this document is trying to solve and any other ND related security problem can be solved by use of SEND. If SEND is not used, as I said on the mike, read section 5.3 of the RFC 4861 which will purge bogus entries due to NUD timeout. This document is of no use at all. =20 =20 Hemant =20 Hemant Singh Technical Leader.engineering Product Development shemant@cisco.com Phone: +1 978 936 1622 Cisco Systems, Inc. United States Cisco.com - http://www.cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CACD09.365027B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The problem this document is trying to solve and = any other ND related security problem can be solved by use of SEND.  If SEND = is not used, as I said on the mike, read section 5.3 of the RFC 4861 which will = purge bogus entries due to NUD timeout.  This document is of no use at = all. 

 

Hemant

 


Hemant Singh
Technical Leader.engineering
Product Development
shemant@cisco.com
Phone: +1 978 936 1622
Cisco Systems, Inc.
United States
Cisco.com - http://www.cisco.com


For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

------_=_NextPart_001_01CACD09.365027B9-- From owner-v6ops@ops.ietf.org Fri Mar 26 10:34:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16373A68D6 for ; Fri, 26 Mar 2010 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bdbwelxYmNW for ; Fri, 26 Mar 2010 10:34:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04CE23A684F for ; Fri, 26 Mar 2010 10:34:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDPs-000PUg-7L for v6ops-data0@psg.com; Fri, 26 Mar 2010 17:33:52 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDPq-000PUO-Ct for v6ops@ops.ietf.org; Fri, 26 Mar 2010 17:33:50 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id B8B62924E6F4; Fri, 26 Mar 2010 10:33:49 -0700 (PDT) X-AuditID: 11807134-b7bcaae000006bd8-5c-4baceffd560d Received: from [17.151.121.225] (Unknown_Domain [17.151.121.225]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 9A.E6.27608.DFFECAB4; Fri, 26 Mar 2010 10:33:49 -0700 (PDT) Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> Date: Fri, 26 Mar 2010 10:33:49 -0700 Cc: IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: [added V6OPS list] On Mar 26, 2010, at 08:11, Ole Troan wrote: >> Yeah, I think that after the bloody simple-security debates of the = past >> week, that many are amazed that anyone on this list was able to miss = the >> carnage. Anyway, the current CPE router draft has the following = security >> requirements in section 4.4: >>=20 >> S-1: The IPv6 CE router SHOULD support >> [I-D.ietf-v6ops-cpe-simple-security]. >>=20 >> S-2: The IPv6 CE router MUST support ingress filtering in = accordance >> with [RFC2827](BCP 38) >>=20 >> The simple-security draft referenced in S-1 describes exactly what >> you're asking for (IMO), only in much greater detail. So I think what >> you're asking for is already in the cpe-router draft, and it would be = a >> good idea for you to look at the simple-security draft and provide >> comments to it, if you think there's something missing.=20 >=20 > indeed, apart from the fact that it does not/will not make any = recommendation about default on or off. If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host the = debate over whether or not to make such a recommendation, then that = would make me very, very happy. We could declare all such flames out of = scope for the discussion to review I-D.ietf-v6ops-cpe-simple-security. = I might even consider bribing you with chocolates and fruit baskets if = that would help. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Mar 26 10:42:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555C33A6BD8 for ; Fri, 26 Mar 2010 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZaRyX5sHQ4u for ; Fri, 26 Mar 2010 10:42:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CE993A6B54 for ; Fri, 26 Mar 2010 10:42:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDXW-0000eB-H0 for v6ops-data0@psg.com; Fri, 26 Mar 2010 17:41:46 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvDXU-0000dO-3g for v6ops@ops.ietf.org; Fri, 26 Mar 2010 17:41:44 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAAOPrEuQ/uCWe2dsb2JhbACbJhUBAQsLJAYcpneZFIR+BIMe X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208";a="4855506" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 Mar 2010 17:07:17 +0000 Received: from sjc-vpn7-997.cisco.com (sjc-vpn7-997.cisco.com [10.21.147.229]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2QHfenR020728; Fri, 26 Mar 2010 17:41:41 GMT Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> Date: Fri, 26 Mar 2010 10:43:31 -0700 Cc: IETF IPv6 Mailing List , IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <60DE0EAF-E6B7-460F-8A44-DE12189E9930@cisco.com> References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: James, >> indeed, apart from the fact that it does not/will not make any = recommendation about default on or off. >=20 > If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host = the debate over whether or not to make such a recommendation, then that = would make me very, very happy. We could declare all such flames out of = scope for the discussion to review I-D.ietf-v6ops-cpe-simple-security. = I might even consider bribing you with chocolates and fruit baskets if = that would help. I'm known to both like chocolate and be gullible, but not _that_ = gullible. ;-) cheers, Ole= From v6ops-archive@ietf.org Fri Mar 26 12:19:54 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F803A69DB for ; Fri, 26 Mar 2010 12:19:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 26 Mar 2010 12:19:28 -0700 (PDT) Received: from 178-24-57-230-dynip.superkabel.de (178-24-57-230-dynip.superkabel.de [178.24.57.230]) by core3.amsl.com (Postfix) with SMTP id C52843A6BBD for ; Fri, 26 Mar 2010 12:19:18 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Discount 77% for v6ops-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100326191918.C52843A6BBD@core3.amsl.com> Date: Fri, 26 Mar 2010 12:19:18 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 72934 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Fri Mar 26 12:34:06 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9366D3A6B5E for ; Fri, 26 Mar 2010 12:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.891 X-Spam-Level: X-Spam-Status: No, score=-99.891 tagged_above=-999 required=5 tests=[AWL=1.579, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV6DRZI93mF7 for ; Fri, 26 Mar 2010 12:34:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C90A3A6774 for ; Fri, 26 Mar 2010 12:34:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvFEm-000G6W-O8 for v6ops-data0@psg.com; Fri, 26 Mar 2010 19:30:32 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvFEh-000G6A-NT for v6ops@ops.ietf.org; Fri, 26 Mar 2010 19:30:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 1692B3A6920; Fri, 26 Mar 2010 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100326193002.1692B3A6920@core3.amsl.com> Date: Fri, 26 Mar 2010 12:30:01 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-10.txt Pages : 37 Date : 2010-03-26 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-cpe-simple-security-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-26121650.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Fri Mar 26 12:48:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2F93A6C36 for ; Fri, 26 Mar 2010 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJTLcZK7nV3G for ; Fri, 26 Mar 2010 12:48:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 165DC3A6C37 for ; Fri, 26 Mar 2010 12:48:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvFUj-000IKR-MO for v6ops-data0@psg.com; Fri, 26 Mar 2010 19:47:01 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvFUh-000IKD-TS for v6ops@ops.ietf.org; Fri, 26 Mar 2010 19:46:59 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 4846B8B347DE for ; Fri, 26 Mar 2010 12:46:59 -0700 (PDT) X-AuditID: 11807130-b7bdeae000004562-0f-4bad0f32f6c2 Received: from [17.151.96.95] (Unknown_Domain [17.151.96.95]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 80.AC.17762.33F0DAB4; Fri, 26 Mar 2010 12:46:59 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I-D.ietf-v6ops-cpe-simple-security-10 Date: Fri, 26 Mar 2010 12:46:58 -0700 Message-Id: <761D008B-0331-49BD-815A-8F27AEAF6FAA@apple.com> To: IPv6 v6ops Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: everyone-- I'm hoping that the revision of the draft just posted by the secretariat = is ready for working group last call. If you can find an error where I = forgot to make an edit to reflect the consensus already established = here, then now would be a great time to bring it to my attention. I = think the chairs have said that WGLC for this draft could begin as soon = as Monday, assuming we think the draft is ready for that. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Mar 26 15:15:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479FA3A6C4C for ; Fri, 26 Mar 2010 15:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpBuSX6qso+7 for ; Fri, 26 Mar 2010 15:15:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6966C3A6A31 for ; Fri, 26 Mar 2010 15:14:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvHhi-0009Nc-R4 for v6ops-data0@psg.com; Fri, 26 Mar 2010 22:08:34 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvHhg-0009NO-Nw for v6ops@ops.ietf.org; Fri, 26 Mar 2010 22:08:32 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4gAJbNrEurR7Ht/2dsb2JhbACKOJByc6YvjxuJeoR+BA X-IronPort-AV: E=Sophos;i="4.51,316,1267401600"; d="scan'208";a="312135742" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2010 22:08:32 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2QM8WsO016228; Fri, 26 Mar 2010 22:08:32 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2QM8UY01432; Fri, 26 Mar 2010 15:08:31 -0700 (PDT) Message-ID: <4BAD305D.3070808@cisco.com> Date: Fri, 26 Mar 2010 23:08:29 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipv6@ietf.org, IPv6 v6ops Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> In-Reply-To: <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/26/10 6:33 PM, james woodyatt wrote: > [added V6OPS list] > > On Mar 26, 2010, at 08:11, Ole Troan wrote: > > >>> Yeah, I think that after the bloody simple-security debates of the past >>> week, that many are amazed that anyone on this list was able to miss the >>> carnage. Anyway, the current CPE router draft has the following security >>> requirements in section 4.4: >>> >>> S-1: The IPv6 CE router SHOULD support >>> [I-D.ietf-v6ops-cpe-simple-security]. >>> What does "support" mean? I would like it to be very clear that "support" does not imply that it be set to "transparent" or "non-transparent" mode by default, just that the functionality exist and be available to be turned on or off. - Mark >>> S-2: The IPv6 CE router MUST support ingress filtering in accordance >>> with [RFC2827](BCP 38) >>> >>> The simple-security draft referenced in S-1 describes exactly what >>> you're asking for (IMO), only in much greater detail. So I think what >>> you're asking for is already in the cpe-router draft, and it would be a >>> good idea for you to look at the simple-security draft and provide >>> comments to it, if you think there's something missing. >>> >> indeed, apart from the fact that it does not/will not make any recommendation about default on or off. >> > If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host the debate over whether or not to make such a recommendation, then that would make me very, very happy. We could declare all such flames out of scope for the discussion to review I-D.ietf-v6ops-cpe-simple-security. I might even consider bribing you with chocolates and fruit baskets if that would help. > > > -- > james woodyatt > member of technical staff, communications engineering > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From smf-discussion@lists.ietf.org Sat Mar 27 04:22:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E013A69AB for ; Sat, 27 Mar 2010 04:22:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 27 Mar 2010 04:22:12 -0700 (PDT) Received: from ppp135-18.tis-dialog.ru (ppp135-18.tis-dialog.ru [83.219.135.18]) by core3.amsl.com (Postfix) with SMTP id 4143F3A686E for ; Sat, 27 Mar 2010 04:22:04 -0700 (PDT) From: Approved VIAGRA® Store Subject: New Private Message for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100327112208.4143F3A686E@core3.amsl.com> Date: Sat, 27 Mar 2010 04:22:04 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 66114 Inc. All rights reserved.

From v6ops-archive@ietf.org Sat Mar 27 07:31:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FDB3A67FD for ; Sat, 27 Mar 2010 07:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.695 X-Spam-Level: X-Spam-Status: No, score=-44.695 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC4Yg9x89sPk for ; Sat, 27 Mar 2010 07:31:23 -0700 (PDT) Received: from alum.rpi.edu (unknown [188.186.84.45]) by core3.amsl.com (Postfix) with SMTP id 4F2823A67B5 for ; Sat, 27 Mar 2010 07:31:19 -0700 (PDT) To: Subject: Good week Sale for v6ops-archive - Up To 76% Off! From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100327143120.4F2823A67B5@core3.amsl.com> Date: Sat, 27 Mar 2010 07:31:19 -0700 (PDT)
       Not seeing images? Click here.



Onlyfor you! Today 85% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-160-009-9956 from the U.S. & Canada or +319-64-9904542in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Sat Mar 27 08:03:25 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863B13A69D3 for ; Sat, 27 Mar 2010 08:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.557 X-Spam-Level: *** X-Spam-Status: No, score=3.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MANGLED_MARKET=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udIke3152AqY for ; Sat, 27 Mar 2010 08:03:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C8B53A69DE for ; Sat, 27 Mar 2010 08:03:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvXSN-000Ice-FR for v6ops-data0@psg.com; Sat, 27 Mar 2010 14:57:47 +0000 Received: from [209.85.218.209] (helo=mail-bw0-f209.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvXSL-000IcQ-Cb for v6ops@ops.ietf.org; Sat, 27 Mar 2010 14:57:45 +0000 Received: by bwz1 with SMTP id 1so2492368bwz.1 for ; Sat, 27 Mar 2010 07:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+XpDxewMEM/t2Uyq8Elkcg59d1DfMJBerqXr7tx6kp8=; b=CzTPZj9BCz9YfmRZEVUbgvWa4zNEAsChOP2oAlRw+d647hHAw8S5+7SjD9U0FZiS24 Fpplg5jByjKanKSsdLskac/WGFQPDJUsarAZUxJWNHHryyiXTxpuEfAHN6qKnyGAtSnK 4IW16RPxawZva5RH7eIUXJQFVu8k6ftWSfdFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ny8OBKWeoZ+287d3SphFlvmx28o4Y9tRCO80F7cF0jXnn+KBff7dDi15sCb6dJ2nSw g3wRcA2lU+l1DmGpHRKt5UvasIkKsLeG5XiKsk4RjKWH4q3vtJaKGSU1WtvM2VA/i7Tr EAw05ippZQIMdlH4eXcLSngKKuKdwUa92wgzs= MIME-Version: 1.0 Received: by 10.204.153.14 with HTTP; Sat, 27 Mar 2010 07:57:43 -0700 (PDT) In-Reply-To: <4BAD305D.3070808@cisco.com> References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> Date: Sat, 27 Mar 2010 15:57:43 +0100 X-Google-Sender-Auth: e9128f72f61bb157 Received: by 10.204.140.4 with SMTP id g4mr3100267bku.170.1269701863451; Sat, 27 Mar 2010 07:57:43 -0700 (PDT) Message-ID: <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 From: Ole Troan To: Mark Townsley Cc: IPv6 v6ops Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark, et al, [removed ipv6] >>>> Yeah, I think that after the bloody simple-security debates of the pas= t >>>> week, that many are amazed that anyone on this list was able to miss t= he >>>> carnage. Anyway, the current CPE router draft has the following securi= ty >>>> requirements in section 4.4: >>>> >>>> =A0S-1: =A0The IPv6 CE router SHOULD support >>>> =A0 =A0 =A0 =A0[I-D.ietf-v6ops-cpe-simple-security]. >>>> > > What does "support" mean? > > I would like it to be very clear that "support" does not imply that it be > set to "transparent" or "non-transparent" mode by default, just that the > functionality exist and be available to be turned on or off. that was also indeed my understanding when we wrote that requirement. would this be even clearer: S-1: The IPv6 CE router SHOULD support [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling this functionality MUST be user configurable. to me this means that the default would be decided by a vendor or operator. not quite sure what the process is for updating a draft which has passed WG= LC? cheers, Ole From usv-chairs@ietf.org Sat Mar 27 11:01:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1A93A6A00 for ; Sat, 27 Mar 2010 11:01:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 27 Mar 2010 11:01:42 -0700 (PDT) Received: from s83-39-247.sfi.paltel.net (s83-39-247.sfi.paltel.net [83.244.39.247]) by core3.amsl.com (Postfix) with SMTP id F2B963A6A4C for ; Sat, 27 Mar 2010 10:56:02 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100327175606.F2B963A6A4C@core3.amsl.com> Date: Sat, 27 Mar 2010 10:56:02 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78652 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Sat Mar 27 12:26:26 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8ACD3A6827 for ; Sat, 27 Mar 2010 12:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.654 X-Spam-Level: X-Spam-Status: No, score=-106.654 tagged_above=-999 required=5 tests=[AWL=-1.589, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C53nq3-MtWrK for ; Sat, 27 Mar 2010 12:26:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD8ED3A69B8 for ; Sat, 27 Mar 2010 12:26:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvbZG-000LaC-TD for v6ops-data0@psg.com; Sat, 27 Mar 2010 19:21:10 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvbZE-000LZt-Lv for v6ops@ops.ietf.org; Sat, 27 Mar 2010 19:21:08 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,320,1267401600"; d="scan'208";a="173356433" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 27 Mar 2010 19:21:08 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2RJL7PK010974; Sat, 27 Mar 2010 19:21:07 GMT Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> Date: Sat, 27 Mar 2010 12:21:07 -0700 Cc: Mark Townsley , IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> To: Ole Troan X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I have not yet sent it to the IEG. If you want to change it, post one = now. In any event, I expect there would be another round of community review. On Mar 27, 2010, at 7:57 AM, Ole Troan wrote: > Mark, et al, >=20 > [removed ipv6] >=20 >>>>> Yeah, I think that after the bloody simple-security debates of the = past >>>>> week, that many are amazed that anyone on this list was able to = miss the >>>>> carnage. Anyway, the current CPE router draft has the following = security >>>>> requirements in section 4.4: >>>>>=20 >>>>> S-1: The IPv6 CE router SHOULD support >>>>> [I-D.ietf-v6ops-cpe-simple-security]. >>>>>=20 >>=20 >> What does "support" mean? >>=20 >> I would like it to be very clear that "support" does not imply that = it be >> set to "transparent" or "non-transparent" mode by default, just that = the >> functionality exist and be available to be turned on or off. >=20 > that was also indeed my understanding when we wrote that requirement. >=20 > would this be even clearer: >=20 > S-1: The IPv6 CE router SHOULD support > [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling this > functionality MUST be user configurable. >=20 > to me this means that the default would be decided by a vendor or = operator. >=20 > not quite sure what the process is for updating a draft which has = passed WG LC? >=20 > cheers, > Ole >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sat Mar 27 13:17:15 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335643A698E for ; Sat, 27 Mar 2010 13:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY-GWM5hRkUk for ; Sat, 27 Mar 2010 13:17:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1EE33A6827 for ; Sat, 27 Mar 2010 13:17:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvcPp-00013H-IJ for v6ops-data0@psg.com; Sat, 27 Mar 2010 20:15:29 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvcPm-00012x-PE for v6ops@ops.ietf.org; Sat, 27 Mar 2010 20:15:27 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJoErkutJV2Y/2dsb2JhbACbLnOkXphdhQEEgx4 X-IronPort-AV: E=Sophos;i="4.51,320,1267401600"; d="scan'208,217";a="96832895" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 27 Mar 2010 20:15:24 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o2RKFObo031171; Sat, 27 Mar 2010 20:15:24 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Mar 2010 15:15:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACDEA.3B883063" Subject: RE: draft-ietf-v6ops-ipv6-cpe-router-04 Date: Sat, 27 Mar 2010 15:15:22 -0500 Message-ID: In-Reply-To: <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-ipv6-cpe-router-04 Thread-Index: AcrN44G0luxvWuq8RimUkfz2EVjwuwABKanQ References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "Ole Troan" Cc: "Mark Townsley (townsley)" , "IPv6 v6ops" X-OriginalArrivalTime: 27 Mar 2010 20:15:24.0422 (UTC) FILETIME=[3BE27A60:01CACDEA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CACDEA.3B883063 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker (fred) >Sent: Saturday, March 27, 2010 12:21 PM >To: Ole Troan >Cc: Mark Townsley (townsley); IPv6 v6ops >Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 >I have not yet sent it to the IEG. If you want to change it, post one now. >In any event, I expect there would be another round of community review. Good to hear that, Fred. Mark Townsley also jabbered a comment on Friday in the v6ops meeting that the Intro or Abstract of the Phase I IPv6 CE Rtr should be a little more clear to define its goals for simple vs. Advanced etc. Did I get this fact correctly? If yes, then once I get the exact quote from Mark's comments we can look into editing our document. Mark also commented on what does one mean by "support" in his email. But now the bullet seems to need more work because soon as one says a feature is configurable, the next question others will ask is, "well, what's the default"? So here is a little more modified text suggestion from me for the relevant bullet. S-1: The IPv6 CE router SHOULD implement [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling the security functionality MUST be user configurable. The default for whether simple security is enabled or disabled is specified in I-D.ietf-v6ops-cpe-simple-security]. Now so we have single source to reference our bullet's properties from; the source being the I-D.ietf-v6ops-cpe-simple-security. Now it's up to v6ops as a WG to nail down which of enabled or disabled is the default in the I-D.ietf-v6ops-cpe-simple-security.document. Hemant ------_=_NextPart_001_01CACDEA.3B883063 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-v6ops-ipv6-cpe-router-04

>-----Original Message-----
>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org<= /A>] On Behalf Of Fred Baker (fred)
>Sent: Saturday, March 27, 2010 12:21 PM
>To: Ole Troan
>Cc: Mark Townsley (townsley); IPv6 v6ops
>Subject: Re: = draft-ietf-v6ops-ipv6-cpe-router-04

>I have not yet sent it to the IEG. If you want to = change it, post one now.

>In any event, I expect there would be another round of = community review.

Good to hear that, Fred.  Mark = Townsley also jabbered a comment on Friday in the v6ops = meeting that the Intro or Abstract of the Phase I IPv6 CE = Rtr should be a little more clear to = define its goals for simple vs. Advanced etc.  Did I get this fact correctly? If yes, = then once I get the exact = quote from Mark's comments we can look into editing our = document.   Mark = also commented on what does one mean by = "support" in his = email.  But now the = bullet seems to need more work because soon as one says a feature is = configurable, the next question others will ask is, "well, what's the = default"?  So here is a = little more modified text suggestion from me for the relevant bullet.

S-1:  The IPv6 CE router SHOULD = implement [I-D.ietf-v6ops-cpe-simple-security]. Enabling or = disabling the security functionality = MUST be user configurable.  The default for whether simple security is enabled or = disabled = is specified in I-D.ietf-v6ops-cpe-simple-security].

Now so we have single source to reference our bullet's = properties from; the source being the I-D.ietf-v6ops-cpe-simple-security.  Now it's up to v6ops as a WG to nail down which = of enabled or disabled is = the default in the I-D.ietf-v6ops-cpe-simple-security.document.

Hemant

------_=_NextPart_001_01CACDEA.3B883063-- From send-archive@lists.ietf.org Sat Mar 27 13:33:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707C93A68F6 for ; Sat, 27 Mar 2010 13:33:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 27 Mar 2010 13:33:07 -0700 (PDT) Received: from adsl21114.4u.com.gh (adsl21114.4u.com.gh [41.210.21.114]) by core3.amsl.com (Postfix) with SMTP id AF54D3A63C9 for ; Sat, 27 Mar 2010 13:32:46 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100327203259.AF54D3A63C9@core3.amsl.com> Date: Sat, 27 Mar 2010 13:32:46 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 79929 Inc. All rights reserved.

From secmech-request@lists.ietf.org Sat Mar 27 14:39:41 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D9E3A6802 for ; Sat, 27 Mar 2010 14:39:41 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 27 Mar 2010 14:39:34 -0700 (PDT) Received: from 212-33-89.adsl.terra.cl (212-33-89.adsl.terra.cl [200.89.33.212]) by core3.amsl.com (Postfix) with SMTP id 172DB3A63C9 for ; Sat, 27 Mar 2010 14:38:27 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Discount 78% for v6ops-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100327213922.172DB3A63C9@core3.amsl.com> Date: Sat, 27 Mar 2010 14:38:27 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 56605 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Sat Mar 27 23:43:18 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF2D3A6A51 for ; Sat, 27 Mar 2010 23:43:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 27 Mar 2010 23:43:12 -0700 (PDT) Received: from alko.permnet.ru (unknown [59.161.147.253]) by core3.amsl.com (Postfix) with SMTP id BF15D3A6A56 for ; Sat, 27 Mar 2010 23:42:55 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 76% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100328064259.BF15D3A6A56@core3.amsl.com> Date: Sat, 27 Mar 2010 23:42:55 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 89094 Inc. All rights reserved.

From urn-archive@ietf.org Sun Mar 28 03:04:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B073A696C for ; Sun, 28 Mar 2010 03:04:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 28 Mar 2010 03:04:23 -0700 (PDT) Received: from ip-83-149-3-64.nwgsm.ru (ip-83-149-3-64.nwgsm.ru [83.149.3.64]) by core3.amsl.com (Postfix) with SMTP id 2840A3A6A74 for ; Sun, 28 Mar 2010 03:00:27 -0700 (PDT) From: Approved VIAGRA® Store Subject: Electronic Discount Code 76% for v6ops-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100328100030.2840A3A6A74@core3.amsl.com> Date: Sun, 28 Mar 2010 03:00:27 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 66461 Inc. All rights reserved.

From secmech-request@lists.ietf.org Sun Mar 28 05:50:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7839C3A6960 for ; Sun, 28 Mar 2010 05:50:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 28 Mar 2010 05:50:22 -0700 (PDT) Received: from amk-solac.com (unknown [122.162.157.43]) by core3.amsl.com (Postfix) with SMTP id 7DAC23A6811 for ; Sun, 28 Mar 2010 05:50:14 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 71% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100328125020.7DAC23A6811@core3.amsl.com> Date: Sun, 28 Mar 2010 05:50:14 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 59228 Inc. All rights reserved.

From uri-review-request@megatron.ietf.org Sun Mar 28 06:11:00 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A972D3A68B6 for ; Sun, 28 Mar 2010 06:11:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 28 Mar 2010 06:10:54 -0700 (PDT) Received: from port-26-adslby-pool40.infonet.by (port-26-adslby-pool40.infonet.by [81.25.40.26]) by core3.amsl.com (Postfix) with SMTP id 81CAD3A67F6 for ; Sun, 28 Mar 2010 06:10:50 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100328131052.81CAD3A67F6@core3.amsl.com> Date: Sun, 28 Mar 2010 06:10:50 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 91422 Inc. All rights reserved.

From v6ops-archive@megatron.ietf.org Sun Mar 28 06:33:44 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC8A3A68EF for ; Sun, 28 Mar 2010 06:33:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 28 Mar 2010 06:33:37 -0700 (PDT) Received: from 19.cn (unknown [210.89.50.226]) by core3.amsl.com (Postfix) with SMTP id 06B1E3A6864 for ; Sun, 28 Mar 2010 06:33:34 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100328133336.06B1E3A6864@core3.amsl.com> Date: Sun, 28 Mar 2010 06:33:34 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 79559 Inc. All rights reserved.

From v6ops-archive@lists.ietf.org Sun Mar 28 08:51:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392F13A67D2 for ; Sun, 28 Mar 2010 08:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.227 X-Spam-Level: X-Spam-Status: No, score=-30.227 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfh+WmIaqDVP for ; Sun, 28 Mar 2010 08:50:56 -0700 (PDT) Received: from agdavi.com (unknown [89.113.233.28]) by core3.amsl.com (Postfix) with SMTP id 2C7733A63EB for ; Sun, 28 Mar 2010 08:50:30 -0700 (PDT) To: Subject: President's Day Sale for v6ops-archive - Up To 71% Off! From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100328155033.2C7733A63EB@core3.amsl.com> Date: Sun, 28 Mar 2010 08:50:30 -0700 (PDT)
       Not seeing images? Click here.



Onlyfor you! Today 84% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@lists.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@lists.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-972-807-1862 from the U.S. & Canada or +392-89-5154299in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Sun Mar 28 09:48:10 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A7F3A684C for ; Sun, 28 Mar 2010 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.13 X-Spam-Level: ** X-Spam-Status: No, score=2.13 tagged_above=-999 required=5 tests=[BAYES_60=1, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH34QSOixDxy for ; Sun, 28 Mar 2010 09:48:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3F083A67AB for ; Sun, 28 Mar 2010 09:48:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvvYj-000HgV-2S for v6ops-data0@psg.com; Sun, 28 Mar 2010 16:41:57 +0000 Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvvYg-000Hfi-6t for v6ops@ops.ietf.org; Sun, 28 Mar 2010 16:41:54 +0000 Received: from p5ddab2b8.dip.t-dialin.net ([93.218.178.184] helo=zaphod.lan.local) by p15139323.pureserver.info with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NvvYc-0004q5-SY for v6ops@ops.ietf.org; Sun, 28 Mar 2010 18:41:50 +0200 From: Konrad Rosenbaum To: v6ops@ops.ietf.org Subject: Re: simple security Date: Sun, 28 Mar 2010 17:41:45 +0100 User-Agent: KMail/1.9.10 References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13807526.O98sudBWg2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003281841.48962@zaphod.konrad.silmor.de> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --nextPart13807526.O98sudBWg2 Content-Type: text/plain; charset="ansi_x3.4-1968" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 24 March 2010, Mohacsi Janos wrote: > > Your NAS should run link-local or ULA if you don't want it to reach the > > outside world. > > How to configure the NAS for such a setup? > - If I use SLAAC? Do I have to prevent RAs with global prefix to be > arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I > get ULA via SLAAC? This requires a pretty complex setup. If I would build the NAS I would let it operate as usual, but add a few=20 simple packet filter rules to the rudimentary firewall inside the device:=20 allow absolutely everything out; allow everything in that targets me at=20 fe80::/10; allow everything in that targets me at fc00::/7 if it comes from= =20 a locally advertise network, do not allow anything else in. I would also=20 give the user an option to disable the packet dropping code (if I felt too= =20 lazy to implement a proper configuration). I wouldn't expect the router or= =20 any other device to protect or fool my NAS device. Maybe someone needs to define a few more simple-security rules for devices= =20 other than CPE gateways? I don't really see an incentive for device engineers to put proper security= =20 into "dumb" devices if there is no spec - they are used to letting=20 the "magic of NAT" take care of this. Konrad --nextPart13807526.O98sudBWg2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkuvhsoACgkQyxXJkXI6YgA3XQCfU2PZ+ZmVjvuzE0FH5h8SyC5G yZIAn3YyZKLuw6V4R7RF4Mp7R2JdS8h+ =i/4E -----END PGP SIGNATURE----- --nextPart13807526.O98sudBWg2-- From owner-v6ops@ops.ietf.org Sun Mar 28 10:08:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6843A67AB for ; Sun, 28 Mar 2010 10:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7ahlBgAyta5 for ; Sun, 28 Mar 2010 10:08:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D743E3A659C for ; Sun, 28 Mar 2010 10:08:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nvvwe-000KhF-3m for v6ops-data0@psg.com; Sun, 28 Mar 2010 17:06:40 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvvwZ-000Kgc-Lz for v6ops@ops.ietf.org; Sun, 28 Mar 2010 17:06:38 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFYpr0urR7Ht/2dsb2JhbACbKHGkS5gdhQEE X-IronPort-AV: E=Sophos;i="4.51,323,1267401600"; d="scan'208";a="106735026" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Mar 2010 17:06:34 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2SH6YV6023771; Sun, 28 Mar 2010 17:06:34 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2SH6XY16445; Sun, 28 Mar 2010 10:06:33 -0700 (PDT) Message-ID: <4BAF8C98.5070407@cisco.com> Date: Sun, 28 Mar 2010 19:06:32 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Konrad Rosenbaum CC: v6ops@ops.ietf.org Subject: Security of devices other than the Gateway (was Re: simple security) References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> In-Reply-To: <201003281841.48962@zaphod.konrad.silmor.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/28/10 6:41 PM, Konrad Rosenbaum wrote: > On Wednesday 24 March 2010, Mohacsi Janos wrote: > >>> Your NAS should run link-local or ULA if you don't want it to reach the >>> outside world. >>> >> How to configure the NAS for such a setup? >> - If I use SLAAC? Do I have to prevent RAs with global prefix to be >> arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I >> get ULA via SLAAC? This requires a pretty complex setup. >> > If I would build the NAS I would let it operate as usual, but add a few > simple packet filter rules to the rudimentary firewall inside the device: > allow absolutely everything out; allow everything in that targets me at > fe80::/10; allow everything in that targets me at fc00::/7 if it comes from > a locally advertise network, do not allow anything else in. I would also > give the user an option to disable the packet dropping code (if I felt too > lazy to implement a proper configuration). I wouldn't expect the router or > any other device to protect or fool my NAS device. > > Maybe someone needs to define a few more simple-security rules for devices > other than CPE gateways? > Not a bad idea at all. Security certainly doesn't start or stop at the gateway. > I don't really see an incentive for device engineers to put proper security > into "dumb" devices if there is no spec - they are used to letting > the "magic of NAT" take care of this. > Agreed. If the applications (or devices built for a specific application) were a bit more aware of the scoping of an IPv6 address, perhaps they could use this for better security, not to mention ease of use. These problems aren't easy, and probably require peeking into APIs and such to be done properly, but perhaps this is where our efforts should be directed. - Mark > > Konrad > From owner-v6ops@ops.ietf.org Sun Mar 28 12:08:51 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B333D3A694E for ; Sun, 28 Mar 2010 12:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.234 X-Spam-Level: *** X-Spam-Status: No, score=3.234 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqr5FazIWrLF for ; Sun, 28 Mar 2010 12:08:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 058953A695C for ; Sun, 28 Mar 2010 12:08:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvxnF-0006Fu-9O for v6ops-data0@psg.com; Sun, 28 Mar 2010 19:05:05 +0000 Received: from [94.243.64.204] (helo=mailfilter.orange.md) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvxnC-0006FE-71 for v6ops@ops.ietf.org; Sun, 28 Mar 2010 19:05:03 +0000 Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 95C41C09D7F; Sun, 28 Mar 2010 22:05:53 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 7D626C09D25; Sun, 28 Mar 2010 22:05:53 +0300 (EEST) Importance: Normal X-Priority: 3 (Normal) Sensitivity: In-Reply-To: <4BAF8C98.5070407@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de>, <4BAF8C98.5070407@cisco.com> Subject: Re: Security of devices other than the Gateway (was Re: simple security) MIME-Version: 1.0 From: Roman.Arcea@orange.md To: Mark Townsley Cc: v6ops@ops.ietf.org Message-ID: Date: Sun, 28 Mar 2010 22:04:59 +0300 X-Mailer: Lotus Domino Web Server Release 8.5.1FP1 January 05, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.1FP1|January 05, 2010) at 03/28/2010 22:04:59, Serialize complete at 03/28/2010 22:04:59, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.1FP1|January 05, 2010) at 03/28/2010 22:04:59, Serialize by Router on postman/OrangeMD(Release 8.5.1FP1|January 05, 2010) at 03/28/2010 22:04:59 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > I don't really see an incentive for device engineers to put proper securi= ty > into "dumb" devices if there is no spec - they are used to letting > the "magic of NAT" take care of this. > >Agreed. If the applications (or devices built for a specific >application) were a bit more aware of the scooping of an IPv6 address, >perhaps they could use this for better security, not to mention ease of >use. As in the simple-security the SOHO users are concerned, could it make sense= to give them the opportunity to define the scope of both the CPE and the e= nd user equipment? In case of NAS, considering that some sort of initial config might be neede= d, a Home Mode vs Internet Mode might make sense. The same thing with the CPE, a dropdown with Home Mode (to connect NAS devi= ces for example), Internet Protected Mode (for those who want simple securi= ty), Internet Unprotected Mode (for no security), under each wire port coul= d make the feature easy to market. It is a little bit more complex with wireless connectivity in the CPE alone= as it would require the user to somehow define the device scope manually, = which is not the way things should work. I could think about using differen= t SSIDs but that does not sound smooth either. Roman From owner-v6ops@ops.ietf.org Sun Mar 28 13:32:03 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFFA3A697B for ; Sun, 28 Mar 2010 13:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.63 X-Spam-Level: ** X-Spam-Status: No, score=2.63 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzvALz8jTmaY for ; Sun, 28 Mar 2010 13:32:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 714683A6774 for ; Sun, 28 Mar 2010 13:32:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nvz5A-000DD7-Df for v6ops-data0@psg.com; Sun, 28 Mar 2010 20:27:40 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nvz57-000DCe-D8 for v6ops@ops.ietf.org; Sun, 28 Mar 2010 20:27:37 +0000 Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nvz4z-0008Kc-1w; Mon, 29 Mar 2010 06:57:29 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 87D954930C; Mon, 29 Mar 2010 06:57:28 +1030 (CST) Date: Mon, 29 Mar 2010 06:57:28 +1030 From: Mark Smith To: Mark Townsley Cc: Konrad Rosenbaum , v6ops@ops.ietf.org Subject: Re: Security of devices other than the Gateway (was Re: simple security) Message-ID: <20100329065728.75f1fdc2@opy.nosense.org> In-Reply-To: <4BAF8C98.5070407@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> <4BAF8C98.5070407@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Sun, 28 Mar 2010 19:06:32 +0200 Mark Townsley wrote: > On 3/28/10 6:41 PM, Konrad Rosenbaum wrote: > > On Wednesday 24 March 2010, Mohacsi Janos wrote: > > > >>> Your NAS should run link-local or ULA if you don't want it to reach the > >>> outside world. > >>> > >> How to configure the NAS for such a setup? > >> - If I use SLAAC? Do I have to prevent RAs with global prefix to be > >> arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I > >> get ULA via SLAAC? This requires a pretty complex setup. > >> > > If I would build the NAS I would let it operate as usual, but add a few > > simple packet filter rules to the rudimentary firewall inside the device: > > allow absolutely everything out; allow everything in that targets me at > > fe80::/10; allow everything in that targets me at fc00::/7 if it comes from > > a locally advertise network, do not allow anything else in. I would also > > give the user an option to disable the packet dropping code (if I felt too > > lazy to implement a proper configuration). I wouldn't expect the router or > > any other device to protect or fool my NAS device. > > > > Maybe someone needs to define a few more simple-security rules for devices > > other than CPE gateways? > > > Not a bad idea at all. Security certainly doesn't start or stop at the > gateway. > > > I don't really see an incentive for device engineers to put proper security > > into "dumb" devices if there is no spec - they are used to letting > > the "magic of NAT" take care of this. > > > Agreed. If the applications (or devices built for a specific > application) were a bit more aware of the scoping of an IPv6 address, > perhaps they could use this for better security, not to mention ease of > use. > As much as I think using ULAs for this is a good simple solution, one model I've thought could be better is the "association" model used by bluetooth or DECT handsets and base stations. If you setup an trusted association between devices, via some sort of enrolment process (e.g. press a button on both devices at once, then acknowledge the relationship), probably with an expiry period (to allow short term trust e.g. temporary access to your printer for a day), the access to devices could then be addressing independent. Following that model, you could access your home NAS, fridge etc. from any location, ULA or global. Regards, Mark. > These problems aren't easy, and probably require peeking into APIs and > such to be done properly, but perhaps this is where our efforts should > be directed. > > - Mark > > > > > Konrad > > > > From owner-v6ops@ops.ietf.org Sun Mar 28 13:45:26 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95ADC3A6990 for ; Sun, 28 Mar 2010 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.87 X-Spam-Level: X-Spam-Status: No, score=-98.87 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0HFYiFQN+Zm for ; Sun, 28 Mar 2010 13:45:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3EE23A684A for ; Sun, 28 Mar 2010 13:45:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvzLD-000EcV-P7 for v6ops-data0@psg.com; Sun, 28 Mar 2010 20:44:15 +0000 Received: from [2001:608:2:2::250] (helo=moebius3.space.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvzLB-000Ec5-GN for v6ops@ops.ietf.org; Sun, 28 Mar 2010 20:44:13 +0000 Received: (qmail 82941 invoked by uid 1007); 28 Mar 2010 22:44:11 +0200 Date: Sun, 28 Mar 2010 22:44:11 +0200 From: Gert Doering To: Mark Smith Cc: Mark Townsley , Konrad Rosenbaum , v6ops@ops.ietf.org Subject: Re: Security of devices other than the Gateway (was Re: simple security) Message-ID: <20100328204411.GC69383@Space.Net> References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> <4BAF8C98.5070407@cisco.com> <20100329065728.75f1fdc2@opy.nosense.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100329065728.75f1fdc2@opy.nosense.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Mar 29, 2010 at 06:57:28AM +1030, Mark Smith wrote: > As much as I think using ULAs for this is a good simple solution, one > model I've thought could be better is the "association" model used by > bluetooth or DECT handsets and base stations. If you setup an > trusted association between devices, via some sort of enrolment > process (e.g. press a button on both devices at once, then acknowledge > the relationship), probably with an expiry period (to allow short > term trust e.g. temporary access to your printer for a day), the access > to devices could then be addressing independent. Following that model, > you could access your home NAS, fridge etc. from any location, ULA or > global. Hear hear. I'm all for that. Time to leave the encrusted IPv4 models behind. (The whole model of "listing specific IP addresses in firewalls to define who is allowed to do what" is something we've learned to accept, because we do not have anything better, but that doesn't make it any more useful. Think "renumbering networks" and "firewall rules in other people's firewall tables"...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From urn-ietf@ietf.org Sun Mar 28 22:35:37 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D0A3A6992 for ; Sun, 28 Mar 2010 22:35:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 28 Mar 2010 22:35:30 -0700 (PDT) Received: from akzonobel.com (unknown [122.3.187.55]) by core3.amsl.com (Postfix) with SMTP id 6BEE43A699A for ; Sun, 28 Mar 2010 22:33:49 -0700 (PDT) From: Approved VIAGRA® Store Subject: Confirmation ref # [474953] To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100329053353.6BEE43A699A@core3.amsl.com> Date: Sun, 28 Mar 2010 22:33:49 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 33457 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 29 00:24:23 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8203A6783 for ; Mon, 29 Mar 2010 00:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.582 X-Spam-Level: X-Spam-Status: No, score=-99.582 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwXayEIdAfcC for ; Mon, 29 Mar 2010 00:24:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 346DB3A67A3 for ; Mon, 29 Mar 2010 00:24:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nw9FO-000Boh-6u for v6ops-data0@psg.com; Mon, 29 Mar 2010 07:18:54 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nw9FL-000BoL-ON for v6ops@ops.ietf.org; Mon, 29 Mar 2010 07:18:51 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 076C486C98; Mon, 29 Mar 2010 09:18:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S761SwuiE4rG; Mon, 29 Mar 2010 09:18:46 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id F229A86C66; Mon, 29 Mar 2010 09:18:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B3DEA86C58; Mon, 29 Mar 2010 09:18:45 +0200 (CEST) Date: Mon, 29 Mar 2010 09:18:45 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Konrad Rosenbaum cc: v6ops@ops.ietf.org Subject: Re: simple security In-Reply-To: <201003281841.48962@zaphod.konrad.silmor.de> Message-ID: References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 28 Mar 2010, Konrad Rosenbaum wrote: > On Wednesday 24 March 2010, Mohacsi Janos wrote: >>> Your NAS should run link-local or ULA if you don't want it to reach the >>> outside world. >> >> How to configure the NAS for such a setup? >> - If I use SLAAC? Do I have to prevent RAs with global prefix to be >> arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I >> get ULA via SLAAC? This requires a pretty complex setup. > > If I would build the NAS I would let it operate as usual, but add a few > simple packet filter rules to the rudimentary firewall inside the device: > allow absolutely everything out; allow everything in that targets me at > fe80::/10; allow everything in that targets me at fc00::/7 if it comes from > a locally advertise network, do not allow anything else in. This does not prevent the NAS and clients to pick up global addresses. The current RFC 3484 does not cope properly with ULA addresses, so therefore there are some risk for no working setup witch such a filtering on NAS: nas-client and nas-server has both ULA and global ipv6 address. If the nas-client want to use global address to reach nas-server, then it will fail. > > I don't really see an incentive for device engineers to put proper security > into "dumb" devices if there is no spec - they are used to letting > the "magic of NAT" take care of this. There is a user expectation: my devices was protrected by IPv4-NAT/CPE , then similar should happen with IPv6.... However I am not favor of firewalls.... Best Regards, Janos Mohacsi From uk@megatron.ietf.org Mon Mar 29 00:45:39 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47E63A68B0 for ; Mon, 29 Mar 2010 00:45:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 29 Mar 2010 00:45:33 -0700 (PDT) Received: from 208-38-117-93.static.izoom.net (208-38-117-93.static.izoom.net [208.38.117.93]) by core3.amsl.com (Postfix) with SMTP id 750E63A6862 for ; Mon, 29 Mar 2010 00:45:31 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 76% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100329074532.750E63A6862@core3.amsl.com> Date: Mon, 29 Mar 2010 00:45:31 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 46237 Inc. All rights reserved.

From v6ops-archive@lists.ietf.org Mon Mar 29 01:56:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960513A68C3 for ; Mon, 29 Mar 2010 01:56:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: USA VIAGRA \256 ID84 ; Mon, 29 Mar 2010 01:56:51 -0700 (PDT) Received: from 126-126-178-94.pool.ukrtel.net (126-126-178-94.pool.ukrtel.net [94.178.126.126]) by core3.amsl.com (Postfix) with SMTP id 253643A67F8 for ; Mon, 29 Mar 2010 01:56:50 -0700 (PDT) Message-Id: <000301cacf1d$bc0bda18$7924a8c0@.pool.ukrtel.net> From: USA VIAGRA ID84 To: Subject: v6ops-archive@lists.ietf.org 56% 0FF on Pfizer. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 29 Mar 2010 01:56:50 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From v6ops-archive@ietf.org Mon Mar 29 01:56:52 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC47A3A67F8 for ; Mon, 29 Mar 2010 01:56:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: USA VIAGRA \256 ID84 ; Mon, 29 Mar 2010 01:56:52 -0700 (PDT) Received: from 126-126-178-94.pool.ukrtel.net (126-126-178-94.pool.ukrtel.net [94.178.126.126]) by core3.amsl.com (Postfix) with SMTP id 2C0F83A686B for ; Mon, 29 Mar 2010 01:56:50 -0700 (PDT) Message-Id: <000301cacf1d$badaad18$bbc7a8c0@.pool.ukrtel.net> From: USA VIAGRA ID84 To: Subject: v6ops-archive@ietf.org 56% 0FF on Pfizer. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 29 Mar 2010 01:56:50 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From v6ops-archive@megatron.ietf.org Mon Mar 29 01:57:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EE73A6912 for ; Mon, 29 Mar 2010 01:57:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: USA VIAGRA \256 ID84 ; Mon, 29 Mar 2010 01:57:14 -0700 (PDT) Received: from 126-126-178-94.pool.ukrtel.net (126-126-178-94.pool.ukrtel.net [94.178.126.126]) by core3.amsl.com (Postfix) with SMTP id 287643A68C3 for ; Mon, 29 Mar 2010 01:57:10 -0700 (PDT) Message-Id: <000301cacf1d$c7046c3c$c498a8c0@.pool.ukrtel.net> From: USA VIAGRA ID84 To: Subject: v6ops-archive@megatron.ietf.org 56% 0FF on Pfizer. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 29 Mar 2010 01:57:10 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From v6ops-archive@megatron.ietf.org Mon Mar 29 06:23:46 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC02A3A6950 for ; Mon, 29 Mar 2010 06:23:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 29 Mar 2010 06:23:39 -0700 (PDT) Received: from advantagecoaching.com (unknown [59.180.160.97]) by core3.amsl.com (Postfix) with SMTP id 0CEDB3A6A5B for ; Mon, 29 Mar 2010 06:22:25 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 77% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100329132227.0CEDB3A6A5B@core3.amsl.com> Date: Mon, 29 Mar 2010 06:22:25 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 84403 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Mon Mar 29 06:52:56 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F0D3A67FB for ; Mon, 29 Mar 2010 06:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=-2.353, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHnc2ztDFLUp for ; Mon, 29 Mar 2010 06:52:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF13F3A6836 for ; Mon, 29 Mar 2010 06:52:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwFJl-0008Rl-CY for v6ops-data0@psg.com; Mon, 29 Mar 2010 13:47:49 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwFJh-0008RN-KB for v6ops@ops.ietf.org; Mon, 29 Mar 2010 13:47:45 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1269870428!14962220!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 19084 invoked from network); 29 Mar 2010 13:47:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Mar 2010 13:47:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2TDkua8018066; Mon, 29 Mar 2010 09:46:56 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2TDkoPv017936; Mon, 29 Mar 2010 09:46:52 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 09:47:03 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 09:47:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACF46.50196DE1" x-cr-puzzleid: {398D7DBD-2373-4614-B0C7-8AA3F4B2B19B} x-cr-hashedpuzzle: D/kF Gm1y HWmS O49I PZ4E SoEL Vcxm atCr eAnh irJx mRht qOUi ubIi wQpT yuLv 7w8N;5;ZgByAGUAZABAAGMAaQBzAGMAbwAuAGMAbwBtADsAbwB0AHIAbwBhAG4AQABlAG0AcABsAG8AeQBlAGUAcwAuAG8AcgBnADsAcwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtADsAdABvAHcAbgBzAGwAZQB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB2ADYAbwBwAHMAQABvAHAAcwAuAGkAZQB0AGYALgBvAHIAZwA=;Sosha1_v1;7;{398D7DBD-2373-4614-B0C7-8AA3F4B2B19B};YgBzADcANgA1ADIAQABhAHQAdAAuAGMAbwBtAA==;Mon, 29 Mar 2010 13:46:50 GMT;UgBFADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AdgA2AG8AcABzAC0AaQBwAHYANgAtAGMAcABlAC0AcgBvAHUAdABlAHIALQAwADQA Content-class: urn:content-classes:message Subject: RE: draft-ietf-v6ops-ipv6-cpe-router-04 Date: Mon, 29 Mar 2010 09:46:50 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-ipv6-cpe-router-04 Thread-Index: AcrN44G0luxvWuq8RimUkfz2EVjwuwABKanQAFbKOPA= References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> From: "STARK, BARBARA H (ATTLABS)" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , "Ole Troan" Cc: "Mark Townsley (townsley)" , "IPv6 v6ops" X-OriginalArrivalTime: 29 Mar 2010 13:47:02.0713 (UTC) FILETIME=[4FCF5A90:01CACF46] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CACF46.50196DE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eee! No! I disagree completely. It is clear to me that there is no consensus within the IETF as to what such a default will be. I don't see this changing. Therefore, there should be no default recommendation in either simple-security or cpe-router. Vendors and service providers are perfectly capable of deciding for themselves what default they want. If the IETF did manage to make a recommendation, I suspect that probably half of the vendors and service providers would choose to ignore that recommendation, no matter which way it went. Default enabled/disabled needs to be completely and totally out of scope for both documents. =20 As for the sentence that Ole recommended adding ("Enabling or disabling this functionality MUST be user configurable."), that is (IMO) completely redundant with text that already exists inside simple-security: REC-41: Gateways MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e. to disable the IPv6 simple security capabilities of the gateway. =20 Therefore, the additional sentence is unnecessary. Support means support. In general, the more words that get added to try to restate the same thing, over and over again, because you're worried people might not interpret the first set of words per your intent, the more likely it is that you will confuse people and cause them to misinterpret your intent. To me, the original text is simple, concise, and says exactly what it needs to say. Barbara Mark also commented on what does one mean by "support" in his email. But now the bullet seems to need more work because soon as one says a feature is configurable, the next question others will ask is, "well, what's the default"? So here is a little more modified text suggestion from me for the relevant bullet. S-1: The IPv6 CE router SHOULD implement [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling the security functionality MUST be user configurable. The default for whether simple security is enabled or disabled is specified in I-D.ietf-v6ops-cpe-simple-security]. Now so we have single source to reference our bullet's properties from; the source being the I-D.ietf-v6ops-cpe-simple-security. Now it's up to v6ops as a WG to nail down which of enabled or disabled is the default in the I-D.ietf-v6ops-cpe-simple-security.document. Hemant ------_=_NextPart_001_01CACF46.50196DE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-v6ops-ipv6-cpe-router-04

Eee! No! I disagree completely. It is clear to me that = there is no consensus within the IETF as to what such a default will be. I = don’t see this changing. Therefore, there should be no default recommendation = in either simple-security or cpe-router. Vendors and service providers are perfectly capable of deciding for themselves what default they want. If = the IETF did manage to make a recommendation, I suspect that probably half = of the vendors and service providers would choose to ignore that = recommendation, no matter which way it went. Default enabled/disabled needs to be = completely and totally out of scope for both documents.

 

As for the sentence that Ole recommended adding = (“Enabling or disabling this functionality MUST be user configurable.”), that is (IMO) completely redundant with text that already exists inside simple-security:

   = REC-41: Gateways MUST provide an easily selected configuration = option

   that = permits a "transparent mode" of operation that forwards = all

   = unsolicited flows regardless of forwarding direction, i.e. to = disable

   the = IPv6 simple security capabilities of the gateway.

 

Therefore, the additional sentence is = unnecessary.

Support means support. In general, the more words that = get added to try to restate the same thing, over and over again, because = you’re worried people might not interpret the first set of words per your = intent, the more likely it is that you will confuse people and cause them to = misinterpret your intent. To me, the original text is simple, concise, and says = exactly what it needs to say.

Barbara

<snip> = Mark also = commented on what does one mean by "support" in his email.  = But now the = bullet seems to need more work because soon as one says a feature is configurable, = the next question others will ask is, "well, what's the = default"?  So here is = a little more modified text suggestion from me for the relevant = bullet.

S-1:  The IPv6 CE router SHOULD implement [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling = the security functionality MUST be user configurable.  The default for whether simple security is enabled = or disabled is specified in I-D.ietf-v6ops-cpe= -simple-security].

Now so = we have single source to reference our bullet's properties from; the source = being the I-D.ietf-v6ops-cpe= -simple-security.  Now it's up to v6ops as a WG to nail down which of enabled or = disabled is the default in = the I-D.ietf-v6ops-cpe= -simple-security.document.

Hemant = </snip>

------_=_NextPart_001_01CACF46.50196DE1-- From owner-v6ops@ops.ietf.org Mon Mar 29 09:26:07 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51183A6A16 for ; Mon, 29 Mar 2010 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.366 X-Spam-Level: X-Spam-Status: No, score=-7.366 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFhen0SmT16b for ; Mon, 29 Mar 2010 09:26:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24BA73A6AFF for ; Mon, 29 Mar 2010 09:24:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwHhf-0004IA-Fs for v6ops-data0@psg.com; Mon, 29 Mar 2010 16:20:39 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwHhc-0004Hn-V1 for v6ops@ops.ietf.org; Mon, 29 Mar 2010 16:20:37 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMNwsEutJV2a/2dsb2JhbACbJXGnSphUhQEEgx4 X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="97065771" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 16:20:35 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o2TGKZCG030583; Mon, 29 Mar 2010 16:20:35 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 11:20:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: simple security Date: Mon, 29 Mar 2010 11:20:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simple security Thread-Index: AcrPEP8zydedIfxZTYiOkx8is2XWWAASl7mw References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> From: "Hemant Singh (shemant)" To: "Mohacsi Janos" , "Konrad Rosenbaum" Cc: X-OriginalArrivalTime: 29 Mar 2010 16:20:34.0701 (UTC) FILETIME=[C2952BD0:01CACF5B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mohacsi Janos Sent: Monday, March 29, 2010 12:19 AM To: Konrad Rosenbaum Cc: v6ops@ops.ietf.org Subject: Re: simple security >The current RFC 3484 does not cope properly with ULA addresses,=20 What do you mean by not cope? ULA and the GUA have global scope and the longest prefix match works fine for packet forwarding if both a ULA and a GUA are configured on a network interface. I don't see any gotcha with RFC 3484 with use of ULA or with use of ULA and a GUA on a network interface. Hemant From owner-v6ops@ops.ietf.org Mon Mar 29 09:38:51 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE50A3A6ACD for ; Mon, 29 Mar 2010 09:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.383 X-Spam-Level: X-Spam-Status: No, score=-100.383 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhp6Ij3DtnWs for ; Mon, 29 Mar 2010 09:38:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44C743A6ACE for ; Mon, 29 Mar 2010 09:38:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwHy8-0006Ip-Lf for v6ops-data0@psg.com; Mon, 29 Mar 2010 16:37:40 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwHy6-0006IF-I5 for v6ops@ops.ietf.org; Mon, 29 Mar 2010 16:37:38 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6DB7E86C69; Mon, 29 Mar 2010 18:37:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SJQ5BjeiENkB; Mon, 29 Mar 2010 18:37:33 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id D8DFD86CA1; Mon, 29 Mar 2010 18:37:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D6E7C86C94; Mon, 29 Mar 2010 18:37:33 +0200 (CEST) Date: Mon, 29 Mar 2010 18:37:33 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Hemant Singh (shemant)" cc: Konrad Rosenbaum , v6ops@ops.ietf.org Subject: RE: simple security In-Reply-To: Message-ID: References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 29 Mar 2010, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Mohacsi Janos > Sent: Monday, March 29, 2010 12:19 AM > To: Konrad Rosenbaum > Cc: v6ops@ops.ietf.org > Subject: Re: simple security > >> The current RFC 3484 does not cope properly with ULA addresses, > > What do you mean by not cope? ULA and the GUA have global scope and the > longest prefix match works fine for packet forwarding if both a ULA and > a GUA are configured on a network interface. I don't see any gotcha > with RFC 3484 with use of ULA or with use of ULA and a GUA on a network > interface. Yes. You are right, but in the context, that I wrote I don't see it is enough. If you have two nodes with both GUA and ULA, but different subnets inside a site: [node1]----------[router]---------[node2] Both GUA and ULA addresses are configured in the DNS... What to configure no node1 and node2 to prefer ULA communication between node1 and node2? And contrary, if I want prefer GUA usage between nodes? Can I do it with the current default RFC 3484? In the default policy table Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 Best Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Mon Mar 29 10:29:05 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC2A3A6AF1 for ; Mon, 29 Mar 2010 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.732 X-Spam-Level: X-Spam-Status: No, score=-107.732 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn0m03yK4Npj for ; Mon, 29 Mar 2010 10:29:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53CB33A6AFD for ; Mon, 29 Mar 2010 10:29:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwIgn-000Dh7-7K for v6ops-data0@psg.com; Mon, 29 Mar 2010 17:23:49 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwIgk-000DgJ-B4 for v6ops@ops.ietf.org; Mon, 29 Mar 2010 17:23:46 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="504826415" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2010 17:23:45 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2THNjhD018418; Mon, 29 Mar 2010 17:23:45 GMT Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Mon, 29 Mar 2010 10:23:45 -0700 Cc: "Hemant Singh (shemant)" , Konrad Rosenbaum , v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> To: Mohacsi Janos X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The default table, as you point out, doesn't specifically reference = FC00::/7; it prefers localhost to any IPv6 address, any IPv6 address to = a 6to4 address, and 6to4 to any IPv4/IPv6 translation mechanism using a = well known prefix. As such, the next rule will apply. The next rule, as = I understand it, will be to order the available addresses by the length = of their matching prefixes from longest to shortest. I would expect, given that scenario, that if we are within the same edge = network (the most common use of ULAs), we will have at least one and = perhaps several prefixes that are longer than /48, and the exact choice = will be specific to the address pair being compared but may choose the = ULA. If we are not in the same network but share PA prefixes from an = ISP, we are likely to use that ISP's prefix. if we do not share prefixes = allocated by an ISP, your guess is as good as mine. I would actually not suggest adding FC00::/7 to the default table; if = some system on the other side of the world is advertising a ULA in DNS = and you have one, you'll try ULA-to-ULA in preference and you won't be = happy with the result. However, you might add your own ULA within your = domain in preference to ::/0. On Mar 29, 2010, at 9:37 AM, Mohacsi Janos wrote: >=20 >=20 >=20 > On Mon, 29 Mar 2010, Hemant Singh (shemant) wrote: >=20 >>=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Mohacsi Janos >> Sent: Monday, March 29, 2010 12:19 AM >> To: Konrad Rosenbaum >> Cc: v6ops@ops.ietf.org >> Subject: Re: simple security >>=20 >>> The current RFC 3484 does not cope properly with ULA addresses, >>=20 >> What do you mean by not cope? ULA and the GUA have global scope and = the >> longest prefix match works fine for packet forwarding if both a ULA = and >> a GUA are configured on a network interface. I don't see any gotcha >> with RFC 3484 with use of ULA or with use of ULA and a GUA on a = network >> interface. >=20 > Yes. You are right, but in the context, that I wrote I don't see it is = enough. If you have two nodes with both GUA and ULA, but different = subnets inside a site: >=20 >=20 > [node1]----------[router]---------[node2] >=20 >=20 > Both GUA and ULA addresses are configured in the DNS... >=20 > What to configure no node1 and node2 to prefer ULA communication = between node1 and node2? >=20 > And contrary, if I want prefer GUA usage between nodes? >=20 > Can I do it with the current default RFC 3484? >=20 > In the default policy table > Prefix Precedence Label > ::1/128 50 0 > ::/0 40 1 > 2002::/16 30 2 > ::/96 20 3 > ::ffff:0:0/96 10 4 >=20 > Best Regards, > Janos Mohacsi >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Mon Mar 29 11:46:21 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C5E3A691C for ; Mon, 29 Mar 2010 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.338 X-Spam-Level: X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt3MAChUpTym for ; Mon, 29 Mar 2010 11:46:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 922AF3A6858 for ; Mon, 29 Mar 2010 11:46:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwJvF-000ONY-Ri for v6ops-data0@psg.com; Mon, 29 Mar 2010 18:42:49 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwJvC-000ONI-L9 for v6ops@ops.ietf.org; Mon, 29 Mar 2010 18:42:46 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="174066663" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2010 18:42:45 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2TIgj2C009880; Mon, 29 Mar 2010 18:42:45 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2TIggY09603; Mon, 29 Mar 2010 11:42:42 -0700 (PDT) Message-ID: <4BB0F49E.1080904@cisco.com> Date: Mon, 29 Mar 2010 20:42:38 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "STARK, BARBARA H (ATTLABS)" CC: "Hemant Singh (shemant)" , "Fred Baker (fred)" , Ole Troan , IPv6 v6ops Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/29/10 3:46 PM, STARK, BARBARA H (ATTLABS) wrote: > Eee! No! I disagree completely. It is clear to me that there is no > consensus within the IETF as to what such a default will be. I don't see > this changing. Therefore, there should be no default recommendation in > either simple-security or cpe-router. Vendors and service providers are > perfectly capable of deciding for themselves what default they want.If > the IETF did manage to make a recommendation, I suspect that probably > half of the vendors and service providers would choose to ignore that > recommendation, no matter which way it went. Default enabled/disabled > needs to be completely and totally out of scope for both documents. Don't forget the case where the CPE doesn't have a service-provider managing the gateway. The operational model (and importance of defaults) is quite different when the primary operator is a consumer vs. an SP. That's why there is all this stress over defaults. If all CPE in the world were owned and operated by SPs with active management planes like TR-69 and the like, a lot more would be "left up to configuration." > > > > As for the sentence that Ole recommended adding ("Enabling or disabling > this functionality MUST be user configurable."), that is (IMO) > completely redundant with text that already exists inside > simple-security: > > REC-41: Gateways MUST provide an easily selected configuration option > > that permits a "transparent mode" of operation that forwards all > > unsolicited flows regardless of forwarding direction, i.e. to disable > > the IPv6 simple security capabilities of the gateway. > > > > Therefore, the additional sentence is unnecessary. > > Support means support. It was confusing to me. In general, the more words that get added to try > to restate the same thing, over and over again, because you're worried > people might not interpret the first set of words per your intent, the > more likely it is that you will confuse people and cause them to > misinterpret your intent. To me, the original text is simple, concise, > and says exactly what it needs to say. My experience is that certain things must be repeated to be heard. For example, even if RFC 4864 plainly states "It does not specify an Internet standard of any kind." people clearly interpret it as such, as has been discussed at length here. - - Mark > > Barbara > > Mark also commented on what does one mean by "support" in his > email. But now the bullet seems to need more work because soon as one > says a feature is configurable, the next question others will ask is, > "well, what's the default"? So here is a little more modified text > suggestion from me for the relevant bullet. > > S-1: The IPv6 CE router SHOULD implement > [I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling the security > functionality MUST be user configurable. The default for whether simple > security is enabled or disabled is specified in > I-D.ietf-v6ops-cpe-simple-security]. > > Now so we have single source to reference our bullet's properties from; > the source being the I-D.ietf-v6ops-cpe-simple-security. Now it's up to > v6ops as a WG to nail down which of enabled or disabled is the default > in the I-D.ietf-v6ops-cpe-simple-security.document. > > Hemant > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLsPSeAAoJEBAcHDFx3DUIbQEH/3hREpnA76JnTffhnZQhnSEH A1o92J9tir4Z94FgMM5FvxMFtv7r2Sa0p9abYze1hW2jvev6uqeWUKkV9kGjNWtL SzmyJtkGv411WY0VLP9se5wDP3AkFjViZTkFnkyfyAsXPVl0NBBp5aZglxN3D3Wq f1ktYeXxB9ntsJucvlMDVEx4aq6vR9UCeAISGCzdYjluHqTNTlvzK3Oy2Vz3mhOr boCwN4bE4h6/XzRQeo3Qp5X/VQVfZ/OY4Cb6Tu/8RyKwfr6jJ0tMn8Zm2tfy8w9K KVMre5z7VEU/kAHoAKqN27ZJ/qOzf7b3MycYyc8OPMCY0oRpdJvv6xyLzo5mpxY= =CVb/ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Mar 29 12:51:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3AE3A690D for ; Mon, 29 Mar 2010 12:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.011 X-Spam-Level: X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEygvFmuiyZu for ; Mon, 29 Mar 2010 12:51:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 085C23A6889 for ; Mon, 29 Mar 2010 12:51:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwKwI-0006SE-TG for v6ops-data0@psg.com; Mon, 29 Mar 2010 19:47:58 +0000 Received: from [216.82.253.115] (helo=mail161.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwKwF-0006R5-Kr for v6ops@ops.ietf.org; Mon, 29 Mar 2010 19:47:55 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-161.messagelabs.com!1269892073!42306374!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26476 invoked from network); 29 Mar 2010 19:47:53 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Mar 2010 19:47:53 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2TJlegs031469; Mon, 29 Mar 2010 15:47:41 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id o2TJlX9w031333; Mon, 29 Mar 2010 15:47:35 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 15:47:46 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 15:47:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-ipv6-cpe-router-04 Date: Mon, 29 Mar 2010 15:47:44 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F12652600@crexc50p> In-Reply-To: <4BB0F49E.1080904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-ipv6-cpe-router-04 Thread-Index: AcrPb6f8miBttNGyRdSovE3G5Hg5qAAAQZmQ References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> <4BB0F49E.1080904@cisco.com> From: "STARK, BARBARA H (ATTLABS)" To: "Mark Townsley" Cc: "Hemant Singh (shemant)" , "Fred Baker (fred)" , "Ole Troan" , "IPv6 v6ops" X-OriginalArrivalTime: 29 Mar 2010 19:47:46.0540 (UTC) FILETIME=[B48942C0:01CACF78] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > Vendors and service providers are > > perfectly capable of deciding for themselves what default they want.If > > the IETF did manage to make a recommendation, I suspect that probably > > half of the vendors and service providers would choose to ignore that > > recommendation, no matter which way it went. Default enabled/disabled > > needs to be completely and totally out of scope for both documents. >=20 > Don't forget the case where the CPE doesn't have a service-provider > managing the gateway. The operational model (and importance of > defaults) > is quite different when the primary operator is a consumer vs. an SP. >=20 > That's why there is all this stress over defaults. If all CPE in the > world were owned and operated by SPs with active management planes like > TR-69 and the like, a lot more would be "left up to configuration." Which is exactly why I used the phrase "vendors and service providers". Vendors determine/set the defaults of all CPE that they sell directly to consumers. I expect such vendors to decide for themselves how to set the defaults on any such CPE. CPE vendors act a lot like service providers in this regard. The most successful ones include functions and set defaults according to what generates the greatest sales and causes the fewest returns (devices returned for refunds). They figure out what it is that consumers really want and are willing to pay for. In my experience, vendors, as a community, tend to be good at providing different products geared towards different segments of the market, with different functions and defaults. No matter whether the IETF recommends default on or off, there will be vendors who ignore that recommendation. Clearly the community is split over what the right recommendation is -- so I think we should just let the market decide, and stop arguing. The market will decide, anyway. > My experience is that certain things must be repeated to be heard. For > example, even if RFC 4864 plainly states "It does not specify an > Internet standard of any kind." people clearly interpret it as such, as > has been discussed at length here. I haven't heard of anyone who interprets RFC 4864 as being "an Internet standard". I know many who have read it, decided they agree with what's said in that one section (4.2), and reference it as describing a function they want. PPPoE isn't a standard, either. That never kept vendors or service providers from implementing it or referencing RFC 2516. If an RFC is perceived as being useful and sensible, it will be widely implemented/referenced. If not, it won't. This is true of RFCs as a whole, and of individual statements within an RFC. And the IETF Category is irrelevant in this regard. But if you want redundancy here, I won't fight it. While I think it's unnecessary, I don't see that it hurts anything in this particular instance. From owner-v6ops@ops.ietf.org Mon Mar 29 13:40:50 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B153A680F for ; Mon, 29 Mar 2010 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.806 X-Spam-Level: X-Spam-Status: No, score=-6.806 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47FFbr5Bi13C for ; Mon, 29 Mar 2010 13:40:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C16B3A6800 for ; Mon, 29 Mar 2010 13:40:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwLiu-000Cn5-2w for v6ops-data0@psg.com; Mon, 29 Mar 2010 20:38:12 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwLir-000Cmq-CW for v6ops@ops.ietf.org; Mon, 29 Mar 2010 20:38:09 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208";a="312615508" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2010 20:38:08 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TKc8em006097; Mon, 29 Mar 2010 20:38:08 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2TKc6Y20822; Mon, 29 Mar 2010 13:38:06 -0700 (PDT) Message-ID: <4BB10FAA.5070407@cisco.com> Date: Mon, 29 Mar 2010 22:38:02 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "STARK, BARBARA H (ATTLABS)" CC: "Hemant Singh (shemant)" , "Fred Baker (fred)" , Ole Troan , IPv6 v6ops Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> <4BB0F49E.1080904@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F12652600@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F12652600@crexc50p> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/29/10 9:47 PM, STARK, BARBARA H (ATTLABS) wrote: > << snip >> > Which is exactly why I used the phrase "vendors and service > providers". Vendors determine/set the defaults of all CPE that they sell > directly to consumers. I expect such vendors to decide for themselves > how to set the defaults on any such CPE. CPE vendors act a lot like > service providers in this regard. The most successful ones include > functions and set defaults according to what generates the greatest > sales and causes the fewest returns (devices returned for refunds). They > figure out what it is that consumers really want and are willing to pay > for. In my experience, vendors, as a community, tend to be good at > providing different products geared towards different segments of the > market, with different functions and defaults. No matter whether the > IETF recommends default on or off, there will be vendors who ignore that > recommendation. Clearly the community is split over what the right > recommendation is -- so I think we should just let the market decide, > and stop arguing. The market will decide, anyway. Vendors don't actively manage the CPE being described here though, and we are talking about configuration parameters in an operations and management working group document. I think we're down in a rathole on the relevance of SDOs and the Market as the final judge. My only point is that there is a real difference between SP-managed, and Consumer-managed CPE. Disagreements in terms of base requirements, configuration items and defaults, etc. often reside in these two very different operational points of view (at least that is my observation in a number of cases). > >> My experience is that certain things must be repeated to be heard. For >> example, even if RFC 4864 plainly states "It does not specify an >> Internet standard of any kind." people clearly interpret it as such, > as >> has been discussed at length here. > > I haven't heard of anyone who interprets RFC 4864 as being "an > Internet standard". I know many who have read it, decided they agree > with what's said in that one section (4.2), and reference it as > describing a function they want. PPPoE isn't a standard, either. That > never kept vendors or service providers from implementing it or > referencing RFC 2516. If an RFC is perceived as being useful and > sensible, it will be widely implemented/referenced. If not, it won't. > This is true of RFCs as a whole, and of individual statements within an > RFC. And the IETF Category is irrelevant in this regard. Comments from James have me thinking that this is one of the shining cases of misunderstanding of the difference between "RFC" and "IETF" - but I do agree that this is a very general feature or bug of the RFC series and IETF, depending on your point of view. We won't solve that one way or another here, I'm just trying to live within the realities of it here and now. > But if you want > redundancy here, I won't fight it. While I think it's unnecessary, I > don't see that it hurts anything in this particular instance. > OK. I do think that being very clear about what the document is and is not recommending when it says "support" is a good idea, outweighing the danger of being redundant across two documents in this particular case. Thanks, - - Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLsQ+qAAoJEBAcHDFx3DUI2UwIAIYS1SHePJOi9jFfhng8a+T6 iRovWGC21yGCdKNyhw2jnTOrlUSTezNCOOwTeagNHUD2hAUeMPaC2uGr3XL3jKgX jKLHNkmJyjH4N/ZnTQMRbWWQykxHt4IdxuMr2cwephKXyZjCiTDSlzqY96iZdcLP +/RkYHpDJaGo1/SwtHggzZFlk8Sk4oMvZ9+WP/dfv8IrIlKsYe2LoQxHW8v6R7W1 vrd3kZIVyDkABUnErwz20SLjU6mRdbRaQGRrUXaZS9bVWi7+XfIU94vX3oBtW/Qo lgbOCSw1giB0amMl689C6MzMSx2R4M3LAaR/gKqKMVZgIxCFuFuy0J/6aAxXi64= =Ycgt -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Mar 29 14:47:24 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5803A698E for ; Mon, 29 Mar 2010 14:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k89G+ZegRAsb for ; Mon, 29 Mar 2010 14:47:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A3103A69B5 for ; Mon, 29 Mar 2010 14:47:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwMke-000J1j-Em for v6ops-data0@psg.com; Mon, 29 Mar 2010 21:44:04 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwMkY-000J1O-RM for v6ops@ops.ietf.org; Mon, 29 Mar 2010 21:43:58 +0000 Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 5442792B5A07; Mon, 29 Mar 2010 14:43:58 -0700 (PDT) X-AuditID: 11807136-b7c8dae000004b66-31-4bb11f1e7a1b Received: from il0602b-dhcp250.apple.com (il0602b-dhcp250.apple.com [17.206.24.250]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id C4.65.19302.E1F11BB4; Mon, 29 Mar 2010 14:43:58 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I-D.ietf-v6ops-cpe-simple-security-10 Date: Mon, 29 Mar 2010 14:43:57 -0700 Message-Id: <955E4D2B-1212-4CFE-B06B-9B91B66EB7E0@apple.com> Cc: IPv6 v6ops To: draft-ietf-v6ops-cpe-simple-security.chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: concerned-- This is to inform the chairs of the V6OPS working group that it is the = sense of the editor of draft-ietf-v6ops-cpe-simple-security and the = design team that worked most closely on it during its development, that = the latest posted revision, i.e. -10, is ready for Working Group Last = Call. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Mon Mar 29 15:01:12 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DCEC3A6901 for ; Mon, 29 Mar 2010 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.765 X-Spam-Level: X-Spam-Status: No, score=-106.765 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3EpYYIe+sEj for ; Mon, 29 Mar 2010 15:01:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9C763A6B99 for ; Mon, 29 Mar 2010 15:01:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwN0D-000KmV-Rk for v6ops-data0@psg.com; Mon, 29 Mar 2010 22:00:09 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwN0B-000Km6-0D for v6ops@ops.ietf.org; Mon, 29 Mar 2010 22:00:07 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEe/sEtAZnwN/2dsb2JhbACbJ3GnBph7hQEEgx4 X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208";a="97157537" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 22:00:04 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TM04Dl002686; Mon, 29 Mar 2010 22:00:04 GMT Subject: Re: I-D.ietf-v6ops-cpe-simple-security-10 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <955E4D2B-1212-4CFE-B06B-9B91B66EB7E0@apple.com> Date: Mon, 29 Mar 2010 15:00:03 -0700 Cc: draft-ietf-v6ops-cpe-simple-security.chairs@tools.ietf.org, IPv6 v6ops Content-Transfer-Encoding: quoted-printable Message-Id: <8AE8C716-EBDC-44F8-9EEA-7FF6A34F5AEF@cisco.com> References: <955E4D2B-1212-4CFE-B06B-9B91B66EB7E0@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1077) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks. On Mar 29, 2010, at 2:43 PM, james woodyatt wrote: > concerned-- >=20 > This is to inform the chairs of the V6OPS working group that it is the = sense of the editor of draft-ietf-v6ops-cpe-simple-security and the = design team that worked most closely on it during its development, that = the latest posted revision, i.e. -10, is ready for Working Group Last = Call. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Mon Mar 29 15:27:17 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CA53A6984 for ; Mon, 29 Mar 2010 15:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.159 X-Spam-Level: * X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btpw5bTWFECd for ; Mon, 29 Mar 2010 15:27:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A27213A6937 for ; Mon, 29 Mar 2010 15:27:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwNP4-000N5c-OZ for v6ops-data0@psg.com; Mon, 29 Mar 2010 22:25:50 +0000 Received: from [128.18.30.17] (helo=mail1.sri.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwNP2-000N5J-2J for v6ops@ops.ietf.org; Mon, 29 Mar 2010 22:25:48 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.3] ([unknown] [71.0.229.73]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L0200N1ME31W6M0@mail.sri.com> for v6ops@ops.ietf.org; Mon, 29 Mar 2010 15:21:03 -0700 (PDT) Message-id: <4BB127CE.7020703@sri.com> Date: Mon, 29 Mar 2010 18:21:02 -0400 From: Ed Jankiewicz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: IPv6 Operations , 6man Subject: FYI: DNSOPS presentation Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Probably no one on either of the IPv6 lists attended the DNSOPS WG meeting in Anaheim, since it was at the same time as 6man. Presentation by Yahoo! of a proposal to "do an ugly hack on DNS" to work around an issue with "broken OSes" that send out AAAA requests when they have no intention/ability to actually use an IPv6 address. Google experience is that a small percentage of their users would lose connectivity because of this, if google.com serves both IPv6 and IPv4 addresses. I can't recall if this particular issue has been discussed here, but either way anyone with an interest should probably pop comments over to the DSNOPS WG list. http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf Also FYI - this has gotten press coverage, not necessarily accurately characterizing the problem or proposed solution http://www.networkworld.com/podcasts/360/2010/032910-nw360-daily.html http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From v6ops-archive@megatron.ietf.org Mon Mar 29 17:32:22 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE183A6B11 for ; Mon, 29 Mar 2010 17:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.6 X-Spam-Level: X-Spam-Status: No, score=-67.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, SARE_FROM_DRUGS=1.666, SARE_RECV_VIRTUACOMBR=1.193, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtZKypz+lmzo for ; Mon, 29 Mar 2010 17:32:21 -0700 (PDT) Received: from c951aa23.virtua.com.br (c951aa23.virtua.com.br [201.81.170.35]) by core3.amsl.com (Postfix) with ESMTP id 4F2373A6B53 for ; Mon, 29 Mar 2010 17:32:18 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@megatron.ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330003218.4F2373A6B53@core3.amsl.com> Date: Mon, 29 Mar 2010 17:32:18 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Jgociq. All rights reserved.
From v6ops-archive@ietf.org Mon Mar 29 17:34:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AE03A6774 for ; Mon, 29 Mar 2010 17:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.6 X-Spam-Level: X-Spam-Status: No, score=-67.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, SARE_FROM_DRUGS=1.666, SARE_RECV_VIRTUACOMBR=1.193, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2219SmNK2jIP for ; Mon, 29 Mar 2010 17:34:19 -0700 (PDT) Received: from c951aa23.virtua.com.br (c951aa23.virtua.com.br [201.81.170.35]) by core3.amsl.com (Postfix) with ESMTP id 882953A63EC for ; Mon, 29 Mar 2010 17:34:18 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330003418.882953A63EC@core3.amsl.com> Date: Mon, 29 Mar 2010 17:34:18 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Funawubj. All rights reserved.
From v6ops-archive@lists.ietf.org Mon Mar 29 17:34:40 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FA13A682F for ; Mon, 29 Mar 2010 17:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.6 X-Spam-Level: X-Spam-Status: No, score=-67.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, SARE_FROM_DRUGS=1.666, SARE_RECV_VIRTUACOMBR=1.193, URIBL_BLACK=20, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ixHvtVQbzjR for ; Mon, 29 Mar 2010 17:34:39 -0700 (PDT) Received: from c951aa23.virtua.com.br (c951aa23.virtua.com.br [201.81.170.35]) by core3.amsl.com (Postfix) with ESMTP id A6FDF3A63EC for ; Mon, 29 Mar 2010 17:34:38 -0700 (PDT) From: "#1 VIAGRA Shop" To: v6ops-archive@lists.ietf.org Subject: Yo, v6ops-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330003438.A6FDF3A63EC@core3.amsl.com> Date: Mon, 29 Mar 2010 17:34:38 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey v6ops-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Iibqzqv. All rights reserved.
From sigtran-archive@lists.ietf.org Mon Mar 29 23:57:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68C83A6A50 for ; Mon, 29 Mar 2010 23:57:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 29 Mar 2010 23:57:27 -0700 (PDT) Received: from alphasite.com (unknown [61.16.235.163]) by core3.amsl.com (Postfix) with SMTP id D48A13A6A0F for ; Mon, 29 Mar 2010 23:57:24 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100330065725.D48A13A6A0F@core3.amsl.com> Date: Mon, 29 Mar 2010 23:57:24 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 60114 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Tue Mar 30 01:45:02 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6583A6878 for ; Tue, 30 Mar 2010 01:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.519 X-Spam-Level: X-Spam-Status: No, score=-100.519 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TapLi7ctsqe for ; Tue, 30 Mar 2010 01:45:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03EAA3A6984 for ; Tue, 30 Mar 2010 01:45:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwWyW-0000CX-Rw for v6ops-data0@psg.com; Tue, 30 Mar 2010 08:39:04 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwWyU-0000CA-0n for v6ops@ops.ietf.org; Tue, 30 Mar 2010 08:39:02 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 12E1386CB9; Tue, 30 Mar 2010 10:38:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id adU8UQ474dYv; Tue, 30 Mar 2010 10:38:55 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id E171C86C59; Tue, 30 Mar 2010 10:38:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D7F8E86C58; Tue, 30 Mar 2010 10:38:55 +0200 (CEST) Date: Tue, 30 Mar 2010 10:38:55 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Fred Baker cc: "Hemant Singh (shemant)" , Konrad Rosenbaum , v6ops@ops.ietf.org Subject: Re: simple security In-Reply-To: Message-ID: References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 29 Mar 2010, Fred Baker wrote: > The default table, as you point out, doesn't specifically reference > FC00::/7; it prefers localhost to any IPv6 address, any IPv6 address to > a 6to4 address, and 6to4 to any IPv4/IPv6 translation mechanism using a > well known prefix. As such, the next rule will apply. The next rule, as > I understand it, will be to order the available addresses by the length > of their matching prefixes from longest to shortest. > > I would expect, given that scenario, that if we are within the same edge > network (the most common use of ULAs), we will have at least one and > perhaps several prefixes that are longer than /48, and the exact choice > will be specific to the address pair being compared but may choose the > ULA. If we are not in the same network but share PA prefixes from an > ISP, we are likely to use that ISP's prefix. if we do not share prefixes > allocated by an ISP, your guess is as good as mine. > > I would actually not suggest adding FC00::/7 to the default table; if > some system on the other side of the world is advertising a ULA in DNS > and you have one, you'll try ULA-to-ULA in preference and you won't be > happy with the result. However, you might add your own ULA within your > domain in preference to ::/0. Agreed. I just wanted to mention in one of my previous e-mail regarding CPE simple security - CPE without firewall: Usage of ULA behind the CPE instead GUA not very trivial. Needs some tweaking to prefer own ULA or RFC3484 policy distribution. Best Regards, Janos Mohacsi > > On Mar 29, 2010, at 9:37 AM, Mohacsi Janos wrote: > >> >> >> >> On Mon, 29 Mar 2010, Hemant Singh (shemant) wrote: >> >>> >>> -----Original Message----- >>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >>> Behalf Of Mohacsi Janos >>> Sent: Monday, March 29, 2010 12:19 AM >>> To: Konrad Rosenbaum >>> Cc: v6ops@ops.ietf.org >>> Subject: Re: simple security >>> >>>> The current RFC 3484 does not cope properly with ULA addresses, >>> >>> What do you mean by not cope? ULA and the GUA have global scope and the >>> longest prefix match works fine for packet forwarding if both a ULA and >>> a GUA are configured on a network interface. I don't see any gotcha >>> with RFC 3484 with use of ULA or with use of ULA and a GUA on a network >>> interface. >> >> Yes. You are right, but in the context, that I wrote I don't see it is enough. If you have two nodes with both GUA and ULA, but different subnets inside a site: >> >> >> [node1]----------[router]---------[node2] >> >> >> Both GUA and ULA addresses are configured in the DNS... >> >> What to configure no node1 and node2 to prefer ULA communication between node1 and node2? >> >> And contrary, if I want prefer GUA usage between nodes? >> >> Can I do it with the current default RFC 3484? >> >> In the default policy table >> Prefix Precedence Label >> ::1/128 50 0 >> ::/0 40 1 >> 2002::/16 30 2 >> ::/96 20 3 >> ::ffff:0:0/96 10 4 >> >> Best Regards, >> Janos Mohacsi >> > > http://www.ipinc.net/IPv4.GIF > > From owner-v6ops@ops.ietf.org Tue Mar 30 08:06:14 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDB53A67B0 for ; Tue, 30 Mar 2010 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9EnPql0O58r for ; Tue, 30 Mar 2010 08:06:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A65A3A6BAD for ; Tue, 30 Mar 2010 08:06:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwcvJ-000Ixd-4m for v6ops-data0@psg.com; Tue, 30 Mar 2010 15:00:09 +0000 Received: from web111401.mail.gq1.yahoo.com ([67.195.15.132]) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwcvC-000IwP-EL for v6ops@ops.ietf.org; Tue, 30 Mar 2010 15:00:03 +0000 Received: (qmail 38668 invoked by uid 60001); 30 Mar 2010 15:00:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269961200; bh=CXU/uK8K73b1QJ6aZpcxwJ+1vzDXpIE0XEsViWxxisA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q53NbNj1NoPDCcmWHg8wYd2ftkMc0oGEwFDY5D5xiunE2PAp+OyM4ZVeHYm8l3bdEEYJ9AusqxbaxZfnytcQvbBXu9olXWenczKlma4FGUpy4EIaiyzvsxYUBLvDm+3W6FWk2fQEk0A2lsU/RX0g7rVAb1GJkLqFDgCcNfubR7o= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LadkuJn/EdLW66Ryzj+qTj9rDd56iUShSQcUz0HhPmZY5atgPFCsZ4dBvrrjvlJFrdy60BSkeWYQ/CcNiAnEn9O35dHEGdwpYi40WKNfGB6RWWLdeZJHC2OJgwsrvzBkw3n1QQoTuBrclHbv8t+1CFmUjAPmbScu5aQ7kNHVOEs=; Message-ID: <450321.38372.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: gnWlRpIVM1mYveYJPPGqIBlvV2s4NYL0p5Uh.O4uNP.WAJN Qpar77dFGM8llrnzjpns4ngyQguzaHGJiWsgxvPmSqWxB1adLB4dHmAHIj94 a9uS9iY_Z_zDUfbGHoIeGH8g6wTFqbgXxpkAOneDUHxLmS_V9MxDsl7w66I7 AScAKDxbSPK7eASNksQSGOhYkRfFmpvJAozACFnQvOwFX8IZgQvuCgkF0aae w9nrNii3pW6rnM4MOuhXm7M7VlHL5Ggo.jv0iTskMzRvu8ToKumRwPgnWR.k tNOPrnd0DstE6ord0YxwV74Tc7UkBwOLsm1UWSXLYK_7JFRtUaBzfcdkxUZ3 gdwbvO1T_kBETicT2XQGP8KEbxLA4gMIwNHA- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Tue, 30 Mar 2010 08:00:00 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: Date: Tue, 30 Mar 2010 08:00:00 -0700 (PDT) From: Behcet Sarikaya Reply-To: Behcet Sarikaya Subject: Re: [3gv6] about Prefix delegation in 3GPP EPC networks To: lizhenqiang@chinamobile.com Cc: 3gv6@ietf.org, IPv6 Operations In-Reply-To: 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 List-ID: Hi Zhengqiang,=0A=A0 By the way as Frank mentioned, we had some good discus= sion on this issue last week on Friday in v6ops, so I am copying this mail = to v6ops.=0A=A0 In Sec. 2 of your contribution, you talk about UE carrying = prefix length to the CN. I don't understand why this is needed as there are= much simpler solutions.=0A=A0 One such simple solution is described in our= draft which was presented in v6ops http://tools.ietf.org/id/draft-sarikaya= -v6ops-prefix-delegation-00.txt=0A=0APlease refer to this draft in your con= tribution.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0A= > From: "lizhenqiang@chinamobile.com" =0A> To:= suresh.krishnan@ericsson.com=0A> Cc: jouni.korhonen@nsn.com; 3gv6@ietf.org= ; dhcwg@ietf.org=0A> Sent: Tue, March 30, 2010 3:13:37 AM=0A> Subject: Re: = [3gv6] about Prefix delegation in 3GPP EPC networks=0A> =0A> =0AThe documen= t I submitted to 3GPP is in the attachment. Please check it. =0A> Thanks.= =0A=0AZhenqiang Li=0A=0A=0A> -----Original Message-----=0A> =0A> From: ext = > href=3D"mailto:lizhenqiang@chinamobile.com">lizhenqiang@chinamobile.com= =0A> =0A> [mailto:> href=3D"mailto:lizhenqiang@chinamobile.com">lizhenqiang= @chinamobile.com]=0A> =0A> Sent: 30. maaliskuuta 2010 10:15=0A> To: > ymail= to=3D"mailto:suresh.krishnan@ericsson.com" =0A> href=3D"mailto:suresh.krish= nan@ericsson.com">suresh.krishnan@ericsson.com=0A> =0A> Cc: > href=3D"mailt= o:youni.korhonen@nsn.com">youni.korhonen@nsn.com; Savolainen =0A> Teemu (No= kia-D/Tampere);=0A> > href=3D"mailto:dhcwg@ietf.org">dhcwg@ietf.org; > ymai= lto=3D"mailto:3gv6@ietf.org" =0A> href=3D"mailto:3gv6@ietf.org">3gv6@ietf.o= rg=0A> Subject: about Prefix =0A> delegation in 3GPP EPC networks=0A> =0A> = Dear Suresh,=0A> =0A> =0A> Nice meeting you at IETF 77.=0A> =0A> First of a= ll, I agree with you =0A> that it is good for a UE to use a=0A> shorter pre= fix to meet the situation, =0A> rather than using multiple /64=0A> prefixes= .=0A> =0A> Some =0A> additional comments about your draft:=0A> 1. Where to = store the prefix =0A> length that you reserved for each UE?=0A> 2. How to v= alidate the request =0A> from UE to avoid address abusing?=0A> 3. The propo= sed method in your draft =0A> seems address wasting, because you=0A> reserv= e /x (x < 64) prefix for =0A> each UE. It is better to store the=0A> minimu= m length that a UE can apply, =0A> and assign the proper lengh to UE=0A> ba= sed on the available adrress pool, =0A> the minimum length the UE can=0A> a= pply, and the length the UE actually =0A> requests.=0A> 4. Are there any ot= her alternatives besides DHCPv6-PD? I =0A> listed some=0A> potential soluti= ons in a 3GPP document. What is your opinion =0A> to them?=0A> =0A> Best Re= gards,=0A> Zhenqiang Li=0A> =0A> 13911635816=0A> Department of Network Tech= nology=0A> China Mobile =0A> Research Institute=0A> 2010-03-26=0A=0A=0A=0A = From owner-v6ops@ops.ietf.org Tue Mar 30 08:58:29 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA67B3A6C72 for ; Tue, 30 Mar 2010 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.579 X-Spam-Level: X-Spam-Status: No, score=-100.579 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNpIFSmXkvk8 for ; Tue, 30 Mar 2010 08:58:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B121D3A6A73 for ; Tue, 30 Mar 2010 08:58:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nwdnq-000PhF-4K for v6ops-data0@psg.com; Tue, 30 Mar 2010 15:56:30 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nwdnk-000PfZ-Vl for v6ops@ops.ietf.org; Tue, 30 Mar 2010 15:56:26 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 96F1B86C24; Tue, 30 Mar 2010 17:56:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PV07PuoysNzK; Tue, 30 Mar 2010 17:56:17 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 5E51086CAD; Tue, 30 Mar 2010 17:56:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5A6ED86C9B; Tue, 30 Mar 2010 17:56:17 +0200 (CEST) Date: Tue, 30 Mar 2010 17:56:17 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Ed Jankiewicz cc: IPv6 Operations , dnsop@ietf.org Subject: Re: FYI: DNSOPS presentation In-Reply-To: <4BB127CE.7020703@sri.com> Message-ID: References: <4BB127CE.7020703@sri.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dear All, Sorry for crossposting. This proposal is the opposite with the principle how the DNS is developed a while ago. The DNS is a highly distributed, hierarchical, autonomous, reliable database with very useful extensions. This modification is proposing lying about the existence of the record The modification is proposed to hide the database record that is used for communication. I am not favor such a modification since: 1. I think we need evidence, that majority of the AAAA queries are going via IPv6 (if the client has working IPv6 and the DNS zones has the necessary AAAA for the zones). 2. Plenty of users still use WinXP, where DNS query via IPv6 is not possible. Probably other systems with similar limitations also exists. This can very negatively impacting the IPv6 usage. 3. There is only few broadband CPE devices deployed at homes are capable of providing DNS information via DHCPv6. Only very recently they started to appear. Thus the addresses of the DNS servers are propagated via DHCP. Therefore these broadband users, however they are IPv6 enabled, will essentially use IPv4 address to reach DNS servers. Will you enable returning AAAA records to these caching servers? If yes. Will you get any information about the broadband ipv6 connectivity? If no. You are excluding caching server users from ipv6? 4. How your scheme will work the caching DNS server - commonly deployed by ISPs to serve their constituency. 5. What about the caching in the DNS server? Will they be flushed when IPv6 or IPv4 connectivity changed? IPv6 connectivity changes of who? 6. Your modification is treating some portion of the users as a second class netizen. They cannot really query AAAA records.... IPv6 is so secret, that we have to hide from them? Sorry for being sometimes sarcastics Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 29 Mar 2010, Ed Jankiewicz wrote: > Probably no one on either of the IPv6 lists attended the DNSOPS WG meeting in > Anaheim, since it was at the same time as 6man. > > Presentation by Yahoo! of a proposal to "do an ugly hack on DNS" to work > around an issue with "broken OSes" that send out AAAA requests when they have > no intention/ability to actually use an IPv6 address. Google experience is > that a small percentage of their users would lose connectivity because of > this, if google.com serves both IPv6 and IPv4 addresses. I can't recall if > this particular issue has been discussed here, but either way anyone with an > interest should probably pop comments over to the DSNOPS WG list. > > http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf > > Also FYI - this has gotten press coverage, not necessarily accurately > characterizing the problem or proposed solution > > http://www.networkworld.com/podcasts/360/2010/032910-nw360-daily.html > http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards > Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From uri-review-request@megatron.ietf.org Tue Mar 30 09:50:55 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CC73A693B for ; Tue, 30 Mar 2010 09:50:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 30 Mar 2010 09:50:48 -0700 (PDT) Received: from accentdisplay.com (unknown [201.230.155.200]) by core3.amsl.com (Postfix) with SMTP id B83BE3A67F3 for ; Tue, 30 Mar 2010 09:50:40 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 70% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100330165041.B83BE3A67F3@core3.amsl.com> Date: Tue, 30 Mar 2010 09:50:40 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 70997 Inc. All rights reserved.

From v6ops-archive@ietf.org Tue Mar 30 12:44:11 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51FF3A6978 for ; Tue, 30 Mar 2010 12:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.273 X-Spam-Level: ** X-Spam-Status: No, score=2.273 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPszJ3uQTzp3 for ; Tue, 30 Mar 2010 12:44:10 -0700 (PDT) Received: from pool-173-78-124-49.tampfl.fios.verizon.net (pool-173-78-124-49.tampfl.fios.verizon.net [173.78.124.49]) by core3.amsl.com (Postfix) with ESMTP id 88E263A6826 for ; Tue, 30 Mar 2010 12:44:10 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is 8AB43C4B MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330194410.88E263A6826@core3.amsl.com> Date: Tue, 30 Mar 2010 12:44:10 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 GOUNEF, Inc.
This e-mail was sent to v6ops-archive@ietf.org.

Click here to unsubscribe
From v6ops-archive@lists.ietf.org Tue Mar 30 12:44:17 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D493A6826 for ; Tue, 30 Mar 2010 12:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.727 X-Spam-Level: X-Spam-Status: No, score=-7.727 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na9K9AaoTlFG for ; Tue, 30 Mar 2010 12:44:16 -0700 (PDT) Received: from pool-173-78-124-49.tampfl.fios.verizon.net (pool-173-78-124-49.tampfl.fios.verizon.net [173.78.124.49]) by core3.amsl.com (Postfix) with ESMTP id 06DC23A681C for ; Tue, 30 Mar 2010 12:44:15 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@lists.ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is CD71657 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330194416.06DC23A681C@core3.amsl.com> Date: Tue, 30 Mar 2010 12:44:15 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 AFAA, Inc.
This e-mail was sent to v6ops-archive@lists.ietf.org.

Click here to unsubscribe
From v6ops-archive@megatron.ietf.org Tue Mar 30 12:44:20 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD6E3A68C8 for ; Tue, 30 Mar 2010 12:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.727 X-Spam-Level: X-Spam-Status: No, score=-17.727 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWqzUeeT6DRf for ; Tue, 30 Mar 2010 12:44:19 -0700 (PDT) Received: from pool-173-78-124-49.tampfl.fios.verizon.net (pool-173-78-124-49.tampfl.fios.verizon.net [173.78.124.49]) by core3.amsl.com (Postfix) with ESMTP id 7DBF43A681C for ; Tue, 30 Mar 2010 12:44:19 -0700 (PDT) From: "Approved VIAGRA e-store" To: v6ops-archive@megatron.ietf.org Subject: Wassup v6ops-archive, your personal 80% discount code is 826423A MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100330194419.7DBF43A681C@core3.amsl.com> Date: Tue, 30 Mar 2010 12:44:19 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 YVYM, Inc.
This e-mail was sent to v6ops-archive@megatron.ietf.org.

Click here to unsubscribe
From owner-v6ops@ops.ietf.org Tue Mar 30 13:45:47 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66AB53A691C for ; Tue, 30 Mar 2010 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.11 X-Spam-Level: X-Spam-Status: No, score=-107.11 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmlgcHDmszOP for ; Tue, 30 Mar 2010 13:45:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB47F3A67F6 for ; Tue, 30 Mar 2010 13:45:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwiDt-0005K1-KP for v6ops-data0@psg.com; Tue, 30 Mar 2010 20:39:41 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwiDq-0005Ja-AR for v6ops@ops.ietf.org; Tue, 30 Mar 2010 20:39:38 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,336,1267401600"; d="scan'208";a="505623400" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2010 20:39:37 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2UKdbhZ008310; Tue, 30 Mar 2010 20:39:37 GMT Subject: Re: simple security Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Tue, 30 Mar 2010 13:39:36 -0700 Cc: "Hemant Singh (shemant)" , Konrad Rosenbaum , v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <325EF2E6-0595-4DA1-8DF9-1908F5396AC0@cisco.com> References: <001501caca91$769511b0$63bf3510$@org> <4BAA2BF5.20400@cisco.com> <201003281841.48962@zaphod.konrad.silmor.de> To: Mohacsi Janos X-Mailer: Apple Mail (2.1078) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Using a ULA *instead* of a GUA makes sense for all the systems that you = only want to access or to have access within the domain. In my house, I = think that is two of them, both printers, and one of those is = USB-attached rather than being IP-attached. The blue-ray player needs to = be able to download from Netflix, the set-top box needs to talk with Cox = for content and control, and then there are those pesky computer things. On Mar 30, 2010, at 1:38 AM, Mohacsi Janos wrote: >=20 >=20 >=20 > On Mon, 29 Mar 2010, Fred Baker wrote: >=20 >> The default table, as you point out, doesn't specifically reference = FC00::/7; it prefers localhost to any IPv6 address, any IPv6 address to = a 6to4 address, and 6to4 to any IPv4/IPv6 translation mechanism using a = well known prefix. As such, the next rule will apply. The next rule, as = I understand it, will be to order the available addresses by the length = of their matching prefixes from longest to shortest. >>=20 >> I would expect, given that scenario, that if we are within the same = edge network (the most common use of ULAs), we will have at least one = and perhaps several prefixes that are longer than /48, and the exact = choice will be specific to the address pair being compared but may = choose the ULA. If we are not in the same network but share PA prefixes = from an ISP, we are likely to use that ISP's prefix. if we do not share = prefixes allocated by an ISP, your guess is as good as mine. >>=20 >> I would actually not suggest adding FC00::/7 to the default table; if = some system on the other side of the world is advertising a ULA in DNS = and you have one, you'll try ULA-to-ULA in preference and you won't be = happy with the result. However, you might add your own ULA within your = domain in preference to ::/0. >=20 > Agreed. I just wanted to mention in one of my previous e-mail = regarding CPE simple security - CPE without firewall: Usage of ULA = behind the CPE instead GUA not very trivial. Needs some tweaking to = prefer own ULA or RFC3484 policy distribution. >=20 > Best Regards, > Janos Mohacsi >=20 >=20 >>=20 >> On Mar 29, 2010, at 9:37 AM, Mohacsi Janos wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, 29 Mar 2010, Hemant Singh (shemant) wrote: >>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >>>> Behalf Of Mohacsi Janos >>>> Sent: Monday, March 29, 2010 12:19 AM >>>> To: Konrad Rosenbaum >>>> Cc: v6ops@ops.ietf.org >>>> Subject: Re: simple security >>>>=20 >>>>> The current RFC 3484 does not cope properly with ULA addresses, >>>>=20 >>>> What do you mean by not cope? ULA and the GUA have global scope = and the >>>> longest prefix match works fine for packet forwarding if both a ULA = and >>>> a GUA are configured on a network interface. I don't see any = gotcha >>>> with RFC 3484 with use of ULA or with use of ULA and a GUA on a = network >>>> interface. >>>=20 >>> Yes. You are right, but in the context, that I wrote I don't see it = is enough. If you have two nodes with both GUA and ULA, but different = subnets inside a site: >>>=20 >>>=20 >>> [node1]----------[router]---------[node2] >>>=20 >>>=20 >>> Both GUA and ULA addresses are configured in the DNS... >>>=20 >>> What to configure no node1 and node2 to prefer ULA communication = between node1 and node2? >>>=20 >>> And contrary, if I want prefer GUA usage between nodes? >>>=20 >>> Can I do it with the current default RFC 3484? >>>=20 >>> In the default policy table >>> Prefix Precedence Label >>> ::1/128 50 0 >>> ::/0 40 1 >>> 2002::/16 30 2 >>> ::/96 20 3 >>> ::ffff:0:0/96 10 4 >>>=20 >>> Best Regards, >>> Janos Mohacsi >>>=20 >>=20 >> http://www.ipinc.net/IPv4.GIF >>=20 >>=20 http://www.ipinc.net/IPv4.GIF From v6ops-archive@megatron.ietf.org Tue Mar 30 21:28:09 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CC73A6A45 for ; Tue, 30 Mar 2010 21:28:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 30 Mar 2010 21:28:03 -0700 (PDT) Received: from acns.colostate.edu (unknown [125.161.202.128]) by core3.amsl.com (Postfix) with SMTP id 319D33A68F9 for ; Tue, 30 Mar 2010 21:28:00 -0700 (PDT) From: Approved VIAGRA® Store Subject: New Private Message for v6ops-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100331042801.319D33A68F9@core3.amsl.com> Date: Tue, 30 Mar 2010 21:28:00 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@megatron.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 52587 Inc. All rights reserved.

From urn-nid-web-archivedd@ietf.org Wed Mar 31 01:23:33 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1E33A6C38 for ; Wed, 31 Mar 2010 01:23:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 31 Mar 2010 01:23:26 -0700 (PDT) Received: from aliceandolivia.com (unknown [119.226.209.66]) by core3.amsl.com (Postfix) with SMTP id 8E4D33A6C39 for ; Wed, 31 Mar 2010 01:17:23 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100331081728.8E4D33A6C39@core3.amsl.com> Date: Wed, 31 Mar 2010 01:17:23 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is v6ops-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 08390 Inc. All rights reserved.

From owner-v6ops@ops.ietf.org Wed Mar 31 01:30:31 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1F03A6C59 for ; Wed, 31 Mar 2010 01:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.267 X-Spam-Level: * X-Spam-Status: No, score=1.267 tagged_above=-999 required=5 tests=[AWL=-1.792, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvl1AgBvXUQH for ; Wed, 31 Mar 2010 01:30:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8027E3A6C5D for ; Wed, 31 Mar 2010 01:25:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwtAU-000GEl-Dv for v6ops-data0@psg.com; Wed, 31 Mar 2010 08:20:54 +0000 Received: from [202.136.110.247] (helo=smtp4.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwtAR-000GE9-FF for v6ops@ops.ietf.org; Wed, 31 Mar 2010 08:20:51 +0000 Received: from 114-30-109-209.ip.adam.com.au ([114.30.109.209] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NwtAH-00080f-CE; Wed, 31 Mar 2010 18:50:41 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A298E4930C; Wed, 31 Mar 2010 18:50:40 +1030 (CST) Date: Wed, 31 Mar 2010 18:50:38 +1030 From: Mark Smith To: Mark Townsley Cc: "STARK, BARBARA H (ATTLABS)" , "Hemant Singh (shemant)" , "Fred Baker (fred)" , Ole Troan , IPv6 v6ops Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04 Message-ID: <20100331185038.42c24bcd@opy.nosense.org> In-Reply-To: <4BB10FAA.5070407@cisco.com> References: <4BACC0C9.2080201@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F124AFDA0@crexc50p> <03DB7B96-7A82-4D6E-9E9E-DB63798E1075@employees.org> <0FBE8CDC-EE01-48B3-A143-A26FAB3DBBF4@apple.com> <4BAD305D.3070808@cisco.com> <2bbba3c11003270757g1846bec1u9bf19028c53bcb37@mail.gmail.com> <0F0BEC91-7970-407C-8E1B-B53E0EA732AD@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F126521C1@crexc50p> <4BB0F49E.1080904@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F12652600@crexc50p> <4BB10FAA.5070407@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-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 List-ID: On Mon, 29 Mar 2010 22:38:02 +0200 Mark Townsley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > On 3/29/10 9:47 PM, STARK, BARBARA H (ATTLABS) wrote: > > > << snip >> > > > Which is exactly why I used the phrase "vendors and service > > providers". Vendors determine/set the defaults of all CPE that they sell > > directly to consumers. I expect such vendors to decide for themselves > > how to set the defaults on any such CPE. CPE vendors act a lot like > > service providers in this regard. The most successful ones include > > functions and set defaults according to what generates the greatest > > sales and causes the fewest returns (devices returned for refunds). They > > figure out what it is that consumers really want and are willing to pay > > for. In my experience, vendors, as a community, tend to be good at > > providing different products geared towards different segments of the > > market, with different functions and defaults. No matter whether the > > IETF recommends default on or off, there will be vendors who ignore that > > recommendation. Clearly the community is split over what the right > > recommendation is -- so I think we should just let the market decide, > > and stop arguing. The market will decide, anyway. > > > > Vendors don't actively manage the CPE being described here though, and > we are talking about configuration parameters in an operations and > management working group document. > > I think we're down in a rathole on the relevance of SDOs and the Market > as the final judge. My only point is that there is a real difference > between SP-managed, and Consumer-managed CPE. Disagreements in terms of > base requirements, configuration items and defaults, etc. often reside > in these two very different operational points of view (at least that is > my observation in a number of cases). > Unfortunately there is also a middle ground. Even in a market where the customer owns/manages the CPE (like here in the .au ADSL market), it is in the SP's interest to provide a level of CPE support, to make sure the customer can use the services that the SP is selling. Recommended defaults that make supporting customer owned CPE easy, or even better, avoidable, have quite a lot of value to SPs. Their helpdesks are pure cost to them Regards, Mark. From v6ops-archive@ietf.org Wed Mar 31 03:55:28 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A083A67D9 for ; Wed, 31 Mar 2010 03:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RATWARE_MS_HASH=1.398, RATWARE_OUTLOOK_NONAME=2.171, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq7+r2SXjcEd for ; Wed, 31 Mar 2010 03:55:27 -0700 (PDT) Received: from 201-42-174-54.dsl.telesp.net.br (201-42-174-54.dsl.telesp.net.br [201.42.174.54]) by core3.amsl.com (Postfix) with SMTP id 8C9703A6943 for ; Wed, 31 Mar 2010 03:55:25 -0700 (PDT) Message-Id: <74c501cad0a7$94a09c30$36ae2ac9@oem-0e404fe95c1> From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: RE: Discount ID04746 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 31 Mar 2010 03:55:25 -0700 (PDT) News
Click here to view as a web page.

View image in browser now
Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright 2009 Pezox Inc. All rights reserved.
From owner-v6ops@ops.ietf.org Wed Mar 31 10:47:48 2010 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE6E3A6928 for ; Wed, 31 Mar 2010 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.138 X-Spam-Level: X-Spam-Status: No, score=-107.138 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWuX0aa5IHK6 for ; Wed, 31 Mar 2010 10:47:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CBD83A67D7 for ; Wed, 31 Mar 2010 10:47:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nx1w9-0001aE-9A for v6ops-data0@psg.com; Wed, 31 Mar 2010 17:42:41 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nx1w7-0001Zz-6X for v6ops@ops.ietf.org; Wed, 31 Mar 2010 17:42:39 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM8ls0urRN+K/2dsb2JhbACbNHGoBJkkhQAEgyM X-IronPort-AV: E=Sophos;i="4.51,342,1267401600"; d="scan'208";a="108341357" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2010 17:42:38 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2VHem3Z014549; Wed, 31 Mar 2010 17:42:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Fwd: ISOC IPv6 Deployment Day Workshop From: Fred Baker Date: Wed, 31 Mar 2010 10:42:38 -0700 Cc: Phil Roberts Content-Transfer-Encoding: quoted-printable Message-Id: <60D2C2D7-974B-429E-A6DB-A5278FDB6353@cisco.com> References: <4BB36E17.3000707@isoc.org> To: IPv6 v6ops X-Mailer: Apple Mail (2.1078) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Off topic but relevant. ISOC is hosting a deployment day workshop in Seattle in April. It is = described here: = https://www.isoc.org/isoc/conferences/registration/?id=3D7ce20e4c88b7e328.=