From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 00:51:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA6121F85AE for ; Mon, 1 Aug 2011 00:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkES5z6qbuL6 for ; Mon, 1 Aug 2011 00:51:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A713421F8506 for ; Mon, 1 Aug 2011 00:51:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QnnHo-0001iYC; Mon, 1 Aug 2011 09:51:40 +0200 Message-Id: To: Daniel Roesen From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> In-reply-to: Your message of "Mon, 1 Aug 2011 07:37:19 +0200 ." <20110801053719.GA10524@srv03.cluenet.de> Date: Mon, 01 Aug 2011 09:51:26 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 07:51:38 -0000 In your letter dated Mon, 1 Aug 2011 07:37:19 +0200 you wrote: >On Mon, Aug 01, 2011 at 11:20:02AM +1000, George Michaelson wrote: >> All three connect on IPv6 for Snow Leopard. >> All three connect on IPv4 for Lion. > >Excellent, so operators have to make sure that their LSN setups will >artificially introduce some delay to bias clients to use IPv6 to >offload the expensive NATs. We shall raise feature requests with the >vendors. What I did in my HE implementation is that when sorting the output of getaddrinfo I give the first address a 'bonus' of 30ms. The net effect is that as long as the first address is within 30ms of the best address, the first address will be used. I think this is good compromise between on the one hand following the destination selection policy and address order in a RR set and on the other hand protecting the user from badly performing addresses. From sander@steffann.nl Mon Aug 1 00:52:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660A821F8557 for ; Mon, 1 Aug 2011 00:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWkXZcIOP2l3 for ; Mon, 1 Aug 2011 00:52:44 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0021F8507 for ; Mon, 1 Aug 2011 00:52:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id D7136200A; Mon, 1 Aug 2011 09:47:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnXUi3LTl7SU; Mon, 1 Aug 2011 09:47:32 +0200 (CEST) Received: from [10.248.1.36] (unknown [188.142.127.132]) by mail.sintact.nl (Postfix) with ESMTP id 08C4B2002; Mon, 1 Aug 2011 09:47:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <20110801053719.GA10524@srv03.cluenet.de> Date: Mon, 1 Aug 2011 09:47:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 07:52:44 -0000 Hi Daniel, > On Mon, Aug 01, 2011 at 11:20:02AM +1000, George Michaelson wrote: >> All three connect on IPv6 for Snow Leopard. >> All three connect on IPv4 for Lion. > > Excellent, so operators have to make sure that their LSN setups will > artificially introduce some delay to bias clients to use IPv6 to > offload the expensive NATs. We shall raise feature requests with the > vendors. I think the NAT will do that automatically all by itself. Met vriendelijke groet, Sander Steffann From ietfc@btconnect.com Mon Aug 1 04:26:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DA621F889A for ; Mon, 1 Aug 2011 04:26:46 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgK0Emj0o+rD for ; Mon, 1 Aug 2011 04:26:45 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 65F8D21F887C for ; Mon, 1 Aug 2011 04:26:44 -0700 (PDT) Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr13.btconnect.com with SMTP id DVP02011; Mon, 01 Aug 2011 12:26:47 +0100 (BST) Message-ID: <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , "IPv6 Operations" References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> Date: Mon, 1 Aug 2011 12:23:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E368D77.0098, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.1.103015:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1400_1499, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4E368D78.0064,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 11:26:46 -0000 ----- Original Message ----- From: "Fred Baker" To: "IPv6 Operations" Sent: Saturday, July 30, 2011 11:37 PM > Pursuant to our discussion Tuesday, I'd be interested in working group comment on > http://tools.ietf.org/html/draft-keranen-ipv6day-measurements > "Some Measurements on World IPv6 Day from End-User Perspective", Ari > Keranen, Jari Arkko, 11-Jul-11 > > I could imagine not publishing as RFC (it has already served its purpose), sending to the IESG as an individual submission for informational status, or adopting as a working group item and eventually sending as that to the IESG for informational status. Up to you guys... I find that bizarre. Of course it should be published as an RFC (with a few tweaks for grammar, ease of use and comprehension). I cannot imagine how it has done its job; its job is to provide us with a point of reference in the current and future discussions about IPv6, where and how much of it there is, etc. and that can only be done as an RFC (or, less good, as its equivalent in some other body). Tom Petch > > What would you like to do? > - do you want to adopt it? > - separate question, do you want to publish it? > - if you want to publish it, do you have any comments? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jeroen@unfix.org Mon Aug 1 05:11:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F9B21F8CEF; Mon, 1 Aug 2011 05:10:41 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY1H3AHQ4BDT; Mon, 1 Aug 2011 05:10:32 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3921F8D39; Mon, 1 Aug 2011 05:10:32 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 8A048801C2BF; Mon, 1 Aug 2011 14:10:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1312200632; bh=MXlCJQLBZHU46Sg4UGG3nkqOp6egFAsSJg2L+to3zts=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MKjYcL4sGPF+j5a0mFlNLSqt3NDjU2jLi1+t2tgLS1uDBTlPQvfd3C5d3b4KT7r3Z kfPO6zb9YRGyrYSVNqnmW0gszFP/Qw6TsWW3yjJo5i1BoGpWSs4salyKcBjkuEQkZS NwPaNTkkCygDXXH3U+a9XS1ND9en3TD0H8pHRlKWGs7iJaG5ThTgEGhHP1UcJY161Y bwU9hejvH8Up5WOOzW7O3alc9UEAzKKhNH62TaqCZyL6gW0jdGYbxI4I68rx/PDtxO 1kn4njFTkrP//5HKN00orY0jF4/CKxOFHh1Vat3FNLDO84kKgNIjYfxop+Sq7WjAAd uEQR32cau/Qxw== Message-ID: <4E3697B8.1010603@unfix.org> Date: Mon, 01 Aug 2011 14:10:32 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> <4E305E3E.2040607@unfix.org> <20110727233634.406021238970@drugs.dv.isc.org> <4E3127F1.2030708@unfix.org> <20110730010626.05D3212542D0@drugs.dv.isc.org> In-Reply-To: <20110730010626.05D3212542D0@drugs.dv.isc.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:11:13 -0000 On 2011-07-30 03:06 , Mark Andrews wrote: > In message <4E3127F1.2030708@unfix.org>, Jeroen Massar writes: >> On 2011-07-28 01:36 , Mark Andrews wrote: >> [..] >>> Is there *one* tunnel management protocol that they all support or >>> does a cpe vendor have to implement multiple ones to reach them >>> all? I'm pretty sure I know the answer to this question but I'd >>> love to be proved wrong. >> >> There is no 'one' solution to the problems that they are solving. >> >> As such there tend to be a combo of: >> - static proto-41 tunnel >> - 6to4 >> - 6rd >> - TSP => dynamic NATted addresses >> - proto-41 + heartbeat + TIC => dynamic public addresses >> - AYIYA + TIC => dynamic NATted addresses > > I was more thinking about commonality with tunnel brokers. These all are implemented by "tunnelbrokers", be they tunnel brokers where you can just fill in the details yourself (6to4) or the others where the parameters are provided by the entity you want to connect to. > 6rd is not a replacement for 6to4 as it requires ISP involment or > someone to create a registry of 3rd party 6rd providers along with > associated parameters sets similar non anycast 6to4. 6rd is then also intended for a per ISP deployment. > static proto-41 > tunnel is also not a viable replacement as it doesn't handle address > reassignment at the CPE end. See the "proto-41 + heartbeat" option, that is standard proto-41 but with a side-channel which beats where the endpoint currently is. But why are you trying to replace 6to4? What are the requirements that you have that are not satisfied by any of the above methods? Greets, Jeroen From dr@cluenet.de Mon Aug 1 07:39:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4F11E80D5 for ; Mon, 1 Aug 2011 07:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3sTVNDLL1sS for ; Mon, 1 Aug 2011 07:39:44 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8600911E8073 for ; Mon, 1 Aug 2011 07:39:44 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id D480C1080A0; Mon, 1 Aug 2011 16:39:49 +0200 (CEST) Date: Mon, 1 Aug 2011 16:39:49 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110801143949.GA18578@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:39:45 -0000 On Mon, Aug 01, 2011 at 09:47:46AM +0200, Sander Steffann wrote: > > Excellent, so operators have to make sure that their LSN setups will > > artificially introduce some delay to bias clients to use IPv6 to > > offload the expensive NATs. We shall raise feature requests with the > > vendors. > > I think the NAT will do that automatically all by itself. Judging from what I'm seeing: Not really. We're talking about sub-millisecond added latency which probably is deep in the noise level of DNS resolution time variance anyway (caveat: I haven't measured and compared that myself). So from this perspective, a HE implementation will (unless the ISP uses substandard hardware to implement the NAT) probably not notice the NAT by any added delay. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From cb.list6@gmail.com Mon Aug 1 08:29:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD1421F8B84 for ; Mon, 1 Aug 2011 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STdPhgSwwt0Z for ; Mon, 1 Aug 2011 08:29:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5E21F8B83 for ; Mon, 1 Aug 2011 08:29:41 -0700 (PDT) Received: by wyj26 with SMTP id 26so1487364wyj.31 for ; Mon, 01 Aug 2011 08:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=JUAKmdLKTuy+pF021biKhfaV0LrjnFvi7cpyiRABBmU=; b=brY+PWgV0N118wcQz/Dd/hH6pzFi4PI9V7QO0KGq06NxsQBIUifVvEv5vt9eVTPfqV Z23z3focL3IWj07+WSrQDDSdBW0jZpDMQKgNH/IuVW8De0fVHnHV89HH0WdglWluy7Cs cODRb1Lobeip5idYWaPKFANxCpWaBuFrL1EZs= MIME-Version: 1.0 Received: by 10.216.132.129 with SMTP id o1mr803214wei.73.1312212586347; Mon, 01 Aug 2011 08:29:46 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 08:29:46 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 08:29:46 -0700 (PDT) In-Reply-To: <20110801143949.GA18578@srv03.cluenet.de> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> Date: Mon, 1 Aug 2011 08:29:46 -0700 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=0016e6de03a4143c1504a9734df1 Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:29:42 -0000 --0016e6de03a4143c1504a9734df1 Content-Type: text/plain; charset=ISO-8859-1 On Aug 1, 2011 7:39 AM, "Daniel Roesen" wrote: > > On Mon, Aug 01, 2011 at 09:47:46AM +0200, Sander Steffann wrote: > > > Excellent, so operators have to make sure that their LSN setups will > > > artificially introduce some delay to bias clients to use IPv6 to > > > offload the expensive NATs. We shall raise feature requests with the > > > vendors. > > > > I think the NAT will do that automatically all by itself. > > Judging from what I'm seeing: Not really. We're talking about > sub-millisecond added latency which probably is deep in the noise level > of DNS resolution time variance anyway (caveat: I haven't measured and > compared that myself). > > So from this perspective, a HE implementation will (unless the ISP uses > substandard hardware to implement the NAT) probably not notice the NAT > by any added delay. > +1 to confirming CGN/LSN does not add latency in a meaningful way. I also find that injecting latency at the nat will be hard sell to management and possibly difficult to instrument. I suggest users use Chrome or Firefox which produces the desired results at the host. Cb > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016e6de03a4143c1504a9734df1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 1, 2011 7:39 AM, "Daniel Roesen" <dr@cluenet.de> wrote:
>
> On Mon, Aug 01, 2011 at 09:47:46AM +0200, Sander Steffann wrote:
> > > Excellent, so operators have to make sure that their LSN set= ups will
> > > artificially introduce some delay to bias clients to use IPv= 6 to
> > > offload the expensive NATs. We shall raise feature requests = with the
> > > vendors.
> >
> > I think the NAT will do that automatically all by itself.
>
> Judging from what I'm seeing: Not really. We're talking about<= br> > sub-millisecond added latency which probably is deep in the noise leve= l
> of DNS resolution time variance anyway (caveat: I haven't measured= and
> compared that myself).
>
> So from this perspective, a HE implementation will (unless the ISP use= s
> substandard hardware to implement the NAT) probably not notice the NAT=
> by any added delay.
>

+1 to confirming CGN/LSN does not add latency in a meaningful way.

I also find that injecting latency at the nat will be hard sell to manag= ement and possibly difficult to instrument.=A0 I suggest users use Chrome o= r Firefox which produces the desired results at the host.

Cb

> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016e6de03a4143c1504a9734df1-- From rajiva@cisco.com Mon Aug 1 08:33:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E1A21F885C for ; Mon, 1 Aug 2011 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HGTMoCsKIFi for ; Mon, 1 Aug 2011 08:33:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 12FFA21F8B1E for ; Mon, 1 Aug 2011 08:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2890; q=dns/txt; s=iport; t=1312212810; x=1313422410; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WXgfTqrWJNjuj3EqbF8bh4jeFotXWfsMKXaTmNGzueQ=; b=kTJcF+ULZku01RtHcW/UhcnVypryOhUn17frmh1hh/FRkIBumaF6lhTx qgfKPrtj/ARxZQebfBv1G6EgbSJJ6EDS9alUbPrrk5CsqybQFII4Ed9+o 2U4PCk7YzV1bouclGU2imd/N04B2UJBbYOilVOP4xZJ+58Ndhh1bdnJry c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAAnHNk6tJV2d/2dsb2JhbABBmA2PVHeBQAEBAQECARIBHQotEgUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah0qhTgGeRoVjXwSHWpAxi3I X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8470347" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2011 15:33:29 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p71FXTtY000373; Mon, 1 Aug 2011 15:33:29 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:33:29 -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 Date: Mon, 1 Aug 2011 10:33:28 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxO6HZ7ory4kfqsSxi56e03F+5J/wBdTzLA References: From: "Rajiv Asati (rajiva)" To: "Lorenzo Colitti" , "Brzozowski, John" X-OriginalArrivalTime: 01 Aug 2011 15:33:29.0366 (UTC) FILETIME=[5CF6C360:01CC5060] Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:33:23 -0000 > In a routed home network, you want guest networks and non-guest networks to be > routed, but not talk to each other. Carrying in the IGP the information about > whether each /64 assigned to an interface is for a guest network or a non- > guest network allows the routers to apply the appropriate firewalls between > the guest network and the non-guest network, while still routing both guest Agreed to the use case, but having to run a heavy-duty protocol like OSPF or ISIS is an overkill to this use case, IMO. However, having the firewall to pick up the policy from IGP database is something pretty advanced, IMO. > and non-guest prefixes. It's a bit like having two VRFs or an MPLS VPN. I like the analogy, of course, MPLS VPN can be made to have two L3VPNs talk to each other. :-)). MPLS VPN can not replace firewall function. I am sure you didn't mean that either, but just in case. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Lorenzo Colitti > Sent: Saturday, July 30, 2011 2:42 PM > To: Brzozowski, John > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > On Sat, Jul 30, 2011 at 00:34, Brzozowski, John > wrote: >=20 >=20 > >* can distribute information beyond IP reachability; for example, "this > >prefix belongs to a guest network" or "this is a prefix that I have > >tentatively assigned to my interface, not a prefix that is already in > >use". This would be useful for autoconfiguration. >=20 > [jjmb] as I emailed before why would this be required of the LAN side > network is part of an already delegated prefix? Am I missing something? >=20 >=20 >=20 > In a routed home network, you want guest networks and non-guest networks to be > routed, but not talk to each other. Carrying in the IGP the information about > whether each /64 assigned to an interface is for a guest network or a non- > guest network allows the routers to apply the appropriate firewalls between > the guest network and the non-guest network, while still routing both guest > and non-guest prefixes. It's a bit like having two VRFs or an MPLS VPN. >=20 > As regards the "tentative" tag, that might be useful when doing > autoconfiguration. As Ole says, a CE could pick one random /64 out of the > aggregate for each of its interfaces and do collision detection to see if it's > unique. If the IGP carries a flag saying "this prefix is tentative" that might > make it easier. >=20 > Of course, these are just examples of why a protocol that can carry additional > information beyond just "this prefix lives here with this metric" can be > useful: it allows the network to do stuff that we haven't thought of yet. >=20 > Cheers, > Lorenzo From wwwrun@rfc-editor.org Mon Aug 1 08:53:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7597311E80DF; Mon, 1 Aug 2011 08:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESB2pNMw5qMi; Mon, 1 Aug 2011 08:53:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1274011E80D8; Mon, 1 Aug 2011 08:53:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EBBE898C4EF; Mon, 1 Aug 2011 08:53:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110801155354.EBBE898C4EF@rfc-editor.org> Date: Mon, 1 Aug 2011 08:53:54 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6342 on Mobile Networks Considerations for IPv6 Deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:53:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6342 Title: Mobile Networks Considerations for IPv6 Deployment Author: R. Koodli Status: Informational Stream: IETF Date: August 2011 Mailbox: rkoodli@cisco.com Pages: 17 Characters: 46288 Obsoletes: RFC6312 I-D Tag: draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis.txt URL: http://www.rfc-editor.org/rfc/rfc6342.txt Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lorenzo@google.com Mon Aug 1 09:20:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E378C11E8077 for ; Mon, 1 Aug 2011 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.847 X-Spam-Level: X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQFVOAorZT6A for ; Mon, 1 Aug 2011 09:20:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA811E80E1 for ; Mon, 1 Aug 2011 09:20:46 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p71GKpb4013348 for ; Mon, 1 Aug 2011 09:20:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312215652; bh=+/AOOrEAO1ZyZlic8j1LB8AMnyA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GFQFuaCTU2GmPu+uMEw4KDvcfNEP1qdKE0QZL1lSMy6Z9VNJF6p34NmVVFCcjEKad tvllv/z8F+56yj6wmxmCg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=vB204Dv5xgb4axr0SPmUJcRXBrkuNmbq14HjkQEW2wh9VwKBYIdfoX9oeEP8aSc/O +4l9toRBE0Sb92qNzh7bg== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq14.eem.corp.google.com with ESMTP id p71GJAZQ022616 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 09:20:50 -0700 Received: by gyf3 with SMTP id 3so4528533gyf.13 for ; Mon, 01 Aug 2011 09:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0fj05D7tM2NkBOOdV6TlfUKT9MFMnDwTv8Utg8xhWJc=; b=aNB1fuhAgjvZZn2uxnpUssiWBir0cFpDOs0U0Ws2FOYlEUoi/AzNc2dRRxsgayheCq 1P0tpLtg+Ch5LBDb1MWw== Received: by 10.150.51.16 with SMTP id y16mr962562yby.0.1312215650114; Mon, 01 Aug 2011 09:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Mon, 1 Aug 2011 09:20:30 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 1 Aug 2011 12:20:30 -0400 Message-ID: To: "Brzozowski, John" Content-Type: multipart/alternative; boundary=000e0cd6a666b19e0a04a97403ff X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:20:47 -0000 --000e0cd6a666b19e0a04a97403ff Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 31, 2011 at 10:38, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > The outer most router supports DHCPv6 PD (LAN side). It would have to be > seeded with adequate address space to serve up IA_PD (and possibly IA_NA) > for downstream routers. Based on conversations to date I assume there > would be interest in downstream routers also support and being able to > delegate prefixes? > There are two issues I see with DHCPv6 PD to distribute prefixes inside the home: 1. Prefix delegation only really works in a tree topology, so when the user plugs things in wrong (e.g., plugs a LAN port into another LAN port, or creates a loop) it won't work. Having a routing protocol will allow things to work regardless of how the user plugs things in. 2. We already use PD between the home network and the ISP. If we use it inside the home as well, then a home router getting a prefix via DHCPv6 PD will not know whether it is connected to the ISP or not, and thus if it should turn on the firewall or not. Both of these issues can be solved by using an IGP. Cheers, Lorenzo --000e0cd6a666b19e0a04a97403ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 31, 2011 at 10:38, Brzozowski, John = <= John_Brzozowski@cable.comcast.com> wrote:
The outer most router supports DHCPv6 PD (LAN side). =A0I= t would have to be
seeded with adequate address space to serve up IA_PD (and possibly IA_NA) for downstream routers. =A0Based on conversations to date I assume there would be interest in downstream routers also support and being able to
delegate prefixes?

There are two issues I see with= DHCPv6 PD to distribute prefixes inside the home:

1. Prefix delegation only really works in a tree topology, so when the use= r plugs things in wrong (e.g., plugs a LAN port into another LAN port, or c= reates a loop) it won't work. Having a routing protocol will allow thin= gs to work regardless of how the user plugs things in.
2. We already use PD between the home network and the ISP. If we use i= t inside the home as well, then a home router getting a prefix via DHCPv6 P= D will not know whether it is connected to the ISP or not, and thus if it s= hould turn on the firewall or not.

Both of these issues can be solved by using an IGP.

Cheers,
Lorenzo
--000e0cd6a666b19e0a04a97403ff-- From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 09:26:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040C921F8C47 for ; Mon, 1 Aug 2011 09:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YypjlZglD57a for ; Mon, 1 Aug 2011 09:26:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14AC21F8C25 for ; Mon, 1 Aug 2011 09:26:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QnvKO-0001isC; Mon, 1 Aug 2011 18:26:52 +0200 Message-Id: To: Cameron Byrne From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> In-reply-to: Your message of "Mon, 1 Aug 2011 08:29:46 -0700 ." Date: Mon, 01 Aug 2011 18:26:44 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:26:51 -0000 In your letter dated Mon, 1 Aug 2011 08:29:46 -0700 you wrote: >+1 to confirming CGN/LSN does not add latency in a meaningful way. > >I also find that injecting latency at the nat will be hard sell to >management and possibly difficult to instrument. I suggest users use Chrome >or Firefox which produces the desired results at the host. As a user, why would I do that? I've no idea how Chrome and Firefox interact with getaddrinfo. Do they actually move an IPv6 to the front of the list. Or do they implement their own solver, bypassing getaddrinfo? Anyhow, assuming Chrome and Firefox would have their own getaddrinfo implementation, you get a 200ms delay whever IPv6 doesn't work. It doesn't even have to be at the user's end, some people manage to misconfigure IPv6 on their servers as well. So what kind of horrors can we expect from CGN that would make Chrome and Firefox a better deal? From lorenzo@google.com Mon Aug 1 09:31:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F121F8E4B for ; Mon, 1 Aug 2011 09:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ZWV0bM7msg for ; Mon, 1 Aug 2011 09:31:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3521F8E2F for ; Mon, 1 Aug 2011 09:31:25 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p71GVQqp019530 for ; Mon, 1 Aug 2011 09:31:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312216291; bh=3PtwbtUVY/0fnah3jJ6I8ob/3js=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=s1UovmBe/A96dL6cRenjt+l4EXKvD/jUZ5hWv1+cnPhuKmfadwUvL+8jeQmCNq2hz Aos1wtXCzrbDQsWeOU6rw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=jNXQ1MyuXb2KUQJ+xM0LjC4Cs2rS/gkF1qrCSSx4QyDjix68zaTlP5VL6kBgoiP99 lFHkp65pFSys7sRh0D0Zg== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by kpbe15.cbf.corp.google.com with ESMTP id p71GVPxR016667 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 09:31:25 -0700 Received: by yxl11 with SMTP id 11so4058491yxl.7 for ; Mon, 01 Aug 2011 09:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eFpfvatQEh0+1Cgh5wh7U2bX42yeb1X/sAUQuZld4tY=; b=okWPW5/68teDC6N0p2gF45pFZorIzsMt2uP2fGF5QZ996apNTsOY72fJJB9tUO+Luf 13fHD7xv/SoPsOQU1uZg== Received: by 10.150.51.16 with SMTP id y16mr973447yby.0.1312216285098; Mon, 01 Aug 2011 09:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Mon, 1 Aug 2011 09:31:05 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> From: Lorenzo Colitti Date: Mon, 1 Aug 2011 09:31:05 -0700 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=000e0cd6a6668ab3a304a974291f X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:31:26 -0000 --000e0cd6a6668ab3a304a974291f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 1, 2011 at 09:26, Philip Homburg wrote: > So what kind of horrors can we expect from CGN that would make Chrome and > Firefox a better deal? One example is the NAT intercepting your HTTP request and showing you a nice "you've run out of ports" error message instead of the web page you wanted to see. --000e0cd6a6668ab3a304a974291f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 1, 2011 at 09:26, Philip Homburg <pch-v6ops-= 2@u-1.phicoh.com> wrote:
So what kind of horrors can we expect from CGN that would= make Chrome and
Firefox a better deal?

One example is the N= AT intercepting your HTTP request and showing you a nice "you've r= un out of ports" error message instead of the web page you wanted to s= ee.
--000e0cd6a6668ab3a304a974291f-- From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 09:36:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E827221F8EBF for ; Mon, 1 Aug 2011 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLMIwZ74XA4d for ; Mon, 1 Aug 2011 09:36:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 278ED21F8EBE for ; Mon, 1 Aug 2011 09:36:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QnvTx-0001jFC; Mon, 1 Aug 2011 18:36:45 +0200 Message-Id: To: Lorenzo Colitti From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> In-reply-to: Your message of "Mon, 1 Aug 2011 09:31:05 -0700 ." Date: Mon, 01 Aug 2011 18:36:44 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:36:49 -0000 In your letter dated Mon, 1 Aug 2011 09:31:05 -0700 you wrote: >One example is the NAT intercepting your HTTP request and showing you a nice >"you've run out of ports" error message instead of the web page you wanted >to see. I'm sure somebody is going to do something as stupid as that. So let's assume that it will happen. Then a slightly more advanced NAT implementation might take that situation as a signal it should start delaying SYN+ACKs to avoid overload and to allow HE to do its trick. From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 09:44:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2221F8D38 for ; Mon, 1 Aug 2011 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d+m4mzItZdB for ; Mon, 1 Aug 2011 09:44:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83121F8D37 for ; Mon, 1 Aug 2011 09:44:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qnvb4-0001isC; Mon, 1 Aug 2011 18:44:06 +0200 Message-Id: To: Lorenzo Colitti From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Mon, 1 Aug 2011 12:20:30 -0400 ." Date: Mon, 01 Aug 2011 18:44:05 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:44:05 -0000 In your letter dated Mon, 1 Aug 2011 12:20:30 -0400 you wrote: >There are two issues I see with DHCPv6 PD to distribute prefixes inside the >home: > >1. Prefix delegation only really works in a tree topology, so when the user >plugs things in wrong (e.g., plugs a LAN port into another LAN port, or >creates a loop) it won't work. Having a routing protocol will allow things >to work regardless of how the user plugs things in. I guess that can be solved by having a router only relay DHCP requests upstream according to its routing protocol's definition of upstream. I.e. a router first requests prefixes for its networks, but doesn't relay anything yet. Then when it can figure out where the DHCP server is, it relays towards the DHCP server. >2. We already use PD between the home network and the ISP. If we use it >inside the home as well, then a home router getting a prefix via DHCPv6 PD >will not know whether it is connected to the ISP or not, and thus if it >should turn on the firewall or not. If a home router only hands out /64s to other routers then routers can take getting something bigger than a /64 as a hint that they should enable the firewall and become a DHCP server themselves. From fred@cisco.com Mon Aug 1 09:49:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BB621F8ED0 for ; Mon, 1 Aug 2011 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cngdhTNbPNaS for ; Mon, 1 Aug 2011 09:49:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 051D421F8ECF for ; Mon, 1 Aug 2011 09:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1762; q=dns/txt; s=iport; t=1312217396; x=1313426996; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=TQ/QU+qW8AFHf9EmVOSlGJOSTm01NX+J7i+TX3J8/zw=; b=cQtBEboR7iYtGQtmjVM1zH2pAvaqKg5n3c//v93oeFWVo4bDDz7Ttb3A lZrmj08A1uW8lzAoDA+Ni34rSNqA+B3cJCpYRUeYfLzAw46kdTv4Yq2Ug pQOAwYdJAaAdCb2sojFoNVsai+5opjsZsh75ze7s7YpzfYHcFwR6JZK+t s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AALPYNk6rRDoG/2dsb2JhbABBmA2PVHeBQAEBAQECAQEBAQ8BJzQLBQcEBQYVATAnMAYTERGHSgShSAGeTIVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8496112" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2011 16:49:55 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p71GnsqZ030282; Mon, 1 Aug 2011 16:49:54 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 01 Aug 2011 09:49:54 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 01 Aug 2011 09:49:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker X-Priority: 3 In-Reply-To: <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> Date: Mon, 1 Aug 2011 09:49:46 -0700 Message-Id: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:49:49 -0000 On Aug 1, 2011, at 3:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Fred Baker" > To: "IPv6 Operations" > Sent: Saturday, July 30, 2011 11:37 PM >=20 >> Pursuant to our discussion Tuesday, I'd be interested in working = group comment > on >> http://tools.ietf.org/html/draft-keranen-ipv6day-measurements >> "Some Measurements on World IPv6 Day from End-User Perspective", Ari >> Keranen, Jari Arkko, 11-Jul-11 >>=20 >> I could imagine not publishing as RFC (it has already served its = purpose), > sending to the IESG as an individual submission for informational = status, or > adopting as a working group item and eventually sending as that to the = IESG for > informational status. Up to you guys... >=20 > I find that bizarre. Of course it should be published as an RFC (with = a few > tweaks for grammar, ease of use and comprehension). I cannot imagine = how it has > done its job; its job is to provide us with a point of reference in = the current > and future discussions about IPv6, where and how much of it there is, = etc. and > that can only be done as an RFC (or, less good, as its equivalent in = some other > body). Well, yes, but we had several other presentations whose only record is = in the proceedings. OK, I take your comment and Keith's as support for = sending it in as an individual submission. > Tom Petch >>=20 >> What would you like to do? >> - do you want to adopt it? >> - separate question, do you want to publish it? >> - if you want to publish it, do you have any comments? >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From cb.list6@gmail.com Mon Aug 1 09:57:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9095411E80FD for ; Mon, 1 Aug 2011 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHeYPh7H0-UZ for ; Mon, 1 Aug 2011 09:57:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A67E711E80FB for ; Mon, 1 Aug 2011 09:57:42 -0700 (PDT) Received: by wwe5 with SMTP id 5so3898562wwe.13 for ; Mon, 01 Aug 2011 09:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/p0SO6VkIEFfAz6wjV31pm/J/js+ZynVzZh3Bbaizg=; b=fQtfl2PJsv/DhPpiTHSt5qGo1itFQab42tPSU0ojtnww6IINL9LrEvWwWJcaA7cmAV hiexkZPtioya3nv2vLSFVCXZfb2WneWWj43NR/J6Zr+x10uXoRHalm+35lMaF7K/Xcfv xp34VMDFfTf/fjlOXBp+4FP60l2xsbbiULrn8= MIME-Version: 1.0 Received: by 10.216.14.19 with SMTP id c19mr886373wec.88.1312217868642; Mon, 01 Aug 2011 09:57:48 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 09:57:48 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> Date: Mon, 1 Aug 2011 09:57:48 -0700 Message-ID: From: Cameron Byrne To: Philip Homburg Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:57:43 -0000 On Mon, Aug 1, 2011 at 9:36 AM, Philip Homburg wrote: > In your letter dated Mon, 1 Aug 2011 09:31:05 -0700 you wrote: >>One example is the NAT intercepting your HTTP request and showing you a nice >>"you've run out of ports" error message instead of the web page you wanted >>to see. > > I'm sure somebody is going to do something as stupid as that. So let's assume > that it will happen. > > Then a slightly more advanced NAT implementation might take that situation > as a signal it should start delaying SYN+ACKs to avoid overload and to > allow HE to do its trick. > The first thing that comes to mind here is an arms races. I believe the scope of LSN/CGN is "big and dumb" so that it can scale, what you are describing is yet another level of state and complexity in a box that we are trying to keep simple (no ALG ...) Cameron From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 10:08:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4BE11E80FF for ; Mon, 1 Aug 2011 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrevAmsehqrd for ; Mon, 1 Aug 2011 10:08:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5911E8077 for ; Mon, 1 Aug 2011 10:08:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QnvyC-0001jKC; Mon, 1 Aug 2011 19:08:00 +0200 Message-Id: To: Cameron Byrne From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> In-reply-to: Your message of "Mon, 1 Aug 2011 09:57:48 -0700 ." Date: Mon, 01 Aug 2011 19:07:57 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:08:10 -0000 In your letter dated Mon, 1 Aug 2011 09:57:48 -0700 you wrote: >On Mon, Aug 1, 2011 at 9:36 AM, Philip Homburg >> Then a slightly more advanced NAT implementation might take that situation >> as a signal it should start delaying SYN+ACKs to avoid overload and to >> allow HE to do its trick. >> >The first thing that comes to mind here is an arms races. > >I believe the scope of LSN/CGN is "big and dumb" so that it can scale, >what you are describing is yet another level of state and complexity >in a box that we are trying to keep simple (no ALG ...) It seems to me that the easiest way to deal with lack of ports is to simply drop the SYN. To be able to send an HTTP error message, would require faking a SYN+ACK plus an HTTP reply. And that only to screw up anything automated that runs over http. Plus that just dropping the SYN may just slow things down enough to let requests go through. Instead of users recognizing fake error replies and writing proxies that hammer the NAT box until they do get a useful reply. From simon.perreault@viagenie.ca Mon Aug 1 10:17:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31711E812A for ; Mon, 1 Aug 2011 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CZzZynaD0nx for ; Mon, 1 Aug 2011 10:17:56 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5805111E8077 for ; Mon, 1 Aug 2011 10:17:55 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B8E3821F52 for ; Mon, 1 Aug 2011 13:18:01 -0400 (EDT) Message-ID: <4E36DFD8.1030604@viagenie.ca> Date: Mon, 01 Aug 2011 13:18:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:17:57 -0000 Lorenzo Colitti wrote, on 08/01/2011 12:31 PM: > One example is the NAT intercepting your HTTP request and showing you a nice > "you've run out of ports" error message instead of the web page you wanted to see. Note that this would break REQ-13 from draft-ietf-behave-lsn-requirements. It's tempting to add this as a MUST NOT sub-bullet... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From lorenzo@google.com Mon Aug 1 10:20:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5311E8115 for ; Mon, 1 Aug 2011 10:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4wvz2naIxgZ for ; Mon, 1 Aug 2011 10:20:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E646611E80AB for ; Mon, 1 Aug 2011 10:20:22 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p71HKOk2009306 for ; Mon, 1 Aug 2011 10:20:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312219225; bh=tb6csSV9/VFGR3zyiolMeinU4lY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=O8F3hmWH2ircpIs6HVRSASNDfF+iafvlAmwig9F2YpBuk04gpKmXK8lxkvown5wh/ 0uUnAykAIipk2zaGTWKhw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Vo1sM9jyk7rpaKz1m7oDzJpGb7HMhBf5xH7+IK/OG1+fGv73JFxqnnbR+tfsvRY7b Pb1kfVabRwXjfzFaYSiHw== Received: from yxk30 (yxk30.prod.google.com [10.190.3.158]) by wpaz13.hot.corp.google.com with ESMTP id p71HK4TY017833 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 10:20:23 -0700 Received: by yxk30 with SMTP id 30so6400695yxk.25 for ; Mon, 01 Aug 2011 10:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vjHZ6pFCJPylAnnEPRhmH2fPDENydM7ZYxih9WsbDOY=; b=F4RtMJNobVYMzR/dXHAq5PxZ4zTpFNsfiXJj3fiY8pGzDOHx003IcQ10Y+gwayNb83 6Gpp1uFZTovXkA9m4Z+A== Received: by 10.150.211.3 with SMTP id j3mr1097866ybg.399.1312219223133; Mon, 01 Aug 2011 10:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Mon, 1 Aug 2011 10:20:03 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 1 Aug 2011 10:20:03 -0700 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=000e0cd48118a98d4304a974d8e1 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:20:23 -0000 --000e0cd48118a98d4304a974d8e1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 1, 2011 at 09:44, Philip Homburg wrote: > If a home router only hands out /64s to other routers then routers can take > getting something bigger than a /64 as a hint that they should enable the > firewall and become a DHCP server themselves. > What if the ISP only hands out a /64 (like mine does)? Disable the firewall? --000e0cd48118a98d4304a974d8e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 1, 2011 at 09:44, Philip Homburg <pch-v6ops-= 2@u-1.phicoh.com> wrote:
If a home router only hands out /64s to other routers the= n routers can take
getting something bigger than a /64 as a hint that they should enable the firewall and become a DHCP server themselves.

What if the ISP only hands out a /64 (like mine does)? Disable the f= irewall?
--000e0cd48118a98d4304a974d8e1-- From lee@asgard.org Mon Aug 1 10:22:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68DD21F8B0E for ; Mon, 1 Aug 2011 10:22:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TIgkkOnBXjA for ; Mon, 1 Aug 2011 10:22:57 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id B155921F8B22 for ; Mon, 1 Aug 2011 10:22:42 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p71HMknb008803 for ; Mon, 1 Aug 2011 13:22:49 -0400 Authentication-Results: cm-omr1 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.165] ([204.235.115.165:35443] helo=HDC00027112) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 20/85-24850-5E0E63E4; Mon, 01 Aug 2011 13:22:46 -0400 From: "Lee Howard" To: "'Erik Kline'" , "'Satoru Matsushima'" References: <76D3E260-5F2E-4E1D-8F33-8B24F9E27EB7@gmail.com> In-Reply-To: Date: Mon, 1 Aug 2011 13:22:45 -0400 Message-ID: <000c01cc506f$a17f05b0$e47d1110$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxPahS9icUeZgzFRvyHSW8rYg8YNAAVGyag Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:22:58 -0000 Is anyone capturing this thread into a problem statement/requirements = document, or are we=20 going to design new protocols, and then fight about which one meets the = requirements? Can we take this to Homenet mailing list? Lee > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Erik Kline > Sent: Sunday, July 31, 2011 6:10 AM > To: Satoru Matsushima > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > On 31 July 2011 09:08, Satoru Matsushima = wrote: > > On 2011/07/31, at 17:39, Erik Kline wrote: > > > >>> Of course, these are just examples of why a protocol that can = carry > >>> additional information beyond just "this prefix lives here with = this metric" > >>> can be useful: it allows the network to do stuff that we haven't = thought of > >>> yet. > >> > >> Like advertise future standardized "this *service* is reachable via > >> this path" sorts of things. The routing protocol could aid in = service > >> discovery this way. > > > > I think it would be a good point. > > A crazy idea come up me like opaque-lsa for advertise beyond = advertising just prefix, and > a flavor of bgp community to import/export to manage connectivity = among routing > instances. >=20 > Hehe. On the plane ride back I was thinking of something like ES-IS > advertising service things to IS-IS routers, which could choose to > propagate them. >=20 > Of course, I also though to redo IS-IS without OSI numbering and just > use link-local addresses...somehow. >=20 > =3D) > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Aug 1 10:23:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9224111E8113 for ; Mon, 1 Aug 2011 10:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.991 X-Spam-Level: X-Spam-Status: No, score=-102.991 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjujuEcz7vqJ for ; Mon, 1 Aug 2011 10:23:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6833711E80AB for ; Mon, 1 Aug 2011 10:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1597; q=dns/txt; s=iport; t=1312219422; x=1313429022; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=rDiV5mZzR7Nwyb/2N4jKgcrpr88ErhmMnFVbi/QQuAw=; b=eGirqNLhuDPupi+iFtbiJ+Ce+p+OduwJjjLCN+BLUZk/+H8RnJoFjJ/D /gnjaa9JEvvOREms8Li7Da0adM3a94FOfdeqCB39mOOh8zmgLTx6EBkVC RzxzBLOj/WQ66XIQcUhVEVSGD6lllDMk+aDLm70l0bad5Ie7DYCpe+KwG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANjgNk6rRDoJ/2dsb2JhbABBDqdTd4FAAQEBAQIBEgEnPwULCw44VwY1h0qhSQGeWYVjXwSHWoshhQeLJlc X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8507171" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2011 17:23:41 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71HNdFk004331; Mon, 1 Aug 2011 17:23:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 01 Aug 2011 10:23:41 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 01 Aug 2011 10:23:41 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 1 Aug 2011 10:23:30 -0700 Message-Id: <9391F701-8004-4F71-9189-531B40906401@cisco.com> References: <201107281656.p6SGu6a9009346@givry.fdupont.fr> <18B15EF7-5F22-4E8F-AFD4-737A67E03B51@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , ops-ads@tools.ietf.org Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:23:38 -0000 On Jul 28, 2011, at 11:56 AM, Tim Chown wrote: > It would be good to get some prioritisation on which drafts are the = highest value to work on, if there's 4 WG drafts and about 35 personal = drafts that are current (published/updated in 2011). I'm not sure what you're asking about. Do you mean "in the tools page" = or somewhere else? Personally, and in my planning of meetings for the working group, for = one IETF I don't look at individual submissions older than the previous = one unless we have done something definitive with them. I don't put = older drafts on the agenda, and frankly tend to assume that the author = has lost interest in them. I also, as you know, tell the authors that's = how I'm acting, and invite them to update their drafts. "Determining the value to the working group" is, BTW, why I have my bot = send an email to the list when a new -00 draft is posted inviting = discussion. When I send those, I am *hoping* that the author will = respond with "this is the discussion I want to have", that someone will = review the draft, and that if people find them interesting/useful they = will say so. Silence, especially from the author, speaks volumes to me = as chair. Yes, in this meeting, we had 40 drafts in the directory and = over 30 that were current, but my initial take from list discussion was = that there were 20 that the operators found valuable to talk about. When = we were able to get a third slot, we added several more drafts and = rearranged the agenda to use it, and I think the Friday discussion was = valuable.=20= From hagen@jauu.net Mon Aug 1 10:55:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1911E8077 for ; Mon, 1 Aug 2011 10:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkITmcM9b5K4 for ; Mon, 1 Aug 2011 10:55:48 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBDF11E810D for ; Mon, 1 Aug 2011 10:55:48 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id E3317F4413A; Mon, 1 Aug 2011 19:55:52 +0200 (CEST) Date: Mon, 1 Aug 2011 19:55:52 +0200 From: Hagen Paul Pfeifer To: George Michaelson Message-ID: <20110801175551.GA2732@nuttenaction> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:55:49 -0000 * George Michaelson | 2011-08-01 11:20:02 [+1000]: >www.apnic.net: 29.668/ 30.224/ 30.511/ 0.305 ms 27.484/ 33.900/ 55.400/ 9.697 ms >www.ripe.net: 384.082/427.672/474.278/32.085 ms 345.837/379.814/450.711/37.940 ms >ipv6actnow.org: 371.395/409.083/457.154/29.726 ms 346.257/384.443/434.757/30.477 ms > >I think that from a difference/variance point of view, all three sites were >rationally 'better' on IPv4 > >So, in that sense "it worked". -The selection alg as encoded in Lion, is >doing a reasonable job. To quote Josh Graessley from Apples IPv6 ML http://web.archiveorange.com/archive/v/Wh4rykklKYyRDNa0EJWU#70wFtRVnk32QeQ4: There are some significant changes in Lion. Results from getaddrinfo are now sorted using routing statistics (destination with the lowest min round trip time wins). If the statistics can not determine which destination is better, an implementation of RFC3484 is used. The default RFC3484 policy is read only. CF and NS layer frameworks that use CFSocketStream do not use getaddrinfo. Those APIs use something similar to happy eyeballs. The A and AAAA queries are started at the same time but the responses are handled as they are received. When an answer is received, it is sorted in to a list of destination addresses. If there are no more addresses coming in (this was the last answer in the DNS packet or mDNSResponder has no more answers in the cache), a connection is started to the first destination on the sorted list. The DNS resolve operation is left running and more answers are processed as they arrive. A timer is setup for a period of time in which we would expect the connection to complete, based on the routing statistics. If the timer fires before the connection is established, a connection to the next best address will be started while the existing connection continues to try and make progress. A similar timer is setup and the process repeats until a connection is established or we run out of addresses to try. The code keeps track of whether or not it has received both A and AAAA response (whether the answer was a list of addresses or no address). If the connection is established before both A and AAAA responses come back, the resolve is kept open for up to a second to allow mDNSResponder to receive a slow response and store it in the cache. This way, subsequent connections to the same host in a short period of time will have all answers in the cache. Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice. You can use the command line tool "nettop -n -m route" to dump a live view of the routing statistics. You can use "nettop -n" to dump a live view of all TCP and UDP sockets on the system. -josh Cheers, Hagen -- Hagen Paul Pfeifer || http://protocollabs.com Telephone: +49 174 5455209 || Key Id: 0x98350C22 Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 From fred@cisco.com Mon Aug 1 11:05:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890E921F8C88 for ; Mon, 1 Aug 2011 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXn2Hlakta4m for ; Mon, 1 Aug 2011 11:05:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DE55E21F8C87 for ; Mon, 1 Aug 2011 11:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1740; q=dns/txt; s=iport; t=1312221915; x=1313431515; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=5H5vZ1FeGxK4Vsi225W6Dhf6a9AfMfzT23ahoT/kfPU=; b=Tv8vey7OTn+RQ7H+XBzlmerKUO4hIRsi05tosIV6aeIrGZqJtc8RWG+Y PgqmlRT2PIIlUUwcmqViwbO1iIImdjnXz/9jmgkxlCTNsUoprbRcadOAy hAuvfjPrADsxdERJc6rhCY/LDKX98KkXguOfbaZRlugcykz5xcePO+Fgd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJLpNk6rRDoI/2dsb2JhbABBp2F3gUABAQEBAgEBAQEPASc0EAsLRicwBhMUDodKBKFCAZ5YhWNfBIdaiyGFB4t9 X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8524733" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2011 18:05:14 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71I5DRO007455 for ; Mon, 1 Aug 2011 18:05:13 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 01 Aug 2011 11:05:13 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 01 Aug 2011 11:05:13 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> Date: Mon, 1 Aug 2011 11:05:04 -0700 Message-Id: <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:05:08 -0000 For the record, if you look through the set of drafts I have posted = since 1989 and the set of RFCs that have come out, you will see that I = personally entertain little expectation that a given draft that I write = will become an RFC. Sometimes they do - for me, 49 times to date. Far = more often - for me, 170 drafts (and many more versions of drafts, but = that's not what I'm talking about) resulting in about 150 = acknowledgements in other RFCs, and in many cases simply being part of = the total IETF discussion - a draft facilitates a discussion that may or = may not be headed in a direction useful to the community or of archival = importance. At this IETF, I posted two drafts in homenet that I frankly = expect to have little archival value, but facilitated a discussion in = the working group. On Jul 30, 2011, at 2:37 PM, Fred Baker wrote: > Pursuant to our discussion Tuesday, I'd be interested in working group = comment on > http://tools.ietf.org/html/draft-keranen-ipv6day-measurements > "Some Measurements on World IPv6 Day from End-User Perspective", Ari > Keranen, Jari Arkko, 11-Jul-11 >=20 > I could imagine not publishing as RFC (it has already served its = purpose), sending to the IESG as an individual submission for = informational status, or adopting as a working group item and eventually = sending as that to the IESG for informational status. Up to you guys... >=20 > What would you like to do? > - do you want to adopt it? > - separate question, do you want to publish it? > - if you want to publish it, do you have any comments? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From pch-b2B3A6689@u-1.phicoh.com Mon Aug 1 11:40:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9D411E8077 for ; Mon, 1 Aug 2011 11:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRTyF5CJItqb for ; Mon, 1 Aug 2011 11:40:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63111E8139 for ; Mon, 1 Aug 2011 11:40:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QnxPu-0001qUC; Mon, 1 Aug 2011 20:40:42 +0200 Message-Id: To: Lorenzo Colitti From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Mon, 1 Aug 2011 10:20:03 -0700 ." Date: Mon, 01 Aug 2011 20:40:30 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:40:42 -0000 In your letter dated Mon, 1 Aug 2011 10:20:03 -0700 you wrote: >What if the ISP only hands out a /64 (like mine does)? Disable the firewall? In that case you would be out of luck. No way to do any kind of subnetting within the standard and no firewall as well :-) But seriously. Inventing a firewall control option for DHCP is not that hard from a protocol point of view. From a security point of view, automatic firewall control from the WAN side is of course a very serious issue. It doesn't matter how do it. If it is done using an IGP, then can you bet that either some ISP happens to be using that IGP on WAN links, or that some script kiddies will try to see what happens if you try to send those packets to random CPEs. From lorenzo@google.com Mon Aug 1 11:48:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB18421F8CDD for ; Mon, 1 Aug 2011 11:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.907 X-Spam-Level: X-Spam-Status: No, score=-105.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw2UHE8iGHyW for ; Mon, 1 Aug 2011 11:48:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3B221F8CDC for ; Mon, 1 Aug 2011 11:48:01 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p71Im7mO024425 for ; Mon, 1 Aug 2011 11:48:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312224488; bh=JSWbOJqPYPBIit1EsYVURMc2QXU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dgMoIPpCLJmyJzQ15VCU+6rfHicbHPyBUNAGNsGr9aSiMc+iw+oGt5yWTJHiWmogm tJLHv02IGiZ1EQMekzNZA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=xRR82Qy4eJNJ1ZpPfBzQzqJ8DbOwMjOTjmbNgYboZu55tvBFlkrFFYXyGZWDhHoNm JSzIsz5x5R0YTElNarelg== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by wpaz17.hot.corp.google.com with ESMTP id p71Ilfxp001954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 11:48:06 -0700 Received: by yxl11 with SMTP id 11so4836503yxl.35 for ; Mon, 01 Aug 2011 11:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IofNFPsvsPC/vl+e6QYGOGpRH24vkoNpiV6zdQhWVKE=; b=FBQsrTm8CXVt6MZX9bYvck6LK+xxmZ3Vppo0Nsj1hLwoYrUkShl92zNH2U2tAAg94J GFxpax0z/FUl4v1I2utA== Received: by 10.150.62.6 with SMTP id k6mr1095409yba.114.1312224486159; Mon, 01 Aug 2011 11:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Mon, 1 Aug 2011 11:47:46 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 1 Aug 2011 14:47:46 -0400 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=000e0cd47baa5cf3fd04a976125a X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:48:03 -0000 --000e0cd47baa5cf3fd04a976125a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 1, 2011 at 14:40, Philip Homburg wrote: > It doesn't matter how do it. If it is done using an IGP, then can you bet > that > either some ISP happens to be using that IGP on WAN links, or that some > script > kiddies will try to see what happens if you try to send those packets to > random CPEs. > IGPs support authentication. As part of setting up your home network, you could associate CPEs with each other and use that to form a common auth key. --000e0cd47baa5cf3fd04a976125a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 1, 2011 at 14:40, Philip Homburg <pch-v6ops-= 2@u-1.phicoh.com> wrote:
It doesn't matter how do it. If it is done using an I= GP, then can you bet that
either some ISP happens to be using that IGP on WAN links, or that some scr= ipt
kiddies will try to see what happens if you try to send those packets to random CPEs.

IGPs support authenticatio= n. As part of setting up your home network, you could associate CPEs with e= ach other and use that to form a common auth key.

--000e0cd47baa5cf3fd04a976125a-- From iesg-secretary@ietf.org Mon Aug 1 12:03:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9016D21F8DDA; Mon, 1 Aug 2011 12:03:03 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS763Xe53LZy; Mon, 1 Aug 2011 12:03:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7231721F8D48; Mon, 1 Aug 2011 12:03:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2011 12:03:01 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:03:03 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 in 3GPP Evolved Packet System' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ No IPR declarations have been submitted directly on this I-D. From shane@castlepoint.net Mon Aug 1 21:39:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1398121F8B62 for ; Mon, 1 Aug 2011 21:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2ZWLjesuJMa for ; Mon, 1 Aug 2011 21:39:57 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6921F8B5F for ; Mon, 1 Aug 2011 21:39:57 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E2BE0268037; Mon, 1 Aug 2011 22:40:03 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Aug 2011 22:40:03 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=53637; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--1054661122 From: Shane Amante In-Reply-To: Date: Mon, 1 Aug 2011 22:39:47 -0600 Message-Id: <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 04:39:58 -0000 --Apple-Mail-23--1054661122 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2011, at 12:47 PM, Lorenzo Colitti wrote: > On Mon, Aug 1, 2011 at 14:40, Philip Homburg = wrote: > It doesn't matter how do it. If it is done using an IGP, then can you = bet that > either some ISP happens to be using that IGP on WAN links, or that = some script > kiddies will try to see what happens if you try to send those packets = to > random CPEs. >=20 > IGPs support authentication. As part of setting up your home network, = you could associate CPEs with each other and use that to form a common = auth key. And, likewise, any ISP worth their salt should be: a) using authentication *within* their access and Backbone network; and, b) using ACL's to protect their routing & signaling protocols ... so there's absolutely no legitimate reason that a customer's network = should ever "accidentally" be joined to the SP's IGP ... -shane= --Apple-Mail-23--1054661122 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Aug 1, 2011, at 12:47 PM, Lorenzo Colitti wrote:

On Mon, Aug 1, 2011 at 14:40, Philip Homburg <pch-v6ops-2@u-1.phicoh.com> wrote:
It doesn't matter how do it. If it is done using an IGP, then can you bet that
either some ISP happens to be using that IGP on WAN links, or that some script
kiddies will try to see what happens if you try to send those packets to
random CPEs.

IGPs support authentication. As part of setting up your home network, you could associate CPEs with each other and use that to form a common auth key.

And, likewise, any ISP worth their salt should be:
a) using authentication *within* their access and Backbone network; and,
b) using ACL's to protect their routing & signaling protocols
... so there's absolutely no legitimate reason that a customer's network should ever "accidentally" be joined to the SP's IGP ...

-shane
--Apple-Mail-23--1054661122-- From newbery@gmail.com Mon Aug 1 22:47:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA2D11E8089 for ; Mon, 1 Aug 2011 22:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP13YyVmDRJe for ; Mon, 1 Aug 2011 22:47:12 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4411E8075 for ; Mon, 1 Aug 2011 22:47:12 -0700 (PDT) Received: by pzk6 with SMTP id 6so11884798pzk.26 for ; Mon, 01 Aug 2011 22:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=HlqajKHLxpf2APye3IFLrXo14RRTXgxKNQaWT84l1AM=; b=af2+Rgvr0okOP2qcPrMG2XPwbvvWaMoMy87VTdV44c6OFdPM7OowBpGakw7iPzzvXx VWYIwzoAjHPYNHSm0uyoNebMzpGXzHMIZ/m6QME1Orp+Rl2cLtfRbqDTP8J8FXemUtyN NT2nuSd31eUOIsV4Yyh8EFX1PJUcFkqi3HKbM= Received: by 10.68.14.1 with SMTP id l1mr1221550pbc.448.1312264039266; Mon, 01 Aug 2011 22:47:19 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id v1sm6366660pbg.79.2011.08.01.22.47.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 22:47:18 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-5--1050616113; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 2 Aug 2011 17:47:07 +1200 In-Reply-To: <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> To: "v6ops@ietf.org WG" References: <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> Message-Id: <3F938CF4-39ED-43B6-A6F4-32E8F527CDE5@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:47:13 -0000 --Apple-Mail-5--1050616113 Content-Type: multipart/alternative; boundary=Apple-Mail-4--1050621207 --Apple-Mail-4--1050621207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2/08/2011, at 4:39 PM, Shane Amante wrote: >=20 > On Aug 1, 2011, at 12:47 PM, Lorenzo Colitti wrote: >=20 >> On Mon, Aug 1, 2011 at 14:40, Philip Homburg = wrote: >> It doesn't matter how do it. If it is done using an IGP, then can you = bet that >> either some ISP happens to be using that IGP on WAN links, or that = some script >> kiddies will try to see what happens if you try to send those packets = to >> random CPEs. >>=20 >> IGPs support authentication. As part of setting up your home network, = you could associate CPEs with each other and use that to form a common = auth key. >=20 > And, likewise, any ISP worth their salt should be: > a) using authentication *within* their access and Backbone network; = and, > b) using ACL's to protect their routing & signaling protocols > ... so there's absolutely no legitimate reason that a customer's = network should ever "accidentally" be joined to the SP's IGP ... It's outside the CPE spec, but I can see that the document could state, = as an assumption, that the ISP will filter routing advertisements from = the CPE and will only pass those that it has determined (via some = external mechanism, undefined in this document) belong to the CPE. This document should state that the CPE should not advertise any invalid = routes (default, link-local, etc.) but that in any case the ISP will = drop any invalid routes. Is there/does there need to be a RFC that can = be referenced here that says what the ISP can or may do with routing = information from CPE? I would assume that if you are injecting general routing information = into your network then: 1. You are using BGP to do it 2. a CPE RFC is completely irrelevant --Apple-Mail-4--1050621207 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 1, 2011, = at 12:47 PM, Lorenzo Colitti wrote:

On Mon, Aug 1, 2011 at 14:40, Philip Homburg <pch-v6ops-2@u-1.phicoh.com&= gt; wrote:
It doesn't matter how do it. If it is done using an = IGP, then can you bet that
either some ISP happens to be using that IGP on WAN links, or that some = script
kiddies will try to see what happens if you try to send those packets = to
random CPEs.

IGPs support = authentication. As part of setting up your home network, you could = associate CPEs with each other and use that to form a common auth = key.

And, likewise, any ISP worth = their salt should be:
a) using authentication *within* their = access and Backbone network; and,
b) using ACL's to protect = their routing & signaling protocols
... so there's = absolutely no legitimate reason that a customer's network should ever = "accidentally" be joined to the SP's IGP = ...

It's outside the CPE spec, = but I can see that the document could state, as an assumption, that the = ISP will filter routing advertisements from the CPE and will only pass = those that it has determined (via some external mechanism, undefined in = this document) belong to the CPE.

This document = should state that the CPE should not advertise any invalid routes = (default, link-local, etc.) but that in any case the ISP will drop any = invalid routes. Is there/does there need to be a RFC that can be = referenced here that says what the ISP can or may do with routing = information from CPE?

I would assume that if = you are injecting general routing information into your network = then:
1. You are using BGP to do it
2. a CPE RFC is = completely irrelevant

= --Apple-Mail-4--1050621207-- --Apple-Mail-5--1050616113 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwODAyMDU0NzEz WjAjBgkqhkiG9w0BCQQxFgQUuhGetvGA/a5c5OGxpFHu/D3AXnAwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBACV8Veba21V8LsNNdKi56PAqIfOahUsI4WGsv1ffwlhbwS1e4sBOiR2W6psQ BeGtQZDqtmHAL2MXHpqiAKPmOq49IFZ6s3dQUGgW8emc1zblirahAs1UbDWIlCHZYhtrnmFLWt/L mebg5810FUJ0RLGozY8IznlRfiN2ZomNZzjJdnQ91sCtTnqCHjbsCYIDD6OdOuQDzte3gaQcxZPl b8SD6xPpN/FICnnV030DSt9k4ZK6PzSu8qpBiPBDGE0QfVyDRuWCPJS6qXEviUZd0Mkwstk80Rl0 wuNm7LrFO7Y59Sc7/GjJ1o4LYRQWexI7oHTMttE/zQFYN31cdX63t9AAAAAAAAA= --Apple-Mail-5--1050616113-- From v6ops@globis.net Tue Aug 2 00:48:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A6B21F8BC5 for ; Tue, 2 Aug 2011 00:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgCdOJJvOxJY for ; Tue, 2 Aug 2011 00:48:06 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62E0D21F85DE for ; Tue, 2 Aug 2011 00:47:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0944B8700D9; Tue, 2 Aug 2011 09:47:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEvBenrFRZ8K; Tue, 2 Aug 2011 09:47:32 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C27D28700AB; Tue, 2 Aug 2011 09:47:31 +0200 (CEST) Message-ID: <4E37AB93.3000005@globis.net> Date: Tue, 02 Aug 2011 09:47:31 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Lorenzo Colitti Content-Type: multipart/alternative; boundary="------------090307060201060901020607" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 07:48:07 -0000 This is a multi-part message in MIME format. --------------090307060201060901020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] default LAN routing protocol for IPv6 CE router > From: > Lorenzo Colitti > Date: > Mon, 1 Aug 2011 14:47:46 -0400 > > To: > Philip Homburg > CC: > "v6ops@ietf.org" > > Precedence: > list > MIME-Version: > 1.0 > References: > > > > > > > In-Reply-To: > > Message-ID: > > Content-Type: > multipart/alternative; boundary=000e0cd47baa5cf3fd04a976125a > Message: > 3 > > > On Mon, Aug 1, 2011 at 14:40, Philip Homburg > > wrote: > > It doesn't matter how do it. If it is done using an IGP, then can > you bet that > either some ISP happens to be using that IGP on WAN links, or that > some script > kiddies will try to see what happens if you try to send those > packets to > random CPEs. > > > IGPs support authentication. As part of setting up your home network, > you could associate CPEs with each other and use that to form a common > auth key. It isn't the mechanics or technology of the protocols that's the issue: it's the trust relationship, the service boundary, and the cost of operational support. The home network and the ISP network are 2 different management domains. If the ISP wants to control a firewall or other equipment on a user's premises then they probably need to provide and own the firewall or CPE. Vice versa for the end user. The mix of a user owned firewall with an ISP provided configuration (even if that's just enable/disable function) just won't work practically in operations. And that's even before the lawyers get involved. It's not an issue that the IETF should attempt to solve/ automate using protocols IMVHO. I don't see why a simple guest or DMZ network would require a VRF-Lite type solution to separate routing tables either, as long as a stateful firewall on the home network ensures logical separation of the two prefixes. As for only delegating a single /64 to home users i) I would hope ISP's are more sympathetic to home users who have genuine needs for a DMZ, guest LAN etc. now that NAT won't provide a solution for this requirement ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even if SLAAC doesn't yet) regards, RayH --------------090307060201060901020607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] default LAN routing protocol for IPv6 CE router
From:
Lorenzo Colitti <lorenzo@google.com>
Date:
Mon, 1 Aug 2011 14:47:46 -0400
To:
Philip Homburg <pch-v6ops-2@u-1.phicoh.com>
CC:
"v6ops@ietf.org" <v6ops@ietf.org>
Precedence:
list
MIME-Version:
1.0
References:
<BF7B0192-EDC9-4A87-BCE3-6ED2F676FFDB@employees.org> <CA5ADFBF.156F7C%john_brzozowski@cable.comcast.com> <CAKD1Yr09v1o79Kihxtzh1XZfARA2=K1TsZDKkKozPTg69n5S-A@mail.gmail.com> <m1Qnvb4-0001isC@stereo.hq.phicoh.net> <CAKD1Yr1Q=v897LvtS4VBo_-WxBEOvccD91DPYSpX6m+nzrztzA@mail.gmail.com> <m1QnxPu-0001qUC@stereo.hq.phicoh.net>
In-Reply-To:
<m1QnxPu-0001qUC@stereo.hq.phicoh.net>
Message-ID:
<CAKD1Yr1oi4qN5aps0WXgq5hcBgyGVKUtkMPTUrrdOwkHwcFTiA@mail.gmail.com>
Content-Type:
multipart/alternative; boundary=000e0cd47baa5cf3fd04a976125a
Message:
3

On Mon, Aug 1, 2011 at 14:40, Philip Homburg <pch-v6ops-2@u-1.phicoh.com> wrote:
It doesn't matter how do it. If it is done using an IGP, then can you bet that
either some ISP happens to be using that IGP on WAN links, or that some script
kiddies will try to see what happens if you try to send those packets to
random CPEs.

IGPs support authentication. As part of setting up your home network, you could associate CPEs with each other and use that to form a common auth key.
It isn't the mechanics or technology of the protocols that's the issue: it's the trust relationship, the service boundary, and the cost of operational support. The home network and the ISP network are 2 different management domains.

If the ISP wants to control a firewall or other equipment on a user's premises then they probably need to provide and own the firewall or CPE. Vice versa for the end user. The mix of a user owned firewall with an ISP provided configuration (even if that's just enable/disable function) just won't work practically in operations. And that's even before the lawyers get involved. It's not an issue that the IETF should attempt to solve/ automate using protocols IMVHO.

I don't see why a simple guest or DMZ network would require a VRF-Lite type solution to separate routing tables either, as long as a stateful firewall on the home network ensures logical separation of the two prefixes.

As for only delegating a single /64 to home users
i) I would hope ISP's are more sympathetic to home users who have genuine needs for a DMZ, guest LAN etc. now that NAT won't provide a solution for this requirement
ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even if SLAAC doesn't yet)

regards,
RayH
--------------090307060201060901020607-- From pch-b2B3A6689@u-1.phicoh.com Tue Aug 2 01:17:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D5A21F85F2 for ; Tue, 2 Aug 2011 01:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uk2mZZRK-UE for ; Tue, 2 Aug 2011 01:17:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0800321F85E3 for ; Tue, 2 Aug 2011 01:17:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoA8T-0001r3C; Tue, 2 Aug 2011 10:15:33 +0200 Message-Id: To: Shane Amante From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> In-reply-to: Your message of "Mon, 1 Aug 2011 22:39:47 -0600 ." <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> Date: Tue, 02 Aug 2011 10:15:18 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:17:37 -0000 In your letter dated Mon, 1 Aug 2011 22:39:47 -0600 you wrote: >And, likewise, any ISP worth their salt should be: >a) using authentication *within* their access and Backbone network; and, >b) using ACL's to protect their routing & signaling protocols >... so there's absolutely no legitimate reason that a customer's network = >should ever "accidentally" be joined to the SP's IGP ... A firewall is a security feature. So, it doesn't matter that much what a responsible ISP does to protect its own networks. What matters is whether any ISP will accidentally do something that would disable its customers' firewalls. Or, whether any ISP will come up with a network configuration that allows customers to disable each others firewalls. From pch-b2B3A6689@u-1.phicoh.com Tue Aug 2 01:22:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4E21F89C2 for ; Tue, 2 Aug 2011 01:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN4hvZ3d7G86 for ; Tue, 2 Aug 2011 01:22:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C21C021F886D for ; Tue, 2 Aug 2011 01:22:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoAEw-0001hwC; Tue, 2 Aug 2011 10:22:14 +0200 Message-Id: To: Ray Hunter From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Tue, 02 Aug 2011 09:47:31 +0200 ." <4E37AB93.3000005@globis.net> Date: Tue, 02 Aug 2011 10:22:07 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:22:19 -0000 In your letter dated Tue, 02 Aug 2011 09:47:31 +0200 you wrote: >If the ISP wants to control a firewall or other equipment on a user's >premises then they probably need to provide and own the firewall or CPE. >Vice versa for the end user. The mix of a user owned firewall with an >ISP provided configuration (even if that's just enable/disable function) >just won't work practically in operations. And that's even before the >lawyers get involved. It's not an issue that the IETF should attempt to >solve/ automate using protocols IMVHO. I don't think it is matter of an ISP wanting to control the user's firewall. Suppose you have a generic home router, just a bunch of ethernet ports and some proessing in a small box. If the home router is attached to a WAN link, then it has to enable its firewall to separate the WAN link from the internal links. If the router is used internal to the user's network then it should not enable its firewall, unless one of the ports is connected to the guest network but then it should have a firewall tailered to guest networks. How do you construct a router such that the router always knows what it has to do, or at least is in some sense fail-safe? From v6ops@globis.net Tue Aug 2 03:12:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD821F8DD2 for ; Tue, 2 Aug 2011 03:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=1.097, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aazxJwIaom-I for ; Tue, 2 Aug 2011 03:12:11 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 057E421F8DD1 for ; Tue, 2 Aug 2011 03:12:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9508C8700DE; Tue, 2 Aug 2011 12:12:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhsru+LZsjzi; Tue, 2 Aug 2011 12:12:12 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 49EB8870021; Tue, 2 Aug 2011 12:12:12 +0200 (CEST) Message-ID: <4E37CD7C.8000403@globis.net> Date: Tue, 02 Aug 2011 12:12:12 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Philip Homburg References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000504020900080805040902" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 10:12:13 -0000 This is a multi-part message in MIME format. --------------000504020900080805040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the earlier suggestion of Lee Howard to capture requirements for a home network first is a very good one. In the current discussion, I don't think it's fully defined yet who operates your "generic home router" and under what conditions: whether the home router is one operated by the user onto a shared bridged IPv6 access network, or whether the home router spec will be used by an ISP for purchasing and operating the home router, and which then also has to take into account the user's requirements for more than one local LAN in the home, or whether there are 2 home router devices (one operated by the user and one operated by the ISP), or even more home router devices that also route between IPv6 prefixes. Appropriate behaviour of an interface will depend very much on the management and deployment scenario. In IPv4 + NAT that was pretty much irrelevant. The outbound path and address could be learned by acting as a DHCPv4 client and the reverse path was "learned" via NAT. And each cascaded device could in turn act as a DHCPv4 server for its downstream neighbors. A simple "outbound only" firewall rarely did harm either. So simple cascading pretty much always worked without any configuration at all. What if a user stacks multiple home routers in IPv6? Do you assume / enforce a tree structure for a home network? Do you assume / enforce a single-homed ISP model? I know cascaded PD has been discussed many times in the past, but is there an RFC for how it should operate in practice? RFC5877 says "Renumbering Still Needs Work" So back to requirements, I think a list might conceivably consist of: 1) a home router should automatically discover its neighbors on a per port basis. 2) a home router should able to automatically detect whether each neighbor is in the same management domain or not 3) a home router should control peering in a secure manner 4) a home router should automatically learn prefixes and interface addresses (NB PD is only defined in rfc3769 to be to a single router attached to an ISP link, and sub-delegations within the site are NOT communicated back to the ISP) 5) Depending on its peering, a home router should determine it's position in the network relative to the CPE PD router (the root of the prefix delegation / home network assuming a tree structure). 6) Depending on it's position in the home network, a home router should automatically determine what functions it needs to enable per port (firewall, learning a delegated prefix, delegating further prefixes, management access allowed .... ) Most current IGP's would fulfill many of those requirements, but probably not all. The main problem is I don't think the above list is anywhere near definitive or widely accepted. So saying one protocol or mechanism is "better" than another is then a bit premature IMHO. regards, RayH Philip Homburg wrote: > In your letter dated Tue, 02 Aug 2011 09:47:31 +0200 you wrote: > >> If the ISP wants to control a firewall or other equipment on a user's >> premises then they probably need to provide and own the firewall or CPE. >> Vice versa for the end user. The mix of a user owned firewall with an >> ISP provided configuration (even if that's just enable/disable function) >> just won't work practically in operations. And that's even before the >> lawyers get involved. It's not an issue that the IETF should attempt to >> solve/ automate using protocols IMVHO. >> > > I don't think it is matter of an ISP wanting to control the user's firewall. > > Suppose you have a generic home router, just a bunch of ethernet ports and > some proessing in a small box. > > If the home router is attached to a WAN link, then it has to enable its > firewall to separate the WAN link from the internal links. > > If the router is used internal to the user's network then it should not > enable its firewall, unless one of the ports is connected to the guest network > but then it should have a firewall tailered to guest networks. > > How do you construct a router such that the router always knows what it > has to do, or at least is in some sense fail-safe? > > > --------------000504020900080805040902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the earlier suggestion of Lee Howard to capture requirements for a home network first is a very good one.

In the current discussion, I don't think it's fully defined yet who operates your "generic home router" and under what conditions: whether the home router is one operated by the user onto a shared bridged IPv6 access network, or whether the home router spec will be used by an ISP for purchasing and operating the home router, and which then also has to take into account the user's requirements for more than one local LAN in the home, or whether there are 2 home router devices (one operated by the user and one operated by the ISP), or even more home router devices that also route between IPv6 prefixes.

Appropriate behaviour of an interface will depend very much on the management and deployment scenario.

In IPv4 + NAT that was pretty much irrelevant. The outbound path and address could be learned by acting as a DHCPv4 client and the reverse path was "learned" via NAT. And each cascaded device could in turn act as a DHCPv4 server for its downstream neighbors. A simple "outbound only" firewall rarely did harm either. So simple cascading pretty much always worked without any configuration at all.

What if a user stacks multiple home routers in IPv6?
Do you assume / enforce a tree structure for a home network?
Do you assume / enforce a single-homed ISP model?

I know cascaded PD has been discussed many times in the past, but is there an RFC for how it should operate in practice?
RFC5877 says "Renumbering Still Needs Work"

So back to requirements, I think a list might conceivably consist of:
1) a home router should automatically discover its neighbors on a per port basis.
2) a home router should able to automatically detect whether each neighbor is in the same management domain or not
3) a home router should control peering in a secure manner
4) a home router should automatically learn prefixes and interface addresses (NB PD is only defined in rfc3769 to be to a single router attached to an ISP link, and sub-delegations within the site are NOT communicated back to the ISP)
5) Depending on its peering, a home router should determine it's position in the network relative to the CPE PD router (the root of the prefix delegation / home network assuming a tree structure).
6) Depending on it's position in the home network, a home router should automatically determine what functions it needs to enable per port (firewall, learning a delegated prefix, delegating further prefixes, management access allowed .... )

Most current IGP's would fulfill many of those requirements, but probably not all. The main problem is I don't think the above list is anywhere near definitive or widely accepted. So saying one protocol or mechanism is "better" than another is then a bit premature IMHO.

regards,
RayH

Philip Homburg wrote: 
In your letter dated Tue, 02 Aug 2011 09:47:31 +0200 you wrote:
  
If the ISP wants to control a firewall or other equipment on a user's 
premises then they probably need to provide and own the firewall or CPE. 
Vice versa for the end user. The mix of a user owned firewall with an 
ISP provided configuration (even if that's just enable/disable function) 
just won't work practically in operations. And that's even before the 
lawyers get involved. It's not an issue that the IETF should attempt to 
solve/ automate using protocols IMVHO.
    

I don't think it is matter of an ISP wanting to control the user's firewall.

Suppose you have a generic home router, just a bunch of ethernet ports and
some proessing in a small box.

If the home router is attached to a WAN link, then it has to enable its 
firewall to separate the WAN link from the internal links.

If the router is used internal to the user's network then it should not 
enable its firewall, unless one of the ports is connected to the guest network
but then it should have a firewall tailered to guest networks.

How do you construct a router such that the router always knows what it
has to do, or at least is in some sense fail-safe?

--------------000504020900080805040902-- From jason.weil@twcable.com Tue Aug 2 04:39:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166D21F8DD5; Tue, 2 Aug 2011 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=1.444, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRKUgv5-RsQh; Tue, 2 Aug 2011 04:39:09 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id AA60121F8DD1; Tue, 2 Aug 2011 04:39:08 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,306,1309752000"; d="scan'208";a="242689659" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Aug 2011 07:36:46 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 2 Aug 2011 07:39:17 -0400 From: "Weil, Jason" To: Ray Hunter , Philip Homburg , "homenet@ietf.org" Date: Tue, 2 Aug 2011 07:39:15 -0400 Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxRCM+EqZcKs4krQfiVXmQz5shxJQ== Message-ID: In-Reply-To: <4E37CD7C.8000403@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:39:10 -0000 Ray, I also agree that requirements and use cases seem the next logical step. I'= d be willing to document the ones that we are contemplating. It would be us= eful to have someone more familiar with DSL/Fiber residential deployments d= o so there as well. As has already been mentioned, this is a great conversation but it really b= elongs on the Homenet list at this point (copying that list in case people = are not following both). Jason From: Ray Hunter > Date: Tue, 2 Aug 2011 06:12:12 -0400 To: Philip Homburg > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router I think the earlier suggestion of Lee Howard to capture requirements for a = home network first is a very good one. In the current discussion, I don't think it's fully defined yet who operate= s your "generic home router" and under what conditions: whether the home ro= uter is one operated by the user onto a shared bridged IPv6 access network,= or whether the home router spec will be used by an ISP for purchasing and = operating the home router, and which then also has to take into account the= user's requirements for more than one local LAN in the home, or whether th= ere are 2 home router devices (one operated by the user and one operated by= the ISP), or even more home router devices that also route between IPv6 pr= efixes. Appropriate behaviour of an interface will depend very much on the manageme= nt and deployment scenario. In IPv4 + NAT that was pretty much irrelevant. The outbound path and addres= s could be learned by acting as a DHCPv4 client and the reverse path was "l= earned" via NAT. And each cascaded device could in turn act as a DHCPv4 ser= ver for its downstream neighbors. A simple "outbound only" firewall rarely = did harm either. So simple cascading pretty much always worked without any = configuration at all. What if a user stacks multiple home routers in IPv6? Do you assume / enforce a tree structure for a home network? Do you assume / enforce a single-homed ISP model? I know cascaded PD has been discussed many times in the past, but is there = an RFC for how it should operate in practice? RFC5877 says "Renumbering Still Needs Work" So back to requirements, I think a list might conceivably consist of: 1) a home router should automatically discover its neighbors on a per port = basis. 2) a home router should able to automatically detect whether each neighbor = is in the same management domain or not 3) a home router should control peering in a secure manner 4) a home router should automatically learn prefixes and interface addresse= s (NB PD is only defined in rfc3769 to be to a single router attached to an= ISP link, and sub-delegations within the site are NOT communicated back to= the ISP) 5) Depending on its peering, a home router should determine it's position i= n the network relative to the CPE PD router (the root of the prefix delegat= ion / home network assuming a tree structure). 6) Depending on it's position in the home network, a home router should aut= omatically determine what functions it needs to enable per port (firewall, = learning a delegated prefix, delegating further prefixes, management access= allowed .... ) Most current IGP's would fulfill many of those requirements, but probably n= ot all. The main problem is I don't think the above list is anywhere near d= efinitive or widely accepted. So saying one protocol or mechanism is "bette= r" than another is then a bit premature IMHO. regards, RayH Philip Homburg wrote: In your letter dated Tue, 02 Aug 2011 09:47:31 +0200 you wrote: If the ISP wants to control a firewall or other equipment on a user's premises then they probably need to provide and own the firewall or CPE. Vice versa for the end user. The mix of a user owned firewall with an ISP provided configuration (even if that's just enable/disable function) just won't work practically in operations. And that's even before the lawyers get involved. It's not an issue that the IETF should attempt to solve/ automate using protocols IMVHO. I don't think it is matter of an ISP wanting to control the user's firewall= . Suppose you have a generic home router, just a bunch of ethernet ports and some proessing in a small box. If the home router is attached to a WAN link, then it has to enable its firewall to separate the WAN link from the internal links. If the router is used internal to the user's network then it should not enable its firewall, unless one of the ports is connected to the guest netw= ork but then it should have a firewall tailered to guest networks. How do you construct a router such that the router always knows what it has to do, or at least is in some sense fail-safe? ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Ray.Bellis@nominet.org.uk Tue Aug 2 04:53:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507A021F8C14; Tue, 2 Aug 2011 04:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.312 X-Spam-Level: X-Spam-Status: No, score=-7.312 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGeE9+3hIZgq; Tue, 2 Aug 2011 04:53:21 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91C21F8C16; Tue, 2 Aug 2011 04:53:20 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=XTGnEYlHsgwZc8cTG4l5BIBA2Osl7OgQ6c4lh1iG4/M5/jBXYzlA49O/ gSfgRmZluCtpmclcwGfdV4YiGe/3tiLE/kvTPNQyF5coE62lAbOke4tz1 5J6m0yl4eXbOX9+; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1312286010; x=1343822010; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20[v6ops]=20default=20LAN=20r outing=20protocol=20for=20IPv6=20CE=0D=0A=09router|Date: =20Tue,=202=20Aug=202011=2011:53:28=20+0000|Message-ID: =20 |To:=20"Weil,=20Jason"=20|CC:=20" homenet@ietf.org"=20,=20"v6ops@ietf.org "=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<61e3a55e-9dfb-4136-89a4-e07747b6efc2> |In-Reply-To:=20 |References:=20; bh=7fV9ZwG/tnbTikjtw0kZv5nsaJ/07jipdCikF/6R6h4=; b=xbpdb7Yr1yD1WXFdm3x43AmFq6GHSZnBLLecA32BNor66XTE/dMYH9Fp Gh1FMW1KPt8I7TxxzCUM6sLX8fQ7muslABl2wRHFxeyqS/2KkFeVO1Zvv oHgZCNH0YPYYA6S; X-IronPort-AV: E=Sophos;i="4.67,306,1309734000"; d="scan'208";a="34501688" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 02 Aug 2011 12:53:29 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 2 Aug 2011 12:53:28 +0100 From: Ray Bellis To: "Weil, Jason" Thread-Topic: [homenet] [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxRCM+EqZcKs4krQfiVXmQz5shxJf//8zIA Date: Tue, 2 Aug 2011 11:53:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <61e3a55e-9dfb-4136-89a4-e07747b6efc2> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:53:22 -0000 On 2 Aug 2011, at 12:39, Weil, Jason wrote: > Ray, >=20 > I also agree that requirements and use cases seem the next logical step. = I'd be willing to document the ones that we are contemplating. It would be = useful to have someone more familiar with DSL/Fiber residential deployments= do so there as well. >=20 > As has already been mentioned, this is a great conversation but it really= belongs on the Homenet list at this point (copying that list in case peopl= e are not following both). Jason=20 Thanks for the cross-post. I agree that this discussion does indeed belong in Homenet, where we are sp= ecifically chartered to investigate the issues surrounding addressing and r= outing within the SOHO network. Ray Bellis Homenet WG co-chair From ietfc@btconnect.com Tue Aug 2 05:10:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BCB21F8E6D for ; Tue, 2 Aug 2011 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U50W8Gw-aQR5 for ; Tue, 2 Aug 2011 05:10:36 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9D21F8E6C for ; Tue, 2 Aug 2011 05:10:34 -0700 (PDT) Received: from pc6 (host109-153-78-164.range109-153.btcentralplus.com [109.153.78.164]) by c2beaomr10.btconnect.com (MOS 4.2.2-FCS) with SMTP id DUW56034; Tue, 2 Aug 2011 13:10:35 +0100 X-Mirapoint-IP-Reputation: reputation=Poor-1, source=Queried, refid=tid=0001.0A0B0303.4E37E93B.003C, actions=tag Message-ID: <032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> Date: Tue, 2 Aug 2011 13:07:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.2.105114:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4E37E941.01D4,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:10:36 -0000 Ari In the hope that you will take up Fred's generous offer to push this through to an RFC, I hope that you will find these comments helpful I would like to see more references, for 6to4 and for the various .pdf; I think it works better to have them all in one place. I find the X-axis of the graphs unclear; time presumably, but what time? I think that the biggest conclusion is omitted; only 2.45% of the top 10,000 sites offer IPv6 via DNS ie next to none; I think that this should be in BIG BOLD LETTERS. And while comprehension is no problem, the idiom is sometimes slightly odd. Doubtless the RFC Editor will fix it but I could point some of these out to you if you want. Tom Petch ----- Original Message ----- From: "Fred Baker" To: "t.petch" Cc: "IPv6 Operations" Sent: Monday, August 01, 2011 6:49 PM On Aug 1, 2011, at 3:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Fred Baker" > To: "IPv6 Operations" > Sent: Saturday, July 30, 2011 11:37 PM > >> Pursuant to our discussion Tuesday, I'd be interested in working group comment > on >> http://tools.ietf.org/html/draft-keranen-ipv6day-measurements >> "Some Measurements on World IPv6 Day from End-User Perspective", Ari >> Keranen, Jari Arkko, 11-Jul-11 >> >> I could imagine not publishing as RFC (it has already served its purpose), > sending to the IESG as an individual submission for informational status, or > adopting as a working group item and eventually sending as that to the IESG for > informational status. Up to you guys... > > I find that bizarre. Of course it should be published as an RFC (with a few > tweaks for grammar, ease of use and comprehension). I cannot imagine how it has > done its job; its job is to provide us with a point of reference in the current > and future discussions about IPv6, where and how much of it there is, etc. and > that can only be done as an RFC (or, less good, as its equivalent in some other > body). Well, yes, but we had several other presentations whose only record is in the proceedings. OK, I take your comment and Keith's as support for sending it in as an individual submission. > Tom Petch >> >> What would you like to do? >> - do you want to adopt it? >> - separate question, do you want to publish it? >> - if you want to publish it, do you have any comments? From dr@cluenet.de Tue Aug 2 05:25:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DC121F8D79 for ; Tue, 2 Aug 2011 05:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIIpSVOEWmOU for ; Tue, 2 Aug 2011 05:25:37 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1338921F8D74 for ; Tue, 2 Aug 2011 05:25:37 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 23F0C1080A0; Tue, 2 Aug 2011 14:25:45 +0200 (CEST) Date: Tue, 2 Aug 2011 14:25:45 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110802122545.GA12922@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:25:38 -0000 On Mon, Aug 01, 2011 at 08:29:46AM -0700, Cameron Byrne wrote: > I also find that injecting latency at the nat will be hard sell to > management and possibly difficult to instrument. It's not a hard sell at all, given that the alternative is to unnecessarily scale up the LSN setups for IPv4 traffic (which could be native, non-NATted IPv6 traffic). Looking at economics, there can be only one strategy: get as much traffic as feasible onto IPv6 as quickly as possible to avoid exploding cost of LSN infrastructure (be it NAT444, DS-Lite, or whatever else). Supporting IPv4 traffic will be much more expensive in the future than before. Keeping traffic on NATted IPv4 more than really necessary (read: acceptable delay penalty) harms us all in multiple ways. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Tue Aug 2 05:28:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336121F8788 for ; Tue, 2 Aug 2011 05:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWk6HE9kyNu2 for ; Tue, 2 Aug 2011 05:28:11 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A31FF21F856B for ; Tue, 2 Aug 2011 05:28:08 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QoE4y-00057Y-Mg; Tue, 02 Aug 2011 08:28:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 2 Aug 2011 08:28:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94027f96e9e4b0c6df6826caeb5513e444d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:28:14 -0000 On Aug 2, 2011, at 4:22 AM, Philip Homburg wrote: > How do you construct a router such that the router always knows what = it > has to do, or at least is in some sense fail-safe? The idea that a firewall should automatically know what "it has to do" = strikes me as utterly bizarre. I realize that there's a desire to = minimize the configuration burden for unsophisticated users (and agree = with that), but the idea that the firewall knows better than the user = what his security policy should be seems ridiculous. A different idea is that the firewall always work in a very minimal mode = by default (e.g. it passes no traffic, or maybe only outgoing port 80 = traffic, but its configuration interface is enabled for the internal = ports) so that the user must configure it in order to get it to do = anything useful. That way, the first thing a user learns about his = router/firewall is how to configure it. Then you want to focus on = making the configuration interface easy to understand. (You also have = to figure out how to keep the user from hooking up the internal port to = the external connection.) But these are user interface issues, not protocol issues. Perhaps = they're better addressed in homenet than here. Keith From pch-b2B3A6689@u-1.phicoh.com Tue Aug 2 05:51:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4321F8DB6 for ; Tue, 2 Aug 2011 05:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEExbVLCTFMa for ; Tue, 2 Aug 2011 05:51:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id BD4F421F8DB5 for ; Tue, 2 Aug 2011 05:51:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoES4-0001gWC; Tue, 2 Aug 2011 14:52:04 +0200 Message-Id: To: Daniel Roesen From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> In-reply-to: Your message of "Tue, 2 Aug 2011 14:25:45 +0200 ." <20110802122545.GA12922@srv03.cluenet.de> Date: Tue, 02 Aug 2011 14:51:48 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:52:00 -0000 In your letter dated Tue, 2 Aug 2011 14:25:45 +0200 you wrote: >It's not a hard sell at all, given that the alternative is to >unnecessarily scale up the LSN setups for IPv4 traffic (which could be >native, non-NATted IPv6 traffic). At least one alternative is to pressure vendors into implementing a form of HE that prefers IPv6 when the performance of IPv6 and IPv4 is roughly equal. From rajiva@cisco.com Tue Aug 2 07:09:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9DC21F8797 for ; Tue, 2 Aug 2011 07:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsxoD6KQQCxX for ; Tue, 2 Aug 2011 07:09:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4257521F86BF for ; Tue, 2 Aug 2011 07:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1657; q=dns/txt; s=iport; t=1312294181; x=1313503781; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=GHpHKAkppE0WkBV8kN8d2BGnj4lZoSHC8t9oz+OHqko=; b=cxk0Tdekr2wlcF1DVnCSSaUBaV5njT7cmQFfPr1StpQ2pFuey2PBYbNv z2CpXx5ytgyuLCuQ4CSHlsHnacGZ2SDKIfNZhCjYy09+Y3fSW/tfIsTbs fUp00LO6mL/pThqSpN9Y50lTLHHn6XMQE6/Rm8f5ddVR0038WxkqyZLPN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQHAJwEOE6tJXG//2dsb2JhbABCpndpAneBQAEBAQECAQEBAQ8BJzQLBQsCAQgYLicwAQEEEyKHSgSiIgGfDYVjXwSSe4UQh1qEFg X-IronPort-AV: E=Sophos;i="4.67,306,1309737600"; d="scan'208";a="8800335" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Aug 2011 14:08:40 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p72E8eK3001582; Tue, 2 Aug 2011 14:08:40 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 09:08:40 -0500 Received: from 144.254.231.93 ([144.254.231.93]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Aug 2011 14:08:39 +0000 References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> Content-Transfer-Encoding: quoted-printable From: "Rajiv Asati (rajiva)" Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxRHa2IhtpGKWUmS4u0gyPancBRAA== Content-Type: text/plain; charset="us-ascii" In-Reply-To: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> Message-ID: <831D5D4C-1CD7-4AFB-91D5-FD2A76657EC9@cisco.com> Date: Tue, 2 Aug 2011 10:08:32 -0400 To: "Keith Moore" MIME-Version: 1.0 (iPhone Mail 8K2) X-OriginalArrivalTime: 02 Aug 2011 14:08:40.0054 (UTC) FILETIME=[ADE92160:01CC511D] Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:09:37 -0000 +1, Keith. Auto-magic is good for basic functions, but not for advanced functions. Cheers, Rajiv Sent from Phone.... On Aug 2, 2011, at 8:28 AM, "Keith Moore" wrote= : > On Aug 2, 2011, at 4:22 AM, Philip Homburg wrote: >=20 >> How do you construct a router such that the router always knows what it >> has to do, or at least is in some sense fail-safe? >=20 > The idea that a firewall should automatically know what "it has to do" str= ikes me as utterly bizarre. I realize that there's a desire to minimize th= e configuration burden for unsophisticated users (and agree with that), but t= he idea that the firewall knows better than the user what his security polic= y should be seems ridiculous. >=20 > A different idea is that the firewall always work in a very minimal mode b= y default (e.g. it passes no traffic, or maybe only outgoing port 80 traffic= , but its configuration interface is enabled for the internal ports) so that= the user must configure it in order to get it to do anything useful. That w= ay, the first thing a user learns about his router/firewall is how to config= ure it. Then you want to focus on making the configuration interface easy t= o understand. (You also have to figure out how to keep the user from hookin= g up the internal port to the external connection.) >=20 > But these are user interface issues, not protocol issues. Perhaps they'r= e better addressed in homenet than here. >=20 > Keith >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Tue Aug 2 08:04:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F911E807E for ; Tue, 2 Aug 2011 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYp9YH016BMC for ; Tue, 2 Aug 2011 08:04:04 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id D027011E807B for ; Tue, 2 Aug 2011 08:04:03 -0700 (PDT) Received: by eya28 with SMTP id 28so6341208eya.21 for ; Tue, 02 Aug 2011 08:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oLq5EaUFFzL8cDLApGcqKSHDK1rKSO3wpe1JjrOaN8k=; b=BMY4XXzXhVroKjSmOtKBJZZLmpMkjJVOpyIrZMUQaBnn4TXSbyDbUFtUcFSrum5TnB Xgnp16NcdzSY6igN+ZP39gvjeDHEgg+RmOQwin5RZO7bGrYLXXGDn5s19SK6ssB57B3G MkuFEsaA7aiYdyabckkapvXo9gdP9XsdKYdnA= MIME-Version: 1.0 Received: by 10.216.233.95 with SMTP id o73mr681669weq.103.1312297452275; Tue, 02 Aug 2011 08:04:12 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Tue, 2 Aug 2011 08:04:12 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Tue, 2 Aug 2011 08:04:12 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> Date: Tue, 2 Aug 2011 08:04:12 -0700 Message-ID: From: Cameron Byrne To: Philip Homburg Content-Type: multipart/alternative; boundary=000e0cd4841a7b878704a9870fe4 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:04:05 -0000 --000e0cd4841a7b878704a9870fe4 Content-Type: text/plain; charset=ISO-8859-1 On Aug 2, 2011 5:52 AM, "Philip Homburg" wrote: > > In your letter dated Tue, 2 Aug 2011 14:25:45 +0200 you wrote: > >It's not a hard sell at all, given that the alternative is to > >unnecessarily scale up the LSN setups for IPv4 traffic (which could be > >native, non-NATted IPv6 traffic). > > At least one alternative is to pressure vendors into implementing a form of > HE that prefers IPv6 when the performance of IPv6 and IPv4 is roughly equal. > Hopefully they will do as you say because it is the right thing to do, as chrome and firefox have already done. Sans that, the isp can promote an appropriet HE implementation that fits everyone's need to be off the LSN. After all, LSN costs and service quality are passed on to the customer. Cb > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --000e0cd4841a7b878704a9870fe4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 2, 2011 5:52 AM, "Philip Homburg" <pch-v6ops-2@u-1.phicoh.com> wrote:
>
> In your letter dated Tue, 2 Aug 2011 14:25:45 +0200 you wrote:
> >It's not a hard sell at all, given that the alternative is to<= br> > >unnecessarily scale up the LSN setups for IPv4 traffic (which coul= d be
> >native, non-NATted IPv6 traffic).
>
> At least one alternative is to pressure vendors into implementing a fo= rm of
> HE that prefers IPv6 when the performance of IPv6 and IPv4 is roughly = equal.
>

Hopefully they will do as you say because it is the right thing to do, a= s chrome and firefox have already done. Sans that, the isp can promote an a= ppropriet HE implementation that fits everyone's need to be off the LSN= .=A0 After all, LSN costs and service quality are passed on to the customer= .

Cb
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--000e0cd4841a7b878704a9870fe4-- From pch-b2B3A6689@u-1.phicoh.com Tue Aug 2 08:17:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5C21F84FA for ; Tue, 2 Aug 2011 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCnDsr3Dg+ic for ; Tue, 2 Aug 2011 08:17:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6730C21F84EF for ; Tue, 2 Aug 2011 08:17:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoGj0-0001jLC; Tue, 2 Aug 2011 17:17:42 +0200 Message-Id: To: Cameron Byrne From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> In-reply-to: Your message of "Tue, 2 Aug 2011 08:04:12 -0700 ." Date: Tue, 02 Aug 2011 17:17:24 +0200 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:17:44 -0000 In your letter dated Tue, 2 Aug 2011 08:04:12 -0700 you wrote: >Hopefully they will do as you say because it is the right thing to do, as >chrome and firefox have already done. Sans that, the isp can promote an >appropriet HE implementation that fits everyone's need to be off the LSN. >After all, LSN costs and service quality are passed on to the customer. At the moment there is almost no content on IPv6 and also about no ISPs providing their users with IPv6. So, vendors have plenty of time to get their act together in this respect. From moore@network-heretics.com Tue Aug 2 08:56:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E321F85BB for ; Tue, 2 Aug 2011 08:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOdVOnZeVlho for ; Tue, 2 Aug 2011 08:56:29 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1262B11E808A for ; Tue, 2 Aug 2011 08:56:20 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QoHKU-0003QH-MM; Tue, 02 Aug 2011 11:56:26 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E381A43.3090107@inex.ie> Date: Tue, 2 Aug 2011 11:56:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402ea26e0e5aad03e150d91a5f4b69329a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:56:31 -0000 On Aug 2, 2011, at 11:39 AM, Nick Hilliard wrote: > On 02/08/2011 13:28, Keith Moore wrote: >> A different idea is that the firewall always work in a very minimal = mode >> by default (e.g. it passes no traffic, or maybe only outgoing port 80 >> traffic, but its configuration interface is enabled for the internal >> ports) so that the user must configure it in order to get it to do >> anything useful. >=20 > Each support call into a support centre costs money, and if you scale = it > up, any user that ends up calling support is basically losing money = for the > ISP. Yes, margins are that thin. >=20 > Building a firewall that almost guarantees that an end-user will need = to > open a support call is both useless to the end-user and financially = harmful > to a service provider. There is no point whatsoever in doing this - = it > adds pointless complexity with no measurable return. >=20 > If you want to build a router suitable for Keith Moore, then go out = and > customise a WRT54G, or hack a soekris into shape. But don't assume = that > most end-users have either the interest or the capability to work out = a > good quality security policy for themselves because by-and-large, they = don't. I understand all of that. What I'm saying is that having the router try = to be clever about what the policy should be, is even worse. =20 Keith From joelja@bogus.com Tue Aug 2 10:24:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD1611E807F for ; Tue, 2 Aug 2011 10:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITkUXyNIFjl3 for ; Tue, 2 Aug 2011 10:24:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF111E8098 for ; Tue, 2 Aug 2011 10:24:08 -0700 (PDT) Received: from [10.101.144.52] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p72HOG2E068571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 17:24:16 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 10:24:11 -0700 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 02 Aug 2011 17:24:17 +0000 (UTC) Subject: [v6ops] draft minutes ietf 81, 3 meetings... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:24:12 -0000 There were at least 2 note-takers plus 2 people scribing on jabber at = various times. I'm am deeply appreciative of the contribution to making = these notes useful. IETF 81=20 V6OPS WG Minutes ------------------------------- --Tuesday July 26 0900-1130 EDT Approximately 200 participants Fred Baker - Introduction The meeting is divided into two sections=20 1. World ipv6 day 2. Old Business * Presentation - World IPV6 Day Measurement results - Keranen http://tools.ietf.org/agenda/81/slides/v6ops-0.pdf = http://tools.ietf.org/html/draft-keranen-ipv6day-measurements * Presentations - Microsoft Measurement report - Chris Palmer http://tools.ietf.org/agenda/81/slides/v6ops-1.pptx the sad graph, basically half a percent of th euser base came in via v6, 7% of those folks were windows xp which is surprising becuase you have to turn it on. as far as method, 91% native 8% 6to4 and 1% teredo. CDN's delivered, really at the last minute but they were there. It's hard to say given the usage that we've validated this at scale. Ralph D - Clarification Question ipv6 geolocation is it unavailable or is it incorrect. Chris - We use third parties and they're lacking the data. ? - What would it take from miscrosofts perspective to roll a patch to enable windows XP Chris P - That's something we've been generically thinking about but there's only a 1000 days of Windows XP left. Lorenzo C - one of the things you achieved with this is the removal of fear. How do you lock in those gains? if you do nothing the fear will come back. John B - We see duplicate DUID when windows devices do DHCPv6, which creates and operational complication. Chris P - Stacks changes are coming in Sept. Eric Kline - Will IE get ahppy eyeballs or fast fallback so it can join the other browsers?=20 Chris P - So things like happy eyeballs are useful but fuzy towards the no. We're inclined to make changes to 3484. Dan W - Hey your v6 is broken is is not generic to the whole internet, it may work in your office or home, so a solution has to have scope. * Presentations - Checkpoint's World IPv6 Day Experience - Bob hinden http://tools.ietf.org/agenda/81/slides/v6ops-3.pdf Mark T - In our experience there are a lot of things we could just leave up afterwards, yet there is a lot of legacy stuff that has to be validated. Bob H - By doing this deployment exercise we're now having conversations about internal deployment now that the IT team feels a lot more comfortable and turns out to have not been that hard. * Presentation - World IPv6 Day, What did we learn (Ripe measurement = report) - Bert Wijnen=20 http://tools.ietf.org/agenda/81/slides/v6ops-4.pdf Bert W - Ripe had about 40 measurement points from which to observe world ipv6 day.=20 Looking at DNS queries, 2 days before, negative cache TTL dropped for several participants. The internet is is a collection of internets connected to each other. Some of our vantage points revealed partitioning which was confirmed with further discussion. when monitoring performance ipv4 vs ipv6 for source destination pairs, v4 was a little better, but very close however. Alain D - Did you monitor the propigation of /48 prefixes , there are rumors of edge providers still filtering. Joel J - We advertise /48 prefixes and these days, we see them basically everywhere we can see with routeviews. Hue Deng - use of nat 64 for services can you detect that in your data? Joel J - Question everyone uses a load-balancer at scale, what are you trying to find? Alain D - With nat64 in front of the a server we have lost the identity of the user. =20 * Presentation - IPv6 day operators report (hurricane electric) - Martin = Levy http://tools.ietf.org/agenda/81/slides/v6ops-19.pdf Only port 80/443 traffic volume changed on IPv6 day. We credit much of this to youtube. Teredo tunnels require that the tunnel-end point return an icmp6 ping. About 11% of ASes are IPv6 enabled, if you count adjacencies, by the time that you get to 7 adjacencies about 50% of those players are ipv6 enabled. Geoff H - Your commnetary about Teredo isn't gelling for me, at the client side the ICMP is in UDP, the modified stun protocol in teredo guesses wrong about 37% of the time with the NAT binding.=20 * Presentation - Comcast expereince with ipv6 deployment - John = Browsowki http://tools.ietf.org/agenda/81/slides/v6ops-20.pdf Traffic increased notably during world ipv6 day. An additional trial is being deployed (DS-Lite) Native dual stack validated, preparing for production deployment. We took Jason Fesler's IPv6 testing code and did some 30,000 tests with end users, found some users that were potentially impacted. Hue D - How is your backoffice deployment supporting IPv6?=20 John B - We've been working on it for about 6 years. The edge of the broadband network is where the effort is. Lee H - I thank you John because we started three years ago which means things have gone much faster.=20 Chris P - Do you have visibility into household customers with gateways that don't support V6?=20 John B - That vast majority, when we enable it in the broadband network we can tall people hey guys you need to upgrade.=20 Chris P - my concern is that maybe if we're lucky we can reach 1 in 4 households. Lorenzo C - As a customer V6 is great and it works as well as ipv4. If you went all out how long would it take you to bring V6 to 1% of your customers?=20 John B - 1% is doable pretty easy thequestion is more like the 90% = number. Fred Baker - Status report World IPv6 day call to arms http://tools.ietf.org/html/draft-chown-v6ops-call-to-arms It doesn't have a lot of value as an RFC so Tim will let it lapse but the info will go into some other drafts. =20 * Presentation - Happyeyeballs implementation report - Dan Wing http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs After discussion on the list, instead of describing the algorithm we decided to describe requirements. There are two versions stateless, e.g. chrome or firefox vs stateful Algorithms. Chris P - I think the direction is fantastic, requirements are good. * Presentation - IPv6 DNS Whitelisting - Jason Livingood http://tools.ietf.org/agenda/81/slides/v6ops-6.pptx = http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implicati= ons Lots of feedback from the IESG, generating version 3-6. We talked to implmentors, and it needs another rev, to make it acceptable to a swap of the community.=20 Wes G - When this approach was first tried manual was the only approach.=20 Lorenzo C - When we started this it was because we had no alternative. We removed ourselves from the discussion because we thought it was a critique of us. It's possible that we can produce a document that we can accept. Focus on intent and consequences in this draft.=20 Fred B - Is there something (a taxonomy of GTM/GSLB) that we should take to DNSOP? Fred Baker - Response to Appeal on 6to4 to historic http://tools.ietf.org/agenda/81/slides/v6ops-24.pptx http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic Keith M - I'm convinced that you did due dilligence with respect to wg consensus.=20 Fred B - It is worth noting that the draft did have some impact (with vendors). New business * Presentation - RFC for IPv6 IP identification field (header) - Mike = Ackerman http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt = http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header Fred B - Question for the group, do you use the IPID in ipv4? (no respondants other than presenters) Weg G - We use it all the time? I've never heard of it... Francis D - it's potentially a covert channel, also why not use the fregmentation header? Bob H - We diefintently want to hear if this is useful. I don't know who puts this header in the packet? Nalini ? - The host clearly Andrei Y - typical use case for this header would be to see if a middle box is modifying the packet.=20 Fred B - What I'm out of this discussion is that the application isn't a bad one, it could be simulated in a fregment. Fred Baker - Meeting complete, go to Lunch ------------------------------- =20 -- Thursday July 28 1520-1720 EDT Approximately 200 participants * Presentation - Stateless 4Via6 - Wojec Dec http://tools.ietf.org/agenda/81/slides/v6ops-8.ppt http://tools.ietf.org/html/draft-dec-stateless-4v6 4v6 index provides enough information to compute an ipv4 address and port index. Example scenario - A CPE, inside it has a port contrained nat44 implmentation along with the 4v6 function. inside the cpe we nat the source ip to a public v4 address and port rnage provided by the v6 address encapsulated and sent to the 4v6 gateway where it is sent on the internet. Alternative modes of operation, mapped, vs translation. Translation has signficantly less impact in the 3gpp case. Oel T - Wanted to ste for the minutes that there isn't any practical difference between encapsulation ad double translation. Wojek D - We didn't get to have the discussion in softwires we belive that V6OPS is the best place to capture the operational issues. Hue D - would like less impact ? Shima - Going to be a work item for softwires. Mark T - The vast majority of both operations are the same, the question is do we compress the headers out or not. I support the minimal effort which is encapsulation. Alain D - This will be done at the interim metting in sept. Jari A - we should put them in the same place (softwire) rather than split them all over the place. Sing Y (cernet) - Sometimes we deploy single translation sometimes double, we haven't found many corner case where one works and the other doesn't. Fred B - Would suggest that people here read the draft, and comment to softwire where the work will be done. Dave T - the difference between tunneling and translation is very small and it would be an odd division to put those in two places. * Presentation - advanced requirements for cpe routers - Ole Troan http://tools.ietf.org/agenda/81/slides/v6ops-9.pdf = http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis Request from homenet to move the lan side of this document to the homenet wg. thus the document will be split in wan requirements vs lan side which will go there. Options give up on the document move to softwires (the ds-lite part)=20 resubmitt 6204 with ds-lite and 6rd requirements continue. Barbara S - I like 6204 option or option 4 Ole T - include requirement for PCP? Alain D - PCP has been through two WG last calls Mark T - 6rd and DS-lite and PCP and making them come up and behave well together, that work is already here. Barbara S - Inclusion of PCP will start the question of do we also include UPnP Lorenzo C - what 6204 and homenet are doing is a relatively partitionable problem. Fred B - Question for Barbara, does this start here or in the BBF (broadband forum) Barbara S - Start them whereever someone is referencing PCP Hemant S - Lan side requirements are where we have real urgency from operators. Fred B - unless homenet feels badly them my expression would be to go for the thing with the nearest completion. Erik K - we need to have the cpe vendors be able to build this early next year. Jari A - we should publish what we have, if there's falky stuff we should pull it. Lorenzo C - In a closer reading of some of the lan side stuff dhcp will definitly hurt homenet work. * Presentation - IPv6 RA-Guard Evasion - Aurturo Servin = http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-evasion http://tools.ietf.org/agenda/81/slides/v6ops-11.pdf Fred B - so you made this presentation in 6man, what was the upshot? Aurturo - Was asking for acceptance becaue it's updates 6105, in v6ops case it's documentation of the issue and the operational solutions. Fernando G - Ra-guard is/was an infomational document produced in v6ops not 6man. Ron B - We would be stepping on the charter of 6Man Joel J - (outside of the problem statement) Fred B - We'll talk with Bob and Brian but it seems like the work can be done in 6man. * Presentation - IPv6 Practices on China Mobile IP Network - Chen Gun=20= = http://tools.ietf.org/html/draft-chen-v6ops-ipv6-bearer-network-trials http://tools.ietf.org/agenda/81/slides/v6ops-16.ppt Chris P - empathize strongly, I think it's great but I have a question are you drving load from your user's against this? Chen G - we have a plan for that, it's a lab exercise. Hue D - we have a national project that will deploy later this year. * Presentation - NAT64 CPE Operation Usages and Requirements - Chen Gun=20= http://tools.ietf.org/agenda/81/slides/v6ops-25.ppt http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe Fred B - If the other draft is covering the same material at least they could be merged. * Presentation - A Discard prefix for IPv6 - Dave Freedman=20 = http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix http://tools.ietf.org/agenda/81/slides/v6ops-12.pdf Dave Freeman - Where should the prefix be from? documentation range? cute hex? more than one address? Global Unicast? Hard-Wired discard prefix is a standards track item. Nick H - There are concievable situations where you might want to leak this prefix e.g. to downstreams for DOS analysis etc (Warren K, Lorenzo C dispute this) Rob ? - We don't have a BCP for implementation Joel J - as one of the coauthor's on the ipv4 (RTBH BCP) the ipv4 one would be virtually identical. Fred - hearing a fair amount of support (hum) in favor no opposed=20 short prefix (e.g. /64) vs /128=20 wg prefernce for /64 This is an arguement for BCP, Lets take this to a working group last call and move it ahead. * Presentation - DHCPv6 Prefix delegation as IPv6 Migration Tool in mobile netoworks - behcet Sarikaya http://tools.ietf.org/agenda/81/slides/v6ops-13.pptx = http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation Fred B - WG do you want to see this as a WG item? (show of hands shows no strong support each way) Nor support (for or against) individal submission Fred Baker - meeting over ------------------------------- Friday July 29 1300-1500 EDT=20 Approximately 80 participants * Presentation - IPv6 Address accountability Considerations - Tim Chown=20 http://tools.ietf.org/agenda/81/slides/v6ops-29.pdf = http://tools.ietf.org/html/draft-chown-v6ops-address-accountability Tim C - At the moment people in ipv4 have a reasonable task of providing address accountability in v6, things like privacy addresses make that harder. Dave T - What do you mean by accountability Tim C - either a hardward port or 802.1x giving you a binding between port and ip address correlation between ip4 arp and ipv6 nd tables and polling rapidly enough that you know your data is relevant, alternatively record all nd traffic on the link. Fred B - Zigbee has Pana=20 Unkown (Back mic) - Use Savi Tim C - Currently documents say logging with Savi should only log potential spoofing events, Logging all mapping data would be required. Fred B - as a Savi author switches in general have places where they log all sorts of things. James W - Shouldn't this rightfully be taken up in NOG organizations, One person's accountability is another Persons Pen Register. Wes G - The privacy concerns are something that should be included in the document. * Presentation - Operational Neighbor Discovery problem and enchancements - Joel Jaeggli http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance http://tools.ietf.org/agenda/81/slides/v6ops-21.pdf Joel - 6Man owns the solutions, V6ops feedback on whether there's a problem or not is helpful. Ole T - What's the relationship of this work to 6 lowpan nd=20 Joel J - Don't know haven't explored that. Lorenzo C - Propose splitting the draft into operational guidance vs protocol changes. Fred B - Are address scans a problem?=20 If this draft is split would the working group take the operational and implementation details (consensus, no opposition) * Presentation - Implementing AplusP in the provider's IPv6 only network - X Deng = http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results http://tools.ietf.org/agenda/81/slides/v6ops-14.ppt X Deng - implemented both port-range and scatter port a+p=20 Fred B - So this is the Demo you showed in the terminal room? X Deng - Yeah What Breaks? UPNP clients.=20 Marshall E / Dan W - Is there a security implication to the mask of ports? If I'm running a Kaminsky Style attack I can guess your next = port. Stuart C - Lot of focus on making UPNP 1.0 work, it never will, you have to throw it out and start again hence IGD 2.0 * Presentation - Rapid Transition of IPv4 contents to be IPv6 accessible - Q Sunq = http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition http://tools.ietf.org/agenda/81/slides/v6ops-27.pptx Wes G - In the case where you turn on content providers, they need to do that on their own edge. Has this show us a practical application worth replicating or is this a proprietary one-off worth documenting.=20 Dan W - if the consensus in the room is that nat64 is inappropiate in front of an ip4-only server because of a loss of the IPv6 source address, then v6ops would benifit from documenting that as a not recomended deplyoment. Lorenzo C / Jason W - There's a disparity where content is ahead of access. Access provders are currently working on that. Fred Baker - Meeting adjourned From jhw@apple.com Tue Aug 2 12:27:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D5021F8570 for ; Tue, 2 Aug 2011 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtOqwmoiQenn for ; Tue, 2 Aug 2011 12:27:26 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E817F21F8568 for ; Tue, 2 Aug 2011 12:27:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LPB0010VFCUV2K1@mail-out.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 12:27:16 -0700 (PDT) X-AuditID: 11807136-b7c35ae000001055-2b-4e3851b8263c Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 55.49.04181.8B1583E4; Tue, 02 Aug 2011 12:36:24 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPB002KTFDFUH10@cardamom.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 12:27:15 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 02 Aug 2011 12:27:15 -0700 Message-id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUiON1OVXdHoIWfwcEmAYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9ohxYLLrBVT/85kb2A8zNLFyMkhIWAiseDpBCYIW0ziwr31 bF2MXBxCAq1MEh0HNjODJHgFBCV+TL4H1MDBwSwgL3HwvCxImFlAS+L7o1YWiPqVTBJbP/5l A6kRFoiR2PutAqSGTUBF4tvlu2DzOQWMJSbcX8cOYrMIqEqc2jyTFaScV8BG4ukrY4gxT5kk zn+5wwhSIwLUO+XMfTaI2+QlFrd8ZpzAyD8LyUWzEC6aheSiBYzMqxgFi1JzEisNTfUSCwpy UvWS83M3MYKCq6HQbAfjjr9yhxgFOBiVeHgjFS38hFgTy4orcw8xSnAwK4nwnrhi7ifEm5JY WZValB9fVJqTWnyIUZqDRUmcl/uzmZ+QQHpiSWp2ampBahFMlomDU6qB0Xq7jWL90tUePGse PftzdMXFy3ncZ848+/4zavatU8nFs469vvbgseyT65fiLz7esHz7BP0btx9oKnNJcD1IuLCF t0zoexXDK8uEo8eXSbyytOprlDOUelX/8OFKQ41g9oRr887s+GBV7Wa1r8tnwZ9fQtryy+ON V7C8C+Gue3wp7Gj12WCD95+UWIozEg21mIuKEwFU9QiqKgIAAA== Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:27:27 -0000 On Aug 2, 2011, at 05:51 , Philip Homburg wrote: > At least one alternative is to pressure vendors into implementing a form of HE that prefers IPv6 when the performance of IPv6 and IPv4 is roughly equal. I don't see that working very well. The key phrase there is "roughly equal" and I don't think it has any useful meaning in practice here. Exhibiting no preference whatever between IPv4 and IPv6 is simpler in practice and delivers more consistent results. Besides, I have a hard time imagining such pressure originating in demands on Apple from its paying customers. What other form of pressure do you have in mind? -- james woodyatt member of technical staff, core os networking From ietfc@btconnect.com Tue Aug 2 13:47:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2E611E8098 for ; Tue, 2 Aug 2011 13:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHEnODydqxXV for ; Tue, 2 Aug 2011 13:47:18 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0E99E11E808C for ; Tue, 2 Aug 2011 13:47:17 -0700 (PDT) Received: from pc6 (host109-153-78-164.range109-153.btcentralplus.com [109.153.78.164]) by c2bthomr14.btconnect.com (MOS 4.2.2-FCS) with SMTP id DVS10043; Tue, 2 Aug 2011 21:47:25 +0100 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E38625D.001D, actions=tag Message-ID: <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , "IPv6 Operations" References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> Date: Tue, 2 Aug 2011 21:44:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.2.193914:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4E38625D.0094,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:47:19 -0000 ----- Original Message ----- From: "Fred Baker" To: "IPv6 Operations" Sent: Monday, August 01, 2011 8:05 PM > For the record, if you look through the set of drafts I have posted since 1989 and the set of RFCs that have come out, you will see that I personally entertain little expectation that a given draft that I write will become an RFC. Sometimes they do - for me, 49 times to date. Far more often - for me, 170 drafts (and many more versions of drafts, but that's not what I'm talking about) resulting in about 150 acknowledgements in other RFCs, and in many cases simply being part of the total IETF discussion - a draft facilitates a discussion that may or may not be headed in a direction useful to the community or of archival importance. At this IETF, I posted two drafts in homenet that I frankly expect to have little archival value, but facilitated a discussion in the working group. Fred Yeeees ... but that is your way of working. I see the same from eg Brian Carpenter or John Klensin; an idea comes up on a list, before I have caught up with the posts there is an I-D from them, technical, process, whatever. For me, perhaps for others, producing an I-D is a Big Job, something to contemplate every six months to give me time to recover before the next one (I see the same two-speed approach with academic papers). I think that for most people the expectation is that I-D leads to RFC or else to disappointment. Tom Petch > > On Jul 30, 2011, at 2:37 PM, Fred Baker wrote: > > > Pursuant to our discussion Tuesday, I'd be interested in working group comment on > > http://tools.ietf.org/html/draft-keranen-ipv6day-measurements > > "Some Measurements on World IPv6 Day from End-User Perspective", Ari > > Keranen, Jari Arkko, 11-Jul-11 > > > > I could imagine not publishing as RFC (it has already served its purpose), sending to the IESG as an individual submission for informational status, or adopting as a working group item and eventually sending as that to the IESG for informational status. Up to you guys... > > > > What would you like to do? > > - do you want to adopt it? > > - separate question, do you want to publish it? > > - if you want to publish it, do you have any comments? > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Tue Aug 2 13:57:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B736F21F8713 for ; Tue, 2 Aug 2011 13:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGFt3LtTfvJH for ; Tue, 2 Aug 2011 13:57:22 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB7821F86F6 for ; Tue, 2 Aug 2011 13:57:22 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QoM1o-0004XN-Hl; Tue, 02 Aug 2011 16:57:28 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore X-Priority: 3 In-Reply-To: <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> Date: Tue, 2 Aug 2011 16:57:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9403f768e63eb0e0499537dfce948b7a75a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:57:22 -0000 On Aug 2, 2011, at 3:44 PM, t.petch wrote: > Yeeees ... but that is your way of working. I see the same from eg = Brian > Carpenter or John Klensin; an idea comes up on a list, before I have = caught up > with the posts there is an I-D from them, technical, process, = whatever. For me, > perhaps for others, producing an I-D is a Big Job, something to = contemplate > every six months to give me time to recover before the next one (I see = the same > two-speed approach with academic papers). >=20 > I think that for most people the expectation is that I-D leads to RFC = or else to > disappointment. I sincerely hope that you're incorrect about that. It's ridiculous to = assume that merely because someone writes a draft, that draft deserves = eventual publication as an RFC and the explicit or implied endorsement = of the IETF community that comes with it. If part of what IETF is doing = isn't culling through ideas and expressions of ideas, selecting some and = discarding others, it's not doing its job. =20 Keith From pch-b2B3A6689@u-1.phicoh.com Tue Aug 2 14:05:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8921F87C3 for ; Tue, 2 Aug 2011 14:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z34RIcXWQVe1 for ; Tue, 2 Aug 2011 14:05:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3F21F8777 for ; Tue, 2 Aug 2011 14:05:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoM9f-0001eQC; Tue, 2 Aug 2011 23:05:35 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> In-reply-to: Your message of "Tue, 02 Aug 2011 12:27:15 -0700 ." Date: Tue, 02 Aug 2011 23:05:30 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:05:34 -0000 In your letter dated Tue, 02 Aug 2011 12:27:15 -0700 you wrote: >On Aug 2, 2011, at 05:51 , Philip Homburg wrote: > >> At least one alternative is to pressure vendors into implementing a form of >HE that prefers IPv6 when the performance of IPv6 and IPv4 is roughly equal. > >I don't see that working very well. The key phrase there is "roughly equal" a >nd I don't think it has any useful meaning in practice here. Exhibiting no pr >eference whatever between IPv4 and IPv6 is simpler in practice and delivers mo >re consistent results. I'd say that preferring IPv6 is more consistent. At the moment I'm using 30ms as the cut off for 'roughly equal' and that seems to be working well. When my HE implementation connects to IPv4 I know that IPv6 is off by at least 30ms. For quite a while I didn't want to this either. I had the same idea that connecting to whatever is faster is best. But when you think about it, the whole world trying to connect to whatever system is fastest. You deny operators an imporant tool for essentially no gain for the customer. I apply the same 30ms to first record in the RR set as well, so authorative DNS servers also have some control (assuming intermediate DNS resolvers, etc. do not reorder the set). >Besides, I have a hard time imagining such pressure or >iginating in demands on Apple from its paying customers. What other form of p >ressure do you have in mind? That could be all kinds of things. I don't think it would be good if ISPs were openly hostile to Apple or if people write how badly Apple implemented certain features. But it may take a while for enough dual-stack content to arrive to be able to actually measure the effect. From nick@inex.ie Tue Aug 2 14:06:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCC21F8892 for ; Tue, 2 Aug 2011 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkLZUIR6dVbn for ; Tue, 2 Aug 2011 14:06:23 -0700 (PDT) Received: from muffin.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48AAC21F8891 for ; Tue, 2 Aug 2011 14:06:22 -0700 (PDT) X-Envelope-To: moore@network-heretics.com Received: from cupcake.local (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p72Fdmnw035566 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 16:39:48 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E381A43.3090107@inex.ie> Date: Tue, 02 Aug 2011 16:39:47 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Keith Moore References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> In-Reply-To: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> X-Enigmail-Version: 1.2 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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:06:23 -0000 On 02/08/2011 13:28, Keith Moore wrote: > A different idea is that the firewall always work in a very minimal mode > by default (e.g. it passes no traffic, or maybe only outgoing port 80 > traffic, but its configuration interface is enabled for the internal > ports) so that the user must configure it in order to get it to do > anything useful. Each support call into a support centre costs money, and if you scale it up, any user that ends up calling support is basically losing money for the ISP. Yes, margins are that thin. Building a firewall that almost guarantees that an end-user will need to open a support call is both useless to the end-user and financially harmful to a service provider. There is no point whatsoever in doing this - it adds pointless complexity with no measurable return. If you want to build a router suitable for Keith Moore, then go out and customise a WRT54G, or hack a soekris into shape. But don't assume that most end-users have either the interest or the capability to work out a good quality security policy for themselves because by-and-large, they don't. Nick From john_brzozowski@cable.comcast.com Tue Aug 2 14:35:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359A011E80B3 for ; Tue, 2 Aug 2011 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkMLCju4ZqSA for ; Tue, 2 Aug 2011 14:35:03 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5311E808F for ; Tue, 2 Aug 2011 14:35:03 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47237265; Tue, 02 Aug 2011 15:39:45 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:35:00 -0400 From: "Brzozowski, John" To: "Rajiv Asati (rajiva)" , Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxO6HZ7YQ4f7+JsMUusl+Ald1vnPQBdTzLAAD+UcIA= Date: Tue, 2 Aug 2011 21:34:59 +0000 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [166.217.5.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <69881C740213C840AF5DFBA5CFC7B040@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:35:04 -0000 +1 for the below. On 8/1/11 11:33 AM, "Rajiv Asati (rajiva)" wrote: >Agreed to the use case, but having to run a heavy-duty protocol like >OSPF or ISIS is an overkill to this use case, IMO. From john_brzozowski@cable.comcast.com Tue Aug 2 14:41:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9925B11E80B7 for ; Tue, 2 Aug 2011 14:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQxj1vPmx+mX for ; Tue, 2 Aug 2011 14:41:39 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8B611E80C7 for ; Tue, 2 Aug 2011 14:41:39 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47238243; Tue, 02 Aug 2011 15:46:41 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:41:42 -0400 From: "Brzozowski, John" To: Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTmsYQ4f7+JsMUusl+Ald1vnPZUCgEUAgAGPloCAAQL+gIABcZuAgAHyAwCAAaj3gA== Date: Tue, 2 Aug 2011 21:41:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [166.217.5.71] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59D1846434AA6047AE919355B1A76100@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:41:40 -0000 On 8/1/11 12:20 PM, "Lorenzo Colitti" wrote: >On Sun, Jul 31, 2011 at 10:38, Brzozowski, John > wrote: > >The outer most router supports DHCPv6 PD (LAN side). It would have to be >seeded with adequate address space to serve up IA_PD (and possibly IA_NA) >for downstream routers. Based on conversations to date I assume there >would be interest in downstream routers also support and being able to >delegate prefixes? > > > >There are two issues I see with DHCPv6 PD to distribute prefixes inside >the home: > >1. Prefix delegation only really works in a tree topology, so when the >user plugs things in wrong (e.g., plugs a LAN port into another LAN port, >or creates a loop) it won't work. Having a routing protocol will allow >things to work regardless of how the user plugs things in. [jjmb] so is the suggestion here to use DHCPv6 PD for the outer most router and something else internally within the home? What sort of topology do you have in mind? I am not seeing a reason why DHCPv6 could not work. Absent DHCPv6 there will be a need for some other protocol, extension, or technique that does not yet exist, right? >2. We already use PD between the home network and the ISP. If we use it >inside the home as well, then a home router getting a prefix via DHCPv6 >PD will not know whether it is connected to the ISP or not, and thus if >it should turn on the firewall or not. [jjmb] should the firewall be off automatically if the router is internal? > >Both of these issues can be solved by using an IGP. [jjmb] including the sub-allocation of prefixes in the home? And this assume the home router is able to support the same. > >Cheers, >Lorenzo > From john_brzozowski@cable.comcast.com Tue Aug 2 14:46:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC07211E80A9 for ; Tue, 2 Aug 2011 14:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba1uVlOL0XbG for ; Tue, 2 Aug 2011 14:46:10 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82711E808F for ; Tue, 2 Aug 2011 14:46:10 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47238987; Tue, 02 Aug 2011 15:51:14 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:46:15 -0400 From: "Brzozowski, John" To: Lorenzo Colitti , Philip Homburg Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUG9QUkF+WhE7KUKZ325NxGyQtJUKGcKA Date: Tue, 2 Aug 2011 21:46:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <066E7D16B45367468FDF1A8B6A9A6DD2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:46:10 -0000 By default I would say no, firewall should be on. You should have the option to disable the firewall, if you wish. IMO - the default rule set for the firewall should be allow all outbound, block all inbound unless the same is a result of a LAN side request. Maybe your router can only support a /64, remember the ISP is one part of the equation. ;) John On 8/1/11 1:20 PM, "Lorenzo Colitti" wrote: >On Mon, Aug 1, 2011 at 09:44, Philip Homburg >wrote: > >If a home router only hands out /64s to other routers then routers can >take >getting something bigger than a /64 as a hint that they should enable the >firewall and become a DHCP server themselves. > > > >What if the ISP only hands out a /64 (like mine does)? Disable the >firewall? > From john_brzozowski@cable.comcast.com Tue Aug 2 14:49:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553AE11E80AE for ; Tue, 2 Aug 2011 14:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=2.471, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OodvCXPepsVd for ; Tue, 2 Aug 2011 14:49:21 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6776D11E80A1 for ; Tue, 2 Aug 2011 14:49:21 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135998421; Tue, 02 Aug 2011 17:49:27 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:49:27 -0400 From: "Brzozowski, John" To: Lee Howard , Erik Kline , 'Satoru Matsushima' Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxPahS9UkF+WhE7KUKZ325NxGyQtAAVGyagAGfh94A= Date: Tue, 2 Aug 2011 21:49:25 +0000 Message-ID: In-Reply-To: <000c01cc506f$a17f05b0$e47d1110$@org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <1343FE604E422E46A9B6590A626D1968@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:49:22 -0000 I was thinking the same thing, the thread is going so well here. :) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/1/11 1:22 PM, "Lee Howard" wrote: >Is anyone capturing this thread into a problem statement/requirements >document, or are we >going to design new protocols, and then fight about which one meets the >requirements? > >Can we take this to Homenet mailing list? > >Lee > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of Erik Kline >> Sent: Sunday, July 31, 2011 6:10 AM >> To: Satoru Matsushima >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >> On 31 July 2011 09:08, Satoru Matsushima >>wrote: >> > On 2011/07/31, at 17:39, Erik Kline wrote: >> > >> >>> Of course, these are just examples of why a protocol that can carry >> >>> additional information beyond just "this prefix lives here with >>this metric" >> >>> can be useful: it allows the network to do stuff that we haven't >>thought of >> >>> yet. >> >> >> >> Like advertise future standardized "this *service* is reachable via >> >> this path" sorts of things. The routing protocol could aid in >>service >> >> discovery this way. >> > >> > I think it would be a good point. >> > A crazy idea come up me like opaque-lsa for advertise beyond >>advertising just prefix, and >> a flavor of bgp community to import/export to manage connectivity among >>routing >> instances. >>=20 >> Hehe. On the plane ride back I was thinking of something like ES-IS >> advertising service things to IS-IS routers, which could choose to >> propagate them. >>=20 >> Of course, I also though to redo IS-IS without OSI numbering and just >> use link-local addresses...somehow. >>=20 >> =3D) >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From john_brzozowski@cable.comcast.com Tue Aug 2 14:54:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7FF21F85AA for ; Tue, 2 Aug 2011 14:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=3.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2GnLFU55oqU for ; Tue, 2 Aug 2011 14:54:16 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5D11E80BD for ; Tue, 2 Aug 2011 14:54:15 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135999092; Tue, 02 Aug 2011 17:54:21 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:54:21 -0400 From: "Brzozowski, John" To: Shane Amante , Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUHw/zXadajaHM0CoA8rWqAKgMpUJPn+AgADd+YA= Date: Tue, 2 Aug 2011 21:54:20 +0000 Message-ID: In-Reply-To: <6F6EA473-29AC-4BF3-9F82-EA1CB6B55238@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [166.217.5.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Aug 2011 15:15:25 -0700 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:54:16 -0000 Agreed, however, it still not make it the best solution for the problem space. On 8/2/11 12:39 AM, "Shane Amante" wrote: > >On Aug 1, 2011, at 12:47 PM, Lorenzo Colitti wrote: > > >On Mon, Aug 1, 2011 at 14:40, Philip Homburg >wrote: > >It doesn't matter how do it. If it is done using an IGP, then can you bet >that >either some ISP happens to be using that IGP on WAN links, or that some >script >kiddies will try to see what happens if you try to send those packets to >random CPEs. > > > >IGPs support authentication. As part of setting up your home network, you >could associate CPEs with each other and use that to form a common auth >key. > > > > >And, likewise, any ISP worth their salt should be: >a) using authentication *within* their access and Backbone network; and, >b) using ACL's to protect their routing & signaling protocols >... so there's absolutely no legitimate reason that a customer's network >should ever "accidentally" be joined to the SP's IGP ... > >-shane >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From john_brzozowski@cable.comcast.com Tue Aug 2 14:57:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4621F85B9 for ; Tue, 2 Aug 2011 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHK7DaMNuo1N for ; Tue, 2 Aug 2011 14:57:18 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9686A21F85AA for ; Tue, 2 Aug 2011 14:57:18 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47240897; Tue, 02 Aug 2011 16:02:09 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:57:11 -0400 From: "Brzozowski, John" To: Michael Newbery Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUHw/zXadajaHM0CoA8rWqAKgMpUJPn+AgAAS0ICAAMv3AA== Date: Tue, 2 Aug 2011 21:57:10 +0000 Message-ID: In-Reply-To: <3F938CF4-39ED-43B6-A6F4-32E8F527CDE5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <983A6C80BB015648869210817797BCF2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Aug 2011 15:15:25 -0700 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:57:19 -0000 This is something that should be today as part of broadband IPv6 deployments to prevent conflict at the service provider edge. I cannot think of a good reason why I would want to accept IPv6 router advertisements, at this time from residential gateways. John On 8/2/11 1:47 AM, "Michael Newbery" wrote: >It's outside the CPE spec, but I can see that the document could state, >as an assumption, that the ISP will filter routing advertisements from >the CPE and will only pass those that it has determined (via some >external mechanism, undefined in this document) belong to the CPE. From john_brzozowski@cable.comcast.com Tue Aug 2 15:12:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AAF21F8559 for ; Tue, 2 Aug 2011 15:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QAcVVD60aeo for ; Tue, 2 Aug 2011 15:12:29 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3435021F8557 for ; Tue, 2 Aug 2011 15:12:28 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47240934; Tue, 02 Aug 2011 16:02:34 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 17:57:34 -0400 From: "Brzozowski, John" To: Michael Newbery Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUHw/zXadajaHM0CoA8rWqAKgMpUJPn+AgAAS0ICAAMv3AA== Date: Tue, 2 Aug 2011 21:57:33 +0000 Message-ID: In-Reply-To: <3F938CF4-39ED-43B6-A6F4-32E8F527CDE5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <6519D2436447C548920AC3F647ACD87D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Aug 2011 15:15:25 -0700 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:12:30 -0000 This is something that should be today as part of broadband IPv6 deployments to prevent conflict at the service provider edge. I cannot think of a good reason why I would want to accept IPv6 router advertisements, at this time from residential gateways. John On 8/2/11 1:47 AM, "Michael Newbery" wrote: >It's outside the CPE spec, but I can see that the document could state, >as an assumption, that the ISP will filter routing advertisements from >the CPE and will only pass those that it has determined (via some >external mechanism, undefined in this document) belong to the CPE. From joelja@bogus.com Tue Aug 2 15:42:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0511E80D4 for ; Tue, 2 Aug 2011 15:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M5bpz64DkES for ; Tue, 2 Aug 2011 15:42:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A79E11E8095 for ; Tue, 2 Aug 2011 15:42:49 -0700 (PDT) Received: from [10.101.144.52] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p72MgtBO086351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Aug 2011 22:42:55 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli X-Priority: 3 In-Reply-To: <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> Date: Tue, 2 Aug 2011 15:42:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77328167-EA8B-4A6B-BF93-350D52348236@bogus.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 02 Aug 2011 22:42:56 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:42:51 -0000 On Aug 2, 2011, at 12:44 PM, t.petch wrote: > I think that for most people the expectation is that I-D leads to RFC = or else to > disappointment. realistically given that there have been something like 21795 drafts = since March 1996 when the tools archive begins and 4435 RFCs in the same = timeframe our success rate is way higher than say the publishing = industry. > Tom Petch >=20 >>=20 >> On Jul 30, 2011, at 2:37 PM, Fred Baker wrote: >>=20 >>> Pursuant to our discussion Tuesday, I'd be interested in working = group > comment on >>> http://tools.ietf.org/html/draft-keranen-ipv6day-measurements >>> "Some Measurements on World IPv6 Day from End-User Perspective", Ari >>> Keranen, Jari Arkko, 11-Jul-11 >>>=20 >>> I could imagine not publishing as RFC (it has already served its = purpose), > sending to the IESG as an individual submission for informational = status, or > adopting as a working group item and eventually sending as that to the = IESG for > informational status. Up to you guys... >>>=20 >>> What would you like to do? >>> - do you want to adopt it? >>> - separate question, do you want to publish it? >>> - if you want to publish it, do you have any comments? >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From john_brzozowski@cable.comcast.com Tue Aug 2 16:08:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202F25E800D for ; Tue, 2 Aug 2011 16:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvwWD3tsg9z9 for ; Tue, 2 Aug 2011 16:08:44 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id CAE755E800A for ; Tue, 2 Aug 2011 16:08:43 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47249507; Tue, 02 Aug 2011 17:13:49 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 19:08:50 -0400 From: "Brzozowski, John" To: Ray Hunter , Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUOhuzXadajaHM0CoA8rWqAKgMpUKHcAA Date: Tue, 2 Aug 2011 23:08:49 +0000 Message-ID: In-Reply-To: <4E37AB93.3000005@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <983A8F2C8CE1F64FA76375724B53A2EA@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:08:45 -0000 On 8/2/11 3:47 AM, "Ray Hunter" wrote: >As for only delegating a single /64 to home users >i) I would hope ISP's are more sympathetic to home users who have genuine >needs for a DMZ, guest LAN etc. now that NAT won't provide a solution for >this requirement [jjmb] I am sure shorter allocations will be available. As I stated in an earlier email the end user also needs to make sure their CPE supports the same. >ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even >if SLAAC doesn't yet) [jjmb] assuming you are referring to longer than /64 this could work you would have to leverage DHCPv6 for address assignment or static configuration. I imagine this may complicate renumbering. From jhw@apple.com Tue Aug 2 16:12:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2421F850E for ; Tue, 2 Aug 2011 16:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.67 X-Spam-Level: X-Spam-Status: No, score=-106.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YC6tkfg0Sod for ; Tue, 2 Aug 2011 16:12:23 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id AF5D821F850B for ; Tue, 2 Aug 2011 16:12:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPB001HJPSFV2L2@mail-out.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 16:12:32 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-9e-4e38840ad939 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 69.2D.04993.A04883E4; Tue, 02 Aug 2011 16:11:06 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPB00I6GPSW8N90@kencur.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 16:12:32 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 02 Aug 2011 16:12:32 -0700 Message-id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTZerxcLP4OlhSYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/bW1ywFl7kq1t9kaWA8xNHFyMkhIWAicfruB1YIW0ziwr31 bF2MXBxCAu1MEt+uf2UBSfAKCEr8mHwPyObgYBaQlzh4XhYkzCygJfH9USsLRP1SJolLe2+A DRIWiJF4NW83WC+bgIrEt8t3mUBsTgFjiZudb8FsFgFViYVnD7JBzFSR+N/AD7HKRuLB/0ZG iJkHmSU2nH8INkdEQF/i49397BCHykssbvnMOIFRYBaS82YhnDcLyXkLGJlXMQoWpeYkVhoa 6iUWFOSk6iXn525iBIVdQ6HBDsa1P/kPMQpwMCrx8DLKW/gJsSaWFVfmHmKU4GBWEuFdGgIU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjvvg5mfkEB6YklqdmpqQWoRTJaJg1OqgXFKxqZcYzeb V74Lli+QXTbPdGLTopbfJ/glOmZILWJ4XGudf25dtBqn45KAb+cl1sx8eYB3YqKfzR5upUNv w7h6lEpX9ajNfKTCvfHgq/mTVtZ6FO9ZuJ5rtuLdKjaFjMjtSQu/9i1zeXf/9J/jOd29HZwH +s6s2fxPhVHj+5RFl2+9n6Jc1/VZiaU4I9FQi7moOBEAgAwa/jcCAAA= Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:12:24 -0000 On Aug 2, 2011, at 14:05 , Philip Homburg wrote: > > I'd say that preferring IPv6 is more consistent. At the moment I'm using 30ms as the cut off for 'roughly equal' and that seems to be working well. Those 30ms of additional latency contribute significantly to the bandwidth delay product. You may find them acceptable, but Apple engineers have looked pretty closely at it and decided that no time interval that could possibly make a difference would be tolerated by users. I don't want to make users pay with a delay factor in the bandwidth delay product just to push an agenda that operators may or may not actually share, depending on with whom you are talking this week. > For quite a while I didn't want to this either. I had the same idea that > connecting to whatever is faster is best. But when you think about it, > the whole world trying to connect to whatever system is fastest. You deny > operators an imporant tool for essentially no gain for the customer. I don't see it that way. I see those 0-30ms of additional latency as an unacceptable penalty that we would be asking our users to pay, in exchange for nothing of any measurable value to them. Do you see where our different perspectives leads us to reach different conclusions? -- james woodyatt member of technical staff, core os networking From Ted.Lemon@nominum.com Tue Aug 2 16:23:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1960111E80FA for ; Tue, 2 Aug 2011 16:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRQG4H95La4U for ; Tue, 2 Aug 2011 16:23:52 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id C630811E80F1 for ; Tue, 2 Aug 2011 16:23:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTjiHEc0mDyrvaH6ESza3PHHiW9VAcx6f@postini.com; Tue, 02 Aug 2011 16:24:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AE7381B8227 for ; Tue, 2 Aug 2011 16:24:01 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7DCE719005D; Tue, 2 Aug 2011 16:24:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 16:23:54 -0700 From: Ted Lemon To: james woodyatt Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Thread-Index: AQHMUWmwYNglGHfzfE6yYnjo1pkUA5UKqQGA Date: Tue, 2 Aug 2011 23:23:53 +0000 Message-ID: <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_1716B088C4DF414CA8EB8B778B7D89BCnominumcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:23:54 -0000 --_000_1716B088C4DF414CA8EB8B778B7D89BCnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 2, 2011, at 7:12 PM, james woodyatt wrote: Those 30ms of additional latency contribute significantly to the bandwidth = delay product. Can you expand on that? I hear this a lot, but it doesn't make much sense= , first because the ratio of SYNs to data-bearing packets is typically larg= e, and secondly because an adaptive algorithm should automatically eliminat= e significant delays. Have you done any kind of data collection and analysis that supports your c= onclusion? --_000_1716B088C4DF414CA8EB8B778B7D89BCnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8B588634F2A36246A4CB74B77FDB4CE2@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 2, 2011, at 7:12 PM, james woodyatt wrote:
Those 30ms of additional latency contribute significantly to the bandwidth delay= product.

Can you expand on that?   I hear this a lot, but it doesn't make = much sense, first because the ratio of SYNs to data-bearing packets is typi= cally large, and secondly because an adaptive algorithm should automaticall= y eliminate significant delays.

Have you done any kind of data collection and analysis that supports y= our conclusion?

--_000_1716B088C4DF414CA8EB8B778B7D89BCnominumcom_-- From john_brzozowski@cable.comcast.com Tue Aug 2 16:23:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68B511E80F9 for ; Tue, 2 Aug 2011 16:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvoJsQGtcDuV for ; Tue, 2 Aug 2011 16:23:53 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDD11E80F2 for ; Tue, 2 Aug 2011 16:23:52 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47249514; Tue, 02 Aug 2011 17:13:55 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 19:08:56 -0400 From: "Brzozowski, John" To: Keith Moore , Philip Homburg Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUO1EzXadajaHM0CoA8rWqAKgMpUJwHsAgABgdoA= Date: Tue, 2 Aug 2011 23:08:55 +0000 Message-ID: In-Reply-To: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <604DA1C57A29894B8B9729F2932D76AC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:23:57 -0000 On 8/2/11 8:28 AM, "Keith Moore" wrote: >On Aug 2, 2011, at 4:22 AM, Philip Homburg wrote: > >> How do you construct a router such that the router always knows what it >> has to do, or at least is in some sense fail-safe? > >The idea that a firewall should automatically know what "it has to do" >strikes me as utterly bizarre. I realize that there's a desire to >minimize the configuration burden for unsophisticated users (and agree >with that), but the idea that the firewall knows better than the user >what his security policy should be seems ridiculous. [jjmb] I agree Keith that having a firewall automatically know what to do is a tall order. I also think the is more than a desire to ease configuration burden, this is a must since most users on the Internet have very basic technical skills. > >A different idea is that the firewall always work in a very minimal mode >by default (e.g. it passes no traffic, or maybe only outgoing port 80 >traffic, but its configuration interface is enabled for the internal >ports) so that the user must configure it in order to get it to do >anything useful. That way, the first thing a user learns about his >router/firewall is how to configure it. Then you want to focus on making >the configuration interface easy to understand. (You also have to figure >out how to keep the user from hooking up the internal port to the >external connection.) [jjmb] I said something similar to this is in an earlier email. To the start there should perhaps be a basic configuration that protects the user and allows the service to be usable. > >But these are user interface issues, not protocol issues. Perhaps >they're better addressed in homenet than here. [jjmb] I could image some protocol work that could ease the pain here, UI for sure could facilitate ease of use. > >Keith > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Aug 2 16:37:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302A21F85C7 for ; Tue, 2 Aug 2011 16:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJOZgMhNeUnT for ; Tue, 2 Aug 2011 16:37:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9791921F85BB for ; Tue, 2 Aug 2011 16:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1444; q=dns/txt; s=iport; t=1312328250; x=1313537850; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=3LuoSpNFcwv+CpLpgW3d6oim6N3LFfSWg+Lv8Drcu8Q=; b=dSMLghw8T66WKJ9P40qSkvhubKdrrmDAP6FQ20aX0PftPrHBCBbi/woj OF3x4xnYZUaRP4gqxTRyWM7L00UIsXQ20nXvmlt8UW1nwVh9FQ/xveg2E GH8v1BwWMRWPv5aejeb9mNc3kfzpEi/KryMFUyZtuA0bDQ1VCbUztIpVU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJaJOE6rRDoG/2dsb2JhbABBAadod4FAAQEBAQIBAQEBDwEnDyULBQsLMQITJzAGEyKHSgSgEgGeUoNTAYIPXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="9011862" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2011 23:37:25 +0000 Received: from Freds-Computer.local ([10.21.119.85]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p72NbONj008855; Tue, 2 Aug 2011 23:37:24 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 02 Aug 2011 16:37:23 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 02 Aug 2011 16:37:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> Date: Tue, 2 Aug 2011 16:37:11 -0700 Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:37:20 -0000 On Jul 31, 2011, at 6:20 PM, George Michaelson wrote: > I had a moment in time to test a Snow Leopard, and Lion OSX setup = @home, before completing my upgrade to Lion on all boxes. >=20 > I tested http://www.apnic.net/ http://ipv6actnow.org/ and = http://www.ripe.net/ >=20 > All three connect on IPv6 for Snow Leopard. >=20 > All three connect on IPv4 for Lion. >=20 > The ping6/ping delay differences: >=20 > IPv6 IPV4 > www.apnic.net: 29.668/ 30.224/ 30.511/ 0.305 ms 27.484/ 33.900/ = 55.400/ 9.697 ms=20 > www.ripe.net: 384.082/427.672/474.278/32.085 ms = 345.837/379.814/450.711/37.940 ms > ipv6actnow.org: 371.395/409.083/457.154/29.726 ms = 346.257/384.443/434.757/30.477 ms >=20 > I think that from a difference/variance point of view, all three sites = were rationally 'better' on IPv4 I'm missing something. with APNIC and RIPE, the average RTT was less = with IPv6 than IPv4, and in all three cases the standard deviation of = the delay was less with IPv6. You must be looking at the data in a way that isn't related to your = statistics... I don't understand your analysis. > So, in that sense "it worked". -The selection alg as encoded in Lion, = is doing a reasonable job. >=20 > -George > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ggm+ietf@apnic.net Tue Aug 2 16:46:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9492911E80DD for ; Tue, 2 Aug 2011 16:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8TLeChYSD49 for ; Tue, 2 Aug 2011 16:46:33 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 527F011E8095 for ; Tue, 2 Aug 2011 16:46:32 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:80b3:e735:d52a:1924] (unknown [IPv6:2001:dc0:a000:4:80b3:e735:d52a:1924]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 97E51B68F7; Wed, 3 Aug 2011 09:46:40 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 3 Aug 2011 09:46:41 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> To: Fred Baker X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:46:33 -0000 On 03/08/2011, at 9:37 AM, Fred Baker wrote: >=20 > On Jul 31, 2011, at 6:20 PM, George Michaelson wrote: >=20 >> I had a moment in time to test a Snow Leopard, and Lion OSX setup = @home, before completing my upgrade to Lion on all boxes. >>=20 >> I tested http://www.apnic.net/ http://ipv6actnow.org/ and = http://www.ripe.net/ >>=20 >> All three connect on IPv6 for Snow Leopard. >>=20 >> All three connect on IPv4 for Lion. >>=20 >> The ping6/ping delay differences: >>=20 >> IPv6 IPV4 >> www.apnic.net: 29.668/ 30.224/ 30.511/ 0.305 ms 27.484/ 33.900/ = 55.400/ 9.697 ms=20 >> www.ripe.net: 384.082/427.672/474.278/32.085 ms = 345.837/379.814/450.711/37.940 ms >> ipv6actnow.org: 371.395/409.083/457.154/29.726 ms = 346.257/384.443/434.757/30.477 ms >>=20 >> I think that from a difference/variance point of view, all three = sites were rationally 'better' on IPv4 >=20 > I'm missing something. with APNIC and RIPE, the average RTT was less = with IPv6 than IPv4, and in all three cases the standard deviation of = the delay was less with IPv6. >=20 > You must be looking at the data in a way that isn't related to your = statistics... I don't understand your analysis. the figures are min/avg/max/std-dev Column 1 set is IPv6. Column 2 set is IPv4.=20 in two, the IPv6 figure is worse RTT in avg compared to IPv4. I cannot = read this as average RTT less with 6 than 4.=20 apnic 30.244 vs 33.900 is the only one with an apparently better avg and = its the one with the biggest variance in std-dev (0.0305 vs 9.697) and I = suspect, given how *few* packets the HE has to work with, thats a = consequence. ripe, the avg is 427.672 (v6) vs 379.814 (v4) and the std dev is 32.085 = vs 37.940. much closer std-dev. HOw did you see the RIPE average RTT as = less in V6? I agree the std dev is less. For short ping runs, I suspect its not = relevant. I should of course have done far far longer pingruns. Why not get a student to test? I think this is well within the = capabilities of an undergrad networks course! -G >=20 >> So, in that sense "it worked". -The selection alg as encoded in Lion, = is doing a reasonable job. >>=20 >> -George >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From jhw@apple.com Tue Aug 2 17:54:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9493A11E8111 for ; Tue, 2 Aug 2011 17:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.666 X-Spam-Level: X-Spam-Status: No, score=-106.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXNRW8TB5coz for ; Tue, 2 Aug 2011 17:54:01 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 987B111E8119 for ; Tue, 2 Aug 2011 17:54:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPB001XTUGKV2W2@mail-out.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 17:53:28 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-d2-4e389bb162fd Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 51.78.05159.2BB983E4; Tue, 02 Aug 2011 17:52:02 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPB0014SUH32X00@cardamom.apple.com> for v6ops@ietf.org; Tue, 02 Aug 2011 17:53:27 -0700 (PDT) From: james woodyatt In-reply-to: <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> Date: Tue, 02 Aug 2011 17:53:27 -0700 Message-id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OVXfTbAs/gzNr+S1OH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHNvZjAVTOasuDFvDnMD41H2LkZODgkBE4nZ//YxQ9hiEhfu rWfrYuTiEBJoZZI4dmc7G0iCV0BQ4sfkeyxdjBwczALyEgfPy4KEmQW0JL4/amWBqF/JJHH+ QCNYvbBAjMSrebtZQGw2ARWJb5fvMoHYnAL2EmsuXgZbxiKgKjHp10WomSoS/xv4IVbZSBzf uJ8ZaiaLxJtD/1lBEiJA9T9OfmKBOFReYnHLZ8YJjAKzkJw3C+G8WUjOW8DIvIpRsCg1J7HS 0FgvsaAgJ1UvOT93EyMo8BoKZXcw7v/Jf4hRgINRiYeXUd7CT4g1say4MvcQowQHs5II79IQ oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeeR/M/IQE0hNLUrNTUwtSi2CyTBycUg2MzL6uNn+v vvHWa+6q9L1kHtntoeoo+Pe7z4c9N6SvtToaPmk1NM3MnZ/968VHv1qXvtX+x17dnii1R/XG PbNPLkdn/H34wJhlw0dbA6EX+ULzt99s+c2+b5oY+/Rdp47dlCwU7nyUxTiDyc6g9M3hvEnc zbNn9obHsN+8cKNl88fbu07NnhCkq8RSnJFoqMVcVJwIADr5+dM4AgAA Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:54:02 -0000 On Aug 2, 2011, at 16:23 , Ted Lemon wrote: > > Have you done any kind of data collection and analysis that supports your conclusion? Yes, we collect data. We've collected a *lot* of data. Please remember that we didn't implement the happy-eyeballs draft. We're not talking about just the 3-way handshake completion time. We collect statistical data from measurements of the round-trip times stored in the protocol control structures, and we prefer destinations with shorter average round-trips over longer and/or unknown ones. The main reason Apple implemented its concurrent TCP connections SPI to the CFNetwork layer is *not* to support IPv6 transition, but instead to help solve an unrelated problem that arises entirely in IPv4-only networks. It's just gravy that it also happens to help in the IPv6 transition case. We only use the order specified in the RFC3484-revised-02 default policy table for the remaining destinations after we have finished initiating connections to all the destinations with statistically relevant round-trip time measurements. -- james woodyatt member of technical staff, core os networking From newbery@gmail.com Tue Aug 2 18:42:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC721F86EC for ; Tue, 2 Aug 2011 18:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7nlLgF2z0aY for ; Tue, 2 Aug 2011 18:42:09 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9053021F86EA for ; Tue, 2 Aug 2011 18:42:09 -0700 (PDT) Received: by pzk6 with SMTP id 6so584716pzk.26 for ; Tue, 02 Aug 2011 18:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=Khx1ktKjWGkRygdPY14zT7Wr7GNZLfTWIFyjoY5tX8w=; b=dbOTCjaQ3az8nIjvHh5VR0HjxPYZo9YOpPQQn3Y6kJs5pK8POu0sz5icRAfadqm44I TIiqGUcOBmOPfpXW31iWx4j8/gcW/tWDdtOzO2jSLIMg56ATnaQC4ufeutpBUrV2P+fo hhuwXuHe78VVRykVXO94xDoaHp4/LE1ilchhk= Received: by 10.142.49.12 with SMTP id w12mr1900682wfw.425.1312335738663; Tue, 02 Aug 2011 18:42:18 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id p7sm441395pbn.65.2011.08.02.18.42.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 18:42:17 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2--978915864; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 3 Aug 2011 13:42:05 +1200 In-Reply-To: <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> To: IPv6 Operations References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> Message-Id: <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 01:42:10 -0000 --Apple-Mail-2--978915864 Content-Type: multipart/alternative; boundary=Apple-Mail-1--978923303 --Apple-Mail-1--978923303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3/08/2011, at 11:23 AM, Ted Lemon wrote: > On Aug 2, 2011, at 7:12 PM, james woodyatt wrote: >> Those 30ms of additional latency contribute significantly to the = bandwidth delay product. >=20 > Can you expand on that? I hear this a lot, but it doesn't make much = sense, first because the ratio of SYNs to data-bearing packets is = typically large, and secondly because an adaptive algorithm should = automatically eliminate significant delays. >=20 > Have you done any kind of data collection and analysis that supports = your conclusion? Looking at http://www.apple.com I count 32 Images 11 Scripts 5 Stylesheets and the base HTML document itself.=20 49 URLs to be fetched Apple/s front page is if anything atypically spare in terms of elements. = The New York TImes has 126 URLs. If we were just looking at delaying the SINGLE first SYN, and if in = addition we perform no parellisation or other optimisation (and of = course modern browsers do both, but anyway) then 30ms would add 1.5 = seconds to the load time of Apple's page and 3.8 to the NYT. Just from = the bandwidth delay product. As someone who is 75ms from the West Coast of the USA as the photon = flies I am acutely aware of what bandwidth delay product does to my = customers. The SYN:Data ratio is completely irrelevant here. TCP = Windowing can't help during the TCP handshake, and that's what the = customers perceive as slow page loading. Of course, for speed of light = latency it's even worse as we suffer the delay for the full 3-way TCP = handshake, not just the first SYN delay as proposed here. Modern software goes to great lengths to counter this with smart = loading etc, but don't discount even a single extra ms as not mattering. --Apple-Mail-1--978923303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 2, 2011, at 7:12 PM, james woodyatt wrote:
Those 30ms of additional latency contribute significantly to the bandwidth = delay product.

Can you expand on that?   I hear this a lot, but it doesn't = make much sense, first because the ratio of SYNs to data-bearing packets = is typically large, and secondly because an adaptive algorithm should = automatically eliminate significant delays.

Have you done any kind of data collection and analysis that = supports your conclusion?

Looking at http://www.apple.com I = count
32 Images
11 Scripts
5 = Stylesheets
and the base HTML document = itself. 

49 URLs to be = fetched

Apple/s front page is if anything = atypically spare in terms of elements. The New York TImes has 126 = URLs.

If we were just looking at delaying the = SINGLE first SYN, and if in addition we perform no parellisation or = other optimisation (and of course modern browsers do both, but anyway) = then 30ms would add 1.5 seconds to the load time of Apple's page and 3.8 = to the NYT. Just from the bandwidth delay = product.

As someone who is 75ms from the West = Coast of the USA as the photon flies I am acutely aware of what = bandwidth delay product does to my customers. The SYN:Data ratio is = completely irrelevant here. TCP Windowing can't help during the TCP = handshake, and that's what the customers perceive as slow page loading. = Of course, for speed of light latency it's even worse as we suffer the = delay for the full 3-way TCP handshake, not just the first SYN delay as = proposed here.

Modern software goes to great = lengths  to counter this with smart loading etc, but don't discount = even a single extra ms as not mattering.

= --Apple-Mail-1--978923303-- --Apple-Mail-2--978915864 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwODAzMDE0MjEz WjAjBgkqhkiG9w0BCQQxFgQU0ivjNlEL3LX0E11dZvksaiBaX60wgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBAJPjODt7oSwnU2z/4wKqIXdCapxxQowdm9umK1lRRwsKD1P9ADwK1awx8aSy 1o746e5eVHS64zSqiljgkZZqRAhvcICTI72Lxw0pswhxc5HOW54WclgCqlrvfP5wRw1Ge74MdPYh Eb0AeEPkG6O7uXvxMs7+P48ZTiB44Mmw2SviV/Oc9Oi7/sfPlHBlxt0lLvJffIjJac5bd7ltNGj9 KjMp1W4UfDElwFLBD5FMvBACalTaLhzwG6cYnQSS6xFDt7l9NgWDT+qUZEFFsvVpoNg5oO9h3zvl rxqAXX1y1cQdHjAC6Vs6dhLxxyw80yUcZHILuNqtvkFRwAwpQtX9454AAAAAAAA= --Apple-Mail-2--978915864-- From ggm+ietf@apnic.net Tue Aug 2 18:55:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0CB5E8013 for ; Tue, 2 Aug 2011 18:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYFeLyi9CL7K for ; Tue, 2 Aug 2011 18:55:50 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 193AE5E800E for ; Tue, 2 Aug 2011 18:55:50 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:80b3:e735:d52a:1924] (unknown [IPv6:2001:dc0:a000:4:80b3:e735:d52a:1924]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B5EABB68C0; Wed, 3 Aug 2011 11:55:59 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> Date: Wed, 3 Aug 2011 11:56:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <35BA0448-A484-468A-A26F-8590CCF1F530@apnic.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> To: Michael Newbery X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 01:55:51 -0000 Its important not to over-estimate the amount of parallelism available = in the browser. And, for that matter, under-estimate! I assumed we got it all over HTTP 1.1 pipes. Turns out, not widely = deployed.=20 Some say, its 5 channels of parallelism max. Some say, thats not honoured in practice. In the various NAT wars and competing 444/666/464/646/6ot4/ arguments, many have said that per user, 1000 ports is = not unreasonable and I believe IVI and like documents discuss the = relative numbers per customer, and at what point they begin to impact = things.. -G On 03/08/2011, at 11:42 AM, Michael Newbery wrote: >=20 > On 3/08/2011, at 11:23 AM, Ted Lemon wrote: >=20 >> On Aug 2, 2011, at 7:12 PM, james woodyatt wrote: >>> Those 30ms of additional latency contribute significantly to the = bandwidth delay product. >>=20 >> Can you expand on that? I hear this a lot, but it doesn't make much = sense, first because the ratio of SYNs to data-bearing packets is = typically large, and secondly because an adaptive algorithm should = automatically eliminate significant delays. >>=20 >> Have you done any kind of data collection and analysis that supports = your conclusion? >=20 > Looking at http://www.apple.com I count > 32 Images > 11 Scripts > 5 Stylesheets > and the base HTML document itself.=20 >=20 > 49 URLs to be fetched >=20 > Apple/s front page is if anything atypically spare in terms of = elements. The New York TImes has 126 URLs. >=20 > If we were just looking at delaying the SINGLE first SYN, and if in = addition we perform no parellisation or other optimisation (and of = course modern browsers do both, but anyway) then 30ms would add 1.5 = seconds to the load time of Apple's page and 3.8 to the NYT. Just from = the bandwidth delay product. >=20 > As someone who is 75ms from the West Coast of the USA as the photon = flies I am acutely aware of what bandwidth delay product does to my = customers. The SYN:Data ratio is completely irrelevant here. TCP = Windowing can't help during the TCP handshake, and that's what the = customers perceive as slow page loading. Of course, for speed of light = latency it's even worse as we suffer the delay for the full 3-way TCP = handshake, not just the first SYN delay as proposed here. >=20 > Modern software goes to great lengths to counter this with smart = loading etc, but don't discount even a single extra ms as not mattering. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Aug 2 21:52:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52921F874F for ; Tue, 2 Aug 2011 21:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sE8uorILndq for ; Tue, 2 Aug 2011 21:52:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75321F85B5 for ; Tue, 2 Aug 2011 21:52:13 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p734qKqI006958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Aug 2011 04:52:20 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--967509103 From: Joel Jaeggli In-Reply-To: Date: Tue, 2 Aug 2011 21:52:19 -0700 Message-Id: <0744313E-0507-45AF-B263-3C8E91557716@bogus.com> References: To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 03 Aug 2011 04:52:21 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] draft-hilliard-v6ops-ipv6-discard-prefix-00 wg Adoption X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 04:52:14 -0000 --Apple-Mail-10--967509103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Any further discussion of this Draft appears to have been lost in the = onslaught of messages about lan routing protocols and Lion address = selection. Very well, we'll take the sentiment expressed in the working = group for acceptance as a wg document as gospel in the absence of = countervailing opinion. Thanks Joel On Jul 28, 2011, at 3:01 PM, Joel Jaeggli wrote: > The consensus in the WG meeting appears to have been in favor of = adoption, if significant contrary opinions isn't registered on the list = we'll addopt it and probably ask for WG Last Lall shortly thereafter. >=20 > please review: >=20 > http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix-00 >=20 > joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-10--967509103 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Any = further discussion of this Draft appears to have been lost in the = onslaught of  messages about lan routing protocols and Lion address = selection. Very well, we'll take the sentiment expressed in the working = group  for acceptance as a wg document as gospel in the absence of = countervailing = opinion.

Thanks
Joel

= On Jul 28, 2011, at 3:01 PM, Joel Jaeggli wrote:

The consensus in the WG = meeting appears to have been in favor of adoption, if significant = contrary opinions isn't registered on the list we'll addopt it and = probably ask for WG Last Lall shortly = thereafter.

please = review:

http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix-= 00

joel
________________________________= _______________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-10--967509103-- From swmike@swm.pp.se Tue Aug 2 22:42:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308A111E809C for ; Tue, 2 Aug 2011 22:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBFTYqlUHrOd for ; Tue, 2 Aug 2011 22:42:57 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75C11E8086 for ; Tue, 2 Aug 2011 22:42:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF17E9C; Wed, 3 Aug 2011 07:43:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA85C9A; Wed, 3 Aug 2011 07:43:04 +0200 (CEST) Date: Wed, 3 Aug 2011 07:43:04 +0200 (CEST) From: Mikael Abrahamsson To: "t.petch" In-Reply-To: <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> Message-ID: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 05:42:58 -0000 On Tue, 2 Aug 2011, t.petch wrote: > I think that for most people the expectation is that I-D leads to RFC or > else to disappointment. Yes, I agree too. Producing a properly formatted I-D is something I would consider being a considerable effort. Writing on the list is for me an equivalent to brainstorm in front of the whiteboard, and THEN when something is hammered out a bit and there seems to be some interest and traction, THEN I produce a document in expectation that this will end up as a final product documenting whatever was discussed. I never start by producing a document before even discussing with my coworkers. I know some do, I don't. Different ways of working. When someone says "put down your idea in form of an I-D and come present it at an IETF meeting, otherwise we're not interested" I read that as "please go away". -- Mikael Abrahamsson email: swmike@swm.pp.se From despres.remi@laposte.net Wed Aug 3 00:24:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6C21F8844 for ; Wed, 3 Aug 2011 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MlnjgVIrCqZ for ; Wed, 3 Aug 2011 00:24:54 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA5821F8834 for ; Wed, 3 Aug 2011 00:24:53 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 061CB700008B; Wed, 3 Aug 2011 09:25:04 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id AD8A4700008A; Wed, 3 Aug 2011 09:24:59 +0200 (CEST) X-SFR-UUID: 20110803072459710.AD8A4700008A@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 3 Aug 2011 09:24:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG , Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:24:55 -0000 Le 2 ao=FBt 2011 =E0 17:17, Philip Homburg a =E9crit : ... >> After all, LSN costs and service quality are passed on to the = customer. Indeed. That's why stateless solutions, where they apply, can be better for = users than LSN-based ones: they tend to be less expensive than LSN-based = solutions, in capex and opex = (tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02)= . > At the moment there is almost no content on IPv6 and also about no = ISPs > providing their users with IPv6. Note that Google is a very significant IPv6-enbled content provider. IETF is less significant, but also a useful one. There may be, I suppose, many others we don't know. > So, vendors have plenty of time to get their act together in this = respect. Whatever the amount of time found to be left for ubiquitous IPv6 = enablement, the earlier the better. Regards, RD >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Wed Aug 3 00:35:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37621F8AEC for ; Wed, 3 Aug 2011 00:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7IHtrUxsajz for ; Wed, 3 Aug 2011 00:35:27 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6679621F8AE1 for ; Wed, 3 Aug 2011 00:35:27 -0700 (PDT) Received: by wwe5 with SMTP id 5so356141wwe.13 for ; Wed, 03 Aug 2011 00:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/N0Kzwv3uxEt5oDR08OetR5mu5ghihCfPmnSbuv5bs=; b=NKZ5mfVH/Q8S1pH7LL5mRHUZyyDqS2Cb5u7IpaLGaGUq0Mgb1lsuoftbclzxldRw5q qvWfJFn2HoxNDI703pHwKfRzEZhvCWGmsYUUGpwxF5X9GJ0W0cUqejcRJAvB4FvkZbu5 HKaDmzxe2VPhYUvStIVfko7BkwuDDPkwlAGXs= MIME-Version: 1.0 Received: by 10.216.14.19 with SMTP id c19mr2509125wec.88.1312356937730; Wed, 03 Aug 2011 00:35:37 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Wed, 3 Aug 2011 00:35:37 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Wed, 3 Aug 2011 00:35:37 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> Date: Wed, 3 Aug 2011 00:35:37 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=001485f1ec0c178a6204a994e944 Cc: v6ops v6ops WG , Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:35:28 -0000 --001485f1ec0c178a6204a994e944 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 3, 2011 12:25 AM, "R=E9mi Despr=E9s" wrot= e: > > > Le 2 ao=FBt 2011 =E0 17:17, Philip Homburg a =E9crit : > ... > >> After all, LSN costs and service quality are passed on to the customer= . > > Indeed. > > That's why stateless solutions, where they apply, can be better for users than LSN-based ones: they tend to be less expensive than LSN-based solutions, in capex and opex ( tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02). > Do you have data to support the claim that stateless is less expensive ? I have not seen a kit price comparison ? projected cost comparison of stateless vs. Stateful ? Cb > > At the moment there is almost no content on IPv6 and also about no ISPs > > providing their users with IPv6. > > Note that Google is a very significant IPv6-enbled content provider. > IETF is less significant, but also a useful one. > There may be, I suppose, many others we don't know. > > > > So, vendors have plenty of time to get their act together in this respect. > > Whatever the amount of time found to be left for ubiquitous IPv6 enablement, the earlier the better. > > Regards, > RD > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --001485f1ec0c178a6204a994e944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 3, 2011 12:25 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 2 ao=FBt 2011 =E0 17:17, Philip Homburg a =E9crit :
> ...
> >> After all, LSN costs and service quality are passed on to the= customer.
>
> Indeed.
>
> That's why stateless solutions, where they apply, can be better fo= r users than LSN-based ones: they tend to be less expensive than LSN-based = solutions, in capex and opex (tools.ietf.org/html/draft-op= erators-softwire-stateless-4v6-motivation-02).
>

Do you have data to support the claim that stateless is less expensive ?= I have not seen a kit price comparison ? projected cost comparison of stat= eless vs. Stateful ?

Cb
> > At the moment there is almost no content on IPv6 and also about n= o ISPs
> > providing their users with IPv6.
>
> Note that Google is a very significant IPv6-enbled content provider. > IETF is less significant, but also a useful one.
> There may be, I suppose, many others we don't know.
>
>
> > So, vendors have plenty of time to get their act together in this= respect.
>
> Whatever the amount of time found to be left for ubiquitous IPv6 enabl= ement, the earlier the better.
>
> Regards,
> RD
>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
>

--001485f1ec0c178a6204a994e944-- From despres.remi@laposte.net Wed Aug 3 00:55:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F7A21F873D for ; Wed, 3 Aug 2011 00:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shqfp0rVFVS1 for ; Wed, 3 Aug 2011 00:55:40 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 89CF521F874E for ; Wed, 3 Aug 2011 00:55:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 4A009700008D; Wed, 3 Aug 2011 09:55:51 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 08E60700008C; Wed, 3 Aug 2011 09:55:51 +0200 (CEST) X-SFR-UUID: 20110803075551365.08E60700008C@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 3 Aug 2011 09:55:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:55:41 -0000 Hi, James, 100% agreement on points you make. May I add that: - To promote IPv6, that is generalizing good IPv6 service that will be = efficient (not wasting energy and money to further damage the IPv4 = service).=20 With IPv4, the lack of global addresses available everywhere, and the = uncertainty as to how many ports applications can use, are already good = reasons to generalize IPv6-service availability. - How damageable to users a voluntary impediment would be cannot be = reliably estimated from ping-based measurements, made at a specific time = from specific locations. King regards, RD =20 Le 3 ao=FBt 2011 =E0 01:12, james woodyatt a =E9crit : > On Aug 2, 2011, at 14:05 , Philip Homburg wrote: >>=20 >> I'd say that preferring IPv6 is more consistent. At the moment I'm = using 30ms as the cut off for 'roughly equal' and that seems to be = working well. >=20 > Those 30ms of additional latency contribute significantly to the = bandwidth delay product. >=20 > You may find them acceptable, but Apple engineers have looked pretty = closely at it and decided that no time interval that could possibly make = a difference would be tolerated by users. +1 > I don't want to make users pay with a delay factor in the bandwidth = delay product just to push an agenda that operators may or may not = actually share, depending on with whom you are talking this week. +1 >=20 >> For quite a while I didn't want to this either. I had the same idea = that >> connecting to whatever is faster is best. But when you think about = it, >> the whole world trying to connect to whatever system is fastest. You = deny >> operators an imporant tool for essentially no gain for the customer. >=20 > I don't see it that way. I see those 0-30ms of additional latency as = an unacceptable penalty that we would be asking our users to pay, in = exchange for nothing of any measurable value to them. =20 +1 > Do you see where our different perspectives leads us to reach = different conclusions? >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Wed Aug 3 00:57:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE72021F8829 for ; Wed, 3 Aug 2011 00:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veGuWx8LCOSJ for ; Wed, 3 Aug 2011 00:57:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3576921F873D for ; Wed, 3 Aug 2011 00:57:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C9E469C; Wed, 3 Aug 2011 09:57:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C78FC9A; Wed, 3 Aug 2011 09:57:10 +0200 (CEST) Date: Wed, 3 Aug 2011 09:57:10 +0200 (CEST) From: Mikael Abrahamsson To: Cameron Byrne In-Reply-To: Message-ID: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Daniel Roesen , v6ops v6ops WG Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:57:01 -0000 On Wed, 3 Aug 2011, Cameron Byrne wrote: > Do you have data to support the claim that stateless is less expensive ? > I have not seen a kit price comparison ? projected cost comparison of > stateless vs. Stateful ? Compare 6to4 wirespeed support in Cisco 7600/Sup720 for instance, where it'll do 10-15Mpps (or so) of translation, and this on 5+ year old kit. If they would have known about 6RD back then, I'm sure they could have implemented it at little extra cost. Even today, buying similar capacity stateful gear I'd say is more expensive, and they also have quite limited session setup rates compared to this nonexistant problem in stateless implementations. -- Mikael Abrahamsson email: swmike@swm.pp.se From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 01:11:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E8521F8B37 for ; Wed, 3 Aug 2011 01:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.486 X-Spam-Level: X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAO8WQLvecuH for ; Wed, 3 Aug 2011 01:11:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B421F8B33 for ; Wed, 3 Aug 2011 01:11:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoWYL-0001idC; Wed, 3 Aug 2011 10:11:45 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> In-reply-to: Your message of "Tue, 02 Aug 2011 16:12:32 -0700 ." Date: Wed, 03 Aug 2011 10:11:39 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:11:42 -0000 In your letter dated Tue, 02 Aug 2011 16:12:32 -0700 you wrote: >On Aug 2, 2011, at 14:05 , Philip Homburg wrote: >> >> I'd say that preferring IPv6 is more consistent. At the moment I'm using 30ms > as the cut off for 'roughly equal' and that seems to be working well. > >Those 30ms of additional latency contribute significantly to the bandwidth dela >y product. > >You may find them acceptable, but Apple engineers have looked pretty closely at > it and decided that no time interval that could possibly make a difference wou >ld be tolerated by users. I don't think I can follow you. What context do you have in mind? In my mind, HE is something that works for many, short-lived connections. HE only gets it right on average. With many short-lived connections that is fine. If you start a large download or if it is a long ssh session, a vnc session, etc., and HE gets it wrong, then it will have a significant impact. Taking your statement literally, 30ms delay on a 1Gbit/s links requires extra buffering of 3.75 MByte. I'm sure you can find products with a 1 Gbit/s interface that are short on memory, but I don't think Apple products are among them. If we drop down to more realistic WAN speeds, then at 100Mbit/s, the extra buffer requirements are 375kByte. So, I'm quite curious what customers you have that would notice an extra 4MByte memory used per 1 Gbit/s of WAN speed. I don't have enough experience with Apple products to know if Apple does something exceedingly clever, but when links start filling up, overall delay increases. Your statement suggest that Apple can do large downloads and still keep the impact on total latency far less than 30ms. This is very impressive. That would mean that VoIP etc, would not require any special treatment because just buffering for tens of milliseconds would be enough. Great. Is that delay control technology already in Snow Leopard or do I have to upgrade to Lion? I guess I can do some experiments to see how it works in Snow Leopard. >push an agenda that operators may or may >not actually share, depending on with whom you are talking this week. I'm quite curious what ISPs prefer CGN over IPv6. But there is an easy way out for them: just don't roll out IPv6. >I don't see it that way. I see those 0-30ms of additional latency as an unacce >ptable penalty that we would be asking our users to pay, in exchange for nothin >g of any measurable value to them. Do you see where our different perspectives > leads us to reach different conclusions? I think CGNs have many risks. Apple ships products worldwide. So customers do not just connect to ISPs who have enough money to do CGN perfectly. There will be plenty will do CGN just barely good enough. And my experience with bad NATs tells me that I would gladly except a 30ms extra delay to get an IPv6 connection without NAT. Life is too short to deal with flaky network connections. In an organization that actually has its act together, the difference in latency between IPv6 and IPv4 is close to zero. So another question is what customers you are thinking about who have IPv6 connections that are actually 30ms worse than IPv4 and still care that much about performance. It doesn't seem to add up. From despres.remi@laposte.net Wed Aug 3 01:14:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D321F8AE9 for ; Wed, 3 Aug 2011 01:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp6jAmHBT7On for ; Wed, 3 Aug 2011 01:14:39 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8686521F8AE1 for ; Wed, 3 Aug 2011 01:14:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 777D2700008E; Wed, 3 Aug 2011 10:14:49 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 20EC2700008D; Wed, 3 Aug 2011 10:14:49 +0200 (CEST) X-SFR-UUID: 20110803081449134.20EC2700008D@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-72--955359766 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 3 Aug 2011 10:14:49 +0200 Message-Id: <2C1F7A8E-504D-4A98-A86F-04730761671C@laposte.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG , Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:14:39 -0000 --Apple-Mail-72--955359766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 3 ao=FBt 2011 =E0 09:35, Cameron Byrne a =E9crit : >=20 > On Aug 3, 2011 12:25 AM, "R=E9mi Despr=E9s" = wrote: > > > > > > Le 2 ao=FBt 2011 =E0 17:17, Philip Homburg a =E9crit : > > ... > > >> After all, LSN costs and service quality are passed on to the = customer. > > > > Indeed. > > > > That's why stateless solutions, where they apply, can be better for = users than LSN-based ones: they tend to be less expensive than LSN-based = solutions, in capex and opex = (tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02)= . > > >=20 > Do you have data to support the claim that stateless is less expensive = ? I have not seen a kit price comparison ? projected cost comparison of = stateless vs. Stateful=20 >=20 No precise data, but confidence in past experience in other contexts, = and in reasons expressed by operators who signed the draft. The point is only that, since users always pay at the end, they have a = stake in having operators choosing solutions that are the less expensive = to them. If a particular operator has competitive prices for LSN solutions, = that's a good choice for it (I appreciate arguments you made and which = apply to your 3GPP network).=20 It is clear, however, that the draft is from operators having different = constraints. That's why I only said "tend to be" less expensive. Regards, RD > Cb > > > At the moment there is almost no content on IPv6 and also about no = ISPs > > > providing their users with IPv6. > > > > Note that Google is a very significant IPv6-enbled content provider. > > IETF is less significant, but also a useful one. > > There may be, I suppose, many others we don't know. > > > > > > > So, vendors have plenty of time to get their act together in this = respect. > > > > Whatever the amount of time found to be left for ubiquitous IPv6 = enablement, the earlier the better. > > > > Regards, > > RD > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --Apple-Mail-72--955359766 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Aug 3, 2011 12:25 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:
>
>
> Le 2 ao=FBt 2011 =E0 17:17, Philip Homburg a =E9crit :
> ...
> >> After all, LSN costs and service quality are passed on to = the customer.
>
> Indeed.
>
> That's why stateless solutions, where they apply, can be better for = users than LSN-based ones: they tend to be less expensive than LSN-based = solutions, in capex and opex (tools.ietf.org/html/draft-operators-softwire-stateless-4v6-= motivation-02).
>

Do you have data to support the claim that stateless is less = expensive ? I have not seen a kit price comparison ? projected cost = comparison of stateless vs. Stateful 

No precise = data, but confidence in past experience in other contexts, and in = reasons expressed by operators who signed the draft.
The point = is only that, since users always pay at the end, they have a stake in = having operators choosing solutions that are the less expensive to = them.

If a particular operator has competitive = prices for LSN solutions, that's a good choice for it (I appreciate = arguments you made and which apply to your 3GPP = network). 
It is clear, however, that the draft is from = operators having different constraints.
That's why I only said = "tend to be" less = expensive.

Regards,
RD


Cb
> > At the moment there is almost no content on IPv6 and also = about no ISPs
> > providing their users with IPv6.
>
> Note that Google is a very significant IPv6-enbled content = provider.
> IETF is less significant, but also a useful one.
> There may be, I suppose, many others we don't know.
>
>
> > So, vendors have plenty of time to get their act together in = this respect.
>
> Whatever the amount of time found to be left for ubiquitous IPv6 = enablement, the earlier the better.
>
> Regards,
> RD
>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/= mailman/listinfo/v6ops
>
>


= --Apple-Mail-72--955359766-- From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 01:21:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED09C21F8B04 for ; Wed, 3 Aug 2011 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMrctKqeSB5U for ; Wed, 3 Aug 2011 01:21:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2332121F8B03 for ; Wed, 3 Aug 2011 01:21:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoWhQ-0001ieC; Wed, 3 Aug 2011 10:21:08 +0200 Message-Id: To: George Michaelson From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <35BA0448-A484-468A-A26F-8590CCF1F530@apnic.net> In-reply-to: Your message of "Wed, 3 Aug 2011 11:56:01 +1000 ." <35BA0448-A484-468A-A26F-8590CCF1F530@apnic.net> Date: Wed, 03 Aug 2011 10:21:07 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:21:05 -0000 In your letter dated Wed, 3 Aug 2011 11:56:01 +1000 you wrote: >Its important not to over-estimate the amount of parallelism available in the b >rowser. And, for that matter, under-estimate! > >I assumed we got it all over HTTP 1.1 pipes. Turns out, not widely deployed. I've been looking quite a bit a web traffic recently. As far as I can tell, it is almost exclusively http/1.1. Sometimes there is an http/1.0 box, but is is very rare. >Some say, its 5 channels of parallelism max. >Some say, thats not honoured in practice. Ah, you mean HTTP pipelining? I don't think it is used very much. I don't think it is very important either. Firefox defaults to 15 parallel connections to a single server. At that point adding piplining doesn't give you much extra. From prvs=119674f2b5=jordi.palet@consulintel.es Wed Aug 3 01:36:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695DC21F8880 for ; Wed, 3 Aug 2011 01:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byRMorUihChk for ; Wed, 3 Aug 2011 01:36:30 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id F122421F8B24 for ; Wed, 3 Aug 2011 01:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1312360092; x=1312964892; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=wRyWja/kZY0qyhw65XgTmYkvpMFxpvkfZqpXKSq1HjU=; b=E65 0r9XC9JUIU4/IS1Y7QSPO8RO0yVpeFDtqj5XNzZpJMj3hWIdQ9irz6bvA8uz1WEP cjV77TLBQn3Kh+WWNThlg5WhA41y6RFRReqQt8ktGtxhrTUHQge15AKGgGgwyhhH E88NNHR8tjdXnlVDmxnCAv1MpTbGwgGABOnmnjnk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JStW8DTCCLMrqdAafFIHG13BhU9G4gfccf3Lv4nOM6EDI29qDgqKCngQGEE4 spAv7cVY77PxdubKaEWqqX7YYfXUz7XgMnbBvUjzw+JCH/M/US6I1d+I8 LbN3tcNrI5MNJJ+Sy66f+1OPdgFh23koZ42L+isS7j1zqegHw+IXNw=; X-MDAV-Processed: consulintel.es, Wed, 03 Aug 2011 10:28:12 +0200 Received: from [10.10.10.115] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003957089.msg for ; Wed, 03 Aug 2011 10:28:11 +0200 X-Spam-Processed: consulintel.es, Wed, 03 Aug 2011 10:28:11 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110803:md50003957089::x43Y8an8VkQl42r4:000052FI X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=119674f2b5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 10:36:25 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:36:31 -0000 Similar experience here. Since installed Lion, I've difficulty to access with IPv6, where it worked before, and still works with Windows. I think Apple is doing very wrong with this implementation. A small RTT difference should not give preference to IPv4, and the user needs to have a way to chose it. Being so strict with RTT will damage IPv6 deployment. Regards, Jordi -----Mensaje original----- De: George Michaelson Responder a: Fecha: Wed, 3 Aug 2011 09:46:41 +1000 Para: Fred Baker CC: IPv6 Operations Asunto: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. > >On 03/08/2011, at 9:37 AM, Fred Baker wrote: > >> >> On Jul 31, 2011, at 6:20 PM, George Michaelson wrote: >> >>> I had a moment in time to test a Snow Leopard, and Lion OSX setup >>>@home, before completing my upgrade to Lion on all boxes. >>> >>> I tested http://www.apnic.net/ http://ipv6actnow.org/ and >>>http://www.ripe.net/ >>> >>> All three connect on IPv6 for Snow Leopard. >>> >>> All three connect on IPv4 for Lion. >>> >>> The ping6/ping delay differences: >>> >>> IPv6 IPV4 >>> www.apnic.net: 29.668/ 30.224/ 30.511/ 0.305 ms 27.484/ 33.900/ >>>55.400/ 9.697 ms >>> www.ripe.net: 384.082/427.672/474.278/32.085 ms >>>345.837/379.814/450.711/37.940 ms >>> ipv6actnow.org: 371.395/409.083/457.154/29.726 ms >>>346.257/384.443/434.757/30.477 ms >>> >>> I think that from a difference/variance point of view, all three sites >>>were rationally 'better' on IPv4 >> >> I'm missing something. with APNIC and RIPE, the average RTT was less >>with IPv6 than IPv4, and in all three cases the standard deviation of >>the delay was less with IPv6. >> >> You must be looking at the data in a way that isn't related to your >>statistics... I don't understand your analysis. > >the figures are min/avg/max/std-dev > >Column 1 set is IPv6. Column 2 set is IPv4. > >in two, the IPv6 figure is worse RTT in avg compared to IPv4. I cannot >read this as average RTT less with 6 than 4. > >apnic 30.244 vs 33.900 is the only one with an apparently better avg and >its the one with the biggest variance in std-dev (0.0305 vs 9.697) and I >suspect, given how *few* packets the HE has to work with, thats a >consequence. > >ripe, the avg is 427.672 (v6) vs 379.814 (v4) and the std dev is 32.085 >vs 37.940. much closer std-dev. HOw did you see the RIPE average RTT as >less in V6? > > >I agree the std dev is less. For short ping runs, I suspect its not >relevant. I should of course have done far far longer pingruns. > >Why not get a student to test? I think this is well within the >capabilities of an undergrad networks course! > >-G > >> >>> So, in that sense "it worked". -The selection alg as encoded in Lion, >>>is doing a reasonable job. >>> >>> -George >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 01:45:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2D21F8AB9 for ; Wed, 3 Aug 2011 01:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4kHBGTGiXsk for ; Wed, 3 Aug 2011 01:45:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2447621F8551 for ; Wed, 3 Aug 2011 01:45:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoX5D-0001gCC; Wed, 3 Aug 2011 10:45:43 +0200 Message-Id: To: Michael Newbery From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> In-reply-to: Your message of "Wed, 3 Aug 2011 13:42:05 +1200 ." <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> Date: Wed, 03 Aug 2011 10:45:38 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:45:38 -0000 In your letter dated Wed, 3 Aug 2011 13:42:05 +1200 you wrote: >Looking at http://www.apple.com I count >32 Images >11 Scripts >5 Stylesheets >and the base HTML document itself.=20 > >49 URLs to be fetched > >Apple/s front page is if anything atypically spare in terms of elements. = >The New York TImes has 126 URLs. > >If we were just looking at delaying the SINGLE first SYN, and if in = >addition we perform no parellisation or other optimisation (and of = >course modern browsers do both, but anyway) then 30ms would add 1.5 = >seconds to the load time of Apple's page and 3.8 to the NYT. Just from = >the bandwidth delay product. The delay bandwidth product is the amount of data that has to be kept in flight to fill the 'tube'. You can't just add up delays of different connections. It is the delay across a single connection that matters. Anyhow, browsers do use parallelism to reduce the impact of latency. Why do you then present a calculation that assumes they don't? For 49 URLs at 15 URLs in parallel to a single server, this would give an additional delay of 120ms. Hardly worth writing home about. For 126 URLs it would be 270ms. >As someone who is 75ms from the West Coast of the USA as the photon = >flies I am acutely aware of what bandwidth delay product does to my = >customers. The SYN:Data ratio is completely irrelevant here. TCP = >Windowing can't help during the TCP handshake, and that's what the = >customers perceive as slow page loading. Of course, for speed of light = >latency it's even worse as we suffer the delay for the full 3-way TCP = >handshake, not just the first SYN delay as proposed here. Slow start is an issue here. And some content providers play tricks with that. >Modern software goes to great lengths to counter this with smart = >loading etc, but don't discount even a single extra ms as not mattering. Not all content is available at your local IX. In my experience, page design is a major factor. Bloated, badly designed pages take forever to load on anything that is not on the page designer's LAN. Well designed pages load quickly even across continents. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 02:09:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7A721F8B28 for ; Wed, 3 Aug 2011 02:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeMxhq6WfJ7N for ; Wed, 3 Aug 2011 02:09:12 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 741DC21F856A for ; Wed, 3 Aug 2011 02:09:12 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QoXQJ-0001el-D4; Wed, 03 Aug 2011 18:37:31 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id F21CD3B34D; Wed, 3 Aug 2011 18:37:30 +0930 (CST) Date: Wed, 3 Aug 2011 18:37:29 +0930 From: Mark Smith To: "Brzozowski, John" Message-ID: <20110803183729.0a1367f8@opy.nosense.org> In-Reply-To: References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:09:13 -0000 On Tue, 2 Aug 2011 21:34:59 +0000 "Brzozowski, John" wrote: > +1 for the below. > Do people realise that ISIS was designed in the era of 20Mhz Motorola 68000s, and that Cisco used to have a paper which advised that an OSPF area should had no more than 50 routers and 200 links, and they were talking about Cisco 2500s, which IIRC had Motorola 68020s and no more than 512KB or 1MB of RAM? The cheapest residential CPE today and in the last 5 years easily exceeded the processing power of the routers when ISIS and OSPF were developed. My 4 year old ADSL router has a 200Mhz ARM CPU in it and 16MB of RAM, and it was a baseline model, costing less than $80 - $100 US (i.e. around $100AU). OSPF and ISIS are not heavy duty or heavy weight these days (and haven't been for more than a decade), and provide distinct re-convergence advantages over RIP, as well as the ability to carry around or be easily extended to carry around information that is not packet forwarding related e.g. services. > > On 8/1/11 11:33 AM, "Rajiv Asati (rajiva)" wrote: > > >Agreed to the use case, but having to run a heavy-duty protocol like > >OSPF or ISIS is an overkill to this use case, IMO. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Wed Aug 3 02:26:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9121F8B1A for ; Wed, 3 Aug 2011 02:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbviwihJYPi9 for ; Wed, 3 Aug 2011 02:26:55 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1026C21F89CC for ; Wed, 3 Aug 2011 02:26:55 -0700 (PDT) Received: from macpro.10ww.steffann.nl (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 845632024; Wed, 3 Aug 2011 11:21:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <20110803183729.0a1367f8@opy.nosense.org> Date: Wed, 3 Aug 2011 11:21:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77116DED-1412-411C-B142-48E9ABF42199@steffann.nl> References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1244.3) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:26:56 -0000 Hi Mark, > The cheapest residential CPE today and in the last 5 years easily > exceeded the processing power of the routers when ISIS and OSPF were > developed. My 4 year old ADSL router has a 200Mhz ARM CPU in it and > 16MB of RAM, and it was a baseline model, costing less than $80 - $100 > US (i.e. around $100AU).=20 >=20 > OSPF and ISIS are not heavy duty or heavy weight these days (and > haven't been for more than a decade), and provide distinct > re-convergence advantages over RIP, as well as the ability to carry > around or be easily extended to carry around information that is not > packet forwarding related e.g. services. I fully agree. I have MikroTik routers here that do RIP, OSPF, BGP, MPLS = etc. on both IPv4 and IPv6 in a box costing $40. Sincerely, Sander Steffann From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 02:40:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52321F8748 for ; Wed, 3 Aug 2011 02:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdEqV7-ovhQD for ; Wed, 3 Aug 2011 02:40:32 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9001321F8749 for ; Wed, 3 Aug 2011 02:40:32 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QoXwN-0002u8-Nq; Wed, 03 Aug 2011 19:10:39 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 1576A3B354; Wed, 3 Aug 2011 19:10:39 +0930 (CST) Date: Wed, 3 Aug 2011 19:10:38 +0930 From: Mark Smith To: Keith Moore Message-ID: <20110803191038.4f11a1b7@opy.nosense.org> In-Reply-To: <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:40:33 -0000 On Tue, 2 Aug 2011 11:56:24 -0400 Keith Moore wrote: > On Aug 2, 2011, at 11:39 AM, Nick Hilliard wrote: > > > On 02/08/2011 13:28, Keith Moore wrote: > >> A different idea is that the firewall always work in a very minimal mode > >> by default (e.g. it passes no traffic, or maybe only outgoing port 80 > >> traffic, but its configuration interface is enabled for the internal > >> ports) so that the user must configure it in order to get it to do > >> anything useful. > > > > Each support call into a support centre costs money, and if you scale it > > up, any user that ends up calling support is basically losing money for the > > ISP. Yes, margins are that thin. > > > > Building a firewall that almost guarantees that an end-user will need to > > open a support call is both useless to the end-user and financially harmful > > to a service provider. There is no point whatsoever in doing this - it > > adds pointless complexity with no measurable return. > > > > If you want to build a router suitable for Keith Moore, then go out and > > customise a WRT54G, or hack a soekris into shape. But don't assume that > > most end-users have either the interest or the capability to work out a > > good quality security policy for themselves because by-and-large, they don't. > Which is why host OS vendors have taken over that policy definition, and provided simple labels such as "home network", "public network" etc. and, for example, when the link on a network connection comes up, asks the end-user where they are/what type of network they've attached to - and that could be automated by recognising the attached networks by using network identifiers such as Wifi SSID or default router MAC addresses. > I understand all of that. What I'm saying is that having the router try to be clever about what the policy should be, is even worse. > And if CPE firewalls become too smart or too obstructionist, Internet application developers will just come up with, or rather, reuse the NAT traversal techniques they've developed in the past, adapted to IPv6, to make their applications traverse those CPE firewalls. Fundamentally I think an arms war exists between Internet application developers and the entities who deploy network located constraints, such as firewalls or NAT, which the networked application developers will always want to win. If their networked applications can't work over the Internet, regardless of the commonly encountered constraints, then there is no point in writing them in the first place, so the developers have a very basic and fundamental motive to work around these constraints. From nick@inex.ie Wed Aug 3 03:19:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18421F8B4E for ; Wed, 3 Aug 2011 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pn3YYVXqCrM for ; Wed, 3 Aug 2011 03:19:56 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id 912D521F8B4B for ; Wed, 3 Aug 2011 03:19:55 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 7C3FA28423 for ; Wed, 3 Aug 2011 11:20:05 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MypiGwM1-90Y for ; Wed, 3 Aug 2011 11:20:04 +0100 (IST) Received: from cupcake.local (unknown [87.198.142.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by prometheus.inex.ie (Postfix) with ESMTPSA id D84FF28421 for ; Wed, 3 Aug 2011 11:20:02 +0100 (IST) Message-ID: <4E3920D1.1090705@inex.ie> Date: Wed, 03 Aug 2011 11:20:01 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> In-Reply-To: <20110803183729.0a1367f8@opy.nosense.org> X-Enigmail-Version: 1.2 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 Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:19:56 -0000 On 03/08/2011 10:07, Mark Smith wrote: > OSPF and ISIS are not heavy duty or heavy weight these days (and > haven't been for more than a decade), and provide distinct > re-convergence advantages over RIP, as well as the ability to carry > around or be easily extended to carry around information that is not > packet forwarding related e.g. services. On a similar note, I'd like to propose that all new vespa scooters be equipped with turbo and superchargers, power steering, electronic drive control, dolby 5.1 speakers and tow-hitches. The rationale is quite clear: these technologies are mature, not at all heavy duty, and carry distinct advantages over alternatives, as well as providing the ability to carry around or be easily extended to carry around equipment that is not scooter related e.g. building materials, boats, rock-concert kit, etc. Nick From jari.arkko@piuha.net Wed Aug 3 03:22:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2185B21F8877 for ; Wed, 3 Aug 2011 03:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttOMtYiGVXBf for ; Wed, 3 Aug 2011 03:22:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3221F8876 for ; Wed, 3 Aug 2011 03:22:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 74ACA2D403; Wed, 3 Aug 2011 13:23:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+c3G9SiPbdu; Wed, 3 Aug 2011 13:23:03 +0300 (EEST) Received: from www.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 080ED2CE66; Wed, 3 Aug 2011 13:23:03 +0300 (EEST) Received: from 87.93.72.13 (SquirrelMail authenticated user jarkko) by www.piuha.net with HTTP; Wed, 3 Aug 2011 13:23:03 +0300 Message-ID: <232e34b2e8abec3c882e23871cca1c9b.squirrel@www.piuha.net> In-Reply-To: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> Date: Wed, 3 Aug 2011 13:23:03 +0300 From: jari.arkko@piuha.net To: "Mikael Abrahamsson" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:22:55 -0000 Speaking as one of the authors. Ari and I have a few drafts (and more to come) of the nature "we observed technology X in environment Y and here are our measurement results". We've been wondering what to do with some of the drafts. I believe some would be useful to publish in a more permanent form than an ID. With feedback folded in, where available. That being said, while in general measurements are very interesting for v6ops (imo more interesting than new solution ideas), but its not clear that the group should spend a lot of time finetuning the results, merging different drafts, etc. In short, if there is interest and feedback we will put in serious effort to get docs like this out as v6ops RFC. Otherwise, we are inclined to publish something ad independent RFC, technical report or some academic forum. Jari From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 03:31:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4909021F8B5A for ; Wed, 3 Aug 2011 03:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0m7YhjbuZEC for ; Wed, 3 Aug 2011 03:31:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7921F8B59 for ; Wed, 3 Aug 2011 03:31:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QoYk9-0001iFC; Wed, 3 Aug 2011 12:32:05 +0200 Message-Id: To: Nick Hilliard From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> In-reply-to: Your message of "Wed, 03 Aug 2011 11:20:01 +0100 ." <4E3920D1.1090705@inex.ie> Date: Wed, 03 Aug 2011 12:32:01 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:31:55 -0000 In your letter dated Wed, 03 Aug 2011 11:20:01 +0100 you wrote: >On 03/08/2011 10:07, Mark Smith wrote: >> OSPF and ISIS are not heavy duty or heavy weight these days (and >> haven't been for more than a decade), and provide distinct >> re-convergence advantages over RIP, as well as the ability to carry >> around or be easily extended to carry around information that is not >> packet forwarding related e.g. services. > >On a similar note, I'd like to propose that all new vespa scooters be >equipped with turbo and superchargers, power steering, electronic drive >control, dolby 5.1 speakers and tow-hitches. The rationale is quite clear: >these technologies are mature, not at all heavy duty, and carry distinct >advantages over alternatives, as well as providing the ability to carry >around or be easily extended to carry around equipment that is not scooter >related e.g. building materials, boats, rock-concert kit, etc. I don't think this remark doesn't help in the context of homenet. What's the point of now saying, oh OSPF, IS-IS, are way too big, it has to be RIP. Only to later find out that you may need all kinds of extra protocols for things that are already solved in OSPF, etc. I think the main thing that should be done now is trying to figure out the scope of a homenet. How many kitchen sinks do we want. From jari.arkko@piuha.net Wed Aug 3 03:34:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9FF21F8A71 for ; Wed, 3 Aug 2011 03:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrDqCiNXOB8M for ; Wed, 3 Aug 2011 03:34:39 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2133621F8865 for ; Wed, 3 Aug 2011 03:34:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3A9482D403; Wed, 3 Aug 2011 13:34:50 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz82gIYGHZPj; Wed, 3 Aug 2011 13:34:49 +0300 (EEST) Received: from www.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 647062CE66; Wed, 3 Aug 2011 13:34:49 +0300 (EEST) Received: from 87.93.72.13 (SquirrelMail authenticated user jarkko) by www.piuha.net with HTTP; Wed, 3 Aug 2011 13:34:49 +0300 Message-ID: In-Reply-To: <4E3920D1.1090705@inex.ie> References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> Date: Wed, 3 Aug 2011 13:34:49 +0300 From: jari.arkko@piuha.net To: "Nick Hilliard" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:34:39 -0000 I do not think its surprising that hardware can run these things. Sure it can. The phone that I am using to write this message certainly can. My watch propably could too. Its also not surprising that with more/newer protocols you can handle more situations, >15 hops, pathologic topologies, user errors, multihoming,mobility, qos. I have no skin in this game, but I am still from the school of thought that it matters what code is easiest available, is already in peoples devices, and is so simple that a home router sweat shop can get it right without employing an actual engineer. Jari From nick@inex.ie Wed Aug 3 04:02:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF521F8B5C for ; Wed, 3 Aug 2011 04:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV9WiCyLD5F4 for ; Wed, 3 Aug 2011 04:02:11 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id 40F8921F8B58 for ; Wed, 3 Aug 2011 04:02:10 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 1DAB428421; Wed, 3 Aug 2011 12:02:22 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIVTvbBut2g0; Wed, 3 Aug 2011 12:02:20 +0100 (IST) Received: from cupcake.local (unknown [87.198.142.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by prometheus.inex.ie (Postfix) with ESMTPSA id 67DC528419; Wed, 3 Aug 2011 12:02:19 +0100 (IST) Message-ID: <4E392ABA.2010702@inex.ie> Date: Wed, 03 Aug 2011 12:02:18 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Philip Homburg References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> In-Reply-To: X-Enigmail-Version: 1.2 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:02:12 -0000 On 03/08/2011 11:32, Philip Homburg wrote: > I don't think this remark doesn't help in the context of homenet. What's the > point of now saying, oh OSPF, IS-IS, are way too big, it has to be RIP. Only > to later find out that you may need all kinds of extra protocols for things > that are already solved in OSPF, etc. > > I think the main thing that should be done now is trying to figure out the > scope of a homenet. How many kitchen sinks do we want. We need simplicity. A specification like this is going to be a baseline spec, and shouldn't contain many bells and whistles. Don't get me wrong. I like technology as much as anyone else, and the thought of recommending RIP over ISIS for anything makes me feel dirty. But the point is, RIP is a very simple protocol to implement, unlike either IS-IS or OSPF. If you create a standard which sets the baseline too high, you will end up with trashy implementations and excess complication. More importantly, if you specify too much in an early RFC, how do you remove it later if it turns out that it was a bad idea in retrospect? Look at all the trouble that 6to4 is causing, yet people on this mailing list are shirking at deprecating it. Yes, you _can_ get boxes which do everything, like the Mikrotik boxes. But how many end-users are going to end up configuring mpls on their home networks, or setting up iBGP on their multi-router installations? There is no need for this level of complexity. It will confuse for no good purpose. Remember, we are specifying something for Mom, Granddad and uncle Joe, to be implemented by Belkin. We're not specifying something for Nick, Philip and Sander, to be implemented by Cisco or Juniper. Perfection will be achieved not when there's nothing more to add, but when there's nothing more that can be taken away. Nick From swmike@swm.pp.se Wed Aug 3 04:13:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4921F8B57 for ; Wed, 3 Aug 2011 04:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+ONhxVP0zIr for ; Wed, 3 Aug 2011 04:13:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1375521F8557 for ; Wed, 3 Aug 2011 04:13:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1C0F29C; Wed, 3 Aug 2011 13:13:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 18DB19A; Wed, 3 Aug 2011 13:13:38 +0200 (CEST) Date: Wed, 3 Aug 2011 13:13:38 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <4E392ABA.2010702@inex.ie> Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:13:27 -0000 On Wed, 3 Aug 2011, Nick Hilliard wrote: > But the point is, RIP is a very simple protocol to implement, unlike either > IS-IS or OSPF. Could someone give a pointer as to how much harder OSPF is to implement? The only metric I can think of right now is size of code in Quagga, where the source code for their different components are as follows: component size ripd 308k ripngd 224k ospf6d 613k ospfd 1469k bgpd 1652k isisd 665k I don't know what exactly this measures, saying isis is twice the code compared to rip (if ripd and ripngd can be considered two separate components, otherwise it's almost the same). -- Mikael Abrahamsson email: swmike@swm.pp.se From sander@steffann.nl Wed Aug 3 04:25:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C360421F8ABC for ; Wed, 3 Aug 2011 04:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ34nrDR5bm8 for ; Wed, 3 Aug 2011 04:25:40 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3298021F86D7 for ; Wed, 3 Aug 2011 04:25:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 838142043; Wed, 3 Aug 2011 13:20:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-07KiFaPSgv; Wed, 3 Aug 2011 13:20:36 +0200 (CEST) Received: from [10.248.1.36] (unknown [188.142.127.132]) by mail.sintact.nl (Postfix) with ESMTP id 32EF92041; Wed, 3 Aug 2011 13:20:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <4E392ABA.2010702@inex.ie> Date: Wed, 3 Aug 2011 13:20:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1244.3) Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:25:40 -0000 Hi Nick, > Yes, you _can_ get boxes which do everything, like the Mikrotik boxes. = But > how many end-users are going to end up configuring mpls on their home > networks, or setting up iBGP on their multi-router installations? = There is > no need for this level of complexity. It will confuse for no good = purpose. That is not what I was saying (or at least not what I meant to say). I = just wanted to show that it's possible to implement these protocols on = cheap hardware. I fully agree that we must design something fool-proof = and easy to use for the average home user. I just don't agree that we = should limit ourselves to protocols like RIP for hardware reasons. > Perfection will be achieved not when there's nothing more to add, but = when > there's nothing more that can be taken away. True, but let's not take away options for the wrong reasons. - Sander From moore@network-heretics.com Wed Aug 3 04:47:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0782D21F8B3D for ; Wed, 3 Aug 2011 04:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9MzMfVK2WuD for ; Wed, 3 Aug 2011 04:47:29 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 683C521F8B24 for ; Wed, 3 Aug 2011 04:47:29 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8097D2083F; Wed, 3 Aug 2011 07:47:40 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 03 Aug 2011 07:47:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=oKuAiCNKolEsE2rbGQ/r4MoW+no=; b=mf I9wCcUTirANoB9+WCPdXCg+pbn0f43OFtvBbDj9ARsdRcti63JToZ92d5hpBXZLq vQKUkAlMjM0XLnXKmjDMJig2ur63vacMBPVjNW3TSoJ1DjOwgJQv/sgGYXFKvdak CCd+Ki3w7b7VT9TLWiwsFda3otmIy/qEPfQXziY7M= X-Sasl-enc: skLuEc6ergSvSEZy9tBGGq4C3MknWj5uNXHz+hWxnOff 1312372060 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BE1884572E2; Wed, 3 Aug 2011 07:47:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110803191038.4f11a1b7@opy.nosense.org> Date: Wed, 3 Aug 2011 07:47:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:47:30 -0000 On Aug 3, 2011, at 5:40 AM, Mark Smith wrote: > Fundamentally I think an arms war exists between Internet > application developers and the entities who deploy network > located constraints, such as firewalls or NAT, which the networked > application developers will always want to win. If their networked > applications can't work over the Internet, regardless of the commonly > encountered constraints, then there is no point in writing them in the > first place, so the developers have a very basic and fundamental motive > to work around these constraints. +1 From moore@network-heretics.com Wed Aug 3 04:54:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7D21F8B8C for ; Wed, 3 Aug 2011 04:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsGBWqyQSEAN for ; Wed, 3 Aug 2011 04:54:28 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DC3DD21F8B82 for ; Wed, 3 Aug 2011 04:54:28 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 91F5720FA2; Wed, 3 Aug 2011 07:54:40 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 03 Aug 2011 07:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=vZfoipyecGGFSOsEUJEXicEKtj4=; b=rD v3orjjiPBv7/V1ApdVyndfLZVUAjn/sZfiXFpAX8861mICvC3d8MhCFJJ1LZWvtF bAJgLhyaopz83hPiw3bUd8qnDzYyH/zKGyxVBkjw+ky1ZIpTimH+NX9DxgShwOKm NJXbu9/8juSXjgZXoTyz4LG5b+f/kcNQZH6MkR4TA= X-Sasl-enc: hawb1GI/quoOR4OH4DPN2skXXBKOn0fy3awTWyv8NqGs 1312372480 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A7726457A42; Wed, 3 Aug 2011 07:54:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore X-Priority: 3 (Normal) In-Reply-To: <232e34b2e8abec3c882e23871cca1c9b.squirrel@www.piuha.net> Date: Wed, 3 Aug 2011 07:54:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> <232e34b2e8abec3c882e23871cca1c9b.squirrel@www.piuha.net> To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:54:30 -0000 On Aug 3, 2011, at 6:23 AM, jari.arkko@piuha.net wrote: > Speaking as one of the authors. >=20 > Ari and I have a few drafts (and more to come) of the nature "we = observed > technology X in environment Y and here are our measurement results". >=20 > We've been wondering what to do with some of the drafts. I believe = some > would be useful to publish in a more permanent form than an ID. With > feedback folded in, where available. That being said, while in general > measurements are very interesting for v6ops (imo more interesting than = new > solution ideas), but its not clear that the group should spend a lot = of > time finetuning the results, merging different drafts, etc. >=20 > In short, if there is interest and feedback we will put in serious = effort > to get docs like this out as v6ops RFC. Otherwise, we are inclined to > publish something ad independent RFC, technical report or some = academic > forum. My recommendation is generally to pursue these as independent = submissions, so that v6ops doesn't have to manage them. But I see = little harm in asking v6ops people for feedback via private mail. Keith From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 04:58:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2621F8B7D for ; Wed, 3 Aug 2011 04:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytS5ri1WDlXd for ; Wed, 3 Aug 2011 04:58:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A532B21F8B7C for ; Wed, 3 Aug 2011 04:58:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qoa6C-0001gtC; Wed, 3 Aug 2011 13:58:56 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> In-reply-to: Your message of "Wed, 3 Aug 2011 07:47:37 -0400 ." <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> Date: Wed, 03 Aug 2011 13:58:32 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 11:58:56 -0000 In your letter dated Wed, 3 Aug 2011 07:47:37 -0400 you wrote: >On Aug 3, 2011, at 5:40 AM, Mark Smith wrote: > >> Fundamentally I think an arms war exists between Internet >> application developers and the entities who deploy network >> located constraints, such as firewalls or NAT, which the networked >> application developers will always want to win. If their networked >> applications can't work over the Internet, regardless of the commonly >> encountered constraints, then there is no point in writing them in the >> first place, so the developers have a very basic and fundamental motive >> to work around these constraints. > >+1 -1 This line of reasoning doesn't make sense to me. When it comes to NAT, why would there be a war? A NAT is not try to block any traffic. It usually has to do a complicated job on a small budget. Same applies to firewalls. If I want to run an application, why would I wait for developers to figure out how to bypass my firewall? From moore@network-heretics.com Wed Aug 3 05:09:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9388221F8AF0 for ; Wed, 3 Aug 2011 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhJadkiKtnEf for ; Wed, 3 Aug 2011 05:09:50 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DE18621F8AEC for ; Wed, 3 Aug 2011 05:09:49 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9D41A20FED; Wed, 3 Aug 2011 08:10:01 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 03 Aug 2011 08:10:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=xfT Zw7On48gR899EqNBpKVYeL5Q=; b=NK6j0LKFxxX/n++/JbS65ntQh7cg1igB3id pguSK0ioaYRqL+VDPYFZqJYjfbVWjVxeDsdSrZhaEXGRwW02XnCNWF7BW++m06sE Zc4ktzt3b0V/cwP8euyyy1CJrA9854S6I7vz3KFx8g9YIFg1MB60HzpkJlK00u6r vq9JZS/8= X-Sasl-enc: MQLS2sg/4JgjrOMG54wF7i/9p7efErgD+/pcgLjok1BW 1312373400 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E8A4456F0B; Wed, 3 Aug 2011 08:10:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21--941249474 From: Keith Moore In-Reply-To: Date: Wed, 3 Aug 2011 08:09:59 -0400 Message-Id: References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:09:51 -0000 --Apple-Mail-21--941249474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2011, at 7:58 AM, Philip Homburg wrote: > In your letter dated Wed, 3 Aug 2011 07:47:37 -0400 you wrote: >> On Aug 3, 2011, at 5:40 AM, Mark Smith wrote: >>=20 >>> Fundamentally I think an arms war exists between Internet >>> application developers and the entities who deploy network >>> located constraints, such as firewalls or NAT, which the networked >>> application developers will always want to win. If their networked >>> applications can't work over the Internet, regardless of the = commonly >>> encountered constraints, then there is no point in writing them in = the >>> first place, so the developers have a very basic and fundamental = motive >>> to work around these constraints. >>=20 >> +1 >=20 > -1 >=20 > This line of reasoning doesn't make sense to me.=20 >=20 > When it comes to NAT, why would there be a war? A NAT is not try to = block any > traffic. It usually has to do a complicated job on a small budget. NAT absolutely has the effect of blocking traffic, and many people have = been sold NATs on the basis that they are a security measure. > Same applies to firewalls. If I want to run an application, why would = I wait > for developers to figure out how to bypass my firewall?=20 In general, many people want the "right thing" to happen without having = to think much about whether it's really the "right thing". When it = doesn't work, they don't want to question whether it's their network = configuration that is the problem. The "right thing" is that applications that they want to work, work, and = applications that they don't want to work, don't work. And somehow, = magically, the network is supposed to know the difference. If the application doesn't work through the NAT or the firewall in its = existing configuration, in these people's minds, it's the application's = fault. Applications that don't work through NATs and firewalls face an = almost-insurmountable barrier to deployment. So most of the = applications that people have heard of, work through NATs and most = firewalls. This further reinforces the perception that the only = applications that matter are those that have no trouble with NATs and = firewalls. The need to make applications work through NATs and firewalls means that = those applications cost quite a bit more to develop and deliver, which = itself imposes a huge barrier. And yet, people will cite the existence = of such applications as evidence that NATs don't cause problems for = applications. (though these days, at least most IETF people are a bit = more enlightened than that) Keith --Apple-Mail-21--941249474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In your letter dated Wed, 3 Aug 2011 07:47:37 -0400 = you wrote:
On Aug 3, 2011, at 5:40 AM, Mark = Smith wrote:

Fundamentally I think an arms war exists between = Internet
application developers and the = entities who deploy network
located constraints, such as = firewalls or NAT, which the = networked
application developers will = always want to win. If their = networked
applications can't work over the = Internet, regardless of the = commonly
encountered constraints, then = there is no point in writing them in = the
first place, so the developers have a very basic and = fundamental motive
to work around these = constraints.

+1

-1

This line of reasoning = doesn't make sense to me.

When it comes to NAT, why would there = be a war? A NAT is not try to block any
traffic. It usually has to do = a complicated job on a small = budget.

NAT absolutely has the = effect of blocking traffic, and many people have been sold NATs on the = basis that they are a security measure.

Same applies to firewalls. If I want to run an = application, why would I wait
for developers to figure out how to = bypass my firewall?

In = general, many people want the "right thing" to happen without having to = think much about whether it's really the "right thing".  When it = doesn't work, they don't want to question whether it's their network = configuration that is the problem.

The "right = thing" is that applications that they want to work, work, and = applications that they don't want to work, don't work.  And = somehow, magically, the network is supposed to know the = difference.

If the application doesn't work = through the NAT or the firewall in its existing configuration, in these = people's minds, it's the application's = fault.

Applications that don't work through = NATs and firewalls face an almost-insurmountable barrier to deployment. =  So most of the applications that people have heard of, work = through NATs and most firewalls.  This further reinforces the = perception that the only applications that matter are those that have no = trouble with NATs and firewalls.

The need to = make applications work through NATs and firewalls means that those = applications cost quite a bit more to develop and deliver, which itself = imposes a huge barrier.  And yet, people will cite the existence of = such applications as evidence that NATs don't cause problems for = applications.  (though these days, at least most IETF people are a = bit more enlightened than = that)

Keith

= --Apple-Mail-21--941249474-- From nick@inex.ie Wed Aug 3 05:34:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB58721F8A55 for ; Wed, 3 Aug 2011 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKbWngf8s3H8 for ; Wed, 3 Aug 2011 05:34:31 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id EB51F21F8A4E for ; Wed, 3 Aug 2011 05:34:30 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 4F72B28427; Wed, 3 Aug 2011 13:34:41 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLqCAv2kSjyt; Wed, 3 Aug 2011 13:34:39 +0100 (IST) Received: from cupcake.local (unknown [87.198.142.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by prometheus.inex.ie (Postfix) with ESMTPSA id B331E28426; Wed, 3 Aug 2011 13:34:38 +0100 (IST) Message-ID: <4E39405D.8080706@inex.ie> Date: Wed, 03 Aug 2011 13:34:37 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> In-Reply-To: X-Enigmail-Version: 1.2 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:34:31 -0000 On 03/08/2011 12:13, Mikael Abrahamsson wrote: > The only metric I can think of right now is size of code in Quagga, where > the source code for their different components are as follows: BIRD tells a similar story in terms of kchars: rip: 39k ospf: 286k bgp 158k XORP also shows similar discrepancies in length, although it being what it is, the numbers are about 10x any other implementation. And the RFC for OSPFv2 is 243 pages, vs. 38 for RIP. Look, I'm not going to offer a formal proof that OSPF/ISIS are more complicated, but I think it's fair to say that we all know they are? And by quite a substantial degree too? And moving on from that, the question which matters is whether they form an appropriate base-line spec for CPE devices. I would suggest not, and I'm going to leave it at that. Nick From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 05:41:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2339721F87D6 for ; Wed, 3 Aug 2011 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Iy29FDvvTzL for ; Wed, 3 Aug 2011 05:41:36 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3F64421F87C6 for ; Wed, 3 Aug 2011 05:41:36 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QoalZ-0002Yj-If; Wed, 03 Aug 2011 22:11:41 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C8CA23B354; Wed, 3 Aug 2011 22:11:40 +0930 (CST) Date: Wed, 3 Aug 2011 22:11:39 +0930 From: Mark Smith To: Philip Homburg Message-ID: <20110803221139.2ecc8ea0@opy.nosense.org> In-Reply-To: References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:41:37 -0000 On Wed, 03 Aug 2011 13:58:32 +0200 Philip Homburg wrote: > In your letter dated Wed, 3 Aug 2011 07:47:37 -0400 you wrote: > >On Aug 3, 2011, at 5:40 AM, Mark Smith wrote: > > > >> Fundamentally I think an arms war exists between Internet > >> application developers and the entities who deploy network > >> located constraints, such as firewalls or NAT, which the networked > >> application developers will always want to win. If their networked > >> applications can't work over the Internet, regardless of the commonly > >> encountered constraints, then there is no point in writing them in the > >> first place, so the developers have a very basic and fundamental motive > >> to work around these constraints. > > > >+1 > > -1 > > This line of reasoning doesn't make sense to me. > > When it comes to NAT, why would there be a war? To clarify, I meant an "arms race" not "arms war". > A NAT is not try to block any traffic. By it's nature it blocks traffic in the inbound direction, regardless of whether that is what the end-user/application wants. Work arounds like manual port forwarding stun, Upnp etc. overcome that to some extent, but they're *work arounds*, and ultimately multiple hosts behind the NAT can't share the same inbound transport layer port. Any application whose communication is best suited to a peer-to-peer architecture may have to work around NATs by using an publicly addressed and mutually visible intermediary or host between the application peers. This relay host is another point of failure, potentially a performance bottle neck, and potentially a man-in-the-middle for the application. A prominent example of an peer-to-peer natured application that has got to a lot of effort to work around NATs is Skype. Imagine if that developer time could have instead been used to develop new features, improve core application functionality, or fix bugs sooner. > It usually has to do a complicated job on a small budget. > > Same applies to firewalls. If I want to run an application, why would I wait > for developers to figure out how to bypass my firewall? > Upstream/network located firewalls create the same sorts of constraints that NATs do. Certainly IPv6 firewalls with e.g. UPnP are going to be better as there is no NAT involved, so transport layer ports can be "shared" or are unique to each host. However, if the CPE firewall is more than one hop away from the host running UPnP so UPnP doesn't work, or the CPE doesn't support a protocol like UPnP, then the application either will fail to work, or the application developer will have to spend time developing work arounds for the network constraint. Application developers would want their application to work for 100% of people try to use it. If they can't achieve 100%, they would want as close to it. Say 20% of the possible users of the application have IPv6 CPE firewalls that can't be switched off via UPnP or something similar, the application developer will have to spend time developing work arounds. Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 05:57:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8144321F873A for ; Wed, 3 Aug 2011 05:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdJRPnE4zzwT for ; Wed, 3 Aug 2011 05:57:43 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id B007521F8581 for ; Wed, 3 Aug 2011 05:57:42 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qob1D-00038a-TV; Wed, 03 Aug 2011 22:27:51 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 56E883B354; Wed, 3 Aug 2011 22:27:51 +0930 (CST) Date: Wed, 3 Aug 2011 22:27:51 +0930 From: Mark Smith To: Nick Hilliard Message-ID: <20110803222751.32fa28e6@opy.nosense.org> In-Reply-To: <4E392ABA.2010702@inex.ie> References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:57:43 -0000 On Wed, 03 Aug 2011 12:02:18 +0100 Nick Hilliard wrote: > On 03/08/2011 11:32, Philip Homburg wrote: > > I don't think this remark doesn't help in the context of homenet. What's the > > point of now saying, oh OSPF, IS-IS, are way too big, it has to be RIP. Only > > to later find out that you may need all kinds of extra protocols for things > > that are already solved in OSPF, etc. > > > > I think the main thing that should be done now is trying to figure out the > > scope of a homenet. How many kitchen sinks do we want. > > We need simplicity. A specification like this is going to be a baseline > spec, and shouldn't contain many bells and whistles. > > Don't get me wrong. I like technology as much as anyone else, and the > thought of recommending RIP over ISIS for anything makes me feel dirty. > But the point is, RIP is a very simple protocol to implement, unlike either > IS-IS or OSPF. If you create a standard which sets the baseline too high, > you will end up with trashy implementations and excess complication. More > importantly, if you specify too much in an early RFC, how do you remove it > later if it turns out that it was a bad idea in retrospect? Look at all > the trouble that 6to4 is causing, yet people on this mailing list are > shirking at deprecating it. > You seem to be assuming that CPE code is implemented from scratch. It's not, most commonly it is packaged up Linux with busybox, and, as an example, for IPv6 RAs, radvd. Quagga or one of the other open source OSPF implementations would easily run on CPE and is likely to be used. OpenWRT would be a very good example of what common CPE hardware is capable of with the right software, and quagga is a package available for it. > Yes, you _can_ get boxes which do everything, like the Mikrotik boxes. But > how many end-users are going to end up configuring mpls on their home > networks, or setting up iBGP on their multi-router installations? There is > no need for this level of complexity. It will confuse for no good purpose. > Remember, we are specifying something for Mom, Granddad and uncle Joe, to > be implemented by Belkin. We're not specifying something for Nick, Philip > and Sander, to be implemented by Cisco or Juniper. > > Perfection will be achieved not when there's nothing more to add, but when > there's nothing more that can be taken away. > Yes, but if you take away essential or valuable functionality, you've gone too far, and will have to put it back or use something else to replace it. A basic OSPF default configuration with a single backbone area, which discovers any neighbors automatically on selected interfaces (i.e. all CPE non-WAN interfaces), forms adjacencies with them and then trades LSAs etc. is quite simple. Troubleshooting OSPF verses RIP is possibly a bit harder, but then mums and dads aren't going to be capable of troubleshooting RIP either. Regards, Mark. From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 06:18:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C43421F8B43 for ; Wed, 3 Aug 2011 06:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdixctwcCzTw for ; Wed, 3 Aug 2011 06:18:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 10A2421F8B37 for ; Wed, 3 Aug 2011 06:18:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QobLN-0001gLC; Wed, 3 Aug 2011 15:18:41 +0200 Message-Id: To: Mark Smith From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> <20110803221139.2ecc8ea0@opy.nosense.org> In-reply-to: Your message of "Wed, 3 Aug 2011 22:11:39 +0930 ." <20110803221139.2ecc8ea0@opy.nosense.org> Date: Wed, 03 Aug 2011 15:18:33 +0200 Cc: "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:18:42 -0000 In your letter dated Wed, 3 Aug 2011 22:11:39 +0930 you wrote: >On Wed, 03 Aug 2011 13:58:32 +0200 >Philip Homburg wrote: >> When it comes to NAT, why would there be a war? > >To clarify, I meant an "arms race" not "arms war". >> A NAT is not try to block any traffic. > >By it's nature it blocks traffic in the inbound direction, regardless >of whether that is what the end-user/application wants. Same thing. An arms race implies a sequence of steps where both sides will use more and more heavy machinery to win. NAT doesn't do that. It just does its thing. >Work arounds >like manual port forwarding stun, Upnp etc. overcome that to some >extent, but they're *work arounds*, and ultimately multiple hosts >behind the NAT can't share the same inbound transport layer port. Exactly. That's technical limitation. Not some sort of 'race'. >A prominent example of an >peer-to-peer natured application that has got to a lot of effort to >work around NATs is Skype. Imagine if that developer time could have >instead been used to develop new features, improve core application >functionality, or fix bugs sooner. Well, it is just a fact of life. IPv4 comes with NAT. It's a pity that application developers seems so silent on this issue. I haven't checked, does Skype even do IPv6? If they would make apps that would work better on IPv6 then there would be a lot more demand. At the moment, as shown on IPv6day, IPv6 is just IPv4 but different. Doesn't seem to have any benefit at all. >> It usually has to do a complicated job on a small budget. >> >> Same applies to firewalls. If I want to run an application, why would I wait >> for developers to figure out how to bypass my firewall? >> >Upstream/network located firewalls create the same sorts of constraints >that NATs do. Certainly IPv6 firewalls with e.g. UPnP are going to be >better as there is no NAT involved, so transport layer ports can be >"shared" or are unique to each host. However, if the CPE firewall is >more than one hop away from the host running UPnP so UPnP doesn't work, >or the CPE doesn't support a protocol like UPnP, then the application >either will fail to work, or the application developer will have to >spend time developing work arounds for the network constraint. Dealing with NAT is tricky due to the technical limitation of NAT. When firewalls became mainstream, there were lots of servers that could be exploited easily. At the moment, clients have caught up with servers and are now at least as easy to exploit if not easier. So now may be the right time to revisit firewall control protocols to try to get applications, hosts and firewalls to cooperate implementing a sensible security policy. >Application developers would want their application to work for 100% of >people try to use it. If they can't achieve 100%, they would want as >close to it. Say 20% of the possible users of the application have IPv6 >CPE firewalls that can't be switched off via UPnP or something similar, >the application developer will have to spend time developing work >arounds. I'd say, we should create good protocols that do work and can be supported easily by applications, operating systems, and network devices. There will always be broken environments. It's upto application developers whether they want to support them or not. From moore@network-heretics.com Wed Aug 3 06:23:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14B21F8B4B for ; Wed, 3 Aug 2011 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu+t0LO51V2S for ; Wed, 3 Aug 2011 06:23:07 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0021F8922 for ; Wed, 3 Aug 2011 06:23:07 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2A8D420908; Wed, 3 Aug 2011 09:23:18 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 03 Aug 2011 09:23:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=Np+UN/M3DK7irYYNhY/+N9GgReg=; b=Sf eqycZPXlw5adXxbBOkFHZaQIvnnpzCfyf1Tyr/y2KB+Kf49MZzKz0h72RDSFFE0K 3I2/Ev42ATwgqYujESATKULYPIrBK7QqAuUSprGDOuvbgBR4hTCHespcoIrBkhhd tqavwHQHyaOQl+pkmoT3NXItMZ8iZNuUAba6kwLR0= X-Sasl-enc: HwosY+uw5XDDYArCwjIZuj8+53L3MRqHXie8P1QW49EK 1312377797 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C306457A02; Wed, 3 Aug 2011 09:23:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 3 Aug 2011 09:23:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58907AF4-7D35-4B3A-8A21-F6DC7D4CEDB6@network-heretics.com> <4E381A43.3090107@inex.ie> <03CF6A46-DB00-4627-9024-AE80138355C6@network-heretics.com> <20110803191038.4f11a1b7@opy.nosense.org> <0949076B-E17F-41C7-BB37-10D7B253FF0A@network-heretics.com> <20110803221139.2ecc8ea0@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:23:08 -0000 On Aug 3, 2011, at 9:18 AM, Philip Homburg wrote: > It's a pity that application developers seems so silent on this issue. = I > haven't checked, does Skype even do IPv6? >=20 > If they would make apps that would work better on IPv6 then there = would be a > lot more demand. Ah yes, that tiny fraction of the net that has reliable IPv6 access = would be clamoring for chance to use those apps to communicate with = others in that tiny fraction. Keith From sthaug@nethelp.no Wed Aug 3 06:32:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFC121F8B1C for ; Wed, 3 Aug 2011 06:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ig5fXigI8Vd for ; Wed, 3 Aug 2011 06:32:06 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 1E7D221F8B10 for ; Wed, 3 Aug 2011 06:32:05 -0700 (PDT) Received: (qmail 26018 invoked from network); 3 Aug 2011 13:32:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 3 Aug 2011 13:32:16 -0000 Date: Wed, 03 Aug 2011 15:32:16 +0200 (CEST) Message-Id: <20110803.153216.74731177.sthaug@nethelp.no> To: ipng@69706e6720323030352d30312d31340a.nosense.org From: sthaug@nethelp.no In-Reply-To: <20110803222751.32fa28e6@opy.nosense.org> References: <4E392ABA.2010702@inex.ie> <20110803222751.32fa28e6@opy.nosense.org> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:32:07 -0000 > > Don't get me wrong. I like technology as much as anyone else, and the > > thought of recommending RIP over ISIS for anything makes me feel dirty. > > But the point is, RIP is a very simple protocol to implement, unlike either > > IS-IS or OSPF. If you create a standard which sets the baseline too high, > > you will end up with trashy implementations and excess complication. More > > importantly, if you specify too much in an early RFC, how do you remove it > > later if it turns out that it was a bad idea in retrospect? Look at all > > the trouble that 6to4 is causing, yet people on this mailing list are > > shirking at deprecating it. > > > > You seem to be assuming that CPE code is implemented from scratch. As far as I know, that used to be the case for a lot of CPEs from various Asian vendors and probably also others (e.g. Linksys). > It's not, most commonly it is packaged up Linux with busybox, and, as an > example, for IPv6 RAs, radvd. I believe several vendors have changed their software development model, and do indeed deliver systems based on Linux nowadays. I'd like to see some more documentation before I conclude that this applies to *most* vendors. > Quagga or one of the other open source > OSPF implementations would easily run on CPE and is likely to be used. This is where I'm not completely convinced. A CPE vendor may conclude that it is cost effective to deliver a system based on a Linux kernel, but that other resource constraints (memory, flash, etc) dictate a different set of software for routing protocols. Yes, more memory or flash could easily accomodate Quagga etc - but these vendors are in the business of saving 10 cents here and 50 cents there - multiplied by many CPEs. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From simon.perreault@viagenie.ca Wed Aug 3 06:36:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299D021F8B76 for ; Wed, 3 Aug 2011 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKuN2QLsPAyM for ; Wed, 3 Aug 2011 06:36:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55821F8B2E for ; Wed, 3 Aug 2011 06:36:49 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CFAC220D23 for ; Wed, 3 Aug 2011 09:37:00 -0400 (EDT) Message-ID: <4E394EFC.9010404@viagenie.ca> Date: Wed, 03 Aug 2011 09:37:00 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> <4E39405D.8080706@inex.ie> In-Reply-To: <4E39405D.8080706@inex.ie> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:36:53 -0000 On 2011-08-03 08:34, Nick Hilliard wrote: > On 03/08/2011 12:13, Mikael Abrahamsson wrote: >> The only metric I can think of right now is size of code in Quagga, where >> the source code for their different components are as follows: > > BIRD tells a similar story in terms of kchars: > > rip: 39k > ospf: 286k > bgp 158k Why does it matter at all? All consumer-grade home routers are built on open-source software. The implementation difficulty seems irrelevant to me. They'll just take what's out there and integrate it to their kit. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jmh@joelhalpern.com Wed Aug 3 06:41:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3967E21F8B7D for ; Wed, 3 Aug 2011 06:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhandO9nHYgV for ; Wed, 3 Aug 2011 06:41:04 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id A0BCF21F8B7C for ; Wed, 3 Aug 2011 06:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 31CD0325C158; Wed, 3 Aug 2011 06:41:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.71.0.17] (rrcs-208-105-237-226.nys.biz.rr.com [208.105.237.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B6AD9325BF6D; Wed, 3 Aug 2011 06:41:15 -0700 (PDT) Message-ID: <4E394FF8.1070503@joelhalpern.com> Date: Wed, 03 Aug 2011 09:41:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] writing drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:41:05 -0000 Well, I can't speak for everyone who has said "write a draft" to you, but for myself, when I say that to someone, it may be "go away", it may be "I would like to see more details on that", or it may be "I can not tell whether you are a genius or crazy, but if you write a draft on this I can at least tell which it is." I believe the second and third are more common, but that is a guess. Given the xml2rfc tools, and stealing a template from an existing draft, it does not take me long to write an initial short draft. Making major edits to an existing draft, now that can take longer. Yours, Joel On 8/3/2011 1:43 AM, Mikael Abrahamsson wrote: > On Tue, 2 Aug 2011, t.petch wrote: > >> I think that for most people the expectation is that I-D leads to RFC >> or else to disappointment. > > Yes, I agree too. Producing a properly formatted I-D is something I > would consider being a considerable effort. Writing on the list is for > me an equivalent to brainstorm in front of the whiteboard, and THEN when > something is hammered out a bit and there seems to be some interest and > traction, THEN I produce a document in expectation that this will end up > as a final product documenting whatever was discussed. > > I never start by producing a document before even discussing with my > coworkers. I know some do, I don't. Different ways of working. > > When someone says "put down your idea in form of an I-D and come present > it at an IETF meeting, otherwise we're not interested" I read that as > "please go away". > From dan.torbet@arrisi.com Wed Aug 3 06:43:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9464F21F844F; Wed, 3 Aug 2011 06:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAOuq1qfs4I3; Wed, 3 Aug 2011 06:43:05 -0700 (PDT) Received: from arrisi.com (ironmail2.arrisi.com [216.234.147.87]) by ietfa.amsl.com (Postfix) with ESMTP id B20BA21F88A6; Wed, 3 Aug 2011 06:42:54 -0700 (PDT) Received: from ([10.2.141.38]) by ironmail2.arrisi.com with ESMTP with TLS id CNFSXF1.36340965; Wed, 03 Aug 2011 09:42:57 -0400 Received: from ATLOWA2.ARRS.ARRISI.com (10.2.131.253) by Troy.ARRS.ARRISI.COM (10.2.141.38) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 3 Aug 2011 09:42:56 -0400 Received: from denexcas1.ARRS.ARRISI.COM (10.50.249.9) by ATLOWA2.ARRS.ARRISI.com (10.2.131.253) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 3 Aug 2011 09:42:56 -0400 Received: from DENEXMAIL1.ARRS.ARRISI.COM ([10.50.249.5]) by denexcas1.ARRS.ARRISI.COM ([10.50.249.9]) with mapi; Wed, 3 Aug 2011 07:42:55 -0600 From: "Torbet, Dan" To: "v6ops@ietf.org" , "homenet@ietf.org" Date: Wed, 3 Aug 2011 07:42:53 -0600 Thread-Topic: default LAN routing protocol for IPv6 CE router Thread-Index: AcxR4z6O+KTfP0SaT3i3zM6mnD5iiw== Message-ID: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> 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.4160-6.500.1024-18300.007 X-TM-AS-Result: No--21.000700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1DENEXMAIL1ARR_" MIME-Version: 1.0 Subject: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:43:07 -0000 --_000_9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1DENEXMAIL1ARR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The conversations so far on this topic have been great. I think however, w= e need to take a step back for a moment and think through what the HOMENET = network looks like when serviced by a CPE Router. In my mind, we have a fe= w scenarios that are possible. The first is a CPE ingress router to the home and no other routers. There = may be in this device multiple SSIDs and they each might need to have their= own address space and have separate firewall/filtering rules. In this cas= e, everything is contained in a single box and so no additional routing pro= tocols are needed. This has been defined in the CPE router (RFC 6204) and= the bis extension that is in draft right now. The second case is a CPE ingress router with N routers behind it. In this = case, I humbly submit that anything where N is greater than 2 says medium s= ized business maybe larger. I find it real hard to get any deeper than 2 r= outers in series for a HOMENET class device deployment. Anything greater th= an that and you likely would not use this class of device anyway. Sure the= re will be situations where this is not true ,but I'll wager that in 90% of= the installations where a CPE router is providing the link to the world, t= his will be the case. Even factoring in SmartGrid I just can't see a very = deep network. Is there a use case for more than 1 or 2 layers in a HOMENET= deployment that uses a CPE router as the connection to the world? To be cl= ear here - this is what I mean: (sorry for the poor ASCII art here ) Provider Router -------- CPE router ----------Router ------ = Router Or Provider | CPE Router ^ Router Router | = | Router Router I will acknowledge that in some business cases you might place a router on = each floor or each building in a campus, but this is where things get blurr= y for me - would you really use a CPE router in these cases for ingress int= o the business? You certainly could, but would you? Given that, I think that defining how many routers exist behind this CPE in= gress router will provide us with a reasonable place from which to define t= he needs and requirements for an IGP running in the home. Dan --_000_9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1DENEXMAIL1ARR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The conversation= s so far on this topic have been great.  I think however, we need to t= ake a step back for a moment and think through what the HOMENET network loo= ks like when serviced by a CPE Router.  In my mind, we have a few scen= arios that are possible.

 

The first is a CPE ingress router to the home an= d no other routers.  There may be in this device multiple SSIDs and th= ey each might need to have their own address space and have separate firewa= ll/filtering rules.  In this case, everything is contained in a single= box and so no additional routing protocols are needed.  This has been= defined in the CPE router (RFC 6204)  and the bis extension that is i= n draft right now.

 

=

The second case is a CPE ingress router with N routers= behind it.  In this case, I humbly submit that anything where N is gr= eater than 2 says medium sized business maybe larger.  I find it real = hard to get any deeper than 2 routers in series for a HOMENET class device = deployment. Anything greater than that and you likely would not use this cl= ass of device anyway.  Sure there will be situations where this is not= true ,but I’ll wager that in 90% of the installations where a CPE ro= uter is providing the link to the world, this will be the case.  Even = factoring in SmartGrid I just can’t see a very deep network.  Is= there a use case for more than 1 or 2 layers in a HOMENET deployment that = uses a CPE router as the connection to the world? To be clear here – = this is what I mean:

(sorry for the poor= ASCII art here )

 

<= p class=3DMsoNormal>         &= nbsp;     Provider Router -------- CPE router ---------= -Router ------ Router 

 =

Or

=  

 

            = ;            &n= bsp;            = ;            &n= bsp;          Provider

        = ;            &n= bsp;            = ;            &n= bsp;            = ;       |

 = ;            &n= bsp;            = ;            &n= bsp;            = ;         CPE Router

=

         =             &nb= sp;            =             &nb= sp;            =     ^

   =             &nb= sp;            =             &nb= sp;    Router        = ;          Router

        &nbs= p;            &= nbsp;           &nbs= p;             = |            &= nbsp;            &nb= sp;   |

   = ;            &n= bsp;            = ;            &n= bsp;    Router        &nb= sp;        Router

 

I will acknowledge t= hat in some business cases you might place a router on each floor or each b= uilding in a campus, but this is where things get blurry for me – wou= ld you really use a CPE router in these cases for ingress into the business= ? You certainly could, but would you?

<= o:p> 

Given that, I think that defining = how many routers exist behind this CPE ingress router will provide us with = a reasonable place from which to define the needs and requirements for an I= GP running in the home.

 

Dan

= --_000_9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1DENEXMAIL1ARR_-- From Ray.Bellis@nominet.org.uk Wed Aug 3 06:50:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E421F8B4D for ; Wed, 3 Aug 2011 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.21 X-Spam-Level: X-Spam-Status: No, score=-9.21 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6OTU+fb5-c1 for ; Wed, 3 Aug 2011 06:50:06 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id AE06C21F8B31 for ; Wed, 3 Aug 2011 06:50:04 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=w68TLM4KoRg17PFt0Pdf47xU1gpAOqbhKMTK6MULjEJFMkDuygPov1WM 3cb3qi3aBMSqbu7/itelKLUze5286m1vEKr/oP9GtBYf4Cd1+OpxgPC4Q yDca30JUIxLDBRH; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1312379418; x=1343915418; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Reply-To:=20"homenet@ietf.org"=20 |Subject:=20Re:=20[v6ops]=20default=20LAN=20routing=20pro tocol=20for=20IPv6=20CE=20router|Date:=20Wed,=203=20Aug =202011=2013:50:13=20+0000|Message-ID:=20|To:=20Simon=20Perre ault=20|CC:=20"v6ops@ietf.or g"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<2e21b2ba-b7d5-42bc-ad4f-e8b16222c5c3> |In-Reply-To:=20<4E394EFC.9010404@viagenie.ca> |References:=20<067E6CE33034954AAC05C9EC85E2577C058E6EF7@ XMB-RCD-111.cisco.com>=0D=0A=09=0D=0A=09<20110803183729.0a1367f 8@opy.nosense.org>=09<4E3920D1.1090705@inex.ie>=0D=0A=20< m1QoYk9-0001iFC@stereo.hq.phicoh.net>=09<4E392ABA.2010702 @inex.ie>=0D=0A=09=0D=0A=20<4E39405D.8080706@inex.ie>=20<4E39 4EFC.9010404@viagenie.ca>; bh=/o6by2xLllFSUg4+bbPRSgRBWzCOXg1rkfPMaUsPqjY=; b=us10Ue487QCK4fT6m6GZiN+xv/5Cy/AoaQbrNSnHbIKLn3R3vPXxfcgk uCbQXC9Roa0aCHbKoR+b70XeK3MadzfIYRwt3T1YcDsBiT/wGb8IoLBiH 6OHaL9lFlTiTzcD; X-IronPort-AV: E=Sophos;i="4.67,310,1309734000"; d="scan'208";a="27661252" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 03 Aug 2011 14:50:15 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Wed, 3 Aug 2011 14:50:14 +0100 From: Ray Bellis To: Simon Perreault Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUciUEQ2yDXmn/0a/wNDxpOiKGJUK5UkAgAADKwCAABaggIAAEW4AgAADsoA= Date: Wed, 3 Aug 2011 13:50:13 +0000 Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> <4E39405D.8080706@inex.ie> <4E394EFC.9010404@viagenie.ca> In-Reply-To: <4E394EFC.9010404@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <2e21b2ba-b7d5-42bc-ad4f-e8b16222c5c3> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "homenet@ietf.org" List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:50:06 -0000 On 3 Aug 2011, at 14:37, Simon Perreault wrote: > Why does it matter at all? All consumer-grade home routers are built on > open-source software. In my experience that's simply not true. When testing 20+ routers for SSAC035 and RFC 5625 we found _barely any_ tha= t were using recognisable OSS stacks for their implementations. Admittedly that was two years ago, and Linux / busybox / dnsmasq is probabl= y somewhat more popular now than then, but the variety of bugs we saw then = was far too great to suggest any significant commonality in their code base= s. Ray [reply-to set to Homenet]= From nick@inex.ie Wed Aug 3 07:06:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3600921F8AE1 for ; Wed, 3 Aug 2011 07:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4pbaXnU0NTw for ; Wed, 3 Aug 2011 07:06:49 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53221F8AA8 for ; Wed, 3 Aug 2011 07:06:48 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id B71FD28426; Wed, 3 Aug 2011 15:06:59 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWd7I5bQMvO8; Wed, 3 Aug 2011 15:06:57 +0100 (IST) Received: from crumpet.foobar.org (unknown [IPv6:2001:4d68:2002:100:d932:64e7:4af5:2861]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: operations) by prometheus.inex.ie (Postfix) with ESMTPSA id B51B328423; Wed, 3 Aug 2011 15:06:57 +0100 (IST) Message-ID: <4E395600.7060901@inex.ie> Date: Wed, 03 Aug 2011 15:06:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Smith References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> <20110803222751.32fa28e6@opy.nosense.org> In-Reply-To: <20110803222751.32fa28e6@opy.nosense.org> X-Enigmail-Version: 1.2 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:06:50 -0000 On 03/08/2011 13:57, Mark Smith wrote: > You seem to be assuming that CPE code is implemented from scratch. > It's not, most commonly it is packaged up Linux with busybox, and, as an > example, for IPv6 RAs, radvd. Quagga or one of the other open source > OSPF implementations would easily run on CPE and is likely to be used. > OpenWRT would be a very good example of what common CPE hardware is > capable of with the right software, and quagga is a package available > for it. The Quagga OSPFv3 implementation is not very good, to the extent that I would not use it in production. It lacks a pile of functionality, and is relatively easy to crash. The Quagga IS-IS implementation (which is the only open source IS-IS implementation as far as I can tell) has substantially not been updated since it was written 10 years ago - and does not support e.g. ipv6. Also, as several people have pointed out, many ip stack implementations are build from scratch, in-house. > Yes, but if you take away essential or valuable functionality, you've > gone too far, and will have to put it back or use something else to > replace it. It is still a lot simpler to add functionality to a specification than to remove it later. Consequently, it is better to start with simpler recommendations and to augment with retrospect, rather than to figure out the best way to fit as many kitchen sinks in as possible. > A basic OSPF default configuration with a single backbone area, which > discovers any neighbors automatically on selected interfaces (i.e. all > CPE non-WAN interfaces), forms adjacencies with them and then trades > LSAs etc. is quite simple. Troubleshooting OSPF verses RIP is possibly a > bit harder, but then mums and dads aren't going to be capable of > troubleshooting RIP either. Configuration complexity is not the problem. The problem is CPE device build complexity. Pennies matter for these boxes. Nick From therbst@silverspringnet.com Wed Aug 3 07:18:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259A21F8A66; Wed, 3 Aug 2011 07:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmRcGta-EiLx; Wed, 3 Aug 2011 07:18:27 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36C21F8A51; Wed, 3 Aug 2011 07:18:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAB5YOU4KyAE8/2dsb2JhbABCgk2mCoFAAQYtQwkSAQgNBAMBAig5FAkIAQEEAQ0FyFKGQgSHWpBGi18 X-IronPort-AV: E=Sophos;i="4.67,310,1309762800"; d="scan'208,217";a="6353148" Received: from unknown (HELO IT-EXCA-01.silverspringnet.com) ([10.200.1.60]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 03 Aug 2011 07:18:39 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Wed, 3 Aug 2011 07:18:38 -0700 From: Thomas Herbst To: "Torbet, Dan" , "v6ops@ietf.org" , "homenet@ietf.org" Date: Wed, 3 Aug 2011 07:18:37 -0700 Thread-Topic: [homenet] default LAN routing protocol for IPv6 CE router Thread-Index: AcxR6Dyus1u1eXeITgq0/GInfmZJUA== Message-ID: In-Reply-To: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5EA627F5BBtherbstsilverspringnetcom_" MIME-Version: 1.0 Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:18:28 -0000 --_000_CA5EA627F5BBtherbstsilverspringnetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IMHO, consumers should be able to connect their routers together fairly ran= domly and have them work, because they will connect them randomly. The hard problem we get to fairly quickly with random connections determini= ng which connections do or do not require special security levels. From: "Torbet, Dan" > Date: Wed, 3 Aug 2011 06:42:53 -0700 To: "v6ops@ietf.org" >, "homenet@ietf.org" > Subject: [homenet] default LAN routing protocol for IPv6 CE router The conversations so far on this topic have been great. I think however, w= e need to take a step back for a moment and think through what the HOMENET = network looks like when serviced by a CPE Router. In my mind, we have a fe= w scenarios that are possible. The first is a CPE ingress router to the home and no other routers. There = may be in this device multiple SSIDs and they each might need to have their= own address space and have separate firewall/filtering rules. In this cas= e, everything is contained in a single box and so no additional routing pro= tocols are needed. This has been defined in the CPE router (RFC 6204) and= the bis extension that is in draft right now. The second case is a CPE ingress router with N routers behind it. In this = case, I humbly submit that anything where N is greater than 2 says medium s= ized business maybe larger. I find it real hard to get any deeper than 2 r= outers in series for a HOMENET class device deployment. Anything greater th= an that and you likely would not use this class of device anyway. Sure the= re will be situations where this is not true ,but I=92ll wager that in 90% = of the installations where a CPE router is providing the link to the world,= this will be the case. Even factoring in SmartGrid I just can=92t see a v= ery deep network. Is there a use case for more than 1 or 2 layers in a HOM= ENET deployment that uses a CPE router as the connection to the world? To b= e clear here =96 this is what I mean: (sorry for the poor ASCII art here ) Provider Router -------- CPE router ----------Router ------ = Router Or Provider | CPE Router ^ Router Router | = | Router Router I will acknowledge that in some business cases you might place a router on = each floor or each building in a campus, but this is where things get blurr= y for me =96 would you really use a CPE router in these cases for ingress i= nto the business? You certainly could, but would you? Given that, I think that defining how many routers exist behind this CPE in= gress router will provide us with a reasonable place from which to define t= he needs and requirements for an IGP running in the home. Dan --_000_CA5EA627F5BBtherbstsilverspringnetcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IMHO, consumers should be able = to connect their routers together fairly randomly and have them work, becau= se they will connect them randomly.

The hard probl= em we get to fairly quickly with random connections determining which conne= ctions do or do not require special security levels. 

From: "Torbet, Dan&q= uot; <Dan.Torbet@arrisi.com= >
Date: Wed, 3 Aug 2011 06:4= 2:53 -0700
To: "v6ops@ietf.org" <v6ops@ietf.org>, "homenet@ietf.org" <homen= et@ietf.org>
Subject: [h= omenet] default LAN routing protocol for IPv6 CE router

<= /div>

The conversa= tions so far on this topic have been great.  I think however, we need = to take a step back for a moment and think through what the HOMENET network= looks like when serviced by a CPE Router.  In my mind, we have a few = scenarios that are possible.

&nbs= p;

The first is a CPE ingress router to the= home and no other routers.  There may be in this device multiple SSID= s and they each might need to have their own address space and have separat= e firewall/filtering rules.  In this case, everything is contained in = a single box and so no additional routing protocols are needed.  This = has been defined in the CPE router (RFC 6204)  and the bis extension t= hat is in draft right now.

 =

The second case is a CPE ingress router wi= th N routers behind it.  In this case, I humbly submit that anything w= here N is greater than 2 says medium sized business maybe larger.  I f= ind it real hard to get any deeper than 2 routers in series for a HOMENET c= lass device deployment. Anything greater than that and you likely would not= use this class of device anyway.  Sure there will be situations where= this is not true ,but I=92ll wager that in 90% of the installations where = a CPE router is providing the link to the world, this will be the case.&nbs= p; Even factoring in SmartGrid I just can=92t see a very deep network. = ; Is there a use case for more than 1 or 2 layers in a HOMENET deployment t= hat uses a CPE router as the connection to the world? To be clear here =96 = this is what I mean:

(sorry for the po= or ASCII art here )

 <= /p>

        &= nbsp;      Provider Router -------- CPE router ---= -------Router ------ Router 

 

Or

 

 

         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             = Provider

     = ;            &n= bsp;            = ;            &n= bsp;            = ;          |

          =             &nb= sp;            =             &nb= sp;            CPE R= outer

     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        ^

           &nb= sp;            =             &nb= sp;        Router    = ;            &n= bsp; Router

    &n= bsp;            = ;            &n= bsp;            = ;      |        = ;            &n= bsp;        |

          &nbs= p;            &= nbsp;           &nbs= p;         Router    = ;             R= outer

 

I will acknowledge that in some business cases you might place = a router on each floor or each building in a campus, but this is where thin= gs get blurry for me =96 would you really use a CPE router in these cases f= or ingress into the business? You certainly could, but would you?

 

Gi= ven that, I think that defining how many routers exist behind this CPE ingr= ess router will provide us with a reasonable place from which to define the= needs and requirements for an IGP running in the home.

 

Dan

--_000_CA5EA627F5BBtherbstsilverspringnetcom_-- From d.sturek@att.net Wed Aug 3 07:25:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B804321F8B0E for ; Wed, 3 Aug 2011 07:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EEvjgdtGOuK for ; Wed, 3 Aug 2011 07:25:10 -0700 (PDT) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with SMTP id 12C9121F8B0D for ; Wed, 3 Aug 2011 07:25:09 -0700 (PDT) Received: from [98.139.212.153] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 03 Aug 2011 14:25:21 -0000 Received: from [98.139.221.48] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 03 Aug 2011 14:25:21 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.bf1.yahoo.com with NNFMP; 03 Aug 2011 14:25:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312381521; bh=RsyUKrtiEe9VlPKiK7/Ji15nT5ofDpTYC7VojPUB3uw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=xPV+7buKm9H/EmFl85jKlCv03mKspjK2g4+jwBsXiuNv5ml0LIJBTvg8ZfkvlaFna0TLNwBHo5wdfWAevLO4cyijzPGXm6sLSuOJuB6WW+v5/npjpOBAaGCKFEdYEtevsjfeRyQ4ytZgrbx2yZLg9BPI4D3oFTC3Q0XZ8KN+Spo= X-Yahoo-Newman-Id: 524805.47788.bm@smtp101.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IfERLM4VM1n40HV9D3legSwRV5NnPqe_PDC7Xi8GRnaUjWD pLq3K6SPfg0JwZ..BtnT5YcNapnqpBzpMy35sjs_txSEBWgzfjYMe5Ppc_3C qoZoISqJG1J84mdROKBu7Opkz0bTv8MbKkAKrfXldkH0GqArY7n_hTiOnGuC 5z2jLLu4oNyH7HI7SfR7OjB9G45UFjlDFq.p9bEMUt0.dJgsSLDYDz0HVfDc zQcCljBFypwVwI8xXF4Xaj.AvnYiAeVkpRT.3yuOYjYQInw8etIQBvSlStkB TpuwTStfgQp40DoGJx5BQEWzRvKtzzlhJlZR1M9bT2qgfFhcD7wClBCQzW25 CHP7.u927CQfDZKl16cOJfrI- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.183.15.120] (d.sturek@38.126.23.254 with login) by smtp101.sbc.mail.bf1.yahoo.com with SMTP; 03 Aug 2011 07:25:20 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 07:25:18 -0700 From: Don Sturek To: "Torbet, Dan" , "v6ops@ietf.org" , "homenet@ietf.org" Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395201121_215684" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:25:13 -0000 > 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_3395201121_215684 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Dan, Here is the initial scenario we are dealing with in the smart energy arena: Provider (eg ISP) Provider (eg utility) | | CPE router CPE router | | Router --------------------------------- router | Link layer | | Interconnect | load shed devices=8A.> I purposely drew in the devices the way I did since some of these networks will evolve as silos then will interconnect when customers upgrade their routers to ones with multiple link layers that accommodate interconnection. Ultimately, there will not be such a rigid division of devices like shown but wanted to emphasize the likelihood that there will be multiple CPE routers in the home and an interconnection between them within the home. Don From: "Torbet, Dan" Date: Wed, 3 Aug 2011 07:42:53 -0600 To: "v6ops@ietf.org" , "homenet@ietf.org" Subject: [v6ops] default LAN routing protocol for IPv6 CE router The conversations so far on this topic have been great. I think however, w= e need to take a step back for a moment and think through what the HOMENET network looks like when serviced by a CPE Router. In my mind, we have a fe= w scenarios that are possible. =20 The first is a CPE ingress router to the home and no other routers. There may be in this device multiple SSIDs and they each might need to have their own address space and have separate firewall/filtering rules. In this case= , everything is contained in a single box and so no additional routing protocols are needed. This has been defined in the CPE router (RFC 6204) and the bis extension that is in draft right now. =20 The second case is a CPE ingress router with N routers behind it. In this case, I humbly submit that anything where N is greater than 2 says medium sized business maybe larger. I find it real hard to get any deeper than 2 routers in series for a HOMENET class device deployment. Anything greater than that and you likely would not use this class of device anyway. Sure there will be situations where this is not true ,but I=B9ll wager that in 90% of the installations where a CPE router is providing the link to the world, this will be the case. Even factoring in SmartGrid I just can=B9t see a very deep network. Is there a use case for more than 1 or 2 layers in a HOMENET deployment that uses a CPE router as the connection to the world? To be clear here =AD this is what I mean: (sorry for the poor ASCII art here ) =20 Provider Router -------- CPE router ----------Router ------ Router =20 =20 Or=20 =20 =20 Provider | CPE Router ^ Router Router | | Router Router =20 I will acknowledge that in some business cases you might place a router on each floor or each building in a campus, but this is where things get blurr= y for me =AD would you really use a CPE router in these cases for ingress into the business? You certainly could, but would you? =20 Given that, I think that defining how many routers exist behind this CPE ingress router will provide us with a reasonable place from which to define the needs and requirements for an IGP running in the home. =20 Dan _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3395201121_215684 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Dan,

=
Here is the initial scenario we are dealing with in the smart energy ar= ena:



    &n= bsp;           Provider (eg ISP)     &nbs= p;                  Provider (e= g utility)
               =          |           &nbs= p;                     &nb= sp;                     &n= bsp;         |
        &nb= sp;            CPE router      =                      = ;                  CPE router
                  &nbs= p;       |               &= nbsp;                     =                      =      |
            &= nbsp;         Router       --------------= -------------------   router
        &nbs= p;                 |     &= nbsp;                  Link lay= er                     &nb= sp; |
                &nbs= p;         |             &= nbsp;            Interconnect     &n= bsp;         |
        &nb= sp;      <Macs,             =                      =                      = ;     <Smart appliances,
        =          iPads,           =                      =                      = ;           plug in vehicles,
  &nbs= p;              Entertainment….>=                      = ;                   load shed d= evices….>

I purposely drew in the devices = the way I did since some of these networks will evolve as silos then will in= terconnect when customers upgrade their routers to ones with multiple link l= ayers that accommodate interconnection.

Ultimately,= there will not be such a rigid division of devices like shown but wanted to= emphasize the likelihood that there will be multiple CPE routers in the hom= e and an interconnection between them within the home.

<= div>Don




From: "Torbet, Dan" <Dan.Torbet@arrisi.com>
Date: Wed, 3 Aug 2011 07:42:53 -0600
To: "v6ops@ietf.org" = <v6ops@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>
Subject: [v6ops] default LAN routing protocol for IPv6 CE router

The conversations so far = on this topic have been great.  I think however, we need to take a step= back for a moment and think through what the HOMENET network looks like whe= n serviced by a CPE Router.  In my mind, we have a few scenarios that a= re possible.

 

The first is a CPE ingress router to the home and no other rou= ters.  There may be in this device multiple SSIDs and they each might n= eed to have their own address space and have separate firewall/filtering rul= es.  In this case, everything is contained in a single box and so no ad= ditional routing protocols are needed.  This has been defined in the CP= E router (RFC 6204)  and the bis extension that is in draft right now.<= o:p>

 

The second case is a CPE ingress router with N routers behind it.  In = this case, I humbly submit that anything where N is greater than 2 says medi= um sized business maybe larger.  I find it real hard to get any deeper = than 2 routers in series for a HOMENET class device deployment. Anything gre= ater than that and you likely would not use this class of device anyway.&nbs= p; Sure there will be situations where this is not true ,but I’ll wage= r that in 90% of the installations where a CPE router is providing the link = to the world, this will be the case.  Even factoring in SmartGrid I jus= t can’t see a very deep network.  Is there a use case for more th= an 1 or 2 layers in a HOMENET deployment that uses a CPE router as the conne= ction to the world? To be clear here – this is what I mean:=

(sorry for the poor ASCII art here )

=

 

  &= nbsp;            Prov= ider Router -------- CPE router ----------Router ------ Router 

 

Or

 

=  

     &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;   Provider

  &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;           |

         =             &nbs= p;            &n= bsp;            =              CPE= Router

     &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;       ^

&n= bsp;            =             &nbs= p;            &n= bsp;      Router      = ;            Router

       =             &nbs= p;            &n= bsp;             = ;  |           &= nbsp;            &nbs= p;    |

  &= nbsp;            = ;            &nb= sp;            &= nbsp;    Router        &nb= sp;        Router

 

I will acknowledge tha= t in some business cases you might place a router on each floor or each buil= ding in a campus, but this is where things get blurry for me – would y= ou really use a CPE router in these cases for ingress into the business? You= certainly could, but would you?

&n= bsp;

Given that, I think that defining how man= y routers exist behind this CPE ingress router will provide us with a reason= able place from which to define the needs and requirements for an IGP runnin= g in the home.

 

Dan

________________________= _______________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3395201121_215684-- From john_brzozowski@cable.comcast.com Tue Aug 2 16:08:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCF5E8017 for ; Tue, 2 Aug 2011 16:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me-rvE46+CQI for ; Tue, 2 Aug 2011 16:08:47 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id B2CA65E8013 for ; Tue, 2 Aug 2011 16:08:46 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47249511; Tue, 02 Aug 2011 17:13:53 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 19:08:54 -0400 From: "Brzozowski, John" To: Philip Homburg , Shane Amante Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUOxQzXadajaHM0CoA8rWqAKgMpUKHpWA Date: Tue, 2 Aug 2011 23:08:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <5DBD4564505FA3499528576566231D9D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Aug 2011 07:26:53 -0700 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:08:47 -0000 Not sure either of the below could happen accidentally. The latter would be especially concerning. On 8/2/11 4:15 AM, "Philip Homburg" wrote: >What matters is whether >any ISP will accidentally do something that would disable its customers' >firewalls. Or, whether any ISP will come up with a network configuration >that >allows customers to disable each others firewalls. From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 07:10:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5121F8AF6; Wed, 3 Aug 2011 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn+jsyIHhyNZ; Wed, 3 Aug 2011 07:10:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E76A221F8B26; Wed, 3 Aug 2011 07:10:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qoc8o-0001hpC; Wed, 3 Aug 2011 16:09:46 +0200 Message-Id: To: "Torbet, Dan" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 3 Aug 2011 07:42:53 -0600 ." <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> Date: Wed, 03 Aug 2011 16:09:37 +0200 X-Mailman-Approved-At: Wed, 03 Aug 2011 07:26:53 -0700 Cc: "v6ops@ietf.org" , "homenet@ietf.org" Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:10:11 -0000 In your letter dated Wed, 3 Aug 2011 07:42:53 -0600 you wrote: > The second case is a CPE ingress router with N routers behind > it. In this case, I humbly submit that anything where N is > greater than 2 says medium sized business maybe larger. >From a layer 3 point of view, I think you are right (but these things are hard to predict). What happens in practice though is that routers cost about the same as switches. So people may stack routers in weird ways just because they need more ports somewhere, or a wireless basestation, etc. It not always easy to figure out how to switch off the routing functionality and get the device to become a switch. Moreover, most users are probably not even aware that there is a difference. So in practice, I wouldn't be surprised if routers would get stacked quite deep. From joelja@bogus.com Wed Aug 3 07:48:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1B21F8B46; Wed, 3 Aug 2011 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-uFyOk6V2nM; Wed, 3 Aug 2011 07:48:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCD21F8B1E; Wed, 3 Aug 2011 07:48:55 -0700 (PDT) Received: from [10.101.144.52] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p73En1FL039361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Aug 2011 14:49:02 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13--931713428 From: Joel Jaeggli In-Reply-To: Date: Wed, 3 Aug 2011 07:48:55 -0700 Message-Id: <42274D5E-BDF0-404F-BDBA-40AB8BA85965@bogus.com> References: To: Thomas Herbst X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 03 Aug 2011 14:49:02 +0000 (UTC) Cc: "v6ops@ietf.org" , "homenet@ietf.org" Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:48:57 -0000 --Apple-Mail-13--931713428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 3, 2011, at 7:18 AM, Thomas Herbst wrote: > IMHO, consumers should be able to connect their routers together = fairly randomly and have them work, because they will connect them = randomly. >=20 > The hard problem we get to fairly quickly with random connections = determining which connections do or do not require special security = levels.=20 the number of time's I've seen two cpe devices cascaded of each other in = ipv4 land is significant, it works for the most part in the sense that = double nat inside your house works for the most part. normally I take = pitty on those folks and help them turn the interior one into a bridge, = but the expectation that anyone will do more than plug them together is = problematic. there are other things that are routers that interact with = the home network... laptop with vmware or virtualbox is a router, today = in ipv4 it nats or bridges, smartphones are routers potentially with = their own downstream devices. some of these devices are relatively = statically connected and some of them are ephemerally connected. > From: "Torbet, Dan" > Date: Wed, 3 Aug 2011 06:42:53 -0700 > To: "v6ops@ietf.org" , "homenet@ietf.org" = > Subject: [homenet] default LAN routing protocol for IPv6 CE router >=20 > The conversations so far on this topic have been great. I think = however, we need to take a step back for a moment and think through what = the HOMENET network looks like when serviced by a CPE Router. In my = mind, we have a few scenarios that are possible. > =20 > The first is a CPE ingress router to the home and no other routers. = There may be in this device multiple SSIDs and they each might need to = have their own address space and have separate firewall/filtering rules. = In this case, everything is contained in a single box and so no = additional routing protocols are needed. This has been defined in the = CPE router (RFC 6204) and the bis extension that is in draft right now. > =20 > The second case is a CPE ingress router with N routers behind it. In = this case, I humbly submit that anything where N is greater than 2 says = medium sized business maybe larger. I find it real hard to get any = deeper than 2 routers in series for a HOMENET class device deployment. = Anything greater than that and you likely would not use this class of = device anyway. Sure there will be situations where this is not true = ,but I=92ll wager that in 90% of the installations where a CPE router is = providing the link to the world, this will be the case. Even factoring = in SmartGrid I just can=92t see a very deep network. Is there a use = case for more than 1 or 2 layers in a HOMENET deployment that uses a CPE = router as the connection to the world? To be clear here =96 this is what = I mean: > (sorry for the poor ASCII art here ) > =20 > Provider Router -------- CPE router ----------Router = ------ Router=20 > =20 > Or > =20 > =20 > Provider > | > CPE Router > ^ > Router = Router > | = | > Router = Router > =20 > I will acknowledge that in some business cases you might place a = router on each floor or each building in a campus, but this is where = things get blurry for me =96 would you really use a CPE router in these = cases for ingress into the business? You certainly could, but would you? > =20 > Given that, I think that defining how many routers exist behind this = CPE ingress router will provide us with a reasonable place from which to = define the needs and requirements for an IGP running in the home. > =20 > Dan > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-13--931713428 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
IMHO, = consumers should be able to connect their routers together fairly = randomly and have them work, because they will connect them = randomly.

The hard problem we get to fairly = quickly with random connections determining which connections do or do = not require special security = levels. 

the number of = time's I've seen two cpe devices cascaded of each other in ipv4 land is = significant, it works for the most part in the sense that double nat = inside your house works for the most part. normally I take pitty on = those folks and help them turn the interior one into a bridge, but the =  expectation that anyone will do more than plug them together is = problematic. there are other things that are routers that interact with = the home network... laptop with vmware or virtualbox is a router, today = in ipv4 it nats or bridges, smartphones are routers potentially with = their own downstream devices. some of these devices are relatively = statically connected and some of them are ephemerally = connected.

From: "Torbet, Dan" <Dan.Torbet@arrisi.com>
Date: Wed, 3 Aug 2011 06:42:53 = -0700
To: "v6ops@ietf.org" <v6ops@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>
Subject: [homenet] default LAN = routing protocol for IPv6 CE router

The = conversations so far on this topic have been great.  I think = however, we need to take a step back for a moment and think through what = the HOMENET network looks like when serviced by a CPE Router.  In = my mind, we have a few scenarios that are possible.
 
The = first is a CPE ingress router to the home and no other routers. =  There may be in this device multiple SSIDs and they each might = need to have their own address space and have separate = firewall/filtering rules.  In this case, everything is contained in = a single box and so no additional routing protocols are needed.  = This has been defined in the CPE router (RFC 6204)  and the bis = extension that is in draft right now.
 
The = second case is a CPE ingress router with N routers behind it.  In = this case, I humbly submit that anything where N is greater than 2 says = medium sized business maybe larger.  I find it real hard to get any = deeper than 2 routers in series for a HOMENET class device deployment. = Anything greater than that and you likely would not use this class of = device anyway.  Sure there will be situations where this is not = true ,but I=92ll wager that in 90% of the installations where a CPE = router is providing the link to the world, this will be the case.  = Even factoring in SmartGrid I just can=92t see a very deep = network.  Is there a use case for more than 1 or 2 layers in a = HOMENET deployment that uses a CPE router as the connection to the = world? To be clear here =96 this is what I mean:
(sorry for the poor ASCII art here = )
 
         =       Provider Router -------- CPE router = ----------Router ------ Router 
 
Or =
 
 
         =             &n= bsp;           &nbs= p;            =             &n= bsp; Provider
         =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
         =             &n= bsp;           &nbs= p;            =             &n= bsp; CPE Router
         =             &n= bsp;           &nbs= p;            =             &n= bsp;     ^
         =             &n= bsp;           &nbs= p;           = Router           &n= bsp;      Router
         =             &n= bsp;           &nbs= p;           =    = |            &= nbsp;         =        |
         =             &n= bsp;           &nbs= p;           = Router   =             &n= bsp; Router
 
I = will acknowledge that in some business cases you might place a router on = each floor or each building in a campus, but this is where things get = blurry for me =96 would you really use a CPE router in these cases for = ingress into the business? You certainly could, but would you? =
 
Given that, I think that defining how many routers = exist behind this CPE ingress router will provide us with a reasonable = place from which to define the needs and requirements for an IGP running = in the home.
 
Dan
_______________________________________________
homenet mailing = list
homenet@ietf.org
https://www.ietf.or= g/mailman/listinfo/homenet

= --Apple-Mail-13--931713428-- From fred@cisco.com Wed Aug 3 09:35:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8BE21F8BBD for ; Wed, 3 Aug 2011 09:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbD4VSjW1DzN for ; Wed, 3 Aug 2011 09:35:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0212A21F86A5 for ; Wed, 3 Aug 2011 09:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=512; q=dns/txt; s=iport; t=1312389369; x=1313598969; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=7KNoUAiFTY9iqnKfH5UhQ39iA9nHJyLIkozXmtbsbac=; b=UunDoLND3CiUZrv/sorCfA6xi1iejAtq9iFjFgygnF7iA5odB2lNgunm hrvsg20NXt/xAacyoisckxVKwi+axYo0/St8NjW7YOa7XsofSqnsKeh1e ySTnnLaYR6MfLRkPzkPrgvwsjpOPnDuDyaUBfLTbja1JybFSuxeHRzpwh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwHAJZ4OU5Io8UR/2dsb2JhbABCmEqPFneBQAEBAQECARIBJz8FCwUGRlcZERGHSqIPAZ5mhWNfBIdaiyGFB4t9 X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="106554233" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 16:35:49 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn3-550.cisco.com [10.21.66.38]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73GZkmG021938; Wed, 3 Aug 2011 16:35:47 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 09:35:47 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 09:35:47 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker X-Priority: 3 (Normal) In-Reply-To: <232e34b2e8abec3c882e23871cca1c9b.squirrel@www.piuha.net> Date: Wed, 3 Aug 2011 09:35:39 -0700 Message-Id: <23606DD9-C056-4618-BCCE-2613B60141D9@cisco.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> <232e34b2e8abec3c882e23871cca1c9b.squirrel@www.piuha.net> To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:35:57 -0000 On Aug 3, 2011, at 3:23 AM, jari.arkko@piuha.net wrote: > In short, if there is interest and feedback we will put in serious = effort > to get docs like this out as v6ops RFC. Otherwise, we are inclined to > publish something ad independent RFC, technical report or some = academic > forum. I can see it both ways. We have had some comment on this draft; I'll = suggest you bring that to closure, after which I'll send it to Ron, and = leave the status and procedure of future documents to you.= From fred@cisco.com Wed Aug 3 09:42:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0F21F8B22 for ; Wed, 3 Aug 2011 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUbZy6M45pjH for ; Wed, 3 Aug 2011 09:42:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0671821F8888 for ; Wed, 3 Aug 2011 09:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1230; q=dns/txt; s=iport; t=1312389746; x=1313599346; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=S96VpynyWHdFm48StzZo/INFejwuSIfMDjoZF9KOX30=; b=JvzRXxKKif8iTr63AfnmrMm+OEamUdbC6PlI7wkH/gUV+d1SXWG55cVF h6gmQ/TTdSnDrHkLO2P1OlXGBLRzqqOm+RPw/xjK4OAKuRAJam2owx564 cg2Tm2AyTQ0djB7ZF98pFCQNZ6iU/zp/3R9hy4LhGtZA+jusqOxg/w2Bf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF95OU6rRDoI/2dsb2JhbABCp2B3gUABAQEBAgESASc/BQsLRlcGNYdKohwBnmaFY18Eh1qLIYUHi30 X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9307536" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 03 Aug 2011 16:42:26 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn3-550.cisco.com [10.21.66.38]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73GgPuk025325; Wed, 3 Aug 2011 16:42:25 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 09:42:25 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 09:42:25 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E394FF8.1070503@joelhalpern.com> Date: Wed, 3 Aug 2011 09:42:09 -0700 Message-Id: <73933E66-76CB-4B67-9ACF-C84A80ACE535@cisco.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> <4E394FF8.1070503@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] writing drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:42:14 -0000 On Aug 3, 2011, at 6:41 AM, Joel M. Halpern wrote: > Well, I can't speak for everyone who has said "write a draft" to you, = but for myself, when I say that to someone, it may be "go away", it may = be "I would like to see more details on that", or it may be "I can not = tell whether you are a genius or crazy, but if you write a draft on this = I can at least tell which it is." I believe the second and third are = more common, but that is a guess. agreed. The problem with simply sending an email to open a discussion = thread or posing a "lightning round" kind of talk is that the basic = proposal gets lost in the noise and the thread invariably migrates. = They're fine for throwing out an idea; carrying it further requires some = discipline. A draft constitutes something everyone can uniformly review = and comment on, and suggest changes to. It also, by the nature of being = such a statement, has the effect of imposing a certain degree of = discipline on the author - Instead of saying "hey, let's all divide by = zero on Tuesday, that sounds like a wonderful idea", the author is = constrained to somewhat explain what s/he is trying to achieve, the = approach, expected results, and so on. From rajiva@cisco.com Wed Aug 3 09:46:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37121F8A66; Wed, 3 Aug 2011 09:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gfSJvmbl+zL; Wed, 3 Aug 2011 09:46:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 74C6621F88A1; Wed, 3 Aug 2011 09:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4897; q=dns/txt; s=iport; t=1312389991; x=1313599591; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=xCATmIsyykdcyRIZWOykyouDjKqbUXm86tPHecUjuFE=; b=kNEKZeaiXHN96j2ePsmeviCnBAk6vqqMWiUVpDr8mh4gsiVFjtGvQg1a 7NmmN89UPZ6NJhr/JMT/LJKSNWyepSlOAKqHZQnbgQ9eB3iG5cswqlPNr 4WdlNXYCK1eHpVds62J2YpU2x697DWPhml4c671OGqyCpK4hcrKPoB1FG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAKp6OU6tJXG+/2dsb2JhbABCmAaPWneBQAEBAQEDAQEBDwEdCjQCFQQCAQgOAwMBAQELBhcBBgEmHwkIAQEEARIIGodOoiEBnmeFY18Eh1qQMYty X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9313538" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2011 16:46:30 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73GkUFQ002578; Wed, 3 Aug 2011 16:46:30 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 11:46:29 -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 Date: Wed, 3 Aug 2011 11:46:29 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxR6UFCR3amT9snQNeTyL9e+PIeoQAE4zWA References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> From: "Rajiv Asati (rajiva)" To: "Don Sturek" , "Torbet, Dan" , , X-OriginalArrivalTime: 03 Aug 2011 16:46:29.0986 (UTC) FILETIME=[E4D7D420:01CC51FC] Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:46:19 -0000 Don, Just curious about 'smart energy' home network - Why is there a router behind the CPE router? Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Don > Sturek > Sent: Wednesday, August 03, 2011 10:25 AM > To: Torbet, Dan; v6ops@ietf.org; homenet@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > Hi Dan, >=20 > Here is the initial scenario we are dealing with in the smart energy arena: >=20 >=20 >=20 > Provider (eg ISP) Provider (eg utility) > | > | > CPE router > CPE router > | > | > Router --------------------------------- router > | Link layer > | > | Interconnect > | > iPads, > plug in vehicles, > Entertainment....> load > shed devices....> >=20 > I purposely drew in the devices the way I did since some of these networks > will evolve as silos then will interconnect when customers upgrade their > routers to ones with multiple link layers that accommodate interconnection. >=20 > Ultimately, there will not be such a rigid division of devices like shown but > wanted to emphasize the likelihood that there will be multiple CPE routers in > the home and an interconnection between them within the home. >=20 > Don >=20 >=20 >=20 >=20 > From: "Torbet, Dan" > Date: Wed, 3 Aug 2011 07:42:53 -0600 > To: "v6ops@ietf.org" , "homenet@ietf.org" > Subject: [v6ops] default LAN routing protocol for IPv6 CE router >=20 >=20 >=20 > The conversations so far on this topic have been great. I think however, we > need to take a step back for a moment and think through what the HOMENET > network looks like when serviced by a CPE Router. In my mind, we have a few > scenarios that are possible. >=20 >=20 >=20 >=20 > The first is a CPE ingress router to the home and no other routers. There may > be in this device multiple SSIDs and they each might need to have their own > address space and have separate firewall/filtering rules. In this case, > everything is contained in a single box and so no additional routing protocols > are needed. This has been defined in the CPE router (RFC 6204) and the bis > extension that is in draft right now. >=20 >=20 >=20 > The second case is a CPE ingress router with N routers behind it. In this > case, I humbly submit that anything where N is greater than 2 says medium > sized business maybe larger. I find it real hard to get any deeper than 2 > routers in series for a HOMENET class device deployment. Anything greater than > that and you likely would not use this class of device anyway. Sure there > will be situations where this is not true ,but I'll wager that in 90% of the > installations where a CPE router is providing the link to the world, this will > be the case. Even factoring in SmartGrid I just can't see a very deep > network. Is there a use case for more than 1 or 2 layers in a HOMENET > deployment that uses a CPE router as the connection to the world? To be clear > here - this is what I mean: >=20 > (sorry for the poor ASCII art here ) >=20 >=20 >=20 > Provider Router -------- CPE router ----------Router ------ > Router >=20 >=20 >=20 > Or >=20 >=20 >=20 >=20 >=20 > Provider >=20 > | >=20 > CPE Router >=20 > ^ >=20 > Router Router >=20 > | > | >=20 > Router Router >=20 >=20 >=20 > I will acknowledge that in some business cases you might place a router on > each floor or each building in a campus, but this is where things get blurry > for me - would you really use a CPE router in these cases for ingress into the > business? You certainly could, but would you? >=20 >=20 >=20 > Given that, I think that defining how many routers exist behind this CPE > ingress router will provide us with a reasonable place from which to define > the needs and requirements for an IGP running in the home. >=20 >=20 >=20 > Dan >=20 > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Aug 3 09:46:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AA321F88A1 for ; Wed, 3 Aug 2011 09:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjdtpP9gCBL5 for ; Wed, 3 Aug 2011 09:46:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD7E21F8A4F for ; Wed, 3 Aug 2011 09:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=927; q=dns/txt; s=iport; t=1312389991; x=1313599591; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=mL9qiIdmKLBdrT1XDLzYiDCTbQBvNxHBOw0SquwMonA=; b=SFNq6ojZq3pHLEKXOQ6kZww8YueQFM7DvktfEmb8v8JsweIp935qqxmQ EPhkCnhREqcatz+m+/1dx0ROX5ppgq5wwT2/DAWWFfuvJX4D72ExtfgLW YFLL8G710nrSDQ+lkNgPywolKMTUa1aUK67kNc5ooL8VHzo1jWJu4wsSo w=; X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9312234" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 03 Aug 2011 16:46:31 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn3-550.cisco.com [10.21.66.38]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73GkUL9022142; Wed, 3 Aug 2011 16:46:30 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 09:46:30 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 09:46:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> Date: Wed, 3 Aug 2011 09:46:22 -0700 Message-Id: <0553C3A2-4BFF-4209-9966-83B2DCE66A1A@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:46:19 -0000 On Jul 27, 2011, at 9:28 AM, Hemant Singh (shemant) wrote: > IPv6 CPE router vendors, please give feedback. Does anyone object if = we specify the default routing protocol as OSPFv3 with only area zero = for the IPv6 CE router bis document? Or would you prefer the document = is silent on specification of any default? Hemant: Question for you... In the meeting Thursday, the working group decided that at least some of = the issues you're wrestling with should move to homenet. The general = divide seemed to be discussion of the home network itself and the WAN = behavior to the ISP. The working group wanted to bring this draft to = closure as quickly as reasonable and let the controversial issues that = aren't relevant to the broadband network go to homenet. Give me a game plan, if you would. What topics do you plan to pursue in = this draft, and which ones do you see moving? Fred= From d.sturek@att.net Wed Aug 3 09:57:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5B21F8880 for ; Wed, 3 Aug 2011 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc9eE5aK87Vn for ; Wed, 3 Aug 2011 09:57:57 -0700 (PDT) Received: from nm20-vm0.access.bullet.mail.sp2.yahoo.com (nm20-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.174]) by ietfa.amsl.com (Postfix) with SMTP id 6914F21F8867 for ; Wed, 3 Aug 2011 09:57:57 -0700 (PDT) Received: from [98.139.44.98] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 16:58:07 -0000 Received: from [98.139.44.65] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 16:58:07 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 16:58:07 -0000 X-Yahoo-Newman-Id: 343052.9478.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 40945 invoked from network); 3 Aug 2011 16:58:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312390686; bh=pyxFTaZrj6JgFb1Q3VozRoZJkkztdQRbWWS1Zq5piyg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=t+K+Zwtp3tICeY+TBDTwrbK4saguamfcimhDkgR/+yoz0mvvrNWp/Vz/6FV/phTKGYIFREspBv48lm27PtN32t9Jy2nXeEDNYlUKVZSnEB+u6LcwcTl+1TOD0CraorwLYo9QPWJFPJc9x4b2EpJXuzCHKxiRD6TMdZOstQPUdhw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1Q0mS9kVM1mjTN4L8WMFvdpjhMb75aKppJR.dQ09lGZREur V7JGmL1h4zngL9o1r8a4BaAzmf7YtSZBzs8pYFly2uEkNm6Jj4mDJkNdXoru upTEEFDQB6Z96x4_nly6PnjjG_06DFFPYaO8OdRPt.uhKpAAx7TTf35pzQXP ochvt6vEKfx41SvQBA2kqlGbpix1Y9s4_VIeuovkYocqCVqAtzZ8SfX9vylf fpFfs_HMZ_WRluZXwRcy.6RsVTId4Js33x0BNgMj8MV682Qjwj904Or4FcUS rrUyeWp9bApXIVexhukN6SKnXXH7TDJn.Sc590fWP94yi7IkiBzFtzeAlP5E LSRKrtJS4t.KtQXu07tqv7Vld5Ujy6VVTVovW3Cwf X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.183.15.120] (d.sturek@38.126.23.254 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 03 Aug 2011 09:58:04 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 09:57:56 -0700 From: Don Sturek To: "Rajiv Asati \(rajiva\)" , "Torbet, Dan" , , Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:57:58 -0000 Hi Rajiv, One of the issues is that many early deployments of smart meter are using IEEE 802.15.4. That technology uses extremely small packet sizes (127 byte packets). Meanwhile, each of the device manufacturers using smart meter information are choosing their own link layer technology. SAE (electric cars) are looking to deploy powerline carrier (HomePlug GreenPHY seems to be the leading candidate, IEEE P1901 subset). So for simple smart meter deployments, the router won't necessarily be present. However, as devices like plug in electric vehicles are deployed and connected to the smart meter, you will end up with routers as well as the CPE router device. Don On 8/3/11 9:46 AM, "Rajiv Asati (rajiva)" wrote: >Don, > >Just curious about 'smart energy' home network - Why is there a router >behind the CPE router? > >Cheers, >Rajiv > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >Of Don >> Sturek >> Sent: Wednesday, August 03, 2011 10:25 AM >> To: Torbet, Dan; v6ops@ietf.org; homenet@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >> >> Hi Dan, >> >> Here is the initial scenario we are dealing with in the smart energy >arena: >> >> >> >> Provider (eg ISP) Provider (eg >utility) >> | >> | >> CPE router >> CPE router >> | >> | >> Router --------------------------------- >router >> | Link layer >> | >> | Interconnect >> | >> > > iPads, >> plug in vehicles, >> Entertainment....> >load >> shed devices....> >> >> I purposely drew in the devices the way I did since some of these >networks >> will evolve as silos then will interconnect when customers upgrade >their >> routers to ones with multiple link layers that accommodate >interconnection. >> >> Ultimately, there will not be such a rigid division of devices like >shown but >> wanted to emphasize the likelihood that there will be multiple CPE >routers in >> the home and an interconnection between them within the home. >> >> Don >> >> >> >> >> From: "Torbet, Dan" >> Date: Wed, 3 Aug 2011 07:42:53 -0600 >> To: "v6ops@ietf.org" , "homenet@ietf.org" > >> Subject: [v6ops] default LAN routing protocol for IPv6 CE router >> >> >> >> The conversations so far on this topic have been great. I think >however, we >> need to take a step back for a moment and think through what the >HOMENET >> network looks like when serviced by a CPE Router. In my mind, we have >a few >> scenarios that are possible. >> >> >> >> >> The first is a CPE ingress router to the home and no other routers. >There may >> be in this device multiple SSIDs and they each might need to have >their own >> address space and have separate firewall/filtering rules. In this >case, >> everything is contained in a single box and so no additional routing >protocols >> are needed. This has been defined in the CPE router (RFC 6204) and >the bis >> extension that is in draft right now. >> >> >> >> The second case is a CPE ingress router with N routers behind it. In >this >> case, I humbly submit that anything where N is greater than 2 says >medium >> sized business maybe larger. I find it real hard to get any deeper >than 2 >> routers in series for a HOMENET class device deployment. Anything >greater than >> that and you likely would not use this class of device anyway. Sure >there >> will be situations where this is not true ,but I'll wager that in 90% >of the >> installations where a CPE router is providing the link to the world, >this will >> be the case. Even factoring in SmartGrid I just can't see a very deep >> network. Is there a use case for more than 1 or 2 layers in a HOMENET >> deployment that uses a CPE router as the connection to the world? To >be clear >> here - this is what I mean: >> >> (sorry for the poor ASCII art here ) >> >> >> >> Provider Router -------- CPE router ----------Router >------ >> Router >> >> >> >> Or >> >> >> >> >> >> Provider >> >> | >> >> CPE Router >> >> ^ >> >> Router >Router >> >> | >> | >> >> Router >Router >> >> >> >> I will acknowledge that in some business cases you might place a >router on >> each floor or each building in a campus, but this is where things get >blurry >> for me - would you really use a CPE router in these cases for ingress >into the >> business? You certainly could, but would you? >> >> >> >> Given that, I think that defining how many routers exist behind this >CPE >> ingress router will provide us with a reasonable place from which to >define >> the needs and requirements for an IGP running in the home. >> >> >> >> Dan >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Wed Aug 3 10:01:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3421F8AD9; Wed, 3 Aug 2011 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.962 X-Spam-Level: X-Spam-Status: No, score=-101.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzo6jb6z3NdV; Wed, 3 Aug 2011 10:00:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1F21F8A30; Wed, 3 Aug 2011 10:00:57 -0700 (PDT) Received: from [192.168.43.44] (mc60536d0.tmodns.net [208.54.5.198]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p73H11nL046903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Aug 2011 17:01:02 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> Date: Wed, 3 Aug 2011 10:00:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 03 Aug 2011 17:01:04 +0000 (UTC) Cc: v6ops@ietf.org, homenet@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:01:07 -0000 On Aug 3, 2011, at 9:46 AM, Rajiv Asati (rajiva) wrote: > Don, >=20 > Just curious about 'smart energy' home network - Why is there a router > behind the CPE router? got a better idea for interconnecting 802.15.4 and 802.3 networks than = at layer-3? > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > Of Don >> Sturek >> Sent: Wednesday, August 03, 2011 10:25 AM >> To: Torbet, Dan; v6ops@ietf.org; homenet@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >> Hi Dan, >>=20 >> Here is the initial scenario we are dealing with in the smart energy > arena: >>=20 >>=20 >>=20 >> Provider (eg ISP) Provider (eg > utility) >> | >> | >> CPE router >> CPE router >> | >> | >> Router --------------------------------- > router >> | Link layer >> | >> | Interconnect >> | >> > > iPads, >> plug in vehicles, >> Entertainment....> > load >> shed devices....> >>=20 >> I purposely drew in the devices the way I did since some of these > networks >> will evolve as silos then will interconnect when customers upgrade > their >> routers to ones with multiple link layers that accommodate > interconnection. >>=20 >> Ultimately, there will not be such a rigid division of devices like > shown but >> wanted to emphasize the likelihood that there will be multiple CPE > routers in >> the home and an interconnection between them within the home. >>=20 >> Don >>=20 >>=20 >>=20 >>=20 >> From: "Torbet, Dan" >> Date: Wed, 3 Aug 2011 07:42:53 -0600 >> To: "v6ops@ietf.org" , "homenet@ietf.org" > >> Subject: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >>=20 >>=20 >> The conversations so far on this topic have been great. I think > however, we >> need to take a step back for a moment and think through what the > HOMENET >> network looks like when serviced by a CPE Router. In my mind, we = have > a few >> scenarios that are possible. >>=20 >>=20 >>=20 >>=20 >> The first is a CPE ingress router to the home and no other routers. > There may >> be in this device multiple SSIDs and they each might need to have > their own >> address space and have separate firewall/filtering rules. In this > case, >> everything is contained in a single box and so no additional routing > protocols >> are needed. This has been defined in the CPE router (RFC 6204) and > the bis >> extension that is in draft right now. >>=20 >>=20 >>=20 >> The second case is a CPE ingress router with N routers behind it. In > this >> case, I humbly submit that anything where N is greater than 2 says > medium >> sized business maybe larger. I find it real hard to get any deeper > than 2 >> routers in series for a HOMENET class device deployment. Anything > greater than >> that and you likely would not use this class of device anyway. Sure > there >> will be situations where this is not true ,but I'll wager that in 90% > of the >> installations where a CPE router is providing the link to the world, > this will >> be the case. Even factoring in SmartGrid I just can't see a very = deep >> network. Is there a use case for more than 1 or 2 layers in a = HOMENET >> deployment that uses a CPE router as the connection to the world? To > be clear >> here - this is what I mean: >>=20 >> (sorry for the poor ASCII art here ) >>=20 >>=20 >>=20 >> Provider Router -------- CPE router ----------Router > ------ >> Router >>=20 >>=20 >>=20 >> Or >>=20 >>=20 >>=20 >>=20 >>=20 >> Provider >>=20 >> | >>=20 >> CPE Router >>=20 >> ^ >>=20 >> Router > Router >>=20 >> | >> | >>=20 >> Router > Router >>=20 >>=20 >>=20 >> I will acknowledge that in some business cases you might place a > router on >> each floor or each building in a campus, but this is where things get > blurry >> for me - would you really use a CPE router in these cases for ingress > into the >> business? You certainly could, but would you? >>=20 >>=20 >>=20 >> Given that, I think that defining how many routers exist behind this > CPE >> ingress router will provide us with a reasonable place from which to > define >> the needs and requirements for an IGP running in the home. >>=20 >>=20 >>=20 >> Dan >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From fred@cisco.com Wed Aug 3 10:04:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B573E21F8B7B; Wed, 3 Aug 2011 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty0AylitOxuE; Wed, 3 Aug 2011 10:04:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0914621F8B79; Wed, 3 Aug 2011 10:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=496; q=dns/txt; s=iport; t=1312391065; x=1313600665; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=OjM7luTFASZGfII3w/xgjpaY330O4Rnhc/VP9GBjr8c=; b=fbIQCsK1iR75naDflOQmevqhzwEj+acJ7N9vAJUCDGjlcuuEtBwVJMf4 uSVc5hS6UQ80tYmGnPInxa4Z6Ofm47EHlBRFw6cflAHVC8lXUgIY8RucQ T7DTqIwpViRlF//hUPvo8qbBxLTmdKPZY2zC0Xp4I0m30L1jhuahJkS0M g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB1/OU6rRDoI/2dsb2JhbABCp2B3gUABAQEBAgESASc/BQsLRlcGNYdKBKJBAZ5mhWNfBIdaiyGFB4t9 X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9316501" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 03 Aug 2011 17:04:24 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn3-550.cisco.com [10.21.66.38]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73H4NTp025456; Wed, 3 Aug 2011 17:04:23 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 10:04:23 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 10:04:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> Date: Wed, 3 Aug 2011 10:04:16 -0700 Message-Id: <6AD8BD68-9D16-48D6-AE2C-52F81CA74D79@cisco.com> References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> To: "Torbet, Dan" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "homenet@ietf.org" Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:04:13 -0000 On Aug 3, 2011, at 6:42 AM, Torbet, Dan wrote: > The conversations so far on this topic have been great. I think = however, we need to take a step back for a moment and think through what = the HOMENET network looks like when serviced by a CPE Router. In my = mind, we have a few scenarios that are possible. That was, of course, one of the objectives of http://tools.ietf.org/html/draft-baker-fun-multi-router "Exploring the multi-router SOHO network", Fred Baker, 1-Jul-11= From fred@cisco.com Wed Aug 3 10:06:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9479121F8B74; Wed, 3 Aug 2011 10:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsVuqBYSeHuj; Wed, 3 Aug 2011 10:06:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B855021F8B5E; Wed, 3 Aug 2011 10:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5629; q=dns/txt; s=iport; t=1312391193; x=1313600793; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=FbhtqaxQp70hQJHeCZHJmq8DA5VrvdbIZVJOHfcHC80=; b=amHSQYkTEhSA8jXIP9q4usSresEMLloeFlPO7puwPMksPC2v2zyRW7lf 2q5AcMzqBrY66AeJ1KqeMgDDdObSdimEWGp0PsWnGAAdLod8VSl6Aajf9 v3o5XABOR+cgPHu9HoEsLj6LBl51seBNsezPS+zggyFWD/QU3KCwOAeXw s=; X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9319369" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2011 17:06:25 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn3-550.cisco.com [10.21.66.38]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p73H6ODi016279; Wed, 3 Aug 2011 17:06:24 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 10:06:24 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 10:06:24 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> Date: Wed, 3 Aug 2011 10:06:17 -0700 Message-Id: References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, homenet@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:06:21 -0000 On Aug 3, 2011, at 9:46 AM, Rajiv Asati (rajiva) wrote: > Don, >=20 > Just curious about 'smart energy' home network - Why is there a router > behind the CPE router? Because there is not (today) a residential router that spans = 802.3/802.11 and 802.15.4 or 1901.2. There is therefore an expectation = that those interfaces might be on a separate router. I can imagine = vastly-multiport routers - you and I make them - but I can also imagine = a cluster of two-port routers. > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > Of Don >> Sturek >> Sent: Wednesday, August 03, 2011 10:25 AM >> To: Torbet, Dan; v6ops@ietf.org; homenet@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >> Hi Dan, >>=20 >> Here is the initial scenario we are dealing with in the smart energy > arena: >>=20 >>=20 >>=20 >> Provider (eg ISP) Provider (eg > utility) >> | >> | >> CPE router >> CPE router >> | >> | >> Router --------------------------------- > router >> | Link layer >> | >> | Interconnect >> | >> > > iPads, >> plug in vehicles, >> Entertainment....> > load >> shed devices....> >>=20 >> I purposely drew in the devices the way I did since some of these > networks >> will evolve as silos then will interconnect when customers upgrade > their >> routers to ones with multiple link layers that accommodate > interconnection. >>=20 >> Ultimately, there will not be such a rigid division of devices like > shown but >> wanted to emphasize the likelihood that there will be multiple CPE > routers in >> the home and an interconnection between them within the home. >>=20 >> Don >>=20 >>=20 >>=20 >>=20 >> From: "Torbet, Dan" >> Date: Wed, 3 Aug 2011 07:42:53 -0600 >> To: "v6ops@ietf.org" , "homenet@ietf.org" > >> Subject: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >>=20 >>=20 >> The conversations so far on this topic have been great. I think > however, we >> need to take a step back for a moment and think through what the > HOMENET >> network looks like when serviced by a CPE Router. In my mind, we = have > a few >> scenarios that are possible. >>=20 >>=20 >>=20 >>=20 >> The first is a CPE ingress router to the home and no other routers. > There may >> be in this device multiple SSIDs and they each might need to have > their own >> address space and have separate firewall/filtering rules. In this > case, >> everything is contained in a single box and so no additional routing > protocols >> are needed. This has been defined in the CPE router (RFC 6204) and > the bis >> extension that is in draft right now. >>=20 >>=20 >>=20 >> The second case is a CPE ingress router with N routers behind it. In > this >> case, I humbly submit that anything where N is greater than 2 says > medium >> sized business maybe larger. I find it real hard to get any deeper > than 2 >> routers in series for a HOMENET class device deployment. Anything > greater than >> that and you likely would not use this class of device anyway. Sure > there >> will be situations where this is not true ,but I'll wager that in 90% > of the >> installations where a CPE router is providing the link to the world, > this will >> be the case. Even factoring in SmartGrid I just can't see a very = deep >> network. Is there a use case for more than 1 or 2 layers in a = HOMENET >> deployment that uses a CPE router as the connection to the world? To > be clear >> here - this is what I mean: >>=20 >> (sorry for the poor ASCII art here ) >>=20 >>=20 >>=20 >> Provider Router -------- CPE router ----------Router > ------ >> Router >>=20 >>=20 >>=20 >> Or >>=20 >>=20 >>=20 >>=20 >>=20 >> Provider >>=20 >> | >>=20 >> CPE Router >>=20 >> ^ >>=20 >> Router > Router >>=20 >> | >> | >>=20 >> Router > Router >>=20 >>=20 >>=20 >> I will acknowledge that in some business cases you might place a > router on >> each floor or each building in a campus, but this is where things get > blurry >> for me - would you really use a CPE router in these cases for ingress > into the >> business? You certainly could, but would you? >>=20 >>=20 >>=20 >> Given that, I think that defining how many routers exist behind this > CPE >> ingress router will provide us with a reasonable place from which to > define >> the needs and requirements for an IGP running in the home. >>=20 >>=20 >>=20 >> Dan >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Wed Aug 3 10:42:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED96C21F854D for ; Wed, 3 Aug 2011 10:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKFXkGV+hzlH for ; Wed, 3 Aug 2011 10:42:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 64BDB21F8549 for ; Wed, 3 Aug 2011 10:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2647; q=dns/txt; s=iport; t=1312393379; x=1313602979; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ziOpEfmimziP3/2G9GKWPydY82mCJoRJs3XuowcC+6E=; b=HR4+eTjjlNok6PZEetr2M5eAr3Ozq78HQDuwRvH8A3RkFNYHIB+7ZJAP 9J6zW8lRkYKOhQlGCTlZ/+YCupFITaYu0aArNtq+/aDyRMR8qFyXHW7X4 marexKZiXN+do0a+EOsoxzQPe7hdzll53Y2HH+f7qr4kxUxWYBDZHLJVf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAANqHOU6rRDoI/2dsb2JhbABCmAaPWneBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah06iTwGeZ4VjXwSHWpAxi3I X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9335666" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 03 Aug 2011 17:42:58 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73HgphS010359; Wed, 3 Aug 2011 17:42:58 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 12:42: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 Date: Wed, 3 Aug 2011 12:42:55 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0599B4E1@XMB-RCD-111.cisco.com> In-Reply-To: <4E395600.7060901@inex.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxR5qWbLSoJdDu/TMKYFln3jj/8/wAHWv5A References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com><20110803183729.0a1367f8@opy.nosense.org><4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie><20110803222751.32fa28e6@opy.nosense.org> <4E395600.7060901@inex.ie> From: "Rajiv Asati (rajiva)" To: "Nick Hilliard" , "Mark Smith" X-OriginalArrivalTime: 03 Aug 2011 17:42:55.0609 (UTC) FILETIME=[C6D4E690:01CC5204] Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:42:47 -0000 Indeed, Nick. And even when they are purchased from outside (off-the-shelf), the cost varies depending on the protocol stack.=20 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick > Hilliard > Sent: Wednesday, August 03, 2011 10:07 AM > To: Mark Smith > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > On 03/08/2011 13:57, Mark Smith wrote: > > You seem to be assuming that CPE code is implemented from scratch. > > It's not, most commonly it is packaged up Linux with busybox, and, as an > > example, for IPv6 RAs, radvd. Quagga or one of the other open source > > OSPF implementations would easily run on CPE and is likely to be used. > > OpenWRT would be a very good example of what common CPE hardware is > > capable of with the right software, and quagga is a package available > > for it. >=20 > The Quagga OSPFv3 implementation is not very good, to the extent that I > would not use it in production. It lacks a pile of functionality, and is > relatively easy to crash. The Quagga IS-IS implementation (which is the > only open source IS-IS implementation as far as I can tell) has > substantially not been updated since it was written 10 years ago - and does > not support e.g. ipv6. >=20 > Also, as several people have pointed out, many ip stack implementations are > build from scratch, in-house. >=20 > > Yes, but if you take away essential or valuable functionality, you've > > gone too far, and will have to put it back or use something else to > > replace it. >=20 > It is still a lot simpler to add functionality to a specification than to > remove it later. Consequently, it is better to start with simpler > recommendations and to augment with retrospect, rather than to figure out > the best way to fit as many kitchen sinks in as possible. >=20 > > A basic OSPF default configuration with a single backbone area, which > > discovers any neighbors automatically on selected interfaces (i.e. all > > CPE non-WAN interfaces), forms adjacencies with them and then trades > > LSAs etc. is quite simple. Troubleshooting OSPF verses RIP is possibly a > > bit harder, but then mums and dads aren't going to be capable of > > troubleshooting RIP either. >=20 > Configuration complexity is not the problem. The problem is CPE device > build complexity. Pennies matter for these boxes. >=20 > Nick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Wed Aug 3 11:10:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9721F8538; Wed, 3 Aug 2011 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.662 X-Spam-Level: X-Spam-Status: No, score=-106.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBKwDpZkBjW3; Wed, 3 Aug 2011 11:10:09 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id AA2BC21F855D; Wed, 3 Aug 2011 11:10:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LPD00EX66FDYQV1@mail-out.apple.com>; Wed, 03 Aug 2011 11:09:31 -0700 (PDT) X-AuditID: 11807137-b7c4bae0000013e5-54-4e398fa2c4ed Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C7.82.05093.2AF893E4; Wed, 03 Aug 2011 11:12:50 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPD007GY6FVR190@kencur.apple.com>; Wed, 03 Aug 2011 11:09:31 -0700 (PDT) From: james woodyatt In-reply-to: <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> Date: Wed, 03 Aug 2011 11:09:30 -0700 Message-id: <80215711-1B7D-428C-9B7B-75D61BFAC66E@apple.com> References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiON1OTXdRv6WfwfqpihbvFx1isTh9bC+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyWl/uYy24w1zRfeYVawPjN6YuRk4OCQETiTO9K9gh bDGJC/fWs3UxcnEICbQzSVz9uIgZJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1soDY QgKTmCS2NSaD2MICfhJ7H59lBbHZBFQkvl2+ywTSyilgK3H/bglImEVAVeLz3QtMEGPMJD71 3mGC2GQjsbHpMxPECe8YJd6c/gqWEBFQlji1ZD4rxJ3yEotbPjNOYBSYheS6WQjXzUJy3QJG 5lWMgkWpOYmVhmZ6iQUFOal6yfm5mxhBAdhQaL6DcftfuUOMAhyMSjy8BUmWfkKsiWXFlbmH GCU4mJVEeOdVAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzbv5o5ickkJ5YkpqdmlqQWgSTZeLg lGpgdNO3vL5hprFBj1HC2hknAgOWWN3Kcyry+VTMG3H9RGjmbk45yVnpZT7zxPSTP6pev3pv uQJ/LFfmnI3he99MfmPEvGXWD71/nKqKf149ZTr+66ps4scpBxUk0o6+ZORNfhnfYL3dbUb7 rZT7pXNYf3nVGIjuEN1be2/mNb1Fq4TfeT6c8G/KQSWW4oxEQy3mouJEAEmSr+k8AgAA Cc: IPv6 Operations , homenet@ietf.org Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:10:10 -0000 On Aug 3, 2011, at 10:00 , Joel Jaeggli wrote: > > got a better idea for interconnecting 802.15.4 and 802.3 networks than at layer-3? How does 802.15.4 achieve the 1280 octet minimum MTU size required by IPv6? I'm sure this is explained in an RFC somewhere, but I don't know. Hoping someone knows off the top of their head and can quickly rattle off a citation from memory. -- james woodyatt member of technical staff, core os networking From rdroms@cisco.com Wed Aug 3 11:12:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554F921F8A57; Wed, 3 Aug 2011 11:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flhRftmNT1eX; Wed, 3 Aug 2011 11:12:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6742321F8A4D; Wed, 3 Aug 2011 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=747; q=dns/txt; s=iport; t=1312395141; x=1313604741; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=i0ZvOxk4yUEBWBq/ycv96hSsz8IhKKfVJwBMI0y0+Fo=; b=YO7oWwQS+NgMZNOKOQkndI9mQyZo0pZCXQVUN41V0wgLgFzT0bkmF1aq Z1Sq/yyJBXN8/dGuo+MtLyJIBk0fshF6+/A54r68oiy1qqF9iCiWuZH5L gUf5u3A2/ZFSkwOeY99rMlKDb73xq2vCtXZJlqyIExYGJ9hiUmv8yClN8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOGOOU6rRDoG/2dsb2JhbABDp2B3gUABAQEBAgEBAQEPASc0CwULCxguJzAGEyKHSgSiNAGeaYVjXwSSe5EA X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9345907" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 03 Aug 2011 18:12:20 +0000 Received: from bxb-rdroms-8712.cisco.com (bxb-rdroms-8712.cisco.com [10.98.10.83]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73ICJlQ003826; Wed, 3 Aug 2011 18:12:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <80215711-1B7D-428C-9B7B-75D61BFAC66E@apple.com> Date: Wed, 3 Aug 2011 14:12:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73A004D0-2CC2-4B19-A3B2-0ADB79081582@cisco.com> References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> <80215711-1B7D-428C-9B7B-75D61BFAC66E@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , homenet@ietf.org Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:12:09 -0000 RFC 4944 - Ralph On Aug 3, 2011, at 2:09 PM 8/3/11, james woodyatt wrote: > On Aug 3, 2011, at 10:00 , Joel Jaeggli wrote: >>=20 >> got a better idea for interconnecting 802.15.4 and 802.3 networks = than at layer-3? >=20 > How does 802.15.4 achieve the 1280 octet minimum MTU size required by = IPv6? I'm sure this is explained in an RFC somewhere, but I don't know. = Hoping someone knows off the top of their head and can quickly rattle = off a citation from memory. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Aug 3 14:21:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA69411E80A8 for ; Wed, 3 Aug 2011 14:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.91 X-Spam-Level: X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHNURH8nuwFw for ; Wed, 3 Aug 2011 14:21:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2089411E80A5 for ; Wed, 3 Aug 2011 14:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=449; q=dns/txt; s=iport; t=1312406510; x=1313616110; h=subject:mime-version:from:in-reply-to:date:cc:reply-to: message-id:references:to:content-transfer-encoding; bh=N9NCLzXFqB0hugXX2TCKtlBgt3e0GtZpLiSCnrU2kh4=; b=UwS+8wDcaD0dEIADg9sED7gnYjIXNs6gZUWWIXzG/1wv6/u/mYIRenjo AgjpTA0z16xAEHIhyDeAoxrEtQJSZhDR3yP/9Op+uaNwqM8CJf7ag/gJS 0GnVEmLrlXo3DJfCYJRWRocxMHn88k25i2uk+Zq4LXZJrvMhJZf8ejjIX o=; X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="scan'208";a="9416263" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2011 21:21:49 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn5-1063.cisco.com [10.21.92.39]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73LLnV3020447; Wed, 3 Aug 2011 21:21:49 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 14:21:49 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 14:21:49 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> Date: Wed, 3 Aug 2011 14:21:32 -0700 Message-Id: <5C124F58-6C9A-484B-9F4B-5EDB9EAA9BF2@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: homenet@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:21:37 -0000 On Jul 27, 2011, at 9:28 AM, Hemant Singh (shemant) wrote: > IPv6 CPE router vendors, please give feedback. Does anyone object if = we specify the default routing protocol as OSPFv3 with only area zero = for the IPv6 CE router bis document? Or would you prefer the document = is silent on specification of any default? I'd suggest we move the LAN discussion to homenet, unless it is required = for the completion of cpe-router-bis. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 14:59:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82111E8097 for ; Wed, 3 Aug 2011 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTbXy5dadAFz for ; Wed, 3 Aug 2011 14:59:34 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3411E8094 for ; Wed, 3 Aug 2011 14:59:34 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QojTZ-0002nS-VK; Thu, 04 Aug 2011 07:29:42 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 19E903B34D; Thu, 4 Aug 2011 07:29:41 +0930 (CST) Date: Thu, 4 Aug 2011 07:29:40 +0930 From: Mark Smith To: sthaug@nethelp.no Message-ID: <20110804072940.4db215df@opy.nosense.org> In-Reply-To: <20110803.153216.74731177.sthaug@nethelp.no> References: <4E392ABA.2010702@inex.ie> <20110803222751.32fa28e6@opy.nosense.org> <20110803.153216.74731177.sthaug@nethelp.no> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:59:35 -0000 On Wed, 03 Aug 2011 15:32:16 +0200 (CEST) sthaug@nethelp.no wrote: > > > Don't get me wrong. I like technology as much as anyone else, and the > > > thought of recommending RIP over ISIS for anything makes me feel dirty. > > > But the point is, RIP is a very simple protocol to implement, unlike either > > > IS-IS or OSPF. If you create a standard which sets the baseline too high, > > > you will end up with trashy implementations and excess complication. More > > > importantly, if you specify too much in an early RFC, how do you remove it > > > later if it turns out that it was a bad idea in retrospect? Look at all > > > the trouble that 6to4 is causing, yet people on this mailing list are > > > shirking at deprecating it. > > > > > > > You seem to be assuming that CPE code is implemented from scratch. > > As far as I know, that used to be the case for a lot of CPEs from > various Asian vendors and probably also others (e.g. Linksys). > > > It's not, most commonly it is packaged up Linux with busybox, and, as an > > example, for IPv6 RAs, radvd. > > I believe several vendors have changed their software development > model, and do indeed deliver systems based on Linux nowadays. I'd like > to see some more documentation before I conclude that this applies to > *most* vendors. > I've worked with 4 residential IPv6 vendors in the last 18 months, and all of them had CPE that was based on Linux etc., including one of the famous ones. There are a few other datapoints. Firstly the supported hardware for projects like OpenWRT, Tomato etc. that are Linux based. I think it is likely that the CPE has been easily "opened up" because it ran Linux in the first place. The other give away are the open source licenses and downloadable source code that the vendors must provide. An Internet search for the vendor name and "gpl" will usually show up the website of where you can see the licenses and download the source code - if they're complying with them of course. > > Quagga or one of the other open source > > OSPF implementations would easily run on CPE and is likely to be used. > > This is where I'm not completely convinced. A CPE vendor may conclude > that it is cost effective to deliver a system based on a Linux kernel, > but that other resource constraints (memory, flash, etc) dictate a > different set of software for routing protocols. Yes, more memory or > flash could easily accomodate Quagga etc - but these vendors are in > the business of saving 10 cents here and 50 cents there - multiplied > by many CPEs. > I understand that. Vendors however can be willing to increase pay those increases if necessary - one of the vendors I worked with increased the flash in the platform I worked on with them to support IPv6. The disappointing thing, at least from my recent experience with radvd, is that it seems that these vendors aren't very willing to contribute back to the projects they use. There may be opportunities to save memory and flash in these projects which would be cheaper to sponsor than putting extra memory or flash in each CPE. For example, the radvd binary between 1.7 to 1.8 shrunk significantly because of this simple patch - http://lists.litech.org/pipermail/radvd-devel-l/2011-May/000609.html Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Aug 3 15:09:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D421F87BD for ; Wed, 3 Aug 2011 15:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNxzIGuCTHzb for ; Wed, 3 Aug 2011 15:09:30 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9821F87AF for ; Wed, 3 Aug 2011 15:09:29 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QojdE-00036K-Cu; Thu, 04 Aug 2011 07:39:40 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 1C67E3B34D; Thu, 4 Aug 2011 07:39:40 +0930 (CST) Date: Thu, 4 Aug 2011 07:39:39 +0930 From: Mark Smith To: "Rajiv Asati (rajiva)" Message-ID: <20110804073939.4236eb5e@opy.nosense.org> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0599B4E1@XMB-RCD-111.cisco.com> References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> <20110803222751.32fa28e6@opy.nosense.org> <4E395600.7060901@inex.ie> <067E6CE33034954AAC05C9EC85E2577C0599B4E1@XMB-RCD-111.cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:09:30 -0000 On Wed, 3 Aug 2011 12:42:55 -0500 "Rajiv Asati (rajiva)" wrote: > Indeed, Nick. > > And even when they are purchased from outside (off-the-shelf), the cost > varies depending on the protocol stack. > If they're Linux based, then the vendor is buying Brooklyn bridge. IPv4 and IPv6 come free with Linux, as does the kernel itself, as long as you comply with the licenses. The tragedy in some respects is that there still seems to be a level of "preciousness" in the firmware, rather than realising it is extremely commodity. Consequently, you see things like the same bug in the firmware from two vendors, and have to ask for it to be fixed twice. You also see a vendor diligently make improvements to their firmware, and then they move to a new version of firmware from their upstream supplier, which doesn't have any of the improvements. The vendor then looses six months or more of time to market because the improvements didn't end up being pushed back up stream, and they have to re-implement them. If the vendors got together and put their resources into projects like OpenWRT everybody would be better off. The places where the vendor could value add would be the combinations of software and hardware features and performance (e.g. dual WAN, 3g, GigEs LAN interfaces, network printer support etc), and the experience of using the device e.g. the web gui. Regards, Mark. From john_brzozowski@cable.comcast.com Wed Aug 3 16:09:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BAB21F87C3 for ; Wed, 3 Aug 2011 16:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz8N8REVoQXk for ; Wed, 3 Aug 2011 16:09:05 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5F22521F8784 for ; Wed, 3 Aug 2011 16:09:01 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47249520; Tue, 02 Aug 2011 17:14:00 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 19:09:01 -0400 From: "Brzozowski, John" To: Nick Hilliard , Keith Moore Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUO1EzXadajaHM0CoA8rWqAKgMpUJwHsAgAA1iYCAACuhAA== Date: Tue, 2 Aug 2011 23:09:00 +0000 Message-ID: In-Reply-To: <4E381A43.3090107@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Aug 2011 16:40:23 -0700 Cc: "homenet@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:09:06 -0000 On 8/2/11 11:39 AM, "Nick Hilliard" wrote: >On 02/08/2011 13:28, Keith Moore wrote: >> A different idea is that the firewall always work in a very minimal mode >> by default (e.g. it passes no traffic, or maybe only outgoing port 80 >> traffic, but its configuration interface is enabled for the internal >> ports) so that the user must configure it in order to get it to do >> anything useful. > >Each support call into a support centre costs money, and if you scale it >up, any user that ends up calling support is basically losing money for >the >ISP. Yes, margins are that thin. [jjmb] +1 > >Building a firewall that almost guarantees that an end-user will need to >open a support call is both useless to the end-user and financially >harmful >to a service provider. There is no point whatsoever in doing this - it >adds pointless complexity with no measurable return. [jjmb] conversely building a firewall that exposes the provider will also cost in some way shape or form. > >If you want to build a router suitable for Keith Moore, then go out and >customise a WRT54G, or hack a soekris into shape. But don't assume that >most end-users have either the interest or the capability to work out a >good quality security policy for themselves because by-and-large, they >don't. [jjmb] advanced users should buy advance routers so they can do advanced things. > >Nick >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Aug 3 16:49:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877C11E80BA for ; Wed, 3 Aug 2011 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER4lylapVACG for ; Wed, 3 Aug 2011 16:49:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4111E80B0 for ; Wed, 3 Aug 2011 16:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=11975; q=dns/txt; s=iport; t=1312415387; x=1313624987; h=from:mime-version:subject:date:references:cc:to: message-id; bh=f6WGaHIzQwe8i7c9NNhy6sKfR7KHQNFbi4omwT15wkc=; b=Gzs84IZdfLgkhK9RJbeaLQ4BHzfUXPLGarmq+A7P7+HYyWsocL7kYrYM yMlDSvQBTyQ7wvJc0etMSu1OyxCOmZkhreCwpc8zXPWgGWiDqg7o+s7So 2SqoPSigAeux4qdVQ+mLQ+lwRZzEcwc+0Ad3U0zX3vDhZFLa30m2qooJP w=; X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGbdOU6rRDoH/2dsb2JhbAA/A6Z0bXeBNwkBAQEBAgESAVsLBQsOAQILAwECKAdGBwIIBhMih0oEoiQBnm2DPoIlXwSCUIUKhiSEfYUHi30 X-IronPort-AV: E=Sophos;i="4.67,313,1309737600"; d="eml'208?scan'208,208,217";a="9462481" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2011 23:49:46 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn5-1063.cisco.com [10.21.92.39]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73Nnk0b012904; Wed, 3 Aug 2011 23:49:46 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Wed, 03 Aug 2011 16:49:46 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Wed, 03 Aug 2011 16:49:46 -0700 From: Fred Baker Mime-Version: 1.0 (Apple Message framework v1084) Date: Wed, 3 Aug 2011 16:49:29 -0700 References: To: IPv6 Operations Message-Id: <4BBC5E1D-5E07-454A-814F-F0224208CC86@cisco.com> X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--899279278 Subject: [v6ops] Fwd: v6ops bounces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:49:35 -0000 --Apple-Mail-8--899279278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI bora@broadcom apparently left broadcom, and whenever an email is sent to = the list boradcom responds with a bounce. Net effect: several folks = appear to have been bounced off the list - even though I jumped the = threshold for that up to prevent that from happening. I have removed him from the list. If you know of people who have been bounced off, please suggest that = they rejoin. Fred, your friendly mailing list admin... Begin forwarded message: > From: "Brzozowski, John" > Date: August 2, 2011 2:58:45 PM PDT > To: Fred Baker > Subject: v6ops bounces >=20 > Any idea why this is happening? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 --Apple-Mail-8--899279278 Content-Type: multipart/mixed; boundary=Apple-Mail-9--899279278 --Apple-Mail-9--899279278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: "Brzozowski, John" = <John_Brzozowski@Cable.Co= mcast.com>
Date: August 2, 2011 2:58:45 PM PDT
To: Fred Baker <fred@cisco.com>
Subject: v6ops = bounces

Any idea why this is = happening?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John= Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@c= able.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


<= /body>= --Apple-Mail-9--899279278 Content-Disposition: attachment; filename="Mail Attachment.eml" Content-Type: message/rfc822; name="Mail Attachment.eml" Content-Transfer-Encoding: 7bit Received: from cable.comcast.com (24.40.8.142) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 2 Aug 2011 17:54:36 -0400 Received: from ([24.40.8.143]) by pacdcimi01.cable.comcast.com with ESMTP id 5503565.155683664; Tue, 02 Aug 2011 17:54:34 -0400 Received: from ([64.170.98.30]) by pacdcedge01.cable.comcast.com with ESMTP id 5302275.EDGE; Tue, 02 Aug 2011 17:54:34 -0400 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6776021F85AA for ; Tue, 2 Aug 2011 14:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312322060; bh=yig0Er8PuulYTdniaMZIlnxLrzQp3RyOpfjVsCXvpW0=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:From: To:Message-ID:Date:List-Id:Sender; b=HHOzSedyPVSCJ01G9ZU5+MyYXtIDFdYuu0RdlqAGkLbC8wv2Jg8nweFROCmsVDHHu 11QXpYW1KlaXBTjFlpmCejPoBeSRRk5wuNP+0/9n9L8QuqQTDCV+h0gUqPggTL+Xs7 nuf8c9gNQbzi7Bv0OvywIWZkiWCfg2L6E8fTDfoY= Subject: Your message to v6ops awaits moderator approval From: To: Message-ID: Date: Tue, 2 Aug 2011 14:54:18 -0700 Precedence: bulk X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list X-List-Administrivia: yes Sender: Errors-To: v6ops-bounces@ietf.org X-esp: ESP<12>= SHA:<0> SHA_FLAGS:<0> UHA:<13> ISC:<0> BAYES:<-1> DKIM:<0> TS:<0> SIG:<> DSC:<0> TRU_scam_spam: <0> TRU_ru_spamsubj: <0> TRU_playsites: <0> TRU_spam2: <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_urllinks: <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> Return-Path: v6ops-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: PACDCEXHUB02.cable.comcast.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-SCL: 0 X-MS-Exchange-Organization-Antispam-Report: v=1.1 cv=MTuXQFnH5TERHqEDfPmIB3CYl8g3Nl2xcInjZDZxYT8= c=1 sm=1 a=BHBjwZcipm4A:10 a=LSVET5z0puwA:10 a=kj9zAlcOel0A:10 a=zMsM9xl/GEwtv+TfZmYMjQ==:17 a=48vgC7mUAAAA:8 a=e2Hco4UgFpnZFYKw9VIA:9 a=CjuIK1q_8ugA:10 a=zMsM9xl/GEwtv+TfZmYMjQ==:117;OrigIP:24.40.8.143;SCL:0 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Your mail to 'v6ops' with the subject Re: [v6ops] default LAN routing protocol for IPv6 CE router Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/v6ops/83b16c18aade057a1d13d0b67201284130e1491a --Apple-Mail-9--899279278 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail-9--899279278 Content-Disposition: attachment; filename="Mail Attachment.eml" Content-Type: message/rfc822; name="Mail Attachment.eml" Content-Transfer-Encoding: 7bit Received: from cable.comcast.com (24.40.8.142) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 2 Aug 2011 17:57:37 -0400 Received: from ([24.40.8.144]) by pacdcimi01.cable.comcast.com with ESMTP id 5503565.155683959; Tue, 02 Aug 2011 17:57:32 -0400 Received: from ([64.170.98.30]) by pacdcedge02.cable.comcast.com with ESMTP id 5302274.EDGE; Tue, 02 Aug 2011 17:57:32 -0400 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B4821F85AA for ; Tue, 2 Aug 2011 14:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312322242; bh=7GcQoRvv5Ya3chSmU37XUrcHxmB85C47BJGtRARJqFo=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:From: To:Message-ID:Date:List-Id:Sender; b=aan4Cq5XuUn6HXB5LLZ7UXUcylPrY2DqvjZRoscO+wDpVJxpmRLyE2XlTrKkgE1WP FX7Q4eGIvTWYjJDM8W5BMZv/Sw56nMgzvnHwPwqF3brfcoSx2rBDnrP8mUUq5TAdLW 95u6zF0zkty21uSKxT3nCV3laUs37EDnVFLhxE6Y= Subject: Your message to v6ops awaits moderator approval From: To: Message-ID: Date: Tue, 2 Aug 2011 14:57:20 -0700 Precedence: bulk X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list X-List-Administrivia: yes Sender: Errors-To: v6ops-bounces@ietf.org X-esp: ESP<12>= SHA:<0> SHA_FLAGS:<0> UHA:<13> ISC:<0> BAYES:<-1> DKIM:<0> TS:<0> SIG:<> DSC:<0> TRU_scam_spam: <0> TRU_ru_spamsubj: <0> TRU_playsites: <0> TRU_spam2: <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_urllinks: <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> Return-Path: v6ops-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: PACDCEXHUB02.cable.comcast.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-SCL: 0 X-MS-Exchange-Organization-Antispam-Report: v=1.1 cv=MTuXQFnH5TERHqEDfPmIB3CYl8g3Nl2xcInjZDZxYT8= c=1 sm=1 a=BHBjwZcipm4A:10 a=LSVET5z0puwA:10 a=kj9zAlcOel0A:10 a=Iecc0d72nz2eu//pniCxAg==:17 a=48vgC7mUAAAA:8 a=e2Hco4UgFpnZFYKw9VIA:9 a=CjuIK1q_8ugA:10 a=Iecc0d72nz2eu//pniCxAg==:117;OrigIP:24.40.8.144;SCL:0 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Your mail to 'v6ops' with the subject Re: [v6ops] default LAN routing protocol for IPv6 CE router Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/v6ops/b90659ea632bccb29733102b3e8330a96b7a3353 --Apple-Mail-9--899279278 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail-9--899279278-- --Apple-Mail-8--899279278-- From warren@kumari.net Wed Aug 3 17:19:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74A521F8828; Wed, 3 Aug 2011 17:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ducqoqCjUKOV; Wed, 3 Aug 2011 17:19:05 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9121F881C; Wed, 3 Aug 2011 17:19:05 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 6E0151B4127F; Wed, 3 Aug 2011 20:19:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 3 Aug 2011 20:19:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067E6CE33034954AAC05C9EC85E2577C058E6EF7@XMB-RCD-111.cisco.com> <20110803183729.0a1367f8@opy.nosense.org> <4E3920D1.1090705@inex.ie> <4E392ABA.2010702@inex.ie> <4E39405D.8080706@inex.ie> <4E394EFC.9010404@viagenie.ca> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:19:06 -0000 On Aug 3, 2011, at 9:50 AM, Ray Bellis wrote: >=20 > On 3 Aug 2011, at 14:37, Simon Perreault wrote: >=20 >> Why does it matter at all? All consumer-grade home routers are built = on >> open-source software. >=20 > In my experience that's simply not true. >=20 > When testing 20+ routers for SSAC035 and RFC 5625 we found _barely = any_ that were using recognisable OSS stacks for their implementations. >=20 > Admittedly that was two years ago, and Linux / busybox / dnsmasq is = probably somewhat more popular now than then, but the variety of bugs we = saw then was far too great to suggest any significant commonality in = their code bases. +1. Also, the number of scary bugs (and unusable UIs and weirdly limited = features) makes me really really afraid of how routing protocols will be = implemented, especially anything link-stateish.=20 W >=20 > Ray >=20 > [reply-to set to Homenet] > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From newbery@gmail.com Wed Aug 3 17:39:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF021F8A91 for ; Wed, 3 Aug 2011 17:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk9kJAqfMu1s for ; Wed, 3 Aug 2011 17:39:58 -0700 (PDT) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 64FFB21F8A80 for ; Wed, 3 Aug 2011 17:39:58 -0700 (PDT) Received: by qyk2 with SMTP id 2so406046qyk.15 for ; Wed, 03 Aug 2011 17:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=P0pitWhdaI3XPNeZYPAMeRtkeJqd7xWl7iK4Oxz0BRM=; b=uiaZB01bK/VI/HYhrqGr59Nq86TBEvy5tE7FCCP56YIfRKbT1Nl+aP0qxun3S9z/vh fJcTVHj3vjY0phGkE+TbavZMu9Uon8SIao4z72duOr0CJgGkb4iWcc7pBtkA2qux49yn eSLKHW8+YgapC9PfaskdTKern+NTOCs/N61ok= Received: by 10.224.194.194 with SMTP id dz2mr86919qab.78.1312418409451; Wed, 03 Aug 2011 17:40:09 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id m7sm1006469qct.29.2011.08.03.17.40.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 17:40:08 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--896246449; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 4 Aug 2011 12:39:56 +1200 In-Reply-To: To: IPv6 Operations References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> Message-Id: <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:39:59 -0000 --Apple-Mail-1--896246449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3/08/2011, at 8:45 PM, Philip Homburg wrote: > In your letter dated Wed, 3 Aug 2011 13:42:05 +1200 you wrote: >> Looking at http://www.apple.com I count >> 32 Images >> 11 Scripts >> 5 Stylesheets >> and the base HTML document itself.=3D20 >>=20 >> 49 URLs to be fetched >>=20 >> Apple/s front page is if anything atypically spare in terms of = elements. =3D >> The New York TImes has 126 URLs. >>=20 >> If we were just looking at delaying the SINGLE first SYN, and if in =3D= >> addition we perform no parellisation or other optimisation (and of =3D >> course modern browsers do both, but anyway) then 30ms would add 1.5 =3D= >> seconds to the load time of Apple's page and 3.8 to the NYT. Just = from =3D >> the bandwidth delay product. >=20 > The delay bandwidth product is the amount of data that has to be kept = in > flight to fill the 'tube'. Yes, and windowing can address that. But you have to open the initial = connection. That first handshake is subject to latency. >=20 > You can't just add up delays of different connections. It is the delay > across a single connection that matters. When someone opens a web page, it goes: 1. Start a TCP session. 2. Fetch the page #1 depends on latency, but it's only one connection. #2 depends more on = bandwidth, slightly on latency and windowing helps here. 3. Parse the page and extract lots of embedded URLs. Some of these will be to the initial site, but a lot won't. Many are to = ad servers, web trackers, assorted web resources, etc.. For each of = these, the browser has to open a session and fetch the resource. If the = browser is at all simple-minded and does things in a mostly serial = fashion, then all those initial latencies will sum. Note that even = infinite bandwidth does not help here, it's the latency which is the = killer. So, you DO have to add up the delays of different connections. = And on most modern web pages, there are a lot of them. >=20 > Anyhow, browsers do use parallelism to reduce the impact of latency. = Why do > you then present a calculation that assumes they don't? >=20 > For 49 URLs at 15 URLs in parallel to a single server, this would give = an > additional delay of 120ms. Hardly worth writing home about. For 126 = URLs > it would be 270ms. Not all browsers behave as you describe. Some do, in fact that's where a = lot of browsers are making improvements, simply because as bandwidth has = risen, latency has become the great enemy and parallelism is one of the = few client options available to combat it. However, I see no reason to make the browser's job any harder. If = latency is to be deliberately introduced, then it needs to be done = because there is a greater benefit to the user than by not introducing = it. --Apple-Mail-1--896246449 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwODA0MDA0MDAy WjAjBgkqhkiG9w0BCQQxFgQUHT3knrjAaNHe89IOCryCrvohdTYwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBADZBLhZh4zTwCjW3H9E8HFcV0nwnvS/qqjQs3QHWfz4jYvLXl1JHDYzfl5dZ QdADSJJQgd8eZODjopV4te8nk8jDUAuBa5R+0AdgN8mYUt8r2PhiD6+kXp8/O8EliQCKlLJ7p6S+ Ls/AxgyKSRTzfose9qw5U6SctlGXpPn9wEv686SmR4iSi0y0DIPALlr4W+n7Mo3ou73ZOrpjbaUU hBPS5iefswLn1g2sVaE8xVVNcgfAFDIBlG6xO/NJ7hGLD0sFal1G+RHSbqghYRNrcj1ECU+OZ/wq 4KNVbrU9Wuyp9MbIBt4lBuMLSCKNRDvHYe2dhqy5OAaNgUaT4J9pVpIAAAAAAAA= --Apple-Mail-1--896246449-- From marka@isc.org Wed Aug 3 18:29:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D821F8AC9 for ; Wed, 3 Aug 2011 18:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAwMVzG1JHDE for ; Wed, 3 Aug 2011 18:29:08 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 408D221F8A7B for ; Wed, 3 Aug 2011 18:29:06 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E7658C9423; Thu, 4 Aug 2011 01:29:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 618CD216C7B; Thu, 4 Aug 2011 01:29:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D8797126C146; Thu, 4 Aug 2011 11:29:03 +1000 (EST) To: Michael Newbery From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> In-reply-to: Your message of "Thu, 04 Aug 2011 12:39:56 +1200." <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> Date: Thu, 04 Aug 2011 11:29:03 +1000 Message-Id: <20110804012903.D8797126C146@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:29:08 -0000 In message <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com>, Michael Newbery writes: > > --Apple-Mail-1--896246449 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > > On 3/08/2011, at 8:45 PM, Philip Homburg wrote: > > > In your letter dated Wed, 3 Aug 2011 13:42:05 +1200 you wrote: > >> Looking at http://www.apple.com I count > >> 32 Images > >> 11 Scripts > >> 5 Stylesheets > >> and the base HTML document itself.=3D20 > >>=20 > >> 49 URLs to be fetched > >>=20 > >> Apple/s front page is if anything atypically spare in terms of > elements. =3D > >> The New York TImes has 126 URLs. > >>=20 > >> If we were just looking at delaying the SINGLE first SYN, and if in =3D > > >> addition we perform no parellisation or other optimisation (and of =3D > >> course modern browsers do both, but anyway) then 30ms would add 1.5 =3D > > >> seconds to the load time of Apple's page and 3.8 to the NYT. Just > from =3D > >> the bandwidth delay product. > >=20 > > The delay bandwidth product is the amount of data that has to be kept > in > > flight to fill the 'tube'. > > Yes, and windowing can address that. But you have to open the initial > connection. That first handshake is subject to latency. > > > > You can't just add up delays of different connections. It is the delay > > across a single connection that matters. > > When someone opens a web page, it goes: > 1. Start a TCP session. > 2. Fetch the page > > #1 depends on latency, but it's only one connection. #2 depends more on > bandwidth, slightly on latency and windowing helps here. > > 3. Parse the page and extract lots of embedded URLs. > Some of these will be to the initial site, but a lot won't. Many are to > ad servers, web trackers, assorted web resources, etc.. For each of > these, the browser has to open a session and fetch the resource. If the > browser is at all simple-minded and does things in a mostly serial > fashion, then all those initial latencies will sum. Note that even > infinite bandwidth does not help here, it's the latency which is the > killer. So, you DO have to add up the delays of different connections. > And on most modern web pages, there are a lot of them. > > > > Anyhow, browsers do use parallelism to reduce the impact of latency. > Why do > > you then present a calculation that assumes they don't? > > > > For 49 URLs at 15 URLs in parallel to a single server, this would give > an > > additional delay of 120ms. Hardly worth writing home about. For 126 > URLs > > it would be 270ms. > > Not all browsers behave as you describe. Some do, in fact that's where a > lot of browsers are making improvements, simply because as bandwidth has > risen, latency has become the great enemy and parallelism is one of the > few client options available to combat it. > > However, I see no reason to make the browser's job any harder. If > latency is to be deliberately introduced, then it needs to be done > because there is a greater benefit to the user than by not introducing > it. Engineering is often about making decisions about what is best for the whole rather than what is best for one component of the system. If IPv4 and IPv6 will be of equal cost to provide then taking the best RTT is the right choice but we know the IPv4 is going to be more costly in the long term to provide and that the additional cost will be proportional to the amount of IPv4 traffic so adding a small IPv6 bias in the destination selection will reduce the overall costs to the user. The costs of deploying LSN will ultimately be borne by the customer in one way or another. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Wed Aug 3 18:32:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3511E80C3 for ; Wed, 3 Aug 2011 18:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.876 X-Spam-Level: X-Spam-Status: No, score=-105.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ1Um+4iXzQX for ; Wed, 3 Aug 2011 18:32:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 851DC11E80C1 for ; Wed, 3 Aug 2011 18:32:38 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p741Wpuw001075 for ; Wed, 3 Aug 2011 18:32:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312421571; bh=7OVIcoihKwFJJf1SOVh7a0h0pCI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=He+TBV2vRxrAlurPmjkY6T1yOqFDTVGS9scrydcSKjCDX+CiIyyMgRXLNVykUq995 4zuB8oZ4DRq7BN3BA1Clw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=PKZk0Wt6H/BFvVFOXT4m0AQf2AO2K/1umPjVSqsF9+oABt7OJZRoFnK8tnyKPz8qT gAv9btLr3mTCIs1CPjgbA== Received: from yib17 (yib17.prod.google.com [10.243.65.81]) by wpaz1.hot.corp.google.com with ESMTP id p741VODx020887 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 3 Aug 2011 18:32:50 -0700 Received: by yib17 with SMTP id 17so103690yib.21 for ; Wed, 03 Aug 2011 18:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NoaFitOQ8HxWVvFZxTsRgLT59jbUKYZZeGGPVbLGFfc=; b=sHGpl5Wxls3dVtSryEsXh+pxsGUrL3m5pL8Gb4mkJFl/Gf1qSTrdxnS5VwBjb9qdyN 0ZtaXJlCcx+m9Nx4AvRQ== Received: by 10.150.160.21 with SMTP id i21mr1421968ybe.57.1312421570227; Wed, 03 Aug 2011 18:32:50 -0700 (PDT) Received: by 10.150.160.21 with SMTP id i21mr1421962ybe.57.1312421570097; Wed, 03 Aug 2011 18:32:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Wed, 3 Aug 2011 18:32:30 -0700 (PDT) In-Reply-To: <20110804012903.D8797126C146@drugs.dv.isc.org> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> From: Lorenzo Colitti Date: Wed, 3 Aug 2011 18:32:30 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=000e0cdf1c567b331104a9a3f52b X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:32:39 -0000 --000e0cdf1c567b331104a9a3f52b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 3, 2011 at 18:29, Mark Andrews wrote: > If IPv4 and IPv6 will be of equal cost to provide then taking the > best RTT is the right choice but we know the IPv4 is going to be > more costly in the long term to provide and that the additional > cost will be proportional to the amount of IPv4 traffic so adding > a small IPv6 bias in the destination selection will reduce the > overall costs to the user. The costs of deploying LSN will ultimately > be borne by the customer in one way or another. > I think that what you're saying is that ISPs want users to use IPv6. But James is saying is that if ISPs wanted their users to use IPv6, they would deploy IPv6. So I doubt that you will agree :-) --000e0cdf1c567b331104a9a3f52b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3, 2011 at 18:29, Mark Andrews <marka@isc.org> wrote:
If IPv4 and IPv6 will be of equal cost to provide then taking the
best RTT is the right choice but we know the IPv4 is going to be
more costly in the long term to provide and that the additional
cost will be proportional to the amount of IPv4 traffic so adding
a small IPv6 bias in the destination selection will reduce the
overall costs to the user. =A0The costs of deploying LSN will ultimately be borne by the customer in one way or another.

I think that what you're saying is that ISPs want users to use= IPv6. But=A0James is saying is that=A0if ISPs wanted their users to use IP= v6, they would deploy IPv6. So I doubt that you will agree :-)
--000e0cdf1c567b331104a9a3f52b-- From marka@isc.org Wed Aug 3 19:46:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72425E8005 for ; Wed, 3 Aug 2011 19:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2WczCdOCc9L for ; Wed, 3 Aug 2011 19:46:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 277A35E8001 for ; Wed, 3 Aug 2011 19:46:59 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1F5B9C941E; Thu, 4 Aug 2011 02:47:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 821A7216C7B; Thu, 4 Aug 2011 02:47:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E9DD5126C85A; Thu, 4 Aug 2011 12:47:01 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 03 Aug 2011 18:32:30 MST." Date: Thu, 04 Aug 2011 12:47:01 +1000 Message-Id: <20110804024701.E9DD5126C85A@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:46:59 -0000 In message , Lorenzo Colitti writes: > On Wed, Aug 3, 2011 at 18:29, Mark Andrews wrote: > > > If IPv4 and IPv6 will be of equal cost to provide then taking the > > best RTT is the right choice but we know the IPv4 is going to be > > more costly in the long term to provide and that the additional > > cost will be proportional to the amount of IPv4 traffic so adding > > a small IPv6 bias in the destination selection will reduce the > > overall costs to the user. The costs of deploying LSN will ultimately > > be borne by the customer in one way or another. > > > > I think that what you're saying is that ISPs want users to use IPv6. > But James is saying is that if ISPs wanted their users to use IPv6, they > would deploy IPv6. So I doubt that you will agree :-) No. I'm arguing about what the behaviour should be when the ISP *has* deployed IPv6 along side IPv4 or is IPv6 only with DS-Lite or NAT64/DNS64 (DNS64 already has some IPv6 bias built in). IPv6 is basically shuffle packet. IPv4 is shuffle and mangle packets. The mangle packets parts is the additional cost but it may not have a noticable time penalty. Often it will be a IPv6 router sitting next to a LSN/AFTR/NAT64 boxes so there isn't even a extra hop penalty. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Wed Aug 3 20:07:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670305E800B for ; Wed, 3 Aug 2011 20:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stk+4vXxSEcj for ; Wed, 3 Aug 2011 20:07:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9771C5E8009 for ; Wed, 3 Aug 2011 20:07:00 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p7437Ast009232 for ; Wed, 3 Aug 2011 20:07:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312427231; bh=l9489tVPrN7nSMW9z1duMWkD1UI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CgbO3E4bDkssySTq3r0SNTH8J84YvCt4IYTYEEIRPFTMpwaoeLg4is2GkzGmrR3tM BYOaWkvY3aRujI8ZEB2FQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Xdg1+C4HRXmQUlrdMVlgdmexE4URftdXzr/zjtXWHyp/S5ViHKzAL6YVly17w/tgn p64/wgs0f7eKALvYD2oyQ== Received: from gwj22 (gwj22.prod.google.com [10.200.10.22]) by wpaz29.hot.corp.google.com with ESMTP id p7436l7p020621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 3 Aug 2011 20:07:09 -0700 Received: by gwj22 with SMTP id 22so1222774gwj.35 for ; Wed, 03 Aug 2011 20:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OFFPGy6xYN6hODbgEzdLR+/vDD/Fk2vnTKQ4o4mGfUE=; b=uIVWLRok/EiPjU8+KIiDl2mF1jqLH0/ve9N0sPhgr97V3rUHRXUrF+0svTxjKb8X/g Q/gupJjghSILkq0p1zaQ== Received: by 10.150.160.21 with SMTP id i21mr1485911ybe.57.1312427229348; Wed, 03 Aug 2011 20:07:09 -0700 (PDT) Received: by 10.150.160.21 with SMTP id i21mr1485905ybe.57.1312427229164; Wed, 03 Aug 2011 20:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Wed, 3 Aug 2011 20:06:49 -0700 (PDT) In-Reply-To: <20110804024701.E9DD5126C85A@drugs.dv.isc.org> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> From: Lorenzo Colitti Date: Wed, 3 Aug 2011 20:06:49 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=000e0cdf1c56c9b5d204a9a546ef X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 03:07:01 -0000 --000e0cdf1c56c9b5d204a9a546ef Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 3, 2011 at 19:47, Mark Andrews wrote: > > I think that what you're saying is that ISPs want users to use IPv6. > > But James is saying is that if ISPs wanted their users to use IPv6, they > > would deploy IPv6. So I doubt that you will agree :-) > > No. I'm arguing about what the behaviour should be when the ISP > *has* deployed IPv6 along side IPv4 or is IPv6 only with DS-Lite > or NAT64/DNS64 (DNS64 already has some IPv6 bias built in). > And I suspect what James is saying is that today, what you describe is such a small percentage of the Internet that there's no point optimizing for it in current operating systems. I don't necessarily agree - for example, I think a 10ms latency penalty is still worth it if real IPv6 is available - but I can see his point. --000e0cdf1c56c9b5d204a9a546ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3, 2011 at 19:47, Mark Andrews <marka@isc.org> wrote:
> I think that what you're saying is that ISP= s want users to use IPv6.
> But James is saying is that if ISPs wanted their users to use IPv6, th= ey
> would deploy IPv6. So I doubt that you will agree :-)

No. I'm arguing about what the behaviour should be when the= ISP
*has* deployed IPv6 along side IPv4 or is IPv6 only with DS-Lite
or NAT64/DNS64 (DNS64 already has some IPv6 bias built in).

And I suspect what James is saying is that today, what= you describe is such a small percentage of the Internet that there's n= o point optimizing for it in current operating systems.

I don't necessarily agree - for example, I think a = 10ms latency penalty is still worth it if real IPv6 is available - but I ca= n see his point.
--000e0cdf1c56c9b5d204a9a546ef-- From ggm+ietf@apnic.net Wed Aug 3 20:25:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B95221F86DE for ; Wed, 3 Aug 2011 20:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v72autrEhTD4 for ; Wed, 3 Aug 2011 20:25:48 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2321F86C7 for ; Wed, 3 Aug 2011 20:25:48 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c] (unknown [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C3E41B6937; Thu, 4 Aug 2011 13:25:59 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Michaelson In-Reply-To: Date: Thu, 4 Aug 2011 13:26:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <87DDEF7F-10ED-426D-8798-E023CFEF6B34@apnic.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 03:25:49 -0000 On 04/08/2011, at 1:06 PM, Lorenzo Colitti wrote: > On Wed, Aug 3, 2011 at 19:47, Mark Andrews wrote: > > I think that what you're saying is that ISPs want users to use IPv6. > > But James is saying is that if ISPs wanted their users to use IPv6, = they > > would deploy IPv6. So I doubt that you will agree :-) >=20 > No. I'm arguing about what the behaviour should be when the ISP > *has* deployed IPv6 along side IPv4 or is IPv6 only with DS-Lite > or NAT64/DNS64 (DNS64 already has some IPv6 bias built in). >=20 > And I suspect what James is saying is that today, what you describe is = such a small percentage of the Internet that there's no point optimizing = for it in current operating systems. >=20 > I don't necessarily agree - for example, I think a 10ms latency = penalty is still worth it if real IPv6 is available - but I can see his = point. I entirely agree with what Apple has done so far. I think its made sense = to me, as a user of their product. I could ask for a tuneable (and I did in fact ask James) but, = pragmatically, given online update cycles, this is within the scope of = Apple to fix later on at very low pain. I know others disagree, but I think Apple has made a reasonable, = justifiable decision for now, and I agree with Lorenzo that it reflects = v4/v6 as we see it NOW. Not what we WANT. What we SEE. Mark, you can't expect people to flag-wave for the future on their = flagship. They put the smallest flag they can on the backstaff. Wait = until the wind rises, bigger flags will come -George From marka@isc.org Wed Aug 3 20:36:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8F11E809E for ; Wed, 3 Aug 2011 20:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZMMnZpFdhwJ for ; Wed, 3 Aug 2011 20:36:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 449AB11E8073 for ; Wed, 3 Aug 2011 20:36:09 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 057035F988D; Thu, 4 Aug 2011 03:36:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 174A2216C81; Thu, 4 Aug 2011 03:36:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 19231126CE1C; Thu, 4 Aug 2011 13:36:06 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 03 Aug 2011 20:06:49 MST." Date: Thu, 04 Aug 2011 13:36:06 +1000 Message-Id: <20110804033606.19231126CE1C@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 03:36:10 -0000 In message , Lorenzo Colitti writes: > --000e0cdf1c56c9b5d204a9a546ef > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Aug 3, 2011 at 19:47, Mark Andrews wrote: > > > > I think that what you're saying is that ISPs want users to use IPv6. > > > But James is saying is that if ISPs wanted their users to use IPv6, they > > > would deploy IPv6. So I doubt that you will agree :-) > > > > No. I'm arguing about what the behaviour should be when the ISP > > *has* deployed IPv6 along side IPv4 or is IPv6 only with DS-Lite > > or NAT64/DNS64 (DNS64 already has some IPv6 bias built in). > > > > And I suspect what James is saying is that today, what you describe is such > a small percentage of the Internet that there's no point optimizing for it > in current operating systems. It all depends on when you think deployment of CGN/AFTR/NAT64 boxes will happen. My feeling is you will see these boxes being widely deployed within 3 years and ISP's scrambling to move IPv4 only customers to IPv4 + IPv6 or IPv6 only to reduce the number of CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code shouldn't make the problem worse when this happens. > I don't necessarily agree - for example, I think a 10ms latency penalty is > still worth it if real IPv6 is available - but I can see his point. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ggm+ietf@apnic.net Wed Aug 3 21:10:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC3521F8757 for ; Wed, 3 Aug 2011 21:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sZver8NeLwf for ; Wed, 3 Aug 2011 21:10:07 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id DB17821F8640 for ; Wed, 3 Aug 2011 21:10:06 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c] (unknown [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D4FDCB68C0; Thu, 4 Aug 2011 14:10:10 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <20110804033606.19231126CE1C@drugs.dv.isc.org> Date: Thu, 4 Aug 2011 14:10:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 04:10:08 -0000 On 04/08/2011, at 1:36 PM, Mark Andrews wrote: >=20 > It all depends on when you think deployment of CGN/AFTR/NAT64 boxes > will happen. My feeling is you will see these boxes being widely > deployed within 3 years and ISP's scrambling to move IPv4 only > customers to IPv4 + IPv6 or IPv6 only to reduce the number of > CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code > shouldn't make the problem worse when this happens. Mark, consider both Apple, and Microsofts codebase 3 years ago, and the = frequency of updates. Lion has been out precisely <1month, and has had one update already. Vista gets regular self-applied updates.=20 You cannot seriously be saying that the consequential 'damage' to the v6 = message stems from this deployment, because it only applies to people = WHO GO ONLINE and if they go online with Apple they get FREE UPDATES. What am I missing? Do you think Apple owners stay on factory defaults? Really? -george= From marka@isc.org Wed Aug 3 21:38:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16EB11E80DE for ; Wed, 3 Aug 2011 21:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtKUW4Be+ynG for ; Wed, 3 Aug 2011 21:38:16 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DDBB411E80CD for ; Wed, 3 Aug 2011 21:38:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4A80F5F98A2; Thu, 4 Aug 2011 04:38:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 54A90216C7B; Thu, 4 Aug 2011 04:38:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id EE880126D30C; Thu, 4 Aug 2011 14:38:05 +1000 (EST) To: George Michaelson From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@a pnic.net> In-reply-to: Your message of "Thu, 04 Aug 2011 14:10:11 +1000." <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> Date: Thu, 04 Aug 2011 14:38:05 +1000 Message-Id: <20110804043805.EE880126D30C@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 04:38:16 -0000 In message <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net>, George Michaelson writes: > > On 04/08/2011, at 1:36 PM, Mark Andrews wrote: > > > > > It all depends on when you think deployment of CGN/AFTR/NAT64 boxes > > will happen. My feeling is you will see these boxes being widely > > deployed within 3 years and ISP's scrambling to move IPv4 only > > customers to IPv4 + IPv6 or IPv6 only to reduce the number of > > CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code > > shouldn't make the problem worse when this happens. > > Mark, consider both Apple, and Microsofts codebase 3 years ago, and the > frequency of updates. I'm also looking at what hasn't happened for those that don't make the jump to the next major os release. You get large numbers stuck at whatever feature set there is at the of the release. Neither of us know if this will be addressed in Lion before the next major release of Mac OS X or not, and there is a major release will it only be addressed in that and not Lion? > Lion has been out precisely <1month, and has had one update already. > > Vista gets regular self-applied updates. > > You cannot seriously be saying that the consequential 'damage' to the v6 > message stems from this deployment, because it only applies to people > WHO GO ONLINE and if they go online with Apple they get FREE UPDATES. > > What am I missing? Do you think Apple owners stay on factory defaults? > > Really? > > -george= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwcarder@wisc.edu Wed Aug 3 21:59:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FD911E80CD for ; Wed, 3 Aug 2011 21:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGM4ZKPuwy5v for ; Wed, 3 Aug 2011 21:59:38 -0700 (PDT) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by ietfa.amsl.com (Postfix) with ESMTP id F07D311E80A6 for ; Wed, 3 Aug 2011 21:59:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LPE005020JPJV00@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 03 Aug 2011 23:59:49 -0500 (CDT) Received: from [192.168.0.7] (66-188-112-13.dhcp.mdsn.wi.charter.com [66.188.112.13]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LPE00HKX0JN5F10@smtpauth1.wiscmail.wisc.edu>; Wed, 03 Aug 2011 23:59:48 -0500 (CDT) Date: Wed, 03 Aug 2011 23:59:47 -0500 From: "Dale W. Carder" In-reply-to: <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> To: George Michaelson Message-id: <37D3D1FF-8042-4DFB-85C1-AD6FE51C1F86@wisc.edu> X-Mailer: Apple Mail (2.1084) X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.4.45114, SenderIP=192.168.0.7 References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EFF6@apnic.net> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 04:59:38 -0000 On Aug 3, 2011, at 11:10 PM, George Michaelson wrote: > > On 04/08/2011, at 1:36 PM, Mark Andrews wrote: > >> >> It all depends on when you think deployment of CGN/AFTR/NAT64 boxes >> will happen. My feeling is you will see these boxes being widely >> deployed within 3 years and ISP's scrambling to move IPv4 only >> customers to IPv4 + IPv6 or IPv6 only to reduce the number of >> CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code >> shouldn't make the problem worse when this happens. > > > Mark, consider both Apple, and Microsofts codebase 3 years ago, and the frequency of updates. > > Lion has been out precisely <1month, and has had one update already. > > Vista gets regular self-applied updates. > > You cannot seriously be saying that the consequential 'damage' to the v6 message stems from this deployment, because it only applies to people WHO GO ONLINE and if they go online with Apple they get FREE UPDATES. > > What am I missing? What we've learned w/ 6to4: having an exit strategy ready for when we measure there is enough harm being done. I believe we need to be thinking about the exit strategy for LSN before it gets us stuck in a costly loop. Biasing v6 would be one approach. Economics for continued v4 service would be another, but inconsistent in applicability and outside of our scope. Dale From john_brzozowski@cable.comcast.com Wed Aug 3 22:24:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1ED11E80A6 for ; Wed, 3 Aug 2011 22:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.19 X-Spam-Level: X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=2.273, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH5PHfUYHjIs for ; Wed, 3 Aug 2011 22:24:40 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C377121F86DD for ; Wed, 3 Aug 2011 22:24:39 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136162472; Thu, 04 Aug 2011 01:24:50 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 01:24:50 -0400 From: "Brzozowski, John" To: "jari.arkko@piuha.net" , Nick Hilliard Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxO6HZ7YQ4f7+JsMUusl+Ald1vnPQBdTzLAAD+UcIAAIJHMgAACiH+AAACEU4AAHxUSAA== Date: Thu, 4 Aug 2011 05:24:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E53523C347A4D428F3EB16AE28F0244@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:24:40 -0000 ....and does not require a home user to be an actual engineer either? On 8/3/11 6:34 AM, "jari.arkko@piuha.net" wrote: >I have no skin in this game, but I am still from the school of thought >that it matters what code is easiest available, is already in peoples >devices, and is so simple that a home router sweat shop can get it right >without employing an actual engineer. From john_brzozowski@cable.comcast.com Wed Aug 3 22:28:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF3111E80E7 for ; Wed, 3 Aug 2011 22:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.281 X-Spam-Level: X-Spam-Status: No, score=-103.281 tagged_above=-999 required=5 tests=[AWL=-1.546, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSaIbeUZYsPB for ; Wed, 3 Aug 2011 22:28:15 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1361B11E80E6 for ; Wed, 3 Aug 2011 22:28:15 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47449338; Wed, 03 Aug 2011 23:31:33 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 01:26:31 -0400 From: "Brzozowski, John" To: Nick Hilliard , Philip Homburg Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMUciUYQ4f7+JsMUusl+Ald1vnPZULORsAgADxc4A= Date: Thu, 4 Aug 2011 05:26:29 +0000 Message-ID: In-Reply-To: <4E392ABA.2010702@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <75CC3DA239744D409B83419F79562667@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:28:15 -0000 The below is a good point, agree. On 8/3/11 7:02 AM, "Nick Hilliard" wrote: >Yes, you _can_ get boxes which do everything, like the Mikrotik boxes. >But >how many end-users are going to end up configuring mpls on their home >networks, or setting up iBGP on their multi-router installations? There >is >no need for this level of complexity. It will confuse for no good >purpose. >Remember, we are specifying something for Mom, Granddad and uncle Joe, to >be implemented by Belkin. We're not specifying something for Nick, Philip >and Sander, to be implemented by Cisco or Juniper. From john.mann@monash.edu Wed Aug 3 22:38:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC1611E80EC for ; Wed, 3 Aug 2011 22:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW4RmUbZC38W for ; Wed, 3 Aug 2011 22:38:07 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE5811E80F0 for ; Wed, 3 Aug 2011 22:38:06 -0700 (PDT) Received: from mail-qw0-f42.google.com ([209.85.216.42]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTjowRZ8JeB+OadRUUn76mIQXYprt5/yj@postini.com; Wed, 03 Aug 2011 22:38:21 PDT Received: by qwi4 with SMTP id 4so1381983qwi.1 for ; Wed, 03 Aug 2011 22:38:13 -0700 (PDT) Received: by 10.229.251.138 with SMTP id ms10mr263981qcb.71.1312436292178; Wed, 03 Aug 2011 22:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.202 with HTTP; Wed, 3 Aug 2011 22:37:52 -0700 (PDT) In-Reply-To: <20110804043805.EE880126D30C@drugs.dv.isc.org> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> <20110804043805.EE880126D30C@drugs.dv.isc.org> From: "John Mann (ITS)" Date: Thu, 4 Aug 2011 15:37:52 +1000 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=00163628524afc539204a9a76285 Cc: IPv6 Operations , George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:38:08 -0000 --00163628524afc539204a9a76285 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 4 August 2011 14:38, Mark Andrews wrote: > > In message <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net>, George > Michaelson > writes: > > > > On 04/08/2011, at 1:36 PM, Mark Andrews wrote: > > > > > > > > It all depends on when you think deployment of CGN/AFTR/NAT64 boxes > > > will happen. My feeling is you will see these boxes being widely > > > deployed within 3 years and ISP's scrambling to move IPv4 only > > > customers to IPv4 + IPv6 or IPv6 only to reduce the number of > > > CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code > > > shouldn't make the problem worse when this happens. > > > > Mark, consider both Apple, and Microsofts codebase 3 years ago, and the > > frequency of updates. > > I'm also looking at what hasn't happened for those that don't make > the jump to the next major os release. You get large numbers stuck > at whatever feature set there is at the of the release. > > Neither of us know if this will be addressed in Lion before the > next major release of Mac OS X or not, and there is a major release > will it only be addressed in that and not Lion? +1 Look at PowerPC Macs stuck on 10.4 / 10.5 that still trust rogue Windows boxes advertising 6to4 routes that don't work. See e.g. the brown and yellow lines on the Mac OS X version distribution graph on http://fud.no/ipv6/ -- still about 20% usage. And now single-core Intel Macs stuck on Snow Leopard that can't get even Lion's initial IPv6 changes. There *can* be a very long tailed distribution for old versions of software, even if software upgrades are free or cheap. Now, if Apple were to back-port IPv6 improvements into all previous releases ... ;-) ;-) --- In other news, Windows XP market share dips below 50 percent . Another long tail here. I don't know if WinXP will get RFC3484-bis updates. Or get a hypothetical IE update that implements Happy Eyeballs that could work-around underlying O/S behaviour ... John --00163628524afc539204a9a76285 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 4 August 2011 14:38, Mark Andrews = <marka@isc.org>= ; wrote:

In message <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net>, George Michae= lson
writes:
>
> On 04/08/2011, at 1:36 PM, Mark Andrews wrote:
>
> >
> > It all depends on when you think deployment of CGN/AFTR/NAT64 box= es
> > will happen. =A0My feeling is you will see these boxes being wide= ly
> > deployed within 3 years and ISP's scrambling to move IPv4 onl= y
> > customers to IPv4 + IPv6 or IPv6 only to reduce the number of
> > CGN/AFTR/NAT64 boxes they need to deploy. =A0Currently shipping c= ode
> > shouldn't make the problem worse when this happens.
>
> Mark, consider both Apple, and Microsofts codebase 3 years ago, and th= e
> frequency of updates.

I'm also looking at what hasn't happened for those that don&#= 39;t make
the jump to the next major os release. =A0You get large numbers stuck
at whatever feature set there is at the of the release.

Neither of us know if this will be addressed in Lion before the
next major release of Mac OS X or not, and there is a major release
will it only be addressed in that and not Lion?

=
+1

Look at PowerPC Macs stuck on 10.4 / 10.5 = that still trust rogue Windows boxes advertising 6to4 routes that don't= work. =A0See e.g. the brown and yellow lines on the Mac OS X version distribution=A0graph = on=A0http://fud.no/ipv6/=A0-- still abo= ut 20% usage.

And now single-core Intel Macs stuck on Snow Leopard th= at can't get even Lion's initial IPv6 changes.

=
There *can* be a very long tailed distribution for old versions of sof= tware, even if software upgrades are free or cheap.

Now, if Apple were to back-port IPv6 improvements into = all previous releases ... ;-) ;-)

---
Another long tail here. =A0I don't know if WinXP will get RFC3484-= bis updates.
Or get a hypothetical IE update that implements Happ= y Eyeballs that could work-around underlying O/S behaviour ...

=A0 =A0 John
--00163628524afc539204a9a76285-- From ggm+ietf@apnic.net Wed Aug 3 23:13:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77E621F8782 for ; Wed, 3 Aug 2011 23:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2ET3PBD8MP for ; Wed, 3 Aug 2011 23:13:49 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 36C7D21F8781 for ; Wed, 3 Aug 2011 23:13:49 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c] (unknown [IPv6:2001:dc0:a000:4:3821:c56f:2266:167c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DCD9AB67ED; Thu, 4 Aug 2011 02:14:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Michaelson In-Reply-To: Date: Thu, 4 Aug 2011 16:14:02 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@ap nic.net> <20110804043805.EE880126D30C@drugs.dv.isc.org> To: John Mann (ITS) X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:13:50 -0000 John, I could understand if this was a 6to4 deprecation issue. Its a v4/v6 PREFERENCE issue. So, for a long tail, some number (20% but I doubt it) of Lion instances = on the global net will continue to prefer V4 over V6. And if there is no V4 in that timeframe, while I am cashing in my lotto = cheque, I will care why? Because, in the absence of V4... guess what the = system will do ... Go on John.. guess 20% of the system will weight V6 below V4, if it detects an RTT = preference under a HE like algorithm favouring V4. What exactly is the 'fail' moment here? -G= From pch-b2B3A6689@u-1.phicoh.com Wed Aug 3 23:48:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBE121F8754 for ; Wed, 3 Aug 2011 23:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHSVD0AcUKZl for ; Wed, 3 Aug 2011 23:48:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B32A821F8753 for ; Wed, 3 Aug 2011 23:48:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QorjN-0001gzC; Thu, 4 Aug 2011 08:48:33 +0200 Message-Id: To: Lorenzo Colitti From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 3 Aug 2011 18:32:30 -0700 ." Date: Thu, 04 Aug 2011 08:48:15 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:48:32 -0000 In your letter dated Wed, 3 Aug 2011 18:32:30 -0700 you wrote: >I think that what you're saying is that ISPs want users to use IPv6. >But James is saying is that if ISPs wanted their users to use IPv6, they >would deploy IPv6. So I doubt that you will agree :-) It may actually be worse. If you look at the following article about RIPE measurements during ipv6day Then if all vendors would be like Apple, IPv6 would essentially be left unused. So this is telling ISPs: do not bother with IPv6 because our client side operating systems are no going to use it anyhow (unless you make IPv6 a couple of sigmas faster than IPv4). From john.mann@monash.edu Wed Aug 3 23:54:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3198B21F850E for ; Wed, 3 Aug 2011 23:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVh0fzNoZ107 for ; Wed, 3 Aug 2011 23:54:40 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E76D21F84F7 for ; Wed, 3 Aug 2011 23:54:40 -0700 (PDT) Received: from mail-qy0-f178.google.com ([209.85.216.178]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTjpCO3CvblBHI6x9XNIrAgFUQWz2CtV0@postini.com; Wed, 03 Aug 2011 23:54:54 PDT Received: by qyk30 with SMTP id 30so111201qyk.9 for ; Wed, 03 Aug 2011 23:54:51 -0700 (PDT) Received: by 10.229.114.139 with SMTP id e11mr272052qcq.261.1312440891097; Wed, 03 Aug 2011 23:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.202 with HTTP; Wed, 3 Aug 2011 23:54:30 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.isc.org> From: "John Mann (ITS)" Date: Thu, 4 Aug 2011 16:54:30 +1000 Message-ID: To: George Michaelson Content-Type: multipart/alternative; boundary=000e0cd6b2d21a429004a9a87542 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:54:41 -0000 --000e0cd6b2d21a429004a9a87542 Content-Type: text/plain; charset=ISO-8859-1 George, On 4 August 2011 16:14, George Michaelson wrote: > > John, I could understand if this was a 6to4 deprecation issue. > > Its a v4/v6 PREFERENCE issue. > > So, for a long tail, some number (20% but I doubt it) of Lion instances on > the global net will continue to prefer V4 over V6. > > And if there is no V4 in that timeframe, while I am cashing in my lotto > cheque, I will care why? Because, in the absence of V4... guess what the > system will do ... > > Go on John.. guess > > 20% of the system will weight V6 below V4, if it detects an RTT preference > under a HE like algorithm favouring V4. > > What exactly is the 'fail' moment here? > > -G I was trying to agree with Mark and comment just on your assertion that regular vendor updates will/can change the settings of previously released software. The vendor 'fail' moment is when they stop feature updates for older software, users can't upgrade (e.g. because of old hardware), and the sub-optimal behaviour gets frozen forever. [ I illustrated my point using the example of IPv6 code that isn't being updated on old Macs and old PCs. I wasn't trying to examine the merits or otherwise of that code. Sorry if you read too much into my message. ] John --000e0cd6b2d21a429004a9a87542 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable George,

On 4 August 2011 16:14, George Mi= chaelson <ggm+= ietf@apnic.net> wrote:

John, I could understand if this was a 6to4 deprecation issue.

Its a v4/v6 PREFERENCE issue.

So, for a long tail, some number (20% but I doubt it) of Lion instances on = the global net will continue to prefer V4 over V6.

And if there is no V4 in that timeframe, while I am cashing in my lotto che= que, I will care why? Because, in the absence of V4... guess what the syste= m will do ...

Go on John.. guess

20% of the system will weight V6 below V4, if it detects an RTT preference = under a HE like algorithm favouring V4.

What exactly is the 'fail' moment here?

-G

I was trying to agree with Mark and co= mment just on your assertion that regular=A0vendor updates will/can change = the settings of previously released software.

The = vendor 'fail' moment is when they stop feature updates for older so= ftware, users can't upgrade (e.g. because of old hardware), and the sub= -optimal behaviour gets frozen forever.

[ I illustrated my point using the example of IPv6 code= that isn't being updated on old Macs and old PCs. I wasn't trying = to examine the merits or otherwise of that code. Sorry if you read too much= into my message. ]

=A0 =A0 John
--000e0cd6b2d21a429004a9a87542-- From ggm+ietf@apnic.net Thu Aug 4 00:08:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29AB11E809C for ; Thu, 4 Aug 2011 00:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pJLzSqhfy0T for ; Thu, 4 Aug 2011 00:08:28 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id C17B411E8089 for ; Thu, 4 Aug 2011 00:08:27 -0700 (PDT) Received: from dynamic221.apnic.net (dynamic221.apnic.net [203.119.42.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 55DE1B689A; Thu, 4 Aug 2011 03:08:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Michaelson In-Reply-To: Date: Thu, 4 Aug 2011 17:08:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is c.org> To: John Mann (ITS) X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:08:37 -0000 On 04/08/2011, at 4:54 PM, John Mann (ITS) wrote: >=20 > I was trying to agree with Mark and comment just on your assertion = that regular vendor updates will/can change the settings of previously = released software. >=20 > The vendor 'fail' moment is when they stop feature updates for older = software, users can't upgrade (e.g. because of old hardware), and the = sub-optimal behaviour gets frozen forever. >=20 > [ I illustrated my point using the example of IPv6 code that isn't = being updated on old Macs and old PCs. I wasn't trying to examine the = merits or otherwise of that code. Sorry if you read too much into my = message. ] >=20 > John John I know my answer was a bit rough but, we can't always take = negatives on positive actions. Apple did a thing, and its a pragmatic = thing, and while I hate acting like fanboi, I think they did a good = thing. Marks position is basically wrong. This is not 6to4, there is no = inherent fail moment in this. this is not something which stops V6 = working at all. It de-preferences V6 in dual stack when the V4 is = demonstrably better. Yes, software fails to be updated in the field. I know this. I am not = naive.=20 But, of the choices in front of us, I think this pragmatic position is a = very good 'do least harm' place to be. I expect others to take other stances. If you want V6 to be better for = your users, de-tuning V4 to make it look better isn't where I think I = want to be, or you want to be. So don't do that. Reducing RTT in V6 to being within tolerance of V4 is actually doable. = Its pretty much what Internode has done, and while I posted a rough and = ready 'look: it prefers V4' thats not frozen in stone. When the V6 RTT = is better, I am willing to look at my Lion preferencing V6. I expect it = will. Good! I look forward to some V6 low latency paths from home, and = when I find them, I will say so. Meantime, on my Vista box, one node at home can't get to a really = important Anaphalaxis website which has put up a V6 AAAA and isn't = responding. Thats pretty close to a major, MAJOR V6 fail to me. An Anaphalaxis information site with a broken Dual-stack? You *bet* I want V4 to work better on that site. -G= From pch-b2B3A6689@u-1.phicoh.com Thu Aug 4 00:26:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63121F8B58 for ; Thu, 4 Aug 2011 00:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.492 X-Spam-Level: X-Spam-Status: No, score=-4.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6FRm4KEVts0 for ; Thu, 4 Aug 2011 00:26:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D7C9D21F8A62 for ; Thu, 4 Aug 2011 00:26:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QosKS-0001jYC; Thu, 4 Aug 2011 09:26:52 +0200 Message-Id: To: George Michaelson From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is c.org> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> In-reply-to: Your message of "Thu, 4 Aug 2011 17:08:40 +1000 ." <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> Date: Thu, 04 Aug 2011 09:26:44 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:26:47 -0000 In your letter dated Thu, 4 Aug 2011 17:08:40 +1000 you wrote: >I expect others to take other stances. If you want V6 to be better for your us >ers, de-tuning V4 to make it look better isn't where I think I want to be, or >you want to be. So don't do that. > >Reducing RTT in V6 to being within tolerance of V4 is actually doable. Its pre >tty much what Internode has done, and while I posted a rough and ready 'look: >it prefers V4' thats not frozen in stone. When the V6 RTT is better, I am will >ing to look at my Lion preferencing V6. I expect it will. Good! I look forward > to some V6 low latency paths from home, and when I find them, I will say so. Without bias, when IPv6 and IPv4 are equal, you can expect half of the connections to go to IPv4. It is only when you make IPv6 better then IPv4 by a couple of sigmas that most of the traffic will go to IPv6. Given that you can't really make IPv6 faster than IPv4, because IPv4 is already as fast as it gets, to only opion left is... To make IPv4 slower than IPv6. (Or just don't bother with IPv6 all together and let the customers pay for CGN). From phdgang@gmail.com Thu Aug 4 00:56:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6273421F8B66 for ; Thu, 4 Aug 2011 00:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKJypHn1Wwl0 for ; Thu, 4 Aug 2011 00:56:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC921F86AC for ; Thu, 4 Aug 2011 00:56:13 -0700 (PDT) Received: by vws12 with SMTP id 12so352145vws.31 for ; Thu, 04 Aug 2011 00:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aQDMAMNCA5iVBc1zwpVEJlcNHjM4Kz+sbFnWfZQJj8k=; b=GWf0EEbTKTRJ/YOO4O8TveVwR7HJDG3sQkX7rfdkt3XN5RccE5da8R3/5vQVh+BJo/ axRIPgTnEGSGymiQfriQx7H3g/XGFKl2wAKc2OjB9/P5zm52bT37ps9GJ4s2ERbdJBgy 1PGqsCiUNsDT4B7zTqBzvYH+aFYW+iuOY/sWA= MIME-Version: 1.0 Received: by 10.52.182.164 with SMTP id ef4mr579747vdc.319.1312444587663; Thu, 04 Aug 2011 00:56:27 -0700 (PDT) Received: by 10.52.165.37 with HTTP; Thu, 4 Aug 2011 00:56:27 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0BEECA65@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB0BEECA65@PRVPEXVS04.corp.twcable.com> Date: Thu, 4 Aug 2011 15:56:27 +0800 Message-ID: From: GangChen To: "George, Wesley" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] comments on draft-chen-v6ops-ipv6-bearer-network-trials X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:56:15 -0000 Hello George, 2011/7/29, George, Wesley : > I'd recommend the MTU consideration be phrased in terms of the fact that the > transport network should be designed to handle standard MTU (1500byte > payload) plus any encaps overhead, rather than the end-user payload being > reduced to meet a low MTU in the core. > A review of 4459 may provide some text of use. Yes. Current practices is in alignment with this recommendation. We will update the draft with such clarification. > > Regarding the testing results - it would be helpful to classify which items > failed testing because of a known lack of vendor support vs items which > failed due to bugs or claimed vendor support that was incomplete or missing. > Naming and shaming is sometimes a good way to ensure that vendors pay closer > attention before claiming support for something, or warning others to be > aware of the problem. The goals here is to help community understand there are some problems we still need to take care about. The gaps between the standard and reality may better to be filled by gathering strength from the communities ;) > > Also, this is interesting as a snapshot of your network, but the draft would > be more useful (and therefore more likely to be adopted as a WG draft) if it > identifies problems that the IETF (this WG or others) can help to solve, > gaps, broken things, BCP recommendations, etc. As mentioned during the meeting, we would filter the problems which could be solved in a specific WG. your comments are appreciated. Many thanks BRs Gang From dougb@dougbarton.us Thu Aug 4 01:14:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C321F8B54 for ; Thu, 4 Aug 2011 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWpj4SpLVG6F for ; Thu, 4 Aug 2011 01:14:55 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D699521F8B50 for ; Thu, 4 Aug 2011 01:14:54 -0700 (PDT) Received: (qmail 2699 invoked by uid 399); 4 Aug 2011 08:15:07 -0000 Received: from unknown (HELO 12-207-105-211.globalsuite.net) (dougb@dougbarton.us@12.207.105.211) by mail2.fluidhosting.com with ESMTPAM; 4 Aug 2011 08:15:07 -0000 X-Originating-IP: 12.207.105.211 X-Sender: dougb@dougbarton.us Message-ID: <4E3A5509.8090205@dougbarton.us> Date: Thu, 04 Aug 2011 01:15:05 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Philip Homburg References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is c.org> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:14:55 -0000 On 08/04/2011 00:26, Philip Homburg wrote: > Without bias, when IPv6 and IPv4 are equal, you can expect half of the > connections to go to IPv4. That's a feature. Apple is under no obligation to promote IPv6 adoption. Contrariwise, they ARE under a fiduciary obligation to produce an OS that people will want to buy. At the point sometime in the future when IPv6 routinely IS better than IPv4, the whole line of discussion will be moot so why not get ahead of the rush? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From pch-b2B3A6689@u-1.phicoh.com Thu Aug 4 01:25:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4169821F8B9B for ; Thu, 4 Aug 2011 01:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.139 X-Spam-Level: X-Spam-Status: No, score=-8.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLdtG4WV8avl for ; Thu, 4 Aug 2011 01:25:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAAB21F8B92 for ; Thu, 4 Aug 2011 01:25:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QotFS-0001iiC; Thu, 4 Aug 2011 10:25:46 +0200 Message-Id: To: Doug Barton From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is c.org> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4 E3A5509.8090205@dougbarton.us> In-reply-to: Your message of "Thu, 04 Aug 2011 01:15:05 -0700 ." <4E3A5509.8090205@dougbarton.us> Date: Thu, 04 Aug 2011 10:25:43 +0200 Cc: IPv6 Operations , George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:25:42 -0000 In your letter dated Thu, 04 Aug 2011 01:15:05 -0700 you wrote: >On 08/04/2011 00:26, Philip Homburg wrote: >> Without bias, when IPv6 and IPv4 are equal, you can expect half of the >> connections to go to IPv4. > >That's a feature. > >Apple is under no obligation to promote IPv6 adoption. Contrariwise, >they ARE under a fiduciary obligation to produce an OS that people will >want to buy. > >At the point sometime in the future when IPv6 routinely IS better than >IPv4, the whole line of discussion will be moot so why not get ahead of >the rush? The only way to make IPv6 better than IPv4 is to make IPv4 worse. You can't just change the laws of physics and make IPv6 packets travel faster than the speed of light. So whereas a bias in Apples software will statistically have no negative effect on systems with equally good IPv4 and IPv6 performance, having ISPs or content providers add a delay for IPv4 will have a negative effect on every IPv4-only system. It is so nice that Apple considers sending 50% of their users traffic through a CGN as in the interest of their users. I'm glad I'm not one of their customers. From ggm+ietf@apnic.net Thu Aug 4 01:44:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C866D21F8BBC for ; Thu, 4 Aug 2011 01:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.423 X-Spam-Level: X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny9GMIDepYdf for ; Thu, 4 Aug 2011 01:44:04 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4221F8BBA for ; Thu, 4 Aug 2011 01:44:03 -0700 (PDT) Received: from [192.168.1.3] (ppp118-208-71-71.lns20.bne4.internode.on.net [118.208.71.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B686DB6840 for ; Thu, 4 Aug 2011 04:44:16 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: George Michaelson In-Reply-To: <4E3A4994.4060606@globis.net> Date: Thu, 4 Aug 2011 18:44:15 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> References: <4E3A4994.4060606@globis.net> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:44:04 -0000 In the spirit of full disclosure, I re-ran the tests. I also added www.arin.net and some other nodes, including = www.afrinic.net. The new state of play, is that the three sites I tried 2 days ago now = work on IPv6, and ARIN worked on IPv6 for about 6 reloads, and now = preferences IPv4, and AfriNIC persists on preferring IPv6. Secondly, I tested in two browsers. The state acquired from one Browser = (chrome) appeared to me, to be carried into the other browser (Safari) = So, to the extent this system is implemented 'below' the application IT WORKED. Now, James, or anyone else is more than welcome to pull the rug from = under me, And I won't complain. Maybe its all a big hoax. More fool me. But right now: =09 1) its adaptive: just because yesterday it preferred V4 doesn't mean it = prefers V4 today 2) its consistent: once it has a local preference in the = kernel/userspace model, it appears to apply it properly across = applications 3) its behaviour preferences the user experience over the network = architect goals. So, with no desire to be rancorous, or upset people, I just want to say I DONT SEE WHAT THE PROBLEM IS HERE. As far as I am concerned, Apple have done a good thing (tm) and, it does = what they say it does (tm) and I am happy. End. As Randy says "I wish my competitors would do something which drives = traffic to me" and, in that respect, I am very sorry but Apple aren't = playing. This is not a move which will force randys competitors = customers to prefer Randy. If you want IPv6 to take off, you have to do it so its INFRASTRUCTURE = (which is what Internode has done) and you have to make its = RTT/Bandwidth-delay follow IPv4 within some sigma of difference (which = is what Internode has done) and if you do this, then Apple's code = logically can decide that IPv6 is better, and use it. It works guys. Can we move on now? -George= From dr@cluenet.de Thu Aug 4 02:20:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A5521F8B56 for ; Thu, 4 Aug 2011 02:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+W-Of1KwDFR for ; Thu, 4 Aug 2011 02:20:21 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6B21F8B7A for ; Thu, 4 Aug 2011 02:20:20 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 41FEA108095; Thu, 4 Aug 2011 11:20:31 +0200 (CEST) Date: Thu, 4 Aug 2011 11:20:31 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110804092031.GA26186@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 09:20:22 -0000 On Thu, Aug 04, 2011 at 06:44:15PM +1000, George Michaelson wrote: > If you want IPv6 to take off, you have to do it so its INFRASTRUCTURE > (which is what Internode has done) and you have to make its > RTT/Bandwidth-delay follow IPv4 within some sigma of difference > (which is what Internode has done) and if you do this, then Apple's > code logically can decide that IPv6 is better, and use it. To reliably prefer IPv6, the IPv6 infrastructure has to have BETTER RTT than IPv4. At least as far as I understand the reports and Apple's comments/description as there is no headstart for IPv6. Assuming the IPv4 topology is "as good as it gets" (within the commercial bounds given), it's "hard" to be better in IPv6, ack? So, you have to intentionally make IPv4 worse than it could be to bias in favor of IPv6. Just because you ran some samples which today preferred IPv6 by luck, doesn't mean the equation resolves to that on grand scale. Unless I'm missing something. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Aug 4 02:30:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C3A21F8B6A for ; Thu, 4 Aug 2011 02:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH6riqzLbAJM for ; Thu, 4 Aug 2011 02:30:01 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 913B321F8B5E for ; Thu, 4 Aug 2011 02:30:00 -0700 (PDT) Received: from 114-30-119-17.ip.adam.com.au ([114.30.119.17] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QouFg-0005C0-Cf; Thu, 04 Aug 2011 19:00:04 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 3B7AC3B355; Thu, 4 Aug 2011 19:00:03 +0930 (CST) Date: Thu, 4 Aug 2011 19:00:02 +0930 From: Mark Smith To: "Brzozowski, John" Message-ID: <20110804190002.16fad9bd@opy.nosense.org> In-Reply-To: References: <4E392ABA.2010702@inex.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 09:30:01 -0000 On Thu, 4 Aug 2011 05:26:29 +0000 "Brzozowski, John" wrote: > The below is a good point, agree. > So it would seem the assertion from those apposed to OSPF is that Mom, Granddad and uncle Joe are competent at configuring, operating and troubleshooting IPv4/RIPv2 and IPv6/RIPng, but will not be capable of learning how to configure, operate or troubleshoot OSPFv3 (and v2)? I'm confident that the reality is that Mom, Granddad and uncle Joe aren't and won't be competent at any of things things, won't care about them and more importantly shouldn't have to care about them. The decision as to what type of technology goes into the "Internet box" the customer uses should only be our concern, not theirs. It should just work and be robust against common failure modes. If OSPF can be made to autoconfigure itself (i.e. discover and establish adjacencies with neighbors, trade databases etc.) as easily as RIP can, which it can very easily, be just as robust as RIP is, which it certainly is, and it provides useful and worthwhile benefits over RIP (quicker reconvergence, carry other information, has better metric ranges, etc. etc.), then it should be used. > > On 8/3/11 7:02 AM, "Nick Hilliard" wrote: > > >Yes, you _can_ get boxes which do everything, like the Mikrotik boxes. > >But > >how many end-users are going to end up configuring mpls on their home > >networks, or setting up iBGP on their multi-router installations? There > >is > >no need for this level of complexity. It will confuse for no good > >purpose. > >Remember, we are specifying something for Mom, Granddad and uncle Joe, to > >be implemented by Belkin. We're not specifying something for Nick, Philip > >and Sander, to be implemented by Cisco or Juniper. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ari.keranen@nomadiclab.com Thu Aug 4 02:33:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F421F8AF9 for ; Thu, 4 Aug 2011 02:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3VCY0qgkmvn for ; Thu, 4 Aug 2011 02:33:35 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id B85CC21F8B5F for ; Thu, 4 Aug 2011 02:33:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 659B14E6DE; Thu, 4 Aug 2011 12:33:45 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYkIw2E0NvdL; Thu, 4 Aug 2011 12:33:43 +0300 (EEST) Received: from EV000C295089FF.lmf.ericsson.se (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 5578C4E6D3; Thu, 4 Aug 2011 12:33:43 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net> Date: Thu, 4 Aug 2011 12:33:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> <032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 09:33:35 -0000 Hi Tom, On Aug 2, 2011, at 2:07 PM, t.petch wrote: > In the hope that you will take up Fred's generous offer to push this = through to > an RFC, I hope that you will find these comments helpful Thanks for the feedback! As Jari already mentioned, we haven't fixed our = plans regarding how and if these results should be published, but if = there is interest in the WG, v6ops RFC is indeed one good option. > I would like to see more references, for 6to4 and for the various = .pdf; I think > it works better to have them all in one place. By .pdf do you mean the graph PDFs, other presentations something else?=20= > I find the X-axis of the graphs unclear; time presumably, but what = time? It's the sequence number of the measurement run; so something like "time = in 3 hour steps since the start of the tests". Probably hours (or even = time and date) would work better here. > I think that the biggest conclusion is omitted; only 2.45% of the top = 10,000 > sites offer IPv6 via DNS ie next to none; I think that this should be = in BIG > BOLD LETTERS. True, but that was not news to anyone :) > And while comprehension is no problem, the idiom is sometimes slightly = odd. > Doubtless the RFC Editor will fix it but I could point some of these = out to you > if you want. That'd be helpful; please send me a mail with those off-list. Cheers, Ari P.S. I'll be out of office for a couple of weeks, so it may take a while = before I have a chance to follow up on this > Tom Petch >=20 > ----- Original Message ----- > From: "Fred Baker" > To: "t.petch" > Cc: "IPv6 Operations" > Sent: Monday, August 01, 2011 6:49 PM > On Aug 1, 2011, at 3:23 AM, t.petch wrote: >=20 >> ----- Original Message ----- >> From: "Fred Baker" >> To: "IPv6 Operations" >> Sent: Saturday, July 30, 2011 11:37 PM >>=20 >>> Pursuant to our discussion Tuesday, I'd be interested in working = group > comment >> on >>> http://tools.ietf.org/html/draft-keranen-ipv6day-measurements >>> "Some Measurements on World IPv6 Day from End-User Perspective", Ari >>> Keranen, Jari Arkko, 11-Jul-11 >>>=20 >>> I could imagine not publishing as RFC (it has already served its = purpose), >> sending to the IESG as an individual submission for informational = status, or >> adopting as a working group item and eventually sending as that to = the IESG > for >> informational status. Up to you guys... >>=20 >> I find that bizarre. Of course it should be published as an RFC = (with a few >> tweaks for grammar, ease of use and comprehension). I cannot imagine = how it > has >> done its job; its job is to provide us with a point of reference in = the > current >> and future discussions about IPv6, where and how much of it there is, = etc. and >> that can only be done as an RFC (or, less good, as its equivalent in = some > other >> body). >=20 > Well, yes, but we had several other presentations whose only record is = in the > proceedings. OK, I take your comment and Keith's as support for = sending it in as > an individual submission. >=20 >> Tom Petch >>>=20 >>> What would you like to do? >>> - do you want to adopt it? >>> - separate question, do you want to publish it? >>> - if you want to publish it, do you have any comments? >=20 From ggm+ietf@apnic.net Thu Aug 4 03:03:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A30121F8B58 for ; Thu, 4 Aug 2011 03:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZqx3qKoDAFg for ; Thu, 4 Aug 2011 03:03:05 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 17A5D21F85BB for ; Thu, 4 Aug 2011 03:03:02 -0700 (PDT) Received: from [192.168.1.3] (ppp118-208-71-71.lns20.bne4.internode.on.net [118.208.71.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 58A6BB6840; Thu, 4 Aug 2011 06:03:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <20110804092031.GA26186@srv03.cluenet.de> Date: Thu, 4 Aug 2011 20:03:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1244.3) Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:03:05 -0000 On 04/08/2011, at 7:20 PM, Daniel Roesen wrote: > On Thu, Aug 04, 2011 at 06:44:15PM +1000, George Michaelson wrote: >> If you want IPv6 to take off, you have to do it so its INFRASTRUCTURE >> (which is what Internode has done) and you have to make its >> RTT/Bandwidth-delay follow IPv4 within some sigma of difference >> (which is what Internode has done) and if you do this, then Apple's >> code logically can decide that IPv6 is better, and use it. >=20 > To reliably prefer IPv6, the IPv6 infrastructure has to have BETTER = RTT > than IPv4. At least as far as I understand the reports and Apple's > comments/description as there is no headstart for IPv6. I am probably talking past you, and several other people. I don't think its my mission in life to "reliably prefer IPv6". Do you think this is a rational position to take, right now? Reliably?=20= >=20 > Assuming the IPv4 topology is "as good as it gets" (within the > commercial bounds given), it's "hard" to be better in IPv6, ack? > So, you have to intentionally make IPv4 worse than it could be to bias > in favor of IPv6. I have no intention of asking anyone to make IPv4 worse. That is silly. = I said so, 3 posts ago. I believe that coding systems to explore 4 and 6, and based on = hysteresis, some heuristics, measurements and held state in a kernel or = routing table or some other construct, decide a preference case-by-case = is fine. And, if it varies, thats fine too. > Just because you ran some samples which today preferred IPv6 by luck, > doesn't mean the equation resolves to that on grand scale. Just because I relay anecdotes, doesn't mean I believe they are = statistics. I have explored what *I* experience, as a user, @home on a true (native) = IPv6 ADSL2+ service which is dual-homed. I have explored what I experience, in OSX Lion and before that in Snow = Leopard. As a user, V4/V6 Agnostic: I think the Lion state is better. >=20 > Unless I'm missing something. Like I say. I think I'm probably talking past some people. Maybe its time to Ask Fred. Fred: with your WG chair hat on. Is it actually held, by V6OPS to be a = FAIL if you find a system logically prefers IPv4 to IPv6? I think thats = a bit silly, but maybe thats the ethos of the group. In Dual_Stack, = isn't that actually a rational choice? I figure a bunch of people might find that very very surprising. -G >=20 > Regards, > Daniel >=20 > --=20 > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Thu Aug 4 03:10:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D768421F8B79 for ; Thu, 4 Aug 2011 03:10:55 -0700 (PDT) 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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vMlRY42oHo for ; Thu, 4 Aug 2011 03:10:55 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4481321F8B77 for ; Thu, 4 Aug 2011 03:10:52 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 98DB2F85EA for ; Thu, 4 Aug 2011 12:11:05 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7AEDBF85E0 for ; Thu, 4 Aug 2011 12:11:05 +0200 (CEST) Received: (qmail 89238 invoked by uid 1007); 4 Aug 2011 12:11:05 +0200 Date: Thu, 4 Aug 2011 12:11:05 +0200 From: Gert Doering To: George Michaelson Message-ID: <20110804101105.GG72014@Space.Net> References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> 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.21 (2010-09-15) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:10:56 -0000 Hi, On Thu, Aug 04, 2011 at 08:03:14PM +1000, George Michaelson wrote: > Fred: with your WG chair hat on. Is it actually held, by V6OPS > to be a FAIL if you find a system logically prefers IPv4 to IPv6? > I think thats a bit silly, but maybe thats the ethos of the group. > In Dual_Stack, isn't that actually a rational choice? > > I figure a bunch of people might find that very very surprising. If we assume IPv4 is here to stay, then "take whatever works better" is the right thing. If we assume IPv4 is coming with extra costs, and more interesting failure modes, etc. (due to LSN/CGN, v4-over-v6 tunneling, ...), I'd like to see a (small) bias towards IPv6. HE with some 10-30ms initial delay for v4, or so. It's not "just user experience today", it's also "moving the majority of the network traffic towards v6" that should the goal, so that we can turn off IPv4 eventually. Which will only be done if most of the traffic has moved - which will not happen if clients will continue to use it if it's "as fast as IPv6". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? 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 dr@cluenet.de Thu Aug 4 03:13:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32921F8B10 for ; Thu, 4 Aug 2011 03:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj5f4df5Z1GU for ; Thu, 4 Aug 2011 03:13:55 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 979DA21F8B13 for ; Thu, 4 Aug 2011 03:13:54 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id BDDE7108081; Thu, 4 Aug 2011 12:14:06 +0200 (CEST) Date: Thu, 4 Aug 2011 12:14:06 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110804101406.GA5008@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:13:55 -0000 On Thu, Aug 04, 2011 at 08:03:14PM +1000, George Michaelson wrote: > I don't think its my mission in life to "reliably prefer IPv6". > > Do you think this is a rational position to take, right now? Reliably? If there is no good reason (read: noticable[!] performance gain) to use IPv4, yes. > > Assuming the IPv4 topology is "as good as it gets" (within the > > commercial bounds given), it's "hard" to be better in IPv6, ack? > > So, you have to intentionally make IPv4 worse than it could be to bias > > in favor of IPv6. > > I have no intention of asking anyone to make IPv4 worse. That is silly. You don't, but effectively operators will do so as there is significant economic advantage to do if endpoints don't prefer IPv6 where reasonably possible. So when you say that it's OK to have traffic go via IPv4 where IPv6 could be used instead with reasonable quality, you also accept the fact of senseless cost to operators (and thus in the end, for end users). To mitigate that, operators are forced to actively intervene. > And, if it varies, thats fine too. No it's not, in the big picture. Technically it is (ignoring the NAT for IPv4 vs non-NAT in IPv6), but economically it's not. > Just because I relay anecdotes, doesn't mean I believe they are statistics. OK. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From pch-b29AA871B@u-1.phicoh.com Thu Aug 4 03:17:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893AF21F84F4 for ; Thu, 4 Aug 2011 03:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.216 X-Spam-Level: X-Spam-Status: No, score=-8.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYGbUtZ32y1C for ; Thu, 4 Aug 2011 03:17:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A9E5921F84F2 for ; Thu, 4 Aug 2011 03:17:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qouzw-0001isC; Thu, 4 Aug 2011 12:17:52 +0200 Message-Id: To: George Michaelson From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> In-reply-to: Your message of "Thu, 4 Aug 2011 20:03:14 +1000 ." Date: Thu, 04 Aug 2011 12:17:31 +0200 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:19:19 -0000 In your letter dated Thu, 4 Aug 2011 20:03:14 +1000 you wrote: >I am probably talking past you, and several other people. > >I don't think its my mission in life to "reliably prefer IPv6". > >Do you think this is a rational position to take, right now? Reliably? Well, if you want to put it that way, I think it is my mission in life to reliably avoid anything that includes NAT. End-to-end IPv4, great. No reason to prefer IPv6 at all. You can't really tell whether the far end has full IPv4, but just prefering IPv6 when the local IPv4 address is not global will probably already help a lot. From sander@steffann.nl Thu Aug 4 03:27:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A341D21F8B3C for ; Thu, 4 Aug 2011 03:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceOKe+8ktxHd for ; Thu, 4 Aug 2011 03:27:18 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id E3F9621F8ABD for ; Thu, 4 Aug 2011 03:27:17 -0700 (PDT) Received: from macpro.10ww.steffann.nl (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 5B431202A; Thu, 4 Aug 2011 12:22:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Sander Steffann In-Reply-To: <20110804101406.GA5008@srv03.cluenet.de> Date: Thu, 4 Aug 2011 12:22:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> <20110804101406.GA5008@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1244.3) Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:27:18 -0000 Hi, >> I don't think its my mission in life to "reliably prefer IPv6". >>=20 >> Do you think this is a rational position to take, right now? = Reliably?=20 >=20 > If there is no good reason (read: noticable[!] performance gain) to = use > IPv4, yes. So maybe we should be talking about percentages instead of '30 ms' or = some other fixed number. Something like 'If IPv4 is =E2=89=A510% faster = than IPv6 it's ok to prefer IPv4'. =46rom a user's point of view I agree = with what Apple is doing. =46rom a long-term migration point of view = (taking CGN costs into account etc) I agree that preferring IPv6 is = important. So maybe we can find a middle ground here? Sincerely, Sander Steffann From moore@network-heretics.com Thu Aug 4 04:43:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF6A21F8B26 for ; Thu, 4 Aug 2011 04:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqqMcmaV4cOL for ; Thu, 4 Aug 2011 04:43:16 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C684621F8B24 for ; Thu, 4 Aug 2011 04:43:16 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QowKg-00056p-P8; Thu, 04 Aug 2011 07:43:23 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <37D3D1FF-8042-4DFB-85C1-AD6FE51C1F86@wisc.edu> Date: Thu, 4 Aug 2011 07:43:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <21F5EE2F-6E81-4E60-8C08-0B6A2A5ADEAE@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EFF6@a pnic.net> <37D3D1FF-8042-4DFB-85C1-AD6FE51C1F86@wisc.edu> To: Dale W. Carder X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940d7a7a25f83d19acc530517c5fb336b76350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations , George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:43:17 -0000 On Aug 4, 2011, at 12:59 AM, Dale W. Carder wrote: > What we've learned w/ 6to4: having an exit strategy ready for when we=20= > measure there is enough harm being done. =20 >=20 > I believe we need to be thinking about the exit strategy for LSN = before=20 > it gets us stuck in a costly loop. Biasing v6 would be one approach. > Economics for continued v4 service would be another, but inconsistent > in applicability and outside of our scope. =20 I'm a big fan of exit strategies. I've often wished that v4 NAT had = been designed with an exit strategy. Note however that a global 'kill switch' is probably not a good exit = strategy. =20 Keith From dr@cluenet.de Thu Aug 4 04:45:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8621F8B47 for ; Thu, 4 Aug 2011 04:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR9-8gCZwNC9 for ; Thu, 4 Aug 2011 04:45:00 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3E25221F8B09 for ; Thu, 4 Aug 2011 04:45:00 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 4E80A10808D; Thu, 4 Aug 2011 13:45:14 +0200 (CEST) Date: Thu, 4 Aug 2011 13:45:14 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110804114514.GB5008@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:45:01 -0000 On Thu, Aug 04, 2011 at 12:39:56PM +1200, Michael Newbery wrote: > However, I see no reason to make the browser's job any harder. If > latency is to be deliberately introduced, then it needs to be done > because there is a greater benefit to the user than by not > introducing it. - less brokeness - less cost - easier troubleshooting due to better predictability/reproducibility. How does that sound to you as an end user - compelling reasons enough? :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Thu Aug 4 04:52:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DEA21F8A96 for ; Thu, 4 Aug 2011 04:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eclYXazfOm4p for ; Thu, 4 Aug 2011 04:52:43 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id D294821F8ACE for ; Thu, 4 Aug 2011 04:52:43 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QowTv-0000n3-ME; Thu, 04 Aug 2011 07:52:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> Date: Thu, 4 Aug 2011 07:52:54 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4375B5AB-9163-45CC-94AF-2B340FC65DC1@network-heretics.com> References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94081fa94f4dce2185e9081301ef53cbc54350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:52:44 -0000 On Aug 4, 2011, at 4:44 AM, George Michaelson wrote: > I DONT SEE WHAT THE PROBLEM IS HERE. +1 From moore@network-heretics.com Thu Aug 4 04:55:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B2A21F8B50 for ; Thu, 4 Aug 2011 04:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viZv-jqCYVI0 for ; Thu, 4 Aug 2011 04:55:22 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1B321F8B49 for ; Thu, 4 Aug 2011 04:55:21 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QowWT-0006x2-GQ; Thu, 04 Aug 2011 07:55:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--855717685 From: Keith Moore In-Reply-To: Date: Thu, 4 Aug 2011 07:55:31 -0400 Message-Id: <9DA6E586-8B1E-4F17-BFC9-491EDC3E07C0@network-heretics.com> References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940003903e9eb76de33670ec09d1ef79ce1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: Daniel Roesen , v6ops@ietf.org, George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:55:23 -0000 --Apple-Mail-1--855717685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 4, 2011, at 6:17 AM, Philip Homburg wrote: > In your letter dated Thu, 4 Aug 2011 20:03:14 +1000 you wrote: >> I am probably talking past you, and several other people. >>=20 >> I don't think its my mission in life to "reliably prefer IPv6". >>=20 >> Do you think this is a rational position to take, right now? = Reliably?=20 >=20 > Well, if you want to put it that way, I think it is my mission in life = to > reliably avoid anything that includes NAT. >=20 > End-to-end IPv4, great. No reason to prefer IPv6 at all. >=20 > You can't really tell whether the far end has full IPv4, but just > prefering IPv6 when the local IPv4 address is not global will probably > already help a lot. +1. provided, of course, that there's a reliable way to determine if you're = behind an LSN that doesn't happen to assign RFC 1918 addresses. Keith --Apple-Mail-1--855717685 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In your letter dated Thu, 4 Aug 2011 20:03:14 +1000 = you wrote:
I am probably talking past you, = and several other people.

I don't think = its my mission in life to "reliably prefer = IPv6".

Do you think = this is a rational position to take, right now? Reliably? =

Well, if you want to put it that way, I think it is = my mission in life to
reliably avoid anything that includes = NAT.

End-to-end IPv4, great. No reason to prefer IPv6 at = all.

You can't really tell whether the far end has full IPv4, but = just
prefering IPv6 when the local IPv4 address is not global will = probably
already help a lot.

+1.<= /div>

provided, of course, that there's a reliable = way to determine if you're behind an LSN that doesn't happen to assign = RFC 1918 = addresses.

Keith

= --Apple-Mail-1--855717685-- From dr@cluenet.de Thu Aug 4 04:55:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F2921F8BAD for ; Thu, 4 Aug 2011 04:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQpc-ABVBDvL for ; Thu, 4 Aug 2011 04:55:28 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 37AAC21F8BB8 for ; Thu, 4 Aug 2011 04:55:28 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 4EAC410808D; Thu, 4 Aug 2011 13:55:42 +0200 (CEST) Date: Thu, 4 Aug 2011 13:55:42 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110804115542.GC5008@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:55:29 -0000 On Thu, Aug 04, 2011 at 02:10:11PM +1000, George Michaelson wrote: > Lion has been out precisely <1month, and has had one update already. http://fud.no/ipv6/gnuplot/osxversions.png 25% of the user base observed by Tore are not even on 10.6. > You cannot seriously be saying that the consequential 'damage' > to the v6 message stems from this deployment, because it only > applies to people WHO GO ONLINE and if they go online with > Apple they get FREE UPDATES. No they don't - at least not always, as far as I'm told. People have to pay for 10.7. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From robert.cragie@gmail.com Wed Aug 3 21:03:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988B721F86C4; Wed, 3 Aug 2011 21:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4TGITNStkbW; Wed, 3 Aug 2011 21:03:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 287E221F86C3; Wed, 3 Aug 2011 21:03:23 -0700 (PDT) Received: by vxi40 with SMTP id 40so1423439vxi.31 for ; Wed, 03 Aug 2011 21:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PnR236v1kyhBD9XotJhMTNeqMwLeG5bV6JWROvOR5Nc=; b=wfoRPa7/2fyUdqd5vgwE4bErDeY5HEyMLs4qoXUNZ+9jn5awgikKQtpN1el3n0+9Sk zZ87JW6mdMsfGn0TNqM2wNJiIDr1evRHg1URkMc7qvx0wQZkGR9GFALNIN+DvNMK62wA 0pY0Tlo7iFmSi7dpCOXrLeAe46nq4FFjppE/Y= MIME-Version: 1.0 Received: by 10.220.192.76 with SMTP id dp12mr73071vcb.212.1312430616483; Wed, 03 Aug 2011 21:03:36 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.6.15 with HTTP; Wed, 3 Aug 2011 21:03:36 -0700 (PDT) In-Reply-To: <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> Date: Thu, 4 Aug 2011 05:03:36 +0100 X-Google-Sender-Auth: -uumSqRKWIkGrNVx7nzUArzudMA Message-ID: From: Robert Cragie To: Joel Jaeggli Content-Type: multipart/alternative; boundary=90e6ba4fbd5ab018af04a9a61074 X-Mailman-Approved-At: Thu, 04 Aug 2011 08:55:56 -0700 Cc: v6ops@ietf.org, homenet@ietf.org Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 04:03:24 -0000 --90e6ba4fbd5ab018af04a9a61074 Content-Type: text/plain; charset=ISO-8859-1 +1 L2 bridging is OK if you can do it but not everything looks like Ethernet frames. Not only that but if we have multi-link subnets using route-over, the router to host ratio goes up considerably. The problem space is then multi-link subnets then multi-subnet site/zone/homenets. L3 routing is the only way this is going to work in homenet. Robert On Wed, Aug 3, 2011 at 6:00 PM, Joel Jaeggli wrote: > > On Aug 3, 2011, at 9:46 AM, Rajiv Asati (rajiva) wrote: > > > Don, > > > > Just curious about 'smart energy' home network - Why is there a router > > behind the CPE router? > > got a better idea for interconnecting 802.15.4 and 802.3 networks than at > layer-3? > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Don > >> Sturek > >> Sent: Wednesday, August 03, 2011 10:25 AM > >> To: Torbet, Dan; v6ops@ietf.org; homenet@ietf.org > >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router > >> > >> Hi Dan, > >> > >> Here is the initial scenario we are dealing with in the smart energy > > arena: > >> > >> > >> > >> Provider (eg ISP) Provider (eg > > utility) > >> | > >> | > >> CPE router > >> CPE router > >> | > >> | > >> Router --------------------------------- > > router > >> | Link layer > >> | > >> | Interconnect > >> | > >> >> >> iPads, > >> plug in vehicles, > >> Entertainment....> > > load > >> shed devices....> > >> > >> I purposely drew in the devices the way I did since some of these > > networks > >> will evolve as silos then will interconnect when customers upgrade > > their > >> routers to ones with multiple link layers that accommodate > > interconnection. > >> > >> Ultimately, there will not be such a rigid division of devices like > > shown but > >> wanted to emphasize the likelihood that there will be multiple CPE > > routers in > >> the home and an interconnection between them within the home. > >> > >> Don > >> > >> > >> > >> > >> From: "Torbet, Dan" > >> Date: Wed, 3 Aug 2011 07:42:53 -0600 > >> To: "v6ops@ietf.org" , "homenet@ietf.org" > > > >> Subject: [v6ops] default LAN routing protocol for IPv6 CE router > >> > >> > >> > >> The conversations so far on this topic have been great. I think > > however, we > >> need to take a step back for a moment and think through what the > > HOMENET > >> network looks like when serviced by a CPE Router. In my mind, we have > > a few > >> scenarios that are possible. > >> > >> > >> > >> > >> The first is a CPE ingress router to the home and no other routers. > > There may > >> be in this device multiple SSIDs and they each might need to have > > their own > >> address space and have separate firewall/filtering rules. In this > > case, > >> everything is contained in a single box and so no additional routing > > protocols > >> are needed. This has been defined in the CPE router (RFC 6204) and > > the bis > >> extension that is in draft right now. > >> > >> > >> > >> The second case is a CPE ingress router with N routers behind it. In > > this > >> case, I humbly submit that anything where N is greater than 2 says > > medium > >> sized business maybe larger. I find it real hard to get any deeper > > than 2 > >> routers in series for a HOMENET class device deployment. Anything > > greater than > >> that and you likely would not use this class of device anyway. Sure > > there > >> will be situations where this is not true ,but I'll wager that in 90% > > of the > >> installations where a CPE router is providing the link to the world, > > this will > >> be the case. Even factoring in SmartGrid I just can't see a very deep > >> network. Is there a use case for more than 1 or 2 layers in a HOMENET > >> deployment that uses a CPE router as the connection to the world? To > > be clear > >> here - this is what I mean: > >> > >> (sorry for the poor ASCII art here ) > >> > >> > >> > >> Provider Router -------- CPE router ----------Router > > ------ > >> Router > >> > >> > >> > >> Or > >> > >> > >> > >> > >> > >> Provider > >> > >> | > >> > >> CPE Router > >> > >> ^ > >> > >> Router > > Router > >> > >> | > >> | > >> > >> Router > > Router > >> > >> > >> > >> I will acknowledge that in some business cases you might place a > > router on > >> each floor or each building in a campus, but this is where things get > > blurry > >> for me - would you really use a CPE router in these cases for ingress > > into the > >> business? You certainly could, but would you? > >> > >> > >> > >> Given that, I think that defining how many routers exist behind this > > CPE > >> ingress router will provide us with a reasonable place from which to > > define > >> the needs and requirements for an IGP running in the home. > >> > >> > >> > >> Dan > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --90e6ba4fbd5ab018af04a9a61074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

L2 bridging is OK if you can do it but not everything= looks like Ethernet frames.=A0Not only that but if we have multi-link subn= ets using route-over, the router to host ratio goes up considerably. The pr= oblem space is then multi-link subnets then multi-subnet site/zone/homenets= .=A0L3 routing is the only way this is going to work in homenet.

Robert

On Wed, A= ug 3, 2011 at 6:00 PM, Joel Jaeggli <joelja@bogus.com> wrote:

On Aug 3, 2011, at 9:46 AM, Rajiv Asati (rajiva) wrote:

> Don,
>
> Just curious about 'smart energy' home network - Why is there = a router
> behind the CPE router?

got a better idea for interconnecting 802.15.4 and 802.3 networks tha= n at layer-3?

> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: v6ops-bounces@ietf= .org [mailto:v6ops-bounces@ie= tf.org] On Behalf
> Of Don
>> Sturek
>> Sent: Wednesday, August 03, 2011 10:25 AM
>> To: Torbet, Dan; v6ops@ietf.org<= /a>; homenet@ietf.org
>> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE rout= er
>>
>> Hi Dan,
>>
>> Here is the initial scenario we are dealing with in the smart ener= gy
> arena:
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Provider (eg ISP) =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Provider (eg
> utility)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CPE router
>> CPE router
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Router =A0 =A0 =A0 ----= -----------------------------
> router
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Link layer
>> |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Interconnect
>> |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <Macs,
>> <Smart appliances,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iPads,
>> plug in vehicles,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Entertainment....>
> load
>> shed devices....>
>>
>> I purposely drew in the devices the way I did since some of these<= br> > networks
>> will evolve as silos then will interconnect when customers upgrade=
> their
>> routers to ones with multiple link layers that accommodate
> interconnection.
>>
>> Ultimately, there will not be such a rigid division of devices lik= e
> shown but
>> wanted to emphasize the likelihood that there will be multiple CPE=
> routers in
>> the home and an interconnection between them within the home.
>>
>> Don
>>
>>
>>
>>
>> From: "Torbet, Dan" <Dan.Torbet@arrisi.com>
>> Date: Wed, 3 Aug 2011 07:42:53 -0600
>> To: "v6ops@ietf.org&quo= t; <v6ops@ietf.org>, "homenet@ietf.org"
> <homenet@ietf.org>
>> Subject: [v6ops] default LAN routing protocol for IPv6 CE router >>
>>
>>
>> The conversations so= far on this topic have been great. =A0I think
> however, we
>> need to take a step back for a moment and think through what the > HOMENET
>> network looks like when serviced by a CPE Router. =A0In my mind, w= e have
> a few
>> scenarios that are possible.
>>
>>
>>
>>
>> The first is a CPE ingress router to the home and no other routers= .
> There may
>> be in this device multiple SSIDs and they each might need to have<= br> > their own
>> address space and have separate firewall/filtering rules. =A0In th= is
> case,
>> everything is contained in a single box and so no additional routi= ng
> protocols
>> are needed. =A0This has been defined in the CPE router (RFC 6204) = =A0and
> the bis
>> extension that is in draft right now.
>>
>>
>>
>> The second case is a CPE ingress router with N routers behind it. = =A0In
> this
>> case, I humbly submit that anything where N is greater than 2 says=
> medium
>> sized business maybe larger. =A0I find it real hard to get any dee= per
> than 2
>> routers in series for a HOMENET class device deployment. Anything<= br> > greater than
>> that and you likely would not use this class of device anyway. =A0= Sure
> there
>> will be situations where this is not true ,but I'll wager that= in 90%
> of the
>> installations where a CPE router is providing the link to the worl= d,
> this will
>> be the case. =A0Even factoring in SmartGrid I just can't see a= very deep
>> network. =A0Is there a use case for more than 1 or 2 layers in a H= OMENET
>> deployment that uses a CPE router as the connection to the world? = To
> be clear
>> here - this is what I mean:
>>
>> (sorry for the poor ASCII art here )
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Provider Router -------- CPE router --= --------Router
> ------
>> Router
>>
>>
>>
>> Or
>>
>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Provider
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CPE Router
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Router
> Router
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> |
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Router
> Router
>>
>>
>>
>> I will acknowledge that in some business cases you might place a > router on
>> each floor or each building in a campus, but this is where things = get
> blurry
>> for me - would you really use a CPE router in these cases for ingr= ess
> into the
>> business? You certainly could, but would you?
>>
>>
>>
>> Given that, I think that defining how many routers exist behind th= is
> CPE
>> ingress router will provide us with a reasonable place from which = to
> define
>> the needs and requirements for an IGP running in the home.
>>
>>
>>
>> Dan
>>
>> ____________________= ___________________________ v6ops mailing list
>> v6ops@ietf.org https://www.ie= tf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--90e6ba4fbd5ab018af04a9a61074-- From fred@cisco.com Thu Aug 4 12:23:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89821F86EE for ; Thu, 4 Aug 2011 12:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.71 X-Spam-Level: X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=-3.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zpg5BuaCoUnE for ; Thu, 4 Aug 2011 12:23:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EC9FE21F86EC for ; Thu, 4 Aug 2011 12:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=124; q=dns/txt; s=iport; t=1312485847; x=1313695447; h=date:from:message-id:to:subject:cc; bh=aDYwaZDT1NJX0gRCjVZVc1hTKLSQnfxjew0xXnWnpxM=; b=lq6wwpnufkOtiFJ3qabJr/BIbVr2DDTEXUYQEsdfg6A2CPaBj7b5bs/z YTyCaRsAxDWi+ShQKLg6I5KmvdFYURAb2mXSb8XnBSR8+ilQfcNysTpZA +KJLwHr+6aj5mLdqU42pSVD77zusMzwQD8EalWWkgHkjqkCpTHtsPEzyl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAHzxOk6rRDoI/2dsb2JhbABDmFABAY8Yd4FZAWY8LYEKh06jDQGebIVjXwSHWpwl X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="scan'208";a="9764457" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 04 Aug 2011 19:24:07 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p74JO63s028904; Thu, 4 Aug 2011 19:24:06 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p74JO6A19177; Thu, 4 Aug 2011 12:24:06 -0700 (PDT) Date: Thu, 4 Aug 2011 12:24:06 -0700 (PDT) From: Message-Id: <201108041924.p74JO6A19177@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-baker-v6ops-test@tools.ietf.org Subject: [v6ops] new draft: draft-baker-v6ops-test-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:23:52 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-baker-v6ops-test. Please take a look at it and comment. From jhw@apple.com Thu Aug 4 12:24:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3FA1F0C39 for ; Thu, 4 Aug 2011 12:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.652 X-Spam-Level: X-Spam-Status: No, score=-106.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yhIXuIm4U7K for ; Thu, 4 Aug 2011 12:24:16 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id B860B21F874A for ; Thu, 4 Aug 2011 12:24:16 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPF00G5A4IMK5R0@mail-out.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 12:24:32 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-66-4e3af196944d Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 97.34.05159.691FA3E4; Thu, 04 Aug 2011 12:23:02 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPF004V04KVY490@kencur.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 12:24:31 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: Date: Thu, 04 Aug 2011 12:24:31 -0700 Message-id: <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUiON1OTXfaRys/g4lvjC1OH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDuzvrAWbOGr2Ni9m72B8Tp3FyMnh4SAicS+OZ+ZIWwxiQv3 1rN1MXJxCAm0M0mcmrGfESTBKyAo8WPyPZYuRg4OZgF5iYPnZUHCzAJaEt8ftbJA1C9lkui5 18YGkhAWCJD41LgPrF5YIEZi77cKkDCbgIrEt8t3mUBsTgFjid/3foDZLAKqEqcOvGSFGK8i 8b+BH2KrjUTv8bdQ47s5JPo2vgKrFxHQl/h4dz87xM3yEotbPjNOYBScheTSWQiXzkJy6QJG 5lWMgkWpOYmVhsZ6iQUFOal6yfm5mxhB4dhQKLuDcf9P/kOMAhyMSjy8gXut/IRYE8uKK3MP MUpwMCuJ8BqdBArxpiRWVqUW5ccXleakFh9ilOZgURLnnffBzE9IID2xJDU7NbUgtQgmy8TB KdXAaBb+PN4itGvK+lWBztE/Mvz0xc49amWbwvXt4BR2/lIlgWnbbrJ+tJXtWOTOuzfc74ND vNEk1VMFwlqG+6YLFbQ32D3a3FH7qO2cOsOntM9fr+kvPCLcrJYrZrRG7fWyhay+tZv3HguI 9gq30393yv9JdBHrhQz9gudlvWwzQyRuLF5wIc5DiaU4I9FQi7moOBEAdZmFE0MCAAA= Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:24:17 -0000 On Aug 4, 2011, at 01:25 , Philip Homburg wrote: > > It is so nice that Apple considers sending 50% of their users traffic through a CGN as in the interest of their users. Once again, I am presented with an illustration of how my perspective is so very different from what seems to be the mainstream in the operator community. I don't see how the new concurrent TCP connections behavior in Lion is "sending 50% of [traffic originating from hosts with Apple operating systems] through a CGN." It's not like we have a CGN-detector in the stack that applies a limit of the form, "Is this destination on a path that requires a CGN? No? Sorry, unacceptable. At least 50% of my outbound packets MUST go through a CGN or I'm not doing my job properly." The way I see it, operators-- specifically Internet service providers-- are the ones who get to choose where to send arbitrary percentages of traffic originated by hosts on their networks, and it's my understanding that, when considering their alteratives, competent operators usually give some passing thoughts, occasionally, to the interests of their customers (where those interests are aligned with the interests of shareholders). It's not the job of Apple's Core OS Networking group to tell Internet service providers whether and how to deploy CGN for IPv4 paths to achieve address amplification and deal with free pool exhaustion. If they're gonna do it, then we're going to try to make it work for our customers as best we can. But, it's their call... as I've been reminded quite forcefully, on this list, and others, again and again. I'm just rather amused that suddenly it's *our* fault that, when you put a CGN into the network, it gets used. Who could have predicted? -- james woodyatt member of technical staff, core os networking From fred@cisco.com Thu Aug 4 12:26:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4821F8747 for ; Thu, 4 Aug 2011 12:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaQVIPgd5SPt for ; Thu, 4 Aug 2011 12:26:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1270321F873A for ; Thu, 4 Aug 2011 12:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=389; q=dns/txt; s=iport; t=1312485978; x=1313695578; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=I7I2kLaulw/5GnqRQLn6Ot4OQPMsoim4KD6iSVkA9ek=; b=RsHIEO5Qj7QrAP2yp4yqIkZnwSwRUC7ved9qO4qxAIcU0XJfVPxb8jbP AsLJVp4aIA//yTftp2zOYXmeaO+gr71y3M75R2/vg8klSVWeo5ocOTJiL 7l4SCgRo+UQr5kbwPsh9SmR7YzJj+4dEAbF+4YhWwH3LDIgi5dnEiF0hs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACXxOk6rRDoI/2dsb2JhbABDp2p3gUABAQEBAgEBAQEPASc0GwtGJzAGEyKHSgSjCwGebIVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="scan'208";a="9766577" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2011 19:26:18 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn6-1332.cisco.com [10.21.125.52]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p74JQHJK030297 for ; Thu, 4 Aug 2011 19:26:17 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Thu, 04 Aug 2011 12:26:18 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Thu, 04 Aug 2011 12:26:18 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201108041924.p74JO6A19177@ftpeng-update.cisco.com> Date: Thu, 4 Aug 2011 12:26:02 -0700 Message-Id: <880C4B24-FA6F-4824-B9B5-1BD7DA4556D3@cisco.com> References: <201108041924.p74JO6A19177@ftpeng-update.cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-baker-v6ops-test-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:26:03 -0000 That was the result of a test of my bot. Please ignore. On Aug 4, 2011, at 12:24 PM, wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-baker-v6ops-test. Please take a look at = it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Thu Aug 4 12:32:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A967911E8082; Thu, 4 Aug 2011 12:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.649 X-Spam-Level: X-Spam-Status: No, score=-106.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uam28ynIQkdQ; Thu, 4 Aug 2011 12:32:49 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32011E807B; Thu, 4 Aug 2011 12:32:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPF00GQS4YZK5R0@mail-out.apple.com>; Thu, 04 Aug 2011 12:33:04 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-0a-4e3af2c68136 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id A5.73.05328.6C2FA3E4; Thu, 04 Aug 2011 12:28:06 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPF0044C4Z4Y4A0@kencur.apple.com>; Thu, 04 Aug 2011 12:33:04 -0700 (PDT) From: james woodyatt In-reply-to: Date: Thu, 04 Aug 2011 12:33:04 -0700 Message-id: References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUiON1OTffYJys/g21npSzeLzrEYnH62F5m ByaPJUt+MgUwRnHZpKTmZJalFunbJXBltMxYz1xwn6PiytYVjA2MzexdjJwcEgImEjMnNLBC 2GISF+6tZ+ti5OIQEmhnkph74AMjSIJXQFDix+R7LF2MHBzMAvISB8/LgoSZBbQkvj9qZQGx hQQmAdU/sQGxhQX8JPY+Pgs2k01AReLb5btMIDanQLDE56c/wWwWAVWJv/vamSBGqkj8b+CH 2GQjsXfjESaIE7YySVzrewtWIyIgItE8PRTiTHmJxS2fGScwCsxCctwshONmITluASPzKkbB otScxEpDE73EgoKcVL3k/NxNjKDwayg02cF48Cf/IUYBDkYlHt5fu6z8hFgTy4orcw8xSnAw K4nwGp0ECvGmJFZWpRblxxeV5qQWH2KU5mBREue9/d7MT0ggPbEkNTs1tSC1CCbLxMEp1cCY Gql95HbQu86DZw6XXXJZ88FeLiwnNE7ya67GcXWPL7UmpotqJ0bEGQXmXVp/aqb7rC/36q+Z z/33qiSBMdxG6vKtdZ/3H7F8a/H1P8Oy5Uv2+mzs35jwPrWYZcW0SaIHsl8K7J918bKmnmTY GtWl337t6F+zPdqMoeT5d94YlpUTpBcJLfYNV2Ipzkg01GIuKk4EAHwOagA7AgAA Cc: IPv6 Operations Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:32:49 -0000 On Aug 3, 2011, at 21:03 , Robert Cragie wrote: > > L2 bridging is OK if you can do it but not everything looks like Ethernet frames. Not only that but if we have multi-link subnets using route-over, the router to host ratio goes up considerably. The problem space is then multi-link subnets then multi-subnet site/zone/homenets. L3 routing is the only way this is going to work in homenet. This is not strictly true. ND-proxy is an alternative. I've been told it's not a *viable* alternative--- for unspecified and possibly non-technical reasons-- but it is an alternative. I've got a big bucket of popcorn to munch while I watch this discussion play out, and I really don't have a strong opinion one way or another. My take, to the extent I have one, is that in comparison to L2-briding and ND-proxy, L3 routing on home networks will be "a bag of hurt" (to borrow a phrase from Le Grande Fromage), but if that's the direction from which rough consensus will emerge... well, okay then. Let's open up the bag. -- james woodyatt member of technical staff, core os networking From sander@steffann.nl Thu Aug 4 13:15:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE221F8B5B for ; Thu, 4 Aug 2011 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PgJxdyrHS2s for ; Thu, 4 Aug 2011 13:15:30 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 733AF21F880C for ; Thu, 4 Aug 2011 13:15:30 -0700 (PDT) Received: from macpro.10ww.steffann.nl (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 4727D2022; Thu, 4 Aug 2011 22:10:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> Date: Thu, 4 Aug 2011 22:10:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D09CE55-76DF-48C7-BB67-F96EEFE4F461@steffann.nl> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:15:31 -0000 Hi James, > I'm just rather amused that suddenly it's *our* fault that, when you = put a CGN into the network, it gets used. Who could have predicted? It's obvious that it is being used. That is what it's there for :-) = What annoys the operators is that it is used more than is necessary... I think it boils down to: - If it is used when it gives better performance to the user: great. - If it is used when the performance is roughly equal to IPv6: please = use IPv6. It's cheaper for the operator, and it doesn't harm the user. And yes: = the decisions Apple makes here can affect the cost in the operator = network. Met vriendelijke groet, Sander Steffann From dougb@dougbarton.us Thu Aug 4 13:52:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9076A21F874A for ; Thu, 4 Aug 2011 13:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWjfeERMIHOY for ; Thu, 4 Aug 2011 13:52:53 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4621F8749 for ; Thu, 4 Aug 2011 13:52:52 -0700 (PDT) Received: (qmail 32464 invoked by uid 399); 4 Aug 2011 20:53:05 -0000 Received: from unknown (HELO 12-207-105-211.globalsuite.net) (dougb@dougbarton.us@12.207.105.211) by mail2.fluidhosting.com with ESMTPAM; 4 Aug 2011 20:53:05 -0000 X-Originating-IP: 12.207.105.211 X-Sender: dougb@dougbarton.us Message-ID: <4E3B06AF.10402@dougbarton.us> Date: Thu, 04 Aug 2011 13:53:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Philip Homburg References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is c.org> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E3A5509.8090205@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , George Michaelson Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:52:53 -0000 On 08/04/2011 01:25, Philip Homburg wrote: > It is so nice that Apple considers sending 50% of their users traffic through > a CGN as in the interest of their users. I'm glad I'm not one of their > customers. As you stated in another message, avoiding nat is your goal. As a result, I think your statement above is an excellent example of the market forces at work. Thus we can *conclude* that apple has met their fiduciary responsibilities. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jhw@apple.com Thu Aug 4 14:00:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8775311E8089 for ; Thu, 4 Aug 2011 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.647 X-Spam-Level: X-Spam-Status: No, score=-106.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xocdRMatK4bn for ; Thu, 4 Aug 2011 14:00:09 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2500211E8082 for ; Thu, 4 Aug 2011 14:00:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LPF0062E90NPC20@mail-out.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 14:00:23 -0700 (PDT) X-AuditID: 11807136-b7c35ae000001055-1e-4e3b0a9e4e41 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id F5.73.04181.F9A0B3E4; Thu, 04 Aug 2011 14:09:51 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPF0024A90ICV00@koseret.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 14:00:18 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <4D09CE55-76DF-48C7-BB67-F96EEFE4F461@steffann.nl> Date: Thu, 04 Aug 2011 14:00:18 -0700 Message-id: <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiON1OXXc+l7WfQddTHovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY87L9awF9zkqurdVNjD+Zeti5OSQEDCRmLZ8LTuELSZx4d56 oDgXh5BAJ5PE/QUdrCAJXgFBiR+T77F0MXJwMAvISxw8LwsSZhbQkvj+qJUFon45k8STXzvA hgoLBEh8atwHVi8sECOx91sFSJhNQEXi2+W7TCA2p4C9xOoHHYwgJSwCqhI7OzlBTF4BG4kT 22IhJjZySPydtYoFpFwEqHXKmftQJ8tLLG75zDiBUWAWkuNmIRw3C8lxCxiZVzEKFqXmJFYa muolFhTkpOol5+duYgSFXEOh2Q7GHX/lDjEKcDAq8fAG7rXyE2JNLCuuzD3EKMHBrCTCW8lg 7SfEm5JYWZValB9fVJqTWnyIUZqDRUmcl/uzmZ+QQHpiSWp2ampBahFMlomDU6qBsUdXSnT5 dDMPuajaw5Nk1X7t9/4s9uzVvFlmn94w2q2Yzvf6i9Mqg0NRJ87+tF9hufygZV8LW+jvxryQ b0WxYYrrZn8JK2569l7gdu7eryuUvyhaBUmlKz3fdmi1kl63/e2LWxn+tN9hC+i10v0ifT5G MfWOpv9xb779l5xVDXmrt9quPtzercRSnJFoqMVcVJwIAEbUmUs1AgAA Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:00:09 -0000 On Aug 4, 2011, at 13:10 , Sander Steffann wrote: > > I think it boils down to: > - If it is used when it gives better performance to the user: great. > - If it is used when the performance is roughly equal to IPv6: please use IPv6. I don't know how to say this differently, so I'm just going to repeat myself. If you provision your networks so that IPv4 paths have longer round-trip times or are congested more often and/or to a greater degree, then we will prefer less congested IPv6 paths. Furthermore, if you provision your networks so that IPv6 paths have longer round-trip times or are congested more often and/or to a greater degree, then we will prefer less congested IPv4/NAT paths. Finally, if you provision your networks so that IPv4 and IPv6 exhibit "roughly equivalent" levels of path latency and congestion, then we're going to try very, very hard to use both IPv4 and IPv6 in "roughly equivalent" measure. Isn't this what traffic engineers have been clamoring at us for years to give them? -- james woodyatt member of technical staff, core os networking From fred@cisco.com Thu Aug 4 14:22:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C07921F8891 for ; Thu, 4 Aug 2011 14:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKIkFtOuMaZj for ; Thu, 4 Aug 2011 14:22:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9DC21F888A for ; Thu, 4 Aug 2011 14:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=124; q=dns/txt; s=iport; t=1312492940; x=1313702540; h=date:from:message-id:to:subject:cc; bh=aDYwaZDT1NJX0gRCjVZVc1hTKLSQnfxjew0xXnWnpxM=; b=MiVzhtfm/BEsn4yo6O8/Vg6DS2JY9QH+R/PBrpTH1LrF6CSDVA6OMQQ5 jq9wo4fCvkGropyVD1sl/qNh633rAekojN8XFeSbqlPL42m0khvT0QoQ7 ad6waN8EULTk51ItVWSiZrCNgGHdMRRZvu5PJ+N3gE0vi6wJdpxomvgP6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAEcNO06rRDoJ/2dsb2JhbABDmFABAY8Yd4FZAWY8LYEKh06ibQGeYYZCBIdanCU X-IronPort-AV: E=Sophos;i="4.67,319,1309737600"; d="scan'208";a="9800638" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2011 21:22:19 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74LMJp8007683; Thu, 4 Aug 2011 21:22:19 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p74LMJS21568; Thu, 4 Aug 2011 14:22:19 -0700 (PDT) Date: Thu, 4 Aug 2011 14:22:19 -0700 (PDT) From: Message-Id: <201108042122.p74LMJS21568@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-baker-v6ops-test@tools.ietf.org Subject: [v6ops] new draft: draft-baker-v6ops-test-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:22:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-baker-v6ops-test. Please take a look at it and comment. From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Aug 4 14:25:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1775021F86BB; Thu, 4 Aug 2011 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf6hJsjZwDMN; Thu, 4 Aug 2011 14:25:37 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADD21F866A; Thu, 4 Aug 2011 14:25:34 -0700 (PDT) Received: from 219-90-209-53.ip.adam.com.au ([219.90.209.53] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qp5QI-0003gu-9m; Fri, 05 Aug 2011 06:55:46 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 8C3B23B34D; Fri, 5 Aug 2011 06:55:45 +0930 (CST) Date: Fri, 5 Aug 2011 06:55:45 +0930 From: Mark Smith To: james woodyatt Message-ID: <20110805065545.438a8218@opy.nosense.org> In-Reply-To: References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM> <067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com> <0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: homenet@ietf.org, IPv6 Operations Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:25:38 -0000 On Thu, 04 Aug 2011 12:33:04 -0700 james woodyatt wrote: > On Aug 3, 2011, at 21:03 , Robert Cragie wrote: > > > > L2 bridging is OK if you can do it but not everything looks like Ethernet frames. Not only that but if we have multi-link subnets using route-over, the router to host ratio goes up considerably. The problem space is then multi-link subnets then multi-subnet site/zone/homenets. L3 routing is the only way this is going to work in homenet. > > This is not strictly true. ND-proxy is an alternative. > > I've been told it's not a *viable* alternative--- for unspecified and possibly non-technical reasons-- but it is an alternative. I've got a big bucket of popcorn to munch while I watch this discussion play out, and I really don't have a strong opinion one way or another. > > My take, to the extent I have one, is that in comparison to L2-briding and ND-proxy, L3 routing on home networks will be "a bag of hurt" (to borrow a phrase from Le Grande Fromage), but if that's the direction from which rough consensus will emerge... well, okay then. Let's open up the bag. > I think that subnets/routing performs more than just the task of overcoming layer 2 differences and controling the size of link layer broadcast domains. They're probably more commonly used today as host grouping mechanism for security or other policies. There requirement is certainly valid for home networks e.g. parent subnet, kid subnet, multicast video subnet (no wifi!) etc. In a pure layer 2 bridged environment the only way to achieve this would be to start tracking individual hosts identities and enforce these policies on a per-host basis at each device that bridges the frames. > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Aug 4 14:28:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27021F8A30 for ; Thu, 4 Aug 2011 14:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4qHthrV-Gbv for ; Thu, 4 Aug 2011 14:28:25 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA121F8A23 for ; Thu, 4 Aug 2011 14:28:25 -0700 (PDT) Received: from 219-90-209-53.ip.adam.com.au ([219.90.209.53] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qp5Sz-0003lg-Bi; Fri, 05 Aug 2011 06:58:33 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id D73143B34D; Fri, 5 Aug 2011 06:58:32 +0930 (CST) Date: Fri, 5 Aug 2011 06:58:32 +0930 From: Mark Smith To: Message-ID: <20110805065832.724dae22@opy.nosense.org> In-Reply-To: <201108042122.p74LMJS21568@ftpeng-update.cisco.com> References: <201108042122.p74LMJS21568@ftpeng-update.cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: draft-baker-v6ops-test@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-baker-v6ops-test-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:28:25 -0000 Hi Fred, On Thu, 4 Aug 2011 14:22:19 -0700 (PDT) wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-baker-v6ops-test. Please take a look at it and comment. Well I suppose I'm commenting on it - I get a Not Found page if I use the above URL. Regards, Mark. From fred@cisco.com Thu Aug 4 14:38:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F317E21F8A23 for ; Thu, 4 Aug 2011 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njUZ52Xdd1Hd for ; Thu, 4 Aug 2011 14:38:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5305021F88D9 for ; Thu, 4 Aug 2011 14:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=509; q=dns/txt; s=iport; t=1312493934; x=1313703534; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=6/6biRUEazwQ/NMGgQ0+L1EZU6qf8hAJvV14A1G8DdY=; b=DeobKbN6v9LEFkGKUCsGw21+PH23hJRHSOBHA5jYj7eRAZ81XjRwXlCR UbBRKUsX2ozi3APLgub9kG8te2cHn7s3MaH9eo4DKdZd2DOYy+Tcd+iQR e70l5Bj0OMv+c+VcCX8/ZNZpVG4sTcqL3v4x0gO2xuxDf+sN6ZslEmtCf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABcRO06rRDoI/2dsb2JhbABDp2p3gUABAQEBAgESASc/BQsLDgouVwYTIodKBKMIAZ5hhWNfBIdaiyGFB4t9 X-IronPort-AV: E=Sophos;i="4.67,319,1309737600"; d="scan'208";a="9805930" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 04 Aug 2011 21:38:53 +0000 Received: from wl-dy-169-228-177-245.ucsd.edu (sjc-vpn6-1332.cisco.com [10.21.125.52]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p74Lc1fr005455; Thu, 4 Aug 2011 21:38:53 GMT Received: from [127.0.0.1] by wl-dy-169-228-177-245.ucsd.edu (PGP Universal service); Thu, 04 Aug 2011 14:38:53 -0700 X-PGP-Universal: processed; by wl-dy-169-228-177-245.ucsd.edu on Thu, 04 Aug 2011 14:38:53 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20110805065832.724dae22@opy.nosense.org> Date: Thu, 4 Aug 2011 14:38:53 -0700 Message-Id: References: <201108042122.p74LMJS21568@ftpeng-update.cisco.com> <20110805065832.724dae22@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: draft-baker-v6ops-test@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-baker-v6ops-test-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:38:39 -0000 that's because it doesn't actually exist; I created it in my local = mirror as a "new" draft. On Aug 4, 2011, at 2:28 PM, Mark Smith wrote: > Hi Fred, >=20 > On Thu, 4 Aug 2011 14:22:19 -0700 (PDT) > wrote: >=20 >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-baker-v6ops-test. Please take a look at = it and comment. >=20 > Well I suppose I'm commenting on it - I get a Not Found page if I use > the above URL. >=20 > Regards, > Mark. >=20 From newbery@gmail.com Thu Aug 4 15:06:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC021F8AA8 for ; Thu, 4 Aug 2011 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCJT9lnXaaon for ; Thu, 4 Aug 2011 15:06:27 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09B0721F8A69 for ; Thu, 4 Aug 2011 15:06:26 -0700 (PDT) Received: by qyk34 with SMTP id 34so49006qyk.10 for ; Thu, 04 Aug 2011 15:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=jGMQ5z5Wq9WNMNLW8B5XZMilOBK/BbwQPzDzzK0n7xg=; b=kROR7F+TAkgk6Y1QHUYtvKn/DkaKQZ4LEfvdQCJaEwtvZi+P4qMiupSOor/Nu2ph81 1hcoM9N3QS3UCPt0M/875gTWzY8svxJ0E3bIsljv/BChV6Dd3YcuJmg9hyN1Iax0U+su OQBv/LYYLN7ZMgSL8Uj1+bAiEY0TcbaIsd268= Received: by 10.229.118.69 with SMTP id u5mr1121810qcq.122.1312495602505; Thu, 04 Aug 2011 15:06:42 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id o4sm1660912qct.13.2011.08.04.15.06.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 15:06:41 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--819052668; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 5 Aug 2011 10:06:31 +1200 In-Reply-To: <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> To: IPv6 Operations References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:06:27 -0000 --Apple-Mail-1--819052668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5/08/2011, at 7:24 AM, james woodyatt wrote: > The way I see it, operators-- specifically Internet service = providers-- are the ones who get to choose where to send arbitrary = percentages of traffic originated by hosts on their networks, [...] >=20 > It's not the job of Apple's Core OS Networking group to tell Internet = service providers whether and how to deploy CGN for IPv4 paths to = achieve address amplification and deal with free pool exhaustion. If = they're gonna do it, then we're going to try to make it work for our = customers as best we can. [...] +1 Is this a classic SEP (Someone Else's Problem)? LSNs are Bad, but since = some ISPs are going to deploy them anyway, can't we make the clients = detect them and de-prefer them, so the ISPs won't have an economic = motive to continue deploying them? I submit that is wrong. Let the ISPs = make their decisions; let the clients work with what is there. LSNs are doomed, because they can't provide IPv4 only access to IPv6. = So, it might well be that an ISP that feels the need to deploy LSN or = NAT64 temporarily could introduce latency to bias customers with a = choice against. It might not be something the've thought about, but as a = way to reduce the need for ongoing investment in interim hardware it has = a certain attraction. But, it is entirely their decision. The last thing = the ISPs need to to be having to second guess the client software, as it = attempts to second guess the ISPs, ...= --Apple-Mail-1--819052668 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwODA0MjIwNjM2 WjAjBgkqhkiG9w0BCQQxFgQUAkFAEFu6gF1iERiND4XFSQuDoC8wgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBACYnc/kGi0p6ihonYkG3OFwPV7jEOwaW5PaZu53788qOTZZbGfnvPYrIFHDx tt66l8KHpPsvSFrdJcsbpRBAYzF/TNiJALVQ7umo2kESFyibUg05EXX3QJFqf1UrGVJshSfwu1Cw XaPbAbic2ucffztXEv+WyC+51wphekrcK64nV23z9vBELS0SDqBzJlRMHBuOMqRfBNsRyV2vIV5x jeNOvoQo0M+QPfr/+1dcoPLFAdBjvaTdcOVp+rZqcINlXQShe9p4YAh/UUTrEaA2k7+wpiUjNw2u CweGrxdgfHhhLityPMl9J8Z+u0pbn743jKfDO9NmcICbV/c5+fbYfTgAAAAAAAA= --Apple-Mail-1--819052668-- From lorenzo@google.com Thu Aug 4 15:19:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E77B21F8ABB for ; Thu, 4 Aug 2011 15:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.886 X-Spam-Level: X-Spam-Status: No, score=-105.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go+vvDu119AW for ; Thu, 4 Aug 2011 15:19:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B44721F8AB0 for ; Thu, 4 Aug 2011 15:19:36 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p74MJnN0025810 for ; Thu, 4 Aug 2011 15:19:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312496389; bh=XJnWooq5y7OwYyTvFBq4yM6u7PA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Y59Ac1KZzAFdegepCSJEoK3gA1+x8ASPV6kEkgy5BjKPIrUvzxwftzxEAJ+H8rUhm Thqst0HAY0t2eru94Aquw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=DjyBRgHHZQe2cHXHP3UW66dOdMxde5Lhox0iIzPI28v1s3GEOm1zeO1Sa+wbrp6Xm YdJNMCjDXvG+BkNWKE/gA== Received: from yxi13 (yxi13.prod.google.com [10.190.3.13]) by kpbe17.cbf.corp.google.com with ESMTP id p74MJ675002972 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 15:19:48 -0700 Received: by yxi13 with SMTP id 13so1874330yxi.40 for ; Thu, 04 Aug 2011 15:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YoDzw2DieG/44qN0z3xD6p1YP0803JmxLV359ThuGLw=; b=RqwuuwBg+2UaIX6/2zVG+SBnvBqhDhrHpNvpxA82lmQPCV+0aKqXfhncO9RGrDXYij lWaz/8kirdjWktJdNTGg== Received: by 10.151.11.10 with SMTP id o10mr2543475ybi.171.1312496388325; Thu, 04 Aug 2011 15:19:48 -0700 (PDT) Received: by 10.151.11.10 with SMTP id o10mr2543470ybi.171.1312496388143; Thu, 04 Aug 2011 15:19:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Thu, 4 Aug 2011 15:19:28 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> From: Lorenzo Colitti Date: Thu, 4 Aug 2011 15:19:28 -0700 Message-ID: To: Michael Newbery Content-Type: multipart/alternative; boundary=000e0cd6aed2fbfa5904a9b56003 X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:19:37 -0000 --000e0cd6aed2fbfa5904a9b56003 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 4, 2011 at 15:06, Michael Newbery wrote: > LSNs are doomed, because they can't provide IPv4 only access to IPv6. > Nope. There will be no IPv6-only content that matters until IPv6 is widely or ubiquitously deployed. So not having access to IPv6 will not matter. --000e0cd6aed2fbfa5904a9b56003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4, 2011 at 15:06, Michael Newbery <newbery@gmail.com<= /a>> wrote:
LSNs are doomed, because they can't provide IPv4 only= access to IPv6.

Nope.=A0There will b= e no IPv6-only content that matters until IPv6 is widely or ubiquitously de= ployed. So not having access to IPv6 will not matter.
--000e0cd6aed2fbfa5904a9b56003-- From marka@isc.org Thu Aug 4 15:31:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DCC22800E for ; Thu, 4 Aug 2011 15:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM+r+HccoGi9 for ; Thu, 4 Aug 2011 15:31:10 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9064922800D for ; Thu, 4 Aug 2011 15:31:09 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A7AFE5F98E6; Thu, 4 Aug 2011 22:31:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8B056216C80; Thu, 4 Aug 2011 22:31:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B88151274527; Fri, 5 Aug 2011 08:31:05 +1000 (EST) To: james woodyatt From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> In-reply-to: Your message of "Thu, 04 Aug 2011 14:00:18 MST." <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> Date: Fri, 05 Aug 2011 08:31:05 +1000 Message-Id: <20110804223105.B88151274527@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:31:10 -0000 In message <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com>, james woodyatt wri tes: > On Aug 4, 2011, at 13:10 , Sander Steffann wrote: > > > > I think it boils down to: > > - If it is used when it gives better performance to the user: great. > > - If it is used when the performance is roughly equal to IPv6: please use I > Pv6. > > I don't know how to say this differently, so I'm just going to repeat myself. > > If you provision your networks so that IPv4 paths have longer round-trip time > s or are congested more often and/or to a greater degree, then we will prefer > less congested IPv6 paths. > > Furthermore, if you provision your networks so that IPv6 paths have longer ro > und-trip times or are congested more often and/or to a greater degree, then w > e will prefer less congested IPv4/NAT paths. > > Finally, if you provision your networks so that IPv4 and IPv6 exhibit "roughl > y equivalent" levels of path latency and congestion, then we're going to try > very, very hard to use both IPv4 and IPv6 in "roughly equivalent" measure. > > Isn't this what traffic engineers have been clamoring at us for years to give > them? In a world where the packets are just being routed that would be optimal, however we are planning for a world where packets aren't just being routed. We are planning for a world where IPv4 packets cost significantly more to dollars to process than IPv6 packets. We are saying that when the paths are of roughly equal performance wise to use the IPv6 path. Even if a ISP puts enough CGN/AFTR/NAT64 equipement in that they can process there entire traffic load over it with performance parity they don't want any traffic to use it. All of these boxes need to log every flow through them for abuse traceback / law enforcement. Mark > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From newbery@gmail.com Thu Aug 4 15:45:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88A11E807F for ; Thu, 4 Aug 2011 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJO4E61DxWI6 for ; Thu, 4 Aug 2011 15:45:33 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE911E807C for ; Thu, 4 Aug 2011 15:45:33 -0700 (PDT) Received: by qyk35 with SMTP id 35so1135995qyk.10 for ; Thu, 04 Aug 2011 15:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=fdeeepGUKKoEw0fxWP85aAp9DI1Y5F+DhzsrYD9xwbE=; b=b0vtIXTBp6sxLAlJrgT2SrRAY4o12jSWs4n16djox9sO69Ol1ML9xGX5Tpq6JVqA+d lYXethCw7ZqZTXRGFnFZ6M5O2I2SozykTTTrXm5sAGg7D1331HLoPXN4UL16mEGX/rHu 3nFmK4+aAXwRSYTc0MUOr0xFuKCMyhge47VFg= Received: by 10.224.191.10 with SMTP id dk10mr1027172qab.170.1312497948896; Thu, 04 Aug 2011 15:45:48 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id s14sm1676914qct.42.2011.08.04.15.45.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 15:45:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3--816706396; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Newbery In-Reply-To: Date: Fri, 5 Aug 2011 10:45:37 +1200 Message-Id: <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFA BFAACD8A@apple.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:45:35 -0000 --Apple-Mail-3--816706396 Content-Type: multipart/alternative; boundary=Apple-Mail-2--816711243 --Apple-Mail-2--816711243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5/08/2011, at 10:19 AM, Lorenzo Colitti wrote: > On Thu, Aug 4, 2011 at 15:06, Michael Newbery = wrote: > LSNs are doomed, because they can't provide IPv4 only access to IPv6. >=20 > Nope. There will be no IPv6-only content that matters until IPv6 is = widely or ubiquitously deployed. So not having access to IPv6 will not = matter. I disagree. The Web is not the Internet. As soon as any significant = number (and I suspect a number as little as 5%) of clients are IPv6 = only, and direct communication is required, then the IPv6 have nots will = start demanding action from their ISP. Consider a hypothetical "Irritated Avians, Network Edition". Frag your = friends---except *your* friend is on LTE and is IPv6 only... You now = need IPv6. Don't make the mistake of thinking that 'content' is only what sits on = central servers. In particular, as an ISP, don't think that content is = something that you own or control. Or understand, for that matter. The = content of the Internet is its edge, its users. The bit in the middle, = where we operators play, is an irritating irrelevancy to the customers. = And that's how it should be. We are the plumbing, and people only care = about plumbing when it doesn't work.= --Apple-Mail-2--816711243 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 5/08/2011, at 10:19 AM, Lorenzo Colitti wrote:

On Thu, Aug 4, 2011 at 15:06, Michael Newbery <newbery@gmail.com> wrote:
LSNs are doomed, because they can't provide IPv4 only access to IPv6.

Nope. There will be no IPv6-only content that matters until IPv6 is widely or ubiquitously deployed. So not having access to IPv6 will not matter.

I disagree. The Web is not the Internet. As soon as any significant number (and I suspect a number as little as 5%) of clients are IPv6 only, and direct communication is required, then the IPv6 have nots will start demanding action from their ISP.

Consider a hypothetical "Irritated Avians, Network Edition". Frag your friends---except *your* friend is on LTE and is IPv6 only... You now need IPv6.

Don't make the mistake of thinking that 'content' is only what sits on central servers. In particular, as an ISP, don't think that content is something that you own or control. Or understand, for that matter. The content of the Internet is its edge, its users. The bit in the middle, where we operators play, is an irritating irrelevancy to the customers. And that's how it should be. We are the plumbing, and people only care about plumbing when it doesn't work.
--Apple-Mail-2--816711243-- --Apple-Mail-3--816706396 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwODA0MjI0NTQz WjAjBgkqhkiG9w0BCQQxFgQUAyJo5neSj8vy+Wo+YN1YnAc3L/EwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBAIMHt7//SQ/FaId5o7PTN4kMKpypmcwSGzOl1C8cMQyLrhx7Lzq8ylZzCYHX FISnQul6ykDz9+s8pD0tbXFooyP+L5jo0M5iz2Zl7/E1nN9F6Ktlfy5pH08yxHu7P6cyQ/X7uz9p Va13N6x6VvVASoBQciRMUoEuMLkj4X+L1hJCSnXQ4ZBP3X46ARp3l7IyeVnsdgkh7lIYD9Rl8FH5 rsqP/4YNIMZt+wder7KnoHdbNy6izF63WojSLPhJmpRD5lgn4csgAy/Jc994pBh0977bL9npIjiR Or6gj8xufDg6T0g1Ez0yqsyRDfCqeJxZc6tgdhIxrdeL6YrinjqDd9kAAAAAAAA= --Apple-Mail-3--816706396-- From moore@network-heretics.com Thu Aug 4 15:48:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF621F8574 for ; Thu, 4 Aug 2011 15:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-CPd2kvd8cC for ; Thu, 4 Aug 2011 15:48:37 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id F30FB21F8564 for ; Thu, 4 Aug 2011 15:48:36 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qp6ie-0003Mn-HF; Thu, 04 Aug 2011 18:48:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> Date: Thu, 4 Aug 2011 18:48:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29B2A4FB-C397-4C45-AB27-A3F02BCD262F@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFA BFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> To: Michael Newbery X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940f64877910f102740ff413c8684d6f618350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:48:38 -0000 On Aug 4, 2011, at 6:45 PM, Michael Newbery wrote: > Don't make the mistake of thinking that 'content' is only what sits on = central servers. +1 From lorenzo@google.com Thu Aug 4 16:03:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A921F8698 for ; Thu, 4 Aug 2011 16:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.894 X-Spam-Level: X-Spam-Status: No, score=-105.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUjDGoivK+xS for ; Thu, 4 Aug 2011 16:03:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4056521F85FE for ; Thu, 4 Aug 2011 16:03:35 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p74N3jt4012523 for ; Thu, 4 Aug 2011 16:03:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312499025; bh=raOJ/vzTmYwI6QaDzgYpPj1IHMU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FPn9itjET7Y6+DMPYJHd79A958QLzYMYrR8rV10mUcIGU6Y0CekBgmSfylDvSgCfY CwSS49LLt7MDR7+zCfw9Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=hIpJNRC4aRV2mF64CmH5HHdtS9E60WASzTEjoNFF9G1vEQJAG5T4pyp/Ol9omM9OZ 4q3EDNgYDN0yhVYyFpj9Q== Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by hpaq1.eem.corp.google.com with ESMTP id p74N3gmS016846 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 16:03:43 -0700 Received: by gwb20 with SMTP id 20so1373746gwb.3 for ; Thu, 04 Aug 2011 16:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JQL9f36Z96SQa9ohxO8zzHaKY+Vu9MrONit+duEdYD8=; b=MdR0l9H1eJL2bD6+0fzX72cMk/fZLHgapBt64TFw4qEjJveOKVJDhR5Sp+ZPkjcNU8 v47gaeTkJ88rMCuIxqjA== Received: by 10.150.160.21 with SMTP id i21mr2652192ybe.57.1312499022559; Thu, 04 Aug 2011 16:03:42 -0700 (PDT) Received: by 10.150.160.21 with SMTP id i21mr2652188ybe.57.1312499022331; Thu, 04 Aug 2011 16:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Thu, 4 Aug 2011 16:03:22 -0700 (PDT) In-Reply-To: <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> From: Lorenzo Colitti Date: Thu, 4 Aug 2011 16:03:22 -0700 Message-ID: To: Michael Newbery Content-Type: multipart/alternative; boundary=000e0cdf1c56fe7f1b04a9b5fd2f X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:03:35 -0000 --000e0cdf1c56fe7f1b04a9b5fd2f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 4, 2011 at 15:45, Michael Newbery wrote: > I disagree. The Web is not the Internet. As soon as any > significant number (and I suspect a number as little as 5%) of clients are > IPv6 only, and direct communication is required, then the IPv6 have nots > will start demanding action from their ISP. > I can't imagine my family, my friends or anyone outside the industry ever calling their ISP asking why they don't have IPv6. You might as well assert that users will call their ISP asking for PPPoA over PPPoE because it has less overhead. --000e0cdf1c56fe7f1b04a9b5fd2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4, 2011 at 15:45, Michael Newbery <newbery@gmail.com<= /a>> wrote:
I dis= agree. The Web is not the Internet. As soon as any significant=A0number=A0(= and I suspect a number as little as 5%) of clients are IPv6 only, and direc= t communication is required, then the IPv6 have nots will start demanding a= ction from their ISP.

I can't imagine my family,= my friends or anyone outside the industry ever calling their ISP asking wh= y they don't have IPv6. You might as well assert that users will call t= heir ISP asking for PPPoA over PPPoE because it has less overhead.
--000e0cdf1c56fe7f1b04a9b5fd2f-- From jhw@apple.com Thu Aug 4 16:17:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76DC21F851A for ; Thu, 4 Aug 2011 16:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.644 X-Spam-Level: X-Spam-Status: No, score=-106.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxYeQnYStqlc for ; Thu, 4 Aug 2011 16:17:40 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B721F8519 for ; Thu, 4 Aug 2011 16:17:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPF00GJGFCKK581@mail-out.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 16:17:53 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-7d-4e3b27763a25 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 7F.39.05328.6772B3E4; Thu, 04 Aug 2011 16:12:54 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPF0059SFDTYE50@kencur.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 16:17:53 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <20110804223105.B88151274527@drugs.dv.isc.org> Date: Thu, 04 Aug 2011 16:17:53 -0700 Message-id: <87805FCB-A7A9-43AE-ACA7-9524B5944272@apple.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> To: Mark Andrews X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUiON1OTbdM3drPYO5JcYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro73nJWPBMbaKF1uPszQwzmXtYuTgkBAwkZjzSrWLkRPIFJO4 cG89WxcjF4eQQDuTxOTO60wgCV4BQYkfk++xgNQzC8hLHDwvCxJmFtCS+P6olQWifimTxII7 IDWcHMICARKfGvdB2TESr+btBrPZBFQkvl2+CzaTU8BaYv6zK6wgNouAqsTq+18ZIearSPxv 4IdYayPxavZURoj5Uzkkth24B9YrIqAg0fb2FRPE0fISi1s+M05gFJyF5NRZCKfOQnLqAkbm VYyCRak5iZWGJnqJBQU5qXrJ+bmbGEHh2FBosoPx4E/+Q4wCHIxKPLy/dln5CbEmlhVX5h5i lOBgVhLhrWSw9hPiTUmsrEotyo8vKs1JLT7EKM3BoiTOe/u9mZ+QQHpiSWp2ampBahFMlomD U6qBkaWL61bfqwSpqvJtZgoqThrvIw9ZL7rc/+1pwHs5PcUiw8Y/F6wnLZCMTSj43+2z5NLe qX+evZKc2Htgkj+vFEs31xn+39GCkWdZZrv2WGQZ33/6k/nnx3XF9qcThD8tXBzUJlnSdjbU uXBLnOBjH8mA5lXzpHx/nP7Z6O+dHT2p/N0r9iXWSizFGYmGWsxFxYkAzAVsHEMCAAA= Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:17:40 -0000 On Aug 4, 2011, at 15:31 , Mark Andrews wrote: > > We are planning for a world where IPv4 packets cost significantly more dollars to process than IPv6 packets. We are saying that when the paths are of roughly equal performance wise to use the IPv6 path. When the additional costs of having IPv4 service available alongside IPv6 are passed along to subscribers-- where they have some hope of noticing anything remotely related to it-- then when we can have a conversation about who should pay, and who should be paid, for making sure that all the IPv4 network elements are only used by IPv4-only hosts. Until then, I recommend trying to get used to the new tactical environment. It's going to be with us for a long while yet to come. -- james woodyatt member of technical staff, core os networking From shane@castlepoint.net Thu Aug 4 17:45:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82F21F854E for ; Thu, 4 Aug 2011 17:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQn+st+Ogxlh for ; Thu, 4 Aug 2011 17:45:06 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0946C21F854D for ; Thu, 4 Aug 2011 17:45:06 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E0FE5268037; Thu, 4 Aug 2011 18:45:21 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 04 Aug 2011 18:45:21 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=50516; syn-fingerprint=65535:54:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> Date: Thu, 4 Aug 2011 18:45:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <034720BC-5F0D-48CA-83FB-277E850585F0@castlepoint.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:45:06 -0000 On Aug 4, 2011, at 1:24 PM, james woodyatt wrote: [--snip--] > The way I see it, operators-- specifically Internet service = providers-- are the ones who get to choose where to send arbitrary = percentages of traffic originated by hosts on their networks, and it's = my understanding that, when considering their alteratives, competent = operators usually give some passing thoughts, occasionally, to the = interests of their customers (where those interests are aligned with the = interests of shareholders). There may be a problem with the aforementioned logic. Specifically, an = ISP's routers are only capable of applying (BGP) Traffic Engineering = *within* and not /between/ address families. IOW, an operator can = control where/how IPv4 packets are routed, but an operator cannot = control, for example, that IPv6 forwarding should be preferred to IPv4 = forwarding. At this point, given implementations of Happy Eyeballs or = behavior like it, the only "control" an operator can feasibly 'exert' to = change the preference of IPv4 compared to IPv6 is to drop packets of one = address family over the other ... which is a extremely crude = sledgehammer for a variety of reasons, that are hopefully obvious. I think it would be more productive to discuss the feasibility of moving = past the notion of a single, "fixed" address policy (e.g.: RFC 3484) to = rule them all and, instead, potentially consider something like: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01 ... or, a similar/better mechanism in RA's. (I'm not here to prescribe = a specific protocol, rather to raise the more general point). For example, if somehow an operator were able to _dynamically_ [and more = strongly] hint to end-hosts that native IPv6 is preferred compared to = IPv4, then _at the right time in the near future_ this would allow = operators to start signaling to hosts, on an per-Metro or per-region (?) = basis, that they believe a good quality, good performance, etc. = deployment of IPv6 exists (in the access, the Backbone and = peering/interconnect portions of the network) and they want hosts to = start originating packets using IPv6, when possible. This would also, = potentially, absolve host stack vendors from making a difficult and/or = wrong call on a single, static address selection policy and, instead, = point the blame & pain of an address selection policy firmly back at the = ISP, where it belongs. :-)=20 Note that this could more generally considered as a, hopefully, = lightweight method of advertising "site" exit routing preferences/hints = towards hosts. This way, when hosts are multi-homed (have two or more = IPv6 prefixes on a single link, but two exit routers to two different = ISP's), an administrator can dynamically signal to hosts that they = should prefer one GUA over another GUA, perhaps because the transit = costs of ISP A are less than the transit costs of ISP B or, = alternatively, because the administrator deems the 'performance' of ISP = A to be substantially better than the 'performance' of ISP B. (As one = example see draft-baker-fun-multi-router-00). Note that if the two = ISP's are of equal cost and performance, administrators could signal a = policy that an equal 'weight' applied to both GUA prefixes advertised to = the host and the host can either more simply round-robin between them = or, if it wants, implement something Happy Eyeball like to squeeze our = more certainty as to a particular path's quality.=20 In summary, it's time we stop thinking "the network" is omniscient and = it will always, automatically know the intent/desire of end-hosts. = Likewise, hosts should only benefit from 'hints' learned from the = network as to "preferred [exit] paths" so that they wouldn't need to = always bother attempting to open connections just to keep finding out = that a particular path/link is of consistently poor performance, (i.e.: = the definition of insanity). =20 > It's not the job of Apple's Core OS Networking group to tell Internet = service providers whether and how to deploy CGN for IPv4 paths to = achieve address amplification and deal with free pool exhaustion. If = they're gonna do it, then we're going to try to make it work for our = customers as best we can. But, it's their call... as I've been reminded = quite forcefully, on this list, and others, again and again. >=20 > I'm just rather amused that suddenly it's *our* fault that, when you = put a CGN into the network, it gets used. Who could have predicted? I wouldn't say it's Apple's fault; however, we probably all need to = "think different". :-) Namely, we should all see if we can find a way = to give operators some amount of control over address selection policy = on hosts, since ultimately we [think we] know our networks best. :-) -shane= From moore@network-heretics.com Thu Aug 4 18:34:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB021F8509 for ; Thu, 4 Aug 2011 18:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuXFaNq6KIoj for ; Thu, 4 Aug 2011 18:34:43 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 266BA21F8568 for ; Thu, 4 Aug 2011 18:34:43 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qp9JO-0000sC-Cl; Thu, 04 Aug 2011 21:34:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11--806559728 From: Keith Moore In-Reply-To: Date: Thu, 4 Aug 2011 21:34:49 -0400 Message-Id: <0FB6E2DB-71FC-449E-A3F4-B65701BA9BD8@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFA BFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940853d02039a1ea450ff982ed6b5a3f023350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:34:43 -0000 --Apple-Mail-11--806559728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 4, 2011, at 7:03 PM, Lorenzo Colitti wrote: > On Thu, Aug 4, 2011 at 15:45, Michael Newbery = wrote: > I disagree. The Web is not the Internet. As soon as any significant = number (and I suspect a number as little as 5%) of clients are IPv6 = only, and direct communication is required, then the IPv6 have nots will = start demanding action from their ISP. >=20 > I can't imagine my family, my friends or anyone outside the industry = ever calling their ISP asking why they don't have IPv6.=20 Perhaps not. But calling their ISP to ask "Why can't I run Irritated = Avian Carriers? I downloaded the app but it says I need something = called ipveesix, and I should call my ISP and ask for it." is at least a = distant possibility. That assumes, of course, that there's enough IPv6 market _somewhere_ to = allow such an app to gain a following. For instance, if educational = institutions generally had IPv6 and students got exposed to interesting = IPv6-only apps, they'd demand those same applications in their homes and = workplaces after leaving academia. Granted, this is somewhat of a longshot. But it's why I and a few = others are still interested in better methods of providing IPv6 service = over the existing IPv4 infrastructure.=20 Keith p.s. I remember when telcos didn't think anyone would actually want to = use the Internet in preference to services that the telcos would = provide. They kept mumbling something about lack of guaranteed service. --Apple-Mail-11--806559728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Thu, Aug 4, 2011 at 15:45, Michael Newbery = <newbery@gmail.com> = wrote:
I = disagree. The Web is not the Internet. As soon as any = significant number (and I suspect a number as little as 5%) of = clients are IPv6 only, and direct communication is required, then the = IPv6 have nots will start demanding action from their ISP.

I can't imagine my family, = my friends or anyone outside the industry ever calling their ISP asking = why they don't have = IPv6. 

Perhaps not. =  But calling their ISP to ask "Why can't I run Irritated Avian = Carriers?  I downloaded the app but it says I need something called = ipveesix, and I should call my ISP and ask for it." is at least a = distant possibility.

That assumes, of course, = that there's enough IPv6 market _somewhere_ to allow such an app to gain = a following.  For instance, if educational institutions generally = had IPv6 and students got exposed to interesting IPv6-only apps, they'd = demand those same applications in their homes and workplaces after = leaving academia.

Granted, this is somewhat of = a longshot.  But it's why I and a few others are still interested = in better methods of providing IPv6 service over the existing IPv4 = infrastructure. 

Keith

<= div>p.s. I remember when telcos didn't think anyone would actually want = to use the Internet in preference to services that the telcos would = provide.  They kept mumbling something about lack of guaranteed = service.

= --Apple-Mail-11--806559728-- From dwcarder@wisc.edu Thu Aug 4 19:26:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7186C11E809B for ; Thu, 4 Aug 2011 19:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDNny7sh42LM for ; Thu, 4 Aug 2011 19:26:40 -0700 (PDT) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id DD91311E807C for ; Thu, 4 Aug 2011 19:26:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LPF00F02O4V8R00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Thu, 04 Aug 2011 21:26:55 -0500 (CDT) Received: from [192.168.0.6] (66-188-112-13.dhcp.mdsn.wi.charter.com [66.188.112.13]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LPF00B2QO4TBV10@smtpauth3.wiscmail.wisc.edu>; Thu, 04 Aug 2011 21:26:54 -0500 (CDT) Date: Thu, 04 Aug 2011 21:26:53 -0500 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and wrapped. From: "Dale W. Carder" In-reply-to: <87805FCB-A7A9-43AE-ACA7-9524B5944272@apple.com> To: james woodyatt Message-id: X-Mailer: Apple Mail (2.1084) X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.5.21815, SenderIP=192.168.0.6 References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB-A7A9-43AE-ACA7-9524B5944272@apple.com> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:26:41 -0000 On Aug 4, 2011, at 4:00 PM, james woodyatt wrote: > > Finally, if you provision your networks so that IPv4 and IPv6 exhibit "roughly equivalent" levels of path latency and congestion, then we're going to try very, very hard to use both IPv4 and IPv6 in "roughly equivalent" measure. That could end up causing a lot of headache. I personally believe it will be a horrible path for Internet engineering to follow when we know, today, that this could be a very, very bad host behavior. > When the additional costs of having IPv4 service available alongside IPv6 are passed along to subscribers Just like how Internet != http, this economic model is similarly limited in applicability. For example, I do some work for a regional ISP that doesn't do billing. It also may not be applicable for many enterprises. > Until then, I recommend trying to get used to the new tactical environment. It's going to be with us for a long while yet to come. And this approach may *exacerbate* the problem by treating the address families as equal when v4 will truly be encumbered. Dale From drc@virtualized.org Thu Aug 4 19:49:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404021F8561 for ; Thu, 4 Aug 2011 19:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRv9NOjDg1dS for ; Thu, 4 Aug 2011 19:49:26 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [IPv6:2607:fc50:1000:9700::dead:beef]) by ietfa.amsl.com (Postfix) with ESMTP id 42E9221F8560 for ; Thu, 4 Aug 2011 19:49:25 -0700 (PDT) Received: from [10.0.1.10] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (authenticated bits=0) by trantor.virtualized.org (8.14.4/8.14.4) with ESMTP id p74HNnEA019588 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NOT); Thu, 4 Aug 2011 17:23:51 GMT (envelope-from drc@virtualized.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20110804115542.GC5008@srv03.cluenet.de> Date: Thu, 4 Aug 2011 07:26:09 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <004C2CB8-C17E-4177-87DA-9BE8408887EF@virtualized.org> References: <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> <20110804115542.GC5008@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1244.3) Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:49:26 -0000 On Aug 4, 2011, at 1:55 AM, Daniel Roesen wrote: > On Thu, Aug 04, 2011 at 02:10:11PM +1000, George Michaelson wrote: >> Lion has been out precisely <1month, and has had one update already. >=20 > http://fud.no/ipv6/gnuplot/osxversions.png >=20 > 25% of the user base observed by Tore are not even on 10.6. I suspect a significant portion of that 25% is running PowerPC = architecture (and hence unable to move to anything above 10.5 despite = how much they might like to). I'm guessing Apple will not be changing = this situation, so that portion of the 25% will probably have a long = tail (as machines die and/or migrate to PowerPC versions of *BSD or = Linux). > No they don't - at least not always, as far as I'm told. People have = to pay for 10.7. Yes. US$30 for up to 5 machines (at least in the US). =20 Regards, -drc From phdgang@gmail.com Thu Aug 4 19:55:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2321F866A; Thu, 4 Aug 2011 19:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlYZYRrjoF+P; Thu, 4 Aug 2011 19:55:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50E3721F859F; Thu, 4 Aug 2011 19:55:30 -0700 (PDT) Received: by vws12 with SMTP id 12so1205745vws.31 for ; Thu, 04 Aug 2011 19:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dWqnDSSNTlSyWppiuKPD0X3NdfHc0UdcsH2aBxMr4rg=; b=E9JUw/Gp/xSaGw0XdAtl+rPsEpryScFSD1ASNJCWOp0YWdgBDmP/yJaCdZ1Xt1kd0l KP0JeqY5xKDSMSyLy3eCX66hpW0g/TuCG/sefj1cRBcgar4F6YObyem8ewkOZ+Eavx6z EGc7ob+dvp1NRjz6jEMylU5+RNMB7uttqDNZU= MIME-Version: 1.0 Received: by 10.52.177.195 with SMTP id cs3mr1652697vdc.185.1312512946318; Thu, 04 Aug 2011 19:55:46 -0700 (PDT) Received: by 10.52.169.129 with HTTP; Thu, 4 Aug 2011 19:55:46 -0700 (PDT) In-Reply-To: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> Date: Fri, 5 Aug 2011 10:55:46 +0800 Message-ID: From: GangChen To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:55:31 -0000 Hello Authors, I think it is worth adding some texts to describe mobile CPE case, in which CPEs with wireless modem use 3GPP access as uplink. Gang 2011/8/2, The IESG : > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'IPv6 in 3GPP Evolved Packet System' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Use of data services in smart phones and broadband services via HSPA > and HSPA+, in particular Internet services, has increased rapidly and > operators that have deployed networks based on 3GPP network > architectures are facing IPv4 address shortages at the Internet > registries and are feeling a pressure to migrate to IPv6. This > document describes the support for IPv6 in 3GPP network > architectures. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jhw@apple.com Thu Aug 4 20:01:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CFF21F877B for ; Thu, 4 Aug 2011 20:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Jmj94g6aONc for ; Thu, 4 Aug 2011 20:01:15 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1AF21F8777 for ; Thu, 4 Aug 2011 20:01:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LPF00INVPPYHOD2@mail-out.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 20:01:23 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-f3-4e3b5ca81602 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 1F.3C.04993.9AC5B3E4; Thu, 04 Aug 2011 19:59:53 -0700 (PDT) Received: from 67-218-110-254.cust.layer42.net (67-218-110-254.cust.layer42.net [67.218.110.254]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPF00B9YPQ70WA0@cardamom.apple.com> for v6ops@ietf.org; Thu, 04 Aug 2011 20:01:23 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: Date: Thu, 04 Aug 2011 20:01:19 -0700 Message-id: <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB-A7A9-43A@apple.com> To: "Dale W. Carder" X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUiON1OVXdljLWfwf4ZfBanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpNPP9kKelkq3mz+xdbAuIi5i5GTQ0LARGLVm1dQtpjEhXvr 2UBsIYFWJonepekgNq+AoMSPyfdYuhg5OJgF5CUOnpcFCTMLaEl8f9TKAlF+nEliSUsZiC0s ECDxqXEfC4QdI/Fq3m4wm01AReLb5btMIDangI3E50+3GUFsFgFViWPXjrNBzHSSWLvoOSPE WhuJi1P2A9lcQPOncki8n7GYHSQhIqAhcbhjISvEzfISi1s+M05gFJyF5NRZCKfOQnLqAkbm VYyCRak5iZWGhnqJBQU5qXrJ+bmbGEHh2FBosINx7U/+Q4wCHIxKPLw/dln5CbEmlhVX5h5i lOBgVhLhrWSw9hPiTUmsrEotyo8vKs1JLT7EKM3BoiTOO++DmZ+QQHpiSWp2ampBahFMlomD U6qBcRWPZKHF3Prux3ZXb728sNNIPpaJ4+2v3APuR3Z48ly/3W6wNee1cfvnD5E8hxTf111r rDP6Ux4yT2WZUgTHvx/M9qsuuU3bpnNyUvfS5VPP8gX9S1x655PtvRRBNaVy3X3HHuzxYXgj F2nvJzipK9BORHz5jG6T7nS+iX8C3nYVCW2Pen0kTYmlOCPRUIu5qDgRAN3vvuhDAgAA Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:01:15 -0000 On Aug 4, 2011, at 7:26 PM, Dale W. Carder wrote: > > That could end up causing a lot of headache. How? Please be specific. The behavior we have now is proven to alleviate the killer throw-your-Macbook-at-the-wall migraine headaches that a lot of our paying customers have been complaining about quite publicly, and I'm not going to get very far inside Apple toward undoing what we've done without more technical detail. -- james woodyatt member of technical staff, core os networking From moore@network-heretics.com Thu Aug 4 20:37:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D911E809B for ; Thu, 4 Aug 2011 20:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B00OkWRXDmz for ; Thu, 4 Aug 2011 20:37:18 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2721F85C7 for ; Thu, 4 Aug 2011 20:37:18 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QpBE3-0007y1-2p; Thu, 04 Aug 2011 23:37:31 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> Date: Thu, 4 Aug 2011 23:37:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5740931A-1202-48B8-87D3-805B71974AE2@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402e9018c330d6ac0757e0e1d12940ddcd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:37:18 -0000 On Aug 4, 2011, at 11:01 PM, james woodyatt wrote: > On Aug 4, 2011, at 7:26 PM, Dale W. Carder wrote: >>=20 >> That could end up causing a lot of headache. >=20 > How? Please be specific. >=20 > The behavior we have now is proven to alleviate the killer = throw-your-Macbook-at-the-wall migraine headaches that a lot of our = paying customers have been complaining about quite publicly, and I'm not = going to get very far inside Apple toward undoing what we've done = without more technical detail. I can think of cases where IPv4 will work better than many kinds of IPv6 = service that we're likely to see anytime soon - e.g. large UDP/IPv6 = packets that are tunneled over IPv4 over Ethernet (or worse, PPPoE) = somewhere along the way. PMTUD helps but can't always fix these issues. I can think of cases where IPv6 will often, or even always, work better = than IPv4 no matter what the relative performance of the two links, e.g. = applications that do address referrals over NAT. A metric that measures the behavior of a network path for one type of = application may be very poor at predicting the behavior of a network = path for a different application. Some apps are latency sensitive, = some are bandwidth sensitive, some are jitter sensitive, and some are = NAT sensitive. =20 But the clever API does not strike me as a problem as long as developers = understand what the clever API optimizes for, i.e., when to use the = clever API and when not to use it. I'm very much in agreement with the idea that if you want hosts and = applications to minimize use of the path through the NAT, pessimize the = path through the NAT. There are lots of ways to do that - add delay, = randomly drop X% of SYN packets, etc.. You can even make the amount of = pessimization adjustable, so that you can start out at zero and tweak = the amount of pessimization over time to minimize the rate of support = calls and/or reduce the cost associated with the NAT. But don't expect = hosts or apps to second guess what the network is doing as a matter of = global policy; let them adapt to the specific network situation that = they find themselves in. A path selection policy that works well in = your network might not work so well in a different network. Keith From marka@isc.org Thu Aug 4 20:38:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB28C21F847D for ; Thu, 4 Aug 2011 20:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiE90uNiFl+v for ; Thu, 4 Aug 2011 20:38:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 379E221F8451 for ; Thu, 4 Aug 2011 20:38:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 260615F988D; Fri, 5 Aug 2011 03:38:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EF828216C80; Fri, 5 Aug 2011 03:38:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C44B4127714F; Fri, 5 Aug 2011 13:38:06 +1000 (EST) To: james woodyatt From: Mark Andrews References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> In-reply-to: Your message of "Thu, 04 Aug 2011 20:01:19 MST." <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> Date: Fri, 05 Aug 2011 13:38:06 +1000 Message-Id: <20110805033806.C44B4127714F@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:38:13 -0000 In message <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com>, james woodyatt wri tes: > On Aug 4, 2011, at 7:26 PM, Dale W. Carder wrote: > > > > That could end up causing a lot of headache. > > How? Please be specific. > > The behavior we have now is proven to alleviate the killer throw-your-Macbook > -at-the-wall migraine headaches that a lot of our paying customers have been > complaining about quite publicly, and I'm not going to get very far inside Ap > ple toward undoing what we've done without more technical detail. James, I've got a Mac Book, running 10.6.8, wireless keyboard and trackpad, external monitor. I sit in front of it 8+ hours day. It migrates to the lounge room for several more hours many evenings. A couple of weeks ago the IPv6 path between home and the IETF servers was stuffed for over a week. Safari was unusable for reaching the IETF site because it took too long to fail over to IPv4 and it didn't remember that it failed with IPv6. Google Chrome on the other hand was fine, a slight pause and off it went using IPv4. I don't think what been done needs to be undone. It just needs to be tuned slightly differently. Mark > -- > james woodyatt > member of technical staff, core os networking > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Thu Aug 4 22:39:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8C21F8AD8 for ; Thu, 4 Aug 2011 22:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDFgXObff-Zd for ; Thu, 4 Aug 2011 22:39:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB6121F8AD6 for ; Thu, 4 Aug 2011 22:39:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5F6339C; Fri, 5 Aug 2011 07:39:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5945B9A; Fri, 5 Aug 2011 07:39:55 +0200 (CEST) Date: Fri, 5 Aug 2011 07:39:55 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:39:44 -0000 On Thu, 4 Aug 2011, Lorenzo Colitti wrote: > I can't imagine my family, my friends or anyone outside the industry > ever calling their ISP asking why they don't have IPv6. You might as > well assert that users will call their ISP asking for PPPoA over PPPoE > because it has less overhead. I don't agree. If I tell my mom that unless she gets a connection with IPv6 she won't be able to see her grandchild in high quality in , she will get a connection with IPv6. Personally I've had heaps of problems getting some video applications working when both parties were behind NAT, but since I work for an ISP I was actually able to make sure I got a larger GUA block at my end which made it work just fine. Most other people are not so fortunate. Now, if just would support IPv6, that would be great :P -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Aug 4 22:58:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202105E8005 for ; Thu, 4 Aug 2011 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlMPCRhwFXXe for ; Thu, 4 Aug 2011 22:58:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA055E8006 for ; Thu, 4 Aug 2011 22:58:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CBC49C; Fri, 5 Aug 2011 07:58:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7A6DD9A; Fri, 5 Aug 2011 07:58:55 +0200 (CEST) Date: Fri, 5 Aug 2011 07:58:55 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> Message-ID: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:58:40 -0000 On Thu, 4 Aug 2011, james woodyatt wrote: > Isn't this what traffic engineers have been clamoring at us for years to > give them? I don't know who told you this, but personally I consider a NAT box to warrant a penalty when that path is considered. As an ISP, when we consider implementing IPv6 we factor in the saving of not having to do IPv4 CGN for some of the traffic, and this factor should increase over time. This has been true all along but now it's changed. All along, the discussion regarding happy eyeballs have been (as far as I could discern) that IPv6 would still be preferred, and HE was going to be used to work around broken IPv6 connectivity. IPv4 would have a configurable penalty, and by default this penalty would be set to "medium" (50-200ms or so). NAT makes the connectivity worse, I don't understand why this wouldn't be a factor in protocol choice for outgoing connections. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Thu Aug 4 23:27:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61B45E800C for ; Thu, 4 Aug 2011 23:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AdQcnLmsxDr for ; Thu, 4 Aug 2011 23:27:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 057E65E8007 for ; Thu, 4 Aug 2011 23:27:11 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p756ROLq022965 for ; Thu, 4 Aug 2011 23:27:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312525644; bh=Q/+FfhE0xRmFcynV6J3fYJSnXOw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oSGaT5Na4FMaFzBMtULnR98KerePSbaW5n1hHJr+59+h6tTYQxHPFiEDGp0kbESDh e/LvZIhIJa+JYSdSUnyLA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Zj3TqpV1GtBoiF6rYIraa5AJlv4+TovyZoO7jRN5GFSU7yZpTU/AWzF4ACdFBmuov UcEEleCrjx2CgX6bcj+6Q== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by wpaz17.hot.corp.google.com with ESMTP id p756R3S3017292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 23:27:23 -0700 Received: by gwj17 with SMTP id 17so1656141gwj.38 for ; Thu, 04 Aug 2011 23:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eSPkhVV9H3xNXnzTqOnGrtGfgybUQjdo77+PlfaU/hQ=; b=rHD9q/TNW2hoVormPGhvdPQHjSKJdkDKn4Zc7sAhREiAGIlZfHuqo2F5rK70swFTpY T82U3Hk3S1241ON90Png== Received: by 10.151.50.15 with SMTP id c15mr2842613ybk.285.1312525643223; Thu, 04 Aug 2011 23:27:23 -0700 (PDT) Received: by 10.151.50.15 with SMTP id c15mr2842608ybk.285.1312525643095; Thu, 04 Aug 2011 23:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Thu, 4 Aug 2011 23:27:03 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> From: Lorenzo Colitti Date: Thu, 4 Aug 2011 23:27:03 -0700 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001517570906b720e104a9bc3034 X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 06:27:12 -0000 --001517570906b720e104a9bc3034 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 4, 2011 at 22:39, Mikael Abrahamsson wrote: > I don't agree. If I tell my mom that unless she gets a connection with IPv6 > she won't be able to see her grandchild in high quality in application here>, she will get a connection with IPv6. > [...] > Now, if just would support IPv6, > that would be great :P And there you have the fallacy of the argument. You say that users will ask for IPv6 to use cool apps, and barely three lines later you say that those cool apps don't support IPv6. --001517570906b720e104a9bc3034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4, 2011 at 22:39, Mikael Abrahamsson= <swmike@swm.pp.se= > wrote:
I don't agree. If I tell my mom that unless she gets = a connection with IPv6 she won't be able to see her grandchild in high = quality in <insert video application here>, she will get a connection= with IPv6.
[...]
Now, if just <insert almost any video application here> would support= IPv6, that would be great :P

And there you= have the fallacy of the argument. You say that users will ask for IPv6 to = use cool apps, and barely three lines later you say that those cool apps do= n't support IPv6.
--001517570906b720e104a9bc3034-- From lorenzo@google.com Thu Aug 4 23:27:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031F11E8093 for ; Thu, 4 Aug 2011 23:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.907 X-Spam-Level: X-Spam-Status: No, score=-105.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yRGh1ygK0MV for ; Thu, 4 Aug 2011 23:27:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EBCF611E8073 for ; Thu, 4 Aug 2011 23:27:13 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p756RTKM005612 for ; Thu, 4 Aug 2011 23:27:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312525650; bh=6g6zfVdF3ThMMHPPLglDydWiGH8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tcZ8yQdo5BiIZVt6pbCOj3vJrU+BrsQF5hdrgjbY0m37mrumDUVYlc1Y4PsPDDbgv /1p9FeXaiYjzNyaNduk+g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=TgphXE5Hia/+kHzxOKfz931Db0eG1Zx5oqjcPUTKwW9L4vR9CSm4IRxK+Ugzv2B+5 vYI//vOQmE9xx467PsXJQ== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq11.eem.corp.google.com with ESMTP id p756R4ga011145 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 23:27:28 -0700 Received: by yib12 with SMTP id 12so1665631yib.24 for ; Thu, 04 Aug 2011 23:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZQNA0cDQp3HKmnJMS8q9QQULR6DSYCHvH71GOdi2GGU=; b=aqT5Wq7jogeuqbTREHFX3SipSXpq5NvnsvMiT2EMFjbaxzP/YYLsJ+SYhlfDprHpI2 SLEsJBRG1M50dFHcwunA== Received: by 10.151.99.8 with SMTP id b8mr2741171ybm.342.1312525648233; Thu, 04 Aug 2011 23:27:28 -0700 (PDT) Received: by 10.151.99.8 with SMTP id b8mr2741167ybm.342.1312525648108; Thu, 04 Aug 2011 23:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Thu, 4 Aug 2011 23:27:08 -0700 (PDT) In-Reply-To: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> From: Lorenzo Colitti Date: Thu, 4 Aug 2011 23:27:08 -0700 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001517511476039ece04a9bc3178 X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 06:27:14 -0000 --001517511476039ece04a9bc3178 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 4, 2011 at 22:58, Mikael Abrahamsson wrote: > As an ISP, when we consider implementing IPv6 we factor in the saving of > not having to do IPv4 CGN for some of the traffic, and this factor should > increase over time. This has been true all along but now it's changed. > It hasn't changed. Fortunately for you, most of your traffic will be from Windows machines, and some Mac traffic will be using Firefox or Chrome, so only a small part of it will prefer IPv4 if there is working IPv6 present. I agree that if all implementations behaved like Safari on Lion, transitioning to IPv6 would be that much more difficult. --001517511476039ece04a9bc3178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4, 2011 at 22:58, Mikael Abrahamsson= <swmike@swm.pp.se= > wrote:
As an ISP, when we consider implementing IPv6 we factor i= n the saving of not having to do IPv4 CGN for some of the traffic, and this= factor should increase over time. This has been true all along but now it&= #39;s changed.

It hasn't changed. Fortunately for you= , most of your traffic will be from Windows machines, and some Mac traffic = will be using Firefox or Chrome, so only a small part of it will prefer IPv= 4 if there is working IPv6 present.

I agree that if all implementations behaved like Safari= on Lion, transitioning to IPv6 would be that much more difficult.
--001517511476039ece04a9bc3178-- From jounikor@gmail.com Thu Aug 4 23:55:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A034A11E8085; Thu, 4 Aug 2011 23:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOXEkHPj1NDu; Thu, 4 Aug 2011 23:55:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB2311E807F; Thu, 4 Aug 2011 23:55:18 -0700 (PDT) Received: by fxe6 with SMTP id 6so3134868fxe.31 for ; Thu, 04 Aug 2011 23:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bo3r2gvEr7T+Yws8RGXqWKGIEA/RdjMIRPUbwJMFF8o=; b=Bhm+GdW3mqpucuLGa+CYy0Yp6jGEIQvh/anehD2ZSWYfD8JM9Dlm5ioTrbUfbvhwy4 SEg1UEd8ZyM6rgiQ+BVBMI+ULXYLawG4mG7RbBFzcPjKVipFUb8+aeV0AqYJiR+q3erY BWRsJQhDVpe//GwIR8RNu4D+7cZGJuQ7SlLhc= Received: by 10.204.142.143 with SMTP id q15mr589342bku.321.1312527334358; Thu, 04 Aug 2011 23:55:34 -0700 (PDT) Received: from a88-114-68-66.elisa-laajakaista.fi (a88-114-68-66.elisa-laajakaista.fi [88.114.68.66]) by mx.google.com with ESMTPS id p24sm756251bkw.41.2011.08.04.23.55.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 23:55:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Fri, 5 Aug 2011 09:55:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> To: GangChen X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Fri, 05 Aug 2011 00:18:07 -0700 Cc: v6ops@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 06:55:19 -0000 Dear Gang, I would be inclined to say that within the 3GPP scope the client is = always the "UE" and its form factor or the end usage scenario does not = really matter. It does not change the way the UE is expected to behave = from the 3GPP system point of view, unless there is a new functional = requirement from 3GPP. - Jouni On Aug 5, 2011, at 5:55 AM, GangChen wrote: > Hello Authors, >=20 > I think it is worth adding some texts to describe mobile CPE case, in > which CPEs with wireless modem use 3GPP access as uplink. >=20 > Gang >=20 >=20 > 2011/8/2, The IESG : >>=20 >> The IESG has received a request from the IPv6 Operations WG (v6ops) = to >> consider the following document: >> - 'IPv6 in 3GPP Evolved Packet System' >> as an Informational RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> Use of data services in smart phones and broadband services via = HSPA >> and HSPA+, in particular Internet services, has increased rapidly = and >> operators that have deployed networks based on 3GPP network >> architectures are facing IPv4 address shortages at the Internet >> registries and are feeling a pressure to migrate to IPv6. This >> document describes the support for IPv6 in 3GPP network >> architectures. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From jounikor@gmail.com Fri Aug 5 00:15:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445385E800C; Fri, 5 Aug 2011 00:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM5citeET4z4; Fri, 5 Aug 2011 00:15:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE745E8007; Fri, 5 Aug 2011 00:15:54 -0700 (PDT) Received: by fxe6 with SMTP id 6so3155136fxe.31 for ; Fri, 05 Aug 2011 00:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=KeH08X5+N7kuvxthmyNkERoqG79a4MI2t2v4BXPRFsQ=; b=PUrg4YXInLFuHc/EeK2GN6WT+y26U+DxUa5OEDbKPZDKV432Uxx/nkmMfhZUtUJKpH rmPgCvtqJh+3+SFcve9dAaNfiWREH7l+LhljXW//bDsO5sQRJhc+EWnaqgOFCgShUN/z vVAlbu5VkJPoerShOKN4oDhSjjqzb9YMvJFpg= Received: by 10.204.135.18 with SMTP id l18mr569696bkt.191.1312528562814; Fri, 05 Aug 2011 00:16:02 -0700 (PDT) Received: from a88-114-68-66.elisa-laajakaista.fi (a88-114-68-66.elisa-laajakaista.fi [88.114.68.66]) by mx.google.com with ESMTPS id s14sm760005bkw.52.2011.08.05.00.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 00:16:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Jouni In-Reply-To: Date: Fri, 5 Aug 2011 10:15:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> To: ietf@ietf.org, IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Fri, 05 Aug 2011 00:18:07 -0700 Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:15:55 -0000 I got one comment to our draft. Section 5.4 discusses some known = neighbor discovery issues out there. I forgot to add one that I believe = belongs here or then in Section 5.2; which one I am not sure yet. In = Section 5.2 it is said that the GGSN/PGW provides an unique IID to the = UE (i.e. guaranteed not to collide with GGSN/PGW's one) for the = link-local address configuration. However, numerous modem drivers today = fail (or don't even care) to deliver the received IID to the host OS = stack and instead the driver comes up with its own (usually some = imaginary MAC address based one..). Therefore, there is theoretical but = very unlikely chance for link-local address collision between the UE and = the gateway on the 3GPP link. Since the UE may or may not perform DAD = this can be unnoticed during the address configuration phase. - Jouni 2011/8/2, The IESG : >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'IPv6 in 3GPP Evolved Packet System' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Use of data services in smart phones and broadband services via HSPA > and HSPA+, in particular Internet services, has increased rapidly = and > operators that have deployed networks based on 3GPP network > architectures are facing IPv4 address shortages at the Internet > registries and are feeling a pressure to migrate to IPv6. This > document describes the support for IPv6 in 3GPP network > architectures. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From swmike@swm.pp.se Fri Aug 5 00:20:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7720A11E807F for ; Fri, 5 Aug 2011 00:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-I4c45vF3Hg for ; Fri, 5 Aug 2011 00:19:59 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9257D11E8073 for ; Fri, 5 Aug 2011 00:19:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 625ED9C; Fri, 5 Aug 2011 09:20:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5F0579A; Fri, 5 Aug 2011 09:20:15 +0200 (CEST) Date: Fri, 5 Aug 2011 09:20:15 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> <093239A0-7153-4240-AB43-E96AFFD7E782@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:20:00 -0000 On Thu, 4 Aug 2011, Lorenzo Colitti wrote: > And there you have the fallacy of the argument. You say that users will > ask for IPv6 to use cool apps, and barely three lines later you say that > those cool apps don't support IPv6. I still have high hopes that they will gain support in the not so distant future. When I read your earlier email it seemed like you indicated that you thought users would *never* ask for IPv6. I think they will, and it'll start in a year or two. -- Mikael Abrahamsson email: swmike@swm.pp.se From pch-b29AA871B@u-1.phicoh.com Fri Aug 5 01:10:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B575D21F8BCB for ; Fri, 5 Aug 2011 01:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.27 X-Spam-Level: X-Spam-Status: No, score=-8.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVCrWApFBCMu for ; Fri, 5 Aug 2011 01:10:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id ED09521F8B6B for ; Fri, 5 Aug 2011 01:10:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QpFUq-0001ipC; Fri, 5 Aug 2011 10:11:08 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> In-reply-to: Your message of "Thu, 04 Aug 2011 20:01:19 -0700 ." <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> Date: Fri, 05 Aug 2011 10:10:58 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:10:58 -0000 In your letter dated Thu, 04 Aug 2011 20:01:19 -0700 you wrote: >On Aug 4, 2011, at 7:26 PM, Dale W. Carder wrote: >> >> That could end up causing a lot of headache. > >How? Please be specific. > >The behavior we have now is proven to alleviate the killer throw-your-Macbook- >at-the-wall migraine headaches that a lot of our paying customers have been co >mplaining about quite publicly, and I'm not going to get very far inside Apple > toward undoing what we've done without more technical detail. So what it boils down to is that Apple came up with their own HE implementation without telling anybody or asking for feedback. And now that they have shipped it, it has to be defended as being the best solution. Sad, but that's usually how it works. There is no way that a slight preference for IPv6 is going result in 'throw-your-Macbook-at-the-wall migraine headaches' when Chrome and Firefox have been shipping with quite crude HE implementations with a much stronger IPv6 preference and (to the extent that they actually know about it) people are happy. From pch-b29AA871B@u-1.phicoh.com Fri Aug 5 01:22:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9223821F8B20 for ; Fri, 5 Aug 2011 01:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.311 X-Spam-Level: X-Spam-Status: No, score=-8.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6cZhlgjyDra for ; Fri, 5 Aug 2011 01:22:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 63C9321F8BA2 for ; Fri, 5 Aug 2011 01:22:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QpFfq-0001iWC; Fri, 5 Aug 2011 10:22:30 +0200 Message-Id: To: Shane Amante From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <0BAE30AF-2E35-493E-A2CE-5FFABFAACD8A@apple.com> <034720BC-5F0D-48CA-83FB-277E850585F0@castlepoint.net> In-reply-to: Your message of "Thu, 4 Aug 2011 18:45:03 -0600 ." <034720BC-5F0D-48CA-83FB-277E850585F0@castlepoint.net> Date: Fri, 05 Aug 2011 10:22:19 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:22:27 -0000 In your letter dated Thu, 4 Aug 2011 18:45:03 -0600 you wrote: >For example, if somehow an operator were able to _dynamically_ [and more = >strongly] hint to end-hosts that native IPv6 is preferred compared to = >IPv4, then _at the right time in the near future_ this would allow = >operators to start signaling to hosts, on an per-Metro or per-region (?) = >basis, that they believe a good quality, good performance, etc. = >deployment of IPv6 exists (in the access, the Backbone and = >peering/interconnect portions of the network) and they want hosts to = >start originating packets using IPv6, when possible. This would also, = >potentially, absolve host stack vendors from making a difficult and/or = >wrong call on a single, static address selection policy and, instead, = >point the blame & pain of an address selection policy firmly back at the = >ISP, where it belongs. :-)=20 I'm not sure in what situation that option would be required. Let's assume that client operatings ship with a Happy Eyeballs implementation with a slight preference for IPv6 then: 1) If the user doesn't have any kind of IPv6 it doesn't matter whether IPv6 is preferred or not. 2) If an ISP provides IPv6 and believes it actually works, then nothing needs to be doen because the systems already prefer IPv6. 3) If an ISP provides IPv6 but believes that it is broken, then this option would be useful. 4) The ISP doesn't provide IPv6 and doesn't want customers to have any other kind of IPv6 either (through tunnels). 4) doesn't make any sense (it may make sense in a corporate environment). So 3) would be the only use case. Other than may be a brief period during testing, I sort of can't imagine ISPs rolling out IPv6 and telling systems not to use it because it doesn't actually work. So, we end up with the first two cases, where from the ISP's perspective, IPv6 should be preferred. From Ray.Bellis@nominet.org.uk Fri Aug 5 03:28:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA41021F8B76 for ; Fri, 5 Aug 2011 03:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.308 X-Spam-Level: X-Spam-Status: No, score=-7.308 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scx9gXgw3I22 for ; Fri, 5 Aug 2011 03:28:35 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5919721F8AD8 for ; Fri, 5 Aug 2011 03:28:33 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=eLukzjoGphC+MxtTTKVihvRBD5/IszR7P613snP2UI4xaPB/HmnrmR44 TRRlkRqsS4mOH1xN0XIsUDEsmUMopdyybLMJhn3PQw6BWUKQDPZQSenAo 8y0fmlGDaRZyKZ2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1312540133; x=1344076133; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[v6ops]=20Lion/Snow=20Leaopard=20side-b y-side=20on=20an=20IPv6=09enabled=0D=0A=09ADSL2+=20home =20line..|Date:=20Fri,=205=20Aug=202011=2010:28:47=20+000 0|Message-ID:=20<24FAA902-28E9-4A50-B7B8-2E958D20F897@nom inet.org.uk>|To:=20George=20Michaelson=20|CC:=20"v6ops@ietf.org"=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20<4E3A4994.40606 06@globis.net>=0D=0A=20<2A58D1AC-5AFE-4118-BFC3-3C5FE1F50 63C@apnic.net>=0D=0A=20<20110804092031.GA26186@srv03.clue net.de>=0D=0A=20; bh=HqBhJcNFH+oEmeEANNuaeh1veuRRiuM7vmkVu7qT1fU=; b=LVu63y5RMWefMlcyTpFTUnOaevlkJu1lACIyNX9jtATJdHQk+R0jOFuC 9m7lVWETze4RtgxBv/KMDrxV2T2sfAGvte2RoWRMx+Toij1UHArU8WySw vq8DDNIvdyGoH1y; X-IronPort-AV: E=Sophos;i="4.67,322,1309734000"; d="scan'208,217";a="34557056" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Aug 2011 11:28:48 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 5 Aug 2011 11:28:48 +0100 From: Ray Bellis To: George Michaelson Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Thread-Index: AQHMUofVjn5uSvgTmEaH7/kxJBPj6JUMZZ8AgAGZeIA= Date: Fri, 5 Aug 2011 10:28:47 +0000 Message-ID: <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_24FAA90228E94A50B7B82E958D20F897nominetorguk_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:28:39 -0000 --_000_24FAA90228E94A50B7B82E958D20F897nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 4 Aug 2011, at 11:03, George Michaelson wrote: I believe that coding systems to explore 4 and 6, and based on hysteresis, = some heuristics, measurements and held state in a kernel or routing table o= r some other construct, decide a preference case-by-case is fine. Perhaps we should repurpose the IPv4 evil bit as an indication of a path th= at is not "end-to-end" transparent ;-) i.e.: "An IPv4 NATing device MUST set the evil bit on all packets to which it has= applied NAT. All else being equal, a client SHOULD prefer an IPv6 path ov= er an IPv4 path that has the evil bit set." [only half kidding] Ray --_000_24FAA90228E94A50B7B82E958D20F897nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 4 Aug 2011, at 11:03= , George Michaelson wrote:

I believe that coding sy= stems to explore 4 and 6, and based on hysteresis, some heuristics, measure= ments and held state in a kernel or routing table or some other construct, = decide a preference case-by-case is fine.


Perhaps we should repurpose the IPv4 evil bit as an indication of a= path that is not "end-to-end" transparent ;-)

i.e.:

"An IPv4 NATing device MUST set = the evil bit on all packets to which it has applied NAT.  All else bei= ng equal, a client SHOULD prefer an IPv6 path over an IPv4 path that has th= e evil bit set."

[only half kidding]

Ray

= --_000_24FAA90228E94A50B7B82E958D20F897nominetorguk_-- From Ray.Bellis@nominet.org.uk Fri Aug 5 03:49:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0010121F8BB8 for ; Fri, 5 Aug 2011 03:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.267 X-Spam-Level: X-Spam-Status: No, score=-9.267 tagged_above=-999 required=5 tests=[AWL=1.332, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycIESdgkaV0a for ; Fri, 5 Aug 2011 03:49:08 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 912F321F856B for ; Fri, 5 Aug 2011 03:49:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=GCxMt42DTtQ34+0PIe+n1TVBKN6mMNGVskryfLoxn/86DD+FGhCEOOAS TCWXgDuPb2537BIwr9P+a5COodgONbd89Mv94RExGdZPR2KLPWO+lXBCj fslY9tIrF0uk8IK; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1312541366; x=1344077366; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[v6ops]=20Lion/Snow=20Leaopard=20side-b y-side=20on=20an=09IPv6=09enabled=0D=0A=09ADSL2+=20home =20line..|Date:=20Fri,=205=20Aug=202011=2010:49:23=20+000 0|Message-ID:=20|To:=20"v6ops@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<24FAA902-28E9-4A50-B7B8-2E958D20F89 7@nominet.org.uk>|References:=20<4E3A4994.4060606@globis. net>=0D=0A=20<2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic. net>=0D=0A=20<20110804092031.GA26186@srv03.cluenet.de>=0D =0A=20=0D =0A=20<24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.u k>; bh=yXVyNfjmgSif5cH8as0bVTR/79lvyVzG/muzzOUJ3UQ=; b=s93D3lgKHxeXnYgE8r1rD3wRbKPLc6HXOua4O77jKxZGlcKHUpxCLwqu Kbtp1uJwf5JNbMuegrL75VW2VBiGwSZz6x9usGrPUNRvFr9jFA3gXTuEe eNRBqTSUhpbNy1o; X-IronPort-AV: E=Sophos;i="4.67,322,1309734000"; d="scan'208";a="27694523" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Aug 2011 11:49:24 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 5 Aug 2011 11:49:24 +0100 From: Ray Bellis To: "v6ops@ietf.org" Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Thread-Index: AQHMU11WJcxikNrJAkmkK5smg1knNQ== Date: Fri, 5 Aug 2011 10:49:23 +0000 Message-ID: References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> In-Reply-To: <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:49:13 -0000 On 5 Aug 2011, at 11:28, Ray Bellis wrote: > "An IPv4 NATing device MUST set the evil bit on all packets to which it h= as applied NAT. All else being equal, a client SHOULD prefer an IPv6 path = over an IPv4 path that has the evil bit set." >=20 > [only half kidding] Ah, I see RFC 3514 already said that the evil bit SHOULD be set by NAT boxe= s. If we changed the rest of the RFC 3514 rules it _might_ just work, though ;= -) Ray From ietfc@btconnect.com Fri Aug 5 03:55:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8DF21F8C16 for ; Fri, 5 Aug 2011 03:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw-pkSdUKZRL for ; Fri, 5 Aug 2011 03:55:30 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2204121F8B98 for ; Fri, 5 Aug 2011 03:55:28 -0700 (PDT) Received: from pc6 (host81-159-99-55.range81-159.btcentralplus.com [81.159.99.55]) by c2bthomr13.btconnect.com (MOS 4.2.2-FCS) with SMTP id DWL34770; Fri, 5 Aug 2011 11:55:35 +0100 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E3BCC27.00D4, actions=tag Message-ID: <022e01cc5355$5f083240$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ari Keranen" References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <033501cc5035$13e0f360$4001a8c0@gateway.2wire.net> <032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net> <6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> Date: Fri, 5 Aug 2011 11:52:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.5.93616:17:7.944, ip=81.159.99.55, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __HAS_HTML, HTML_NO_HTTP, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4E3BCC2E.0165,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:55:30 -0000 inline --- Original Message ----- From: "Ari Keranen" To: "t.petch" Cc: "IPv6 Operations" Sent: Thursday, August 04, 2011 11:33 AM On Aug 2, 2011, at 2:07 PM, t.petch wrote: > In the hope that you will take up Fred's generous offer to push this through to > an RFC, I hope that you will find these comments helpful Thanks for the feedback! As Jari already mentioned, we haven't fixed our plans regarding how and if these results should be published, but if there is interest in the WG, v6ops RFC is indeed one good option. > I would like to see more references, for 6to4 and for the various .pdf; I think > it works better to have them all in one place. By .pdf do you mean the graph PDFs, other presentations something else? I mean the graph PDFs, where you have the URI in the text but not in the References, I would like it at least in the latter, less concerned about the former. > I find the X-axis of the graphs unclear; time presumably, but what time? It's the sequence number of the measurement run; so something like "time in 3 hour steps since the start of the tests". Probably hours (or even time and date) would work better here. Yes, date and time would be lovely; I thought it was measurement run but did not have a start point and the interval was not obvious. > I think that the biggest conclusion is omitted; only 2.45% of the top 10,000 > sites offer IPv6 via DNS ie next to none; I think that this should be in BIG > BOLD LETTERS. True, but that was not news to anyone :) Disagree; we know that the availability of IPv6 is negligible but we do not know how much it is, and a hard data point at a point in time will provide a valuable record. I was surprised at how small it was, I would have guessed 10-20% ( but then I am probably misled but the amount of traffic on the v6ops list:-) > And while comprehension is no problem, the idiom is sometimes slightly odd. > Doubtless the RFC Editor will fix it but I could point some of these out to you > if you want. That'd be helpful; please send me a mail with those off-list. I hope you do; Fred has indicated a willingness to help. I cannot think of a way to put it without being unfair to Fred, but it is an offer never to spurn. Tom Petch Cheers, Ari P.S. I'll be out of office for a couple of weeks, so it may take a while before I have a chance to follow up on this > Tom Petch > > ----- Original Message ----- > From: "Fred Baker" > To: "t.petch" > Cc: "IPv6 Operations" > Sent: Monday, August 01, 2011 6:49 PM > On Aug 1, 2011, at 3:23 AM, t.petch wrote: From moore@network-heretics.com Fri Aug 5 05:29:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C381021F8AFE for ; Fri, 5 Aug 2011 05:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1V3jxk1D9sI for ; Fri, 5 Aug 2011 05:29:43 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4621F8AFD for ; Fri, 5 Aug 2011 05:29:42 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QpJI8-0002i2-Py; Fri, 05 Aug 2011 08:14:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 5 Aug 2011 08:14:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90C15691-CE4B-444C-A131-48939E3B78F6@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9408387740d06e2790dfc9668a022fb69e0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:29:43 -0000 On Aug 5, 2011, at 4:10 AM, Philip Homburg wrote: > In your letter dated Thu, 04 Aug 2011 20:01:19 -0700 you wrote: >> On Aug 4, 2011, at 7:26 PM, Dale W. Carder wrote: >>>=20 >>> That could end up causing a lot of headache. >>=20 >> How? Please be specific. >>=20 >> The behavior we have now is proven to alleviate the killer = throw-your-Macbook- >> at-the-wall migraine headaches that a lot of our paying customers = have been co >> mplaining about quite publicly, and I'm not going to get very far = inside Apple >> toward undoing what we've done without more technical detail. >=20 > So what it boils down to is that Apple came up with their own HE > implementation without telling anybody or asking for feedback. And now = that > they have shipped it, it has to be defended as being the best = solution. Sad, > but that's usually how it works. Don't defend HE as being the best solution either. HE is of pretty = narrow applicability, really. The document doesn't overstate its = applicability, and the algorithm described in the document is not bad = for web browsers, which is why I have no objection to it. (and I'm = happy to see IETF work in this area) But the algorithm isn't going to = work well for apps in general. Also, my understanding is that Apple doesn't force programmers to use = the clever API. Programmers can still (and sometimes should) use = simpler APIs and do their own style of path selection that better fits = the needs of their specific application. Also, don't assume that the v6ops group is in a good position to pass = sole judgment on these algorithms. =20 And as someone else pointed out, Apple has a small share of the = installed base. If this ends up creating a problem, Apple's customers, = and Apple, will notice, and both will have incentive to fix it. = Meanwhile the impact on the rest of the net will be negligible.=20 Architecturally speaking, putting a global preference policy based on = address type into every host is a very dubious idea. It cannot work = well in general. Keith From narten@us.ibm.com Fri Aug 5 05:33:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9B21F8B05 for ; Fri, 5 Aug 2011 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.107 X-Spam-Level: X-Spam-Status: No, score=-106.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KUfg9ECqw4a for ; Fri, 5 Aug 2011 05:33:22 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8A321F8AFE for ; Fri, 5 Aug 2011 05:33:21 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p75CJUjh017149 for ; Fri, 5 Aug 2011 08:19:30 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p75CWZip214806 for ; Fri, 5 Aug 2011 08:32:35 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p758WMM8031785 for ; Fri, 5 Aug 2011 05:32:22 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-194-214.mts.ibm.com [9.65.194.214]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p758WMWt031753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 05:32:22 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p75CWWX4032477; Fri, 5 Aug 2011 08:32:33 -0400 Message-Id: <201108051232.p75CWWX4032477@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" In-reply-to: <4E394FF8.1070503@joelhalpern.com> References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> <4E394FF8.1070503@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Wed, 03 Aug 2011 09:41:12 -0400." Date: Fri, 05 Aug 2011 08:32:32 -0400 From: Thomas Narten Cc: IPv6 Operations Subject: Re: [v6ops] writing drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:33:23 -0000 > On 8/3/2011 1:43 AM, Mikael Abrahamsson wrote: > > On Tue, 2 Aug 2011, t.petch wrote: > > > >> I think that for most people the expectation is that I-D leads to RFC > >> or else to disappointment. > > > > Yes, I agree too. Producing a properly formatted I-D is something I > > would consider being a considerable effort. Writing on the list is for > > me an equivalent to brainstorm in front of the whiteboard, and THEN when > > something is hammered out a bit and there seems to be some interest and > > traction, THEN I produce a document in expectation that this will end up > > as a final product documenting whatever was discussed. > > > > I never start by producing a document before even discussing with my > > coworkers. I know some do, I don't. Different ways of working. FWIW, I (and I suspect a lot of readers of this list), at best "skim" email threads and hit "D" for large chunks of them. If you want my attention, make it count. If you can't take the time to write something succinct and somewhat self-contained, but instead think it better to contribute to a thread with 200+ messages, do not think for a second that everyone (or even many) are paying more than superficial attention. Case in point, I only read the above because I generally find Joel's postings worth my time to look at. Can't say that for a lot of other postings. Especially from those who post disproportionately and excessively. Fred Baker writes: > agreed. The problem with simply sending an email to open a > discussion thread or posing a "lightning round" kind of talk is > that the basic proposal gets lost in the noise and the thread > invariably migrates. These lists have way too much noise to spend an hour a day of valuable time reading them in the hope there is one tidbit of useful information. Thomas From dr@cluenet.de Fri Aug 5 05:44:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD821F8B15 for ; Fri, 5 Aug 2011 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSSzM0swI5PA for ; Fri, 5 Aug 2011 05:44:01 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C279321F8AF7 for ; Fri, 5 Aug 2011 05:44:00 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 176A81080A2; Fri, 5 Aug 2011 14:44:17 +0200 (CEST) Date: Fri, 5 Aug 2011 14:44:17 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110805124417.GA16338@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:44:01 -0000 On Fri, Aug 05, 2011 at 10:28:47AM +0000, Ray Bellis wrote: > Perhaps we should repurpose the IPv4 evil bit as an indication > of a path that is not "end-to-end" transparent ;-) Actually, OSX could source packets with the evil bit set, so operators can introduce additional biasing delay only for those packets and don't impare users of less selfish, short-sighted networking stacks. :-) > "An IPv4 NATing device MUST set the evil bit on all packets to which > it has applied NAT. All else being equal, a client SHOULD prefer an > IPv6 path over an IPv4 path that has the evil bit set." > > [only half kidding] Indeed only half kidding. SYN-ACK marking in some magic way perhaps? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Fri Aug 5 05:52:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7423621F8B37 for ; Fri, 5 Aug 2011 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA5DUVSxNBas for ; Fri, 5 Aug 2011 05:52:31 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1C21F8B23 for ; Fri, 5 Aug 2011 05:52:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 470AA20802; Fri, 5 Aug 2011 08:52:48 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 05 Aug 2011 08:52:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=t2e+xAn0mExgd4GSTdaXauuHg9s=; b=qq gTmd7I0VXY+PvkphLbJXrWhn+KOEv2OMqxtM6miIFgpfD/CgwZQuzznDm2ATJwMo TKkEFVR+HemaQ1Wg+ojXN+jmInK2iLlCuan1VU7tMtRhp6Mvw7Q7VEzTmAZed4RH wnM2YZRLALfVVKtI7Y1K8UAKIeoTFarvzjBTC2eH0= X-Sasl-enc: XOEOinZ4fxlHD3Z+wTnrMdyDQSv4vr29Fb5tXfFOfayt 1312548767 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BE864180E0; Fri, 5 Aug 2011 08:52:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110805124417.GA16338@srv03.cluenet.de> Date: Fri, 5 Aug 2011 08:52:46 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7FF5270D-C8C2-465C-BE0A-4F5E58D963FF@network-heretics.com> References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk> <20110805124417.GA16338@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:52:35 -0000 On Aug 5, 2011, at 8:44 AM, Daniel Roesen wrote: > On Fri, Aug 05, 2011 at 10:28:47AM +0000, Ray Bellis wrote: >> Perhaps we should repurpose the IPv4 evil bit as an indication >> of a path that is not "end-to-end" transparent ;-) > > Actually, OSX could source packets with the evil bit set, so operators > can introduce additional biasing delay only for those packets and don't > impare users of less selfish, short-sighted networking stacks. :-) cast-iron pot. stainless steel kettle. Keith From Ted.Lemon@nominum.com Fri Aug 5 06:23:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF3221F8B00 for ; Fri, 5 Aug 2011 06:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJxhME1JznBG for ; Fri, 5 Aug 2011 06:23:54 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 826EC21F8AFE for ; Fri, 5 Aug 2011 06:23:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTjvu+gZVps7T6X+GLH+dl2LIzvGegk0L@postini.com; Fri, 05 Aug 2011 06:24:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E4DE31B8162 for ; Fri, 5 Aug 2011 06:24:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 08B3319005D; Fri, 5 Aug 2011 06:24:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Fri, 5 Aug 2011 06:23:57 -0700 From: Ted Lemon To: Philip Homburg Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Thread-Index: AQHMU0dHRVa7aNWwW0q26rsswqWBjZUOtKQA Date: Fri, 5 Aug 2011 13:23:57 +0000 Message-ID: References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_B3C69AB170A64D989AB485ADC98FD04Anominumcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:23:55 -0000 --_000_B3C69AB170A64D989AB485ADC98FD04Anominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 5, 2011, at 4:10 AM, Philip Homburg wrote: So what it boils down to is that Apple came up with their own HE implementation without telling anybody or asking for feedback. And now that they have shipped it, it has to be defended as being the best solution. Sad= , but that's usually how it works. In all fairness, Apple was working on this implementation before HE was a g= limmer in anybody's eye, and indeed Stuart Cheshire described it in some de= tail in a v6ops meeting about two years ago. I kind of think it might hav= e inspired the development of HE, but I may be wrong about that. In any c= ase, I think throwing stones here is not really constructive. --_000_B3C69AB170A64D989AB485ADC98FD04Anominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 5, 2011, at 4:10 AM, Philip Homburg wrote:
So what it boils down to is that Apple came up with their own HE
implementation without telling anybody or asking for feedback. And now that=
they have shipped it, it has to be defended as being the best solution. Sad= ,
but that's usually how it works.

In all fairness, Apple was working on this implementation before HE wa= s a glimmer in anybody's eye, and indeed Stuart Cheshire described it in so= me detail in a v6ops meeting about two years ago.   I kind of think it= might have inspired the development of HE, but I may be wrong about that.   In any case, I think throwing= stones here is not really constructive.

--_000_B3C69AB170A64D989AB485ADC98FD04Anominumcom_-- From pch-b29AA871B@u-1.phicoh.com Fri Aug 5 06:53:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C485A21F8B8B for ; Fri, 5 Aug 2011 06:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.043 X-Spam-Level: X-Spam-Status: No, score=-8.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bQGqmzZjsKR for ; Fri, 5 Aug 2011 06:53:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id EE08921F8661 for ; Fri, 5 Aug 2011 06:53:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QpKqq-0001hHC; Fri, 5 Aug 2011 15:54:12 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> In-reply-to: Your message of "Fri, 5 Aug 2011 13:23:57 +0000 ." Date: Fri, 05 Aug 2011 15:53:45 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:53:57 -0000 In your letter dated Fri, 5 Aug 2011 13:23:57 +0000 you wrote: >In all fairness, Apple was working on this implementation before HE was a g= >limmer in anybody's eye, and indeed Stuart Cheshire described it in some de= >tail in a v6ops meeting about two years ago. I kind of think it might hav= >e inspired the development of HE, but I may be wrong about that. In any c= >ase, I think throwing stones here is not really constructive. He certainly deserves credit for presenting it. But then you can't just go off to an island and just implement something. It is always possible that as an operating system designer, you miss an operator perspective. Of course, it is possible that the implementation was frozen long before there was any discussion here about the subject. But then you can just say that you will try to get it fixed in a future release. If Apple really has more than two years of experience with HE, then it would have been nice if they would have shared some. From pch-b29AA871B@u-1.phicoh.com Fri Aug 5 07:06:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44F21F8B74 for ; Fri, 5 Aug 2011 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4-6JMz7v3Rj for ; Fri, 5 Aug 2011 07:06:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0992521F8B57 for ; Fri, 5 Aug 2011 07:06:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QpL3D-0001iVC; Fri, 5 Aug 2011 16:06:59 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> <90C15691-CE4B-444C-A131-48939E3B78F6@network-heretics.com> In-reply-to: Your message of "Fri, 5 Aug 2011 08:14:15 -0400 ." <90C15691-CE4B-444C-A131-48939E3B78F6@network-heretics.com> Date: Fri, 05 Aug 2011 16:06:52 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:06:48 -0000 In your letter dated Fri, 5 Aug 2011 08:14:15 -0400 you wrote: >Don't defend HE as being the best solution either. HE is of pretty = >narrow applicability, really. The document doesn't overstate its = >applicability, and the algorithm described in the document is not bad = >for web browsers, which is why I have no objection to it. (and I'm = >happy to see IETF work in this area) But the algorithm isn't going to = >work well for apps in general. > >Also, my understanding is that Apple doesn't force programmers to use = >the clever API. Programmers can still (and sometimes should) use = >simpler APIs and do their own style of path selection that better fits = >the needs of their specific application. I could be wrong, but I think I read somewhere that Apple does reorder the results of getaddrinfo. If that is true then application that use the basic socket extensions would end up with HE whether they want it or not. >Architecturally speaking, putting a global preference policy based on = >address type into every host is a very dubious idea. It cannot work = >well in general. Note that the HE draft is smart enough to say that the address selection policy should be followed unless there is evidence that a certain address or protocol doesn't work all that well. So there is the possibility of local overrides. From dr@cluenet.de Fri Aug 5 07:08:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98AA21F8BDC for ; Fri, 5 Aug 2011 07:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMMQRFMU3XDt for ; Fri, 5 Aug 2011 07:08:33 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 184C421F8BF8 for ; Fri, 5 Aug 2011 07:08:33 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 3E18B108099; Fri, 5 Aug 2011 16:08:50 +0200 (CEST) Date: Fri, 5 Aug 2011 16:08:50 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110805140850.GA8376@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB-A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:08:34 -0000 On Fri, Aug 05, 2011 at 03:53:45PM +0200, Philip Homburg wrote: > It is always possible that as an operating system designer, you miss an > operator perspective. I get a distinct impression that the operator perspective wasn't of relevant interest (and still isn't). To make the IPv6 transission as painless as possible, all stakeholders have to work together, based on a common "big picture". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Ted.Lemon@nominum.com Fri Aug 5 07:12:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23AE21F86DE for ; Fri, 5 Aug 2011 07:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqG8rhKYk3Lh for ; Fri, 5 Aug 2011 07:12:38 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2221F857D for ; Fri, 5 Aug 2011 07:12:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTjv6Z0zPqZzyEOA4YG4IGxripLl4COwE@postini.com; Fri, 05 Aug 2011 07:12:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B7FE01B8162 for ; Fri, 5 Aug 2011 07:12:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1CBDA19005D; Fri, 5 Aug 2011 07:12:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Fri, 5 Aug 2011 07:12:52 -0700 From: Ted Lemon To: Philip Homburg Thread-Topic: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Thread-Index: AQHMU3cstcpgpAEh70aqEMAeNQehhZUOwe+A Date: Fri, 5 Aug 2011 14:12:52 +0000 Message-ID: <7D696784-586E-4F42-B01A-37A21C432992@nominum.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_7D696784586E4F42B01A37A21C432992nominumcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:12:38 -0000 --_000_7D696784586E4F42B01A37A21C432992nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 5, 2011, at 9:53 AM, Philip Homburg wrote: But then you can't just go off to an island and just implement something. It is always possible that as an operating system designer, you miss an operator perspective. I'm not sure v6ops is the place to have an argument about this, but I will = remind you of the IETF motto: "running code and rough consensus." --_000_7D696784586E4F42B01A37A21C432992nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ABFCA539CA824468EB3E05CA17D9120@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 5, 2011, at 9:53 AM, Philip Homburg wrote:
But then you can't just go off to an island and just implement something.
It is always possible that as an operating system designer, you miss an
operator perspective.

I'm not sure v6ops is the place to have an argument about this, but I = will remind you of the IETF motto: "running code and rough consensus.&= quot;

--_000_7D696784586E4F42B01A37A21C432992nominumcom_-- From cb.list6@gmail.com Fri Aug 5 09:14:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947E021F8B6B for ; Fri, 5 Aug 2011 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7pFOoMsftuX for ; Fri, 5 Aug 2011 09:14:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8148121F8B4D for ; Fri, 5 Aug 2011 09:14:05 -0700 (PDT) Received: by wyg8 with SMTP id 8so1430474wyg.31 for ; Fri, 05 Aug 2011 09:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VJT0vvLRsxSIphR8t+yMfZCf6XUVwGnf8/BjK+Lu79A=; b=QOnSLAwXyjhQn3+RSEL/QzG1P7mXdzfu/Y35HIkfbqs0V9i9sH4fjH6XfPPOalkSJ9 Ns9aDNBVCBB8spMLohmcifpuqu9v9B5aKzQYHmquTWbUoV1SMRdk6k9SCbBOqWs13fHU JXPhKFPdfZ7cLs+lqhy2odVqKL71joJ0yGFas= MIME-Version: 1.0 Received: by 10.216.208.17 with SMTP id p17mr691528weo.72.1312560862741; Fri, 05 Aug 2011 09:14:22 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Fri, 5 Aug 2011 09:14:22 -0700 (PDT) In-Reply-To: <7D696784-586E-4F42-B01A-37A21C432992@nominum.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> <7D696784-586E-4F42-B01A-37A21C432992@nominum.com> Date: Fri, 5 Aug 2011 09:14:22 -0700 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 16:14:06 -0000 On Fri, Aug 5, 2011 at 7:08 AM, Daniel Roesen wrote: > On Fri, Aug 05, 2011 at 03:53:45PM +0200, Philip Homburg wrote: >> It is always possible that as an operating system designer, you miss an >> operator perspective. > > I get a distinct impression that the operator perspective wasn't of > relevant interest (and still isn't). > > To make the IPv6 transission as painless as possible, all stakeholders > have to work together, based on a common "big picture". > I don't believe Apple's goal is IPv6 transition, they are locally optimizing their own product and user experience. Cameron > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From warren@kumari.net Fri Aug 5 11:02:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6011E8070 for ; Fri, 5 Aug 2011 11:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C2P0c4JHh5a for ; Fri, 5 Aug 2011 11:02:29 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65521F8B15 for ; Fri, 5 Aug 2011 11:02:29 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B859E1B416D8; Fri, 5 Aug 2011 14:02:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 5 Aug 2011 14:02:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1544161F-CE90-4914-9DE8-E70C3270A019@kumari.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <78E0CEA6-3 E21-42ED-9704-64383CF9B83F@apple.com> <7D696784-586E-4F42-B01A-37A21C432992@nominum.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 18:02:30 -0000 [ Not responding specifically to Cameron here, more of a meta comment. ] On Aug 5, 2011, at 12:14 PM, Cameron Byrne wrote: > On Fri, Aug 5, 2011 at 7:08 AM, Daniel Roesen wrote: >> On Fri, Aug 05, 2011 at 03:53:45PM +0200, Philip Homburg wrote: >>> It is always possible that as an operating system designer, you miss = an >>> operator perspective. >>=20 >> I get a distinct impression that the operator perspective wasn't of >> relevant interest (and still isn't). >>=20 >> To make the IPv6 transission as painless as possible, all = stakeholders >> have to work together, based on a common "big picture". >>=20 >=20 > I don't believe Apple's goal is IPv6 transition, they are locally > optimizing their own product and user experience. Wow! Imagine that, a company optimizing their user experience and = providing the *users* what they want, instead of some religious = ideology. For shame. For years the users have been living under the shackles of NAT, and = their lives have been pure hell because of it -- they have not been able = to use the applications they want, have not been able to access any = content, send email, use VoIP, etc. Now is the time to liberate them = from the tyranny of address translation and drag them, kicking and = screaming into a new world, full of happiness, light and more bits in an = address. Sure, their lives may suck for a while while we add some latency to = their IPv4 world, but, hey, this will just provide the necessary impetus = to make them change... and, once they have, their dancing hamsters sure = will look prettier, and they'll never look back... W >=20 > Cameron >=20 >=20 >> Best regards, >> Daniel >>=20 >> -- >> CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From moore@network-heretics.com Fri Aug 5 11:08:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522BC21F8B62 for ; Fri, 5 Aug 2011 11:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vro5afsOSWop for ; Fri, 5 Aug 2011 11:08:40 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 712A621F8C3F for ; Fri, 5 Aug 2011 11:08:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5904E20B31; Fri, 5 Aug 2011 14:08:57 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 05 Aug 2011 14:08:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=VkrmrTkADp7rklOFI7NY6l3SXlw=; b=jk ttDt0dKVVN0j5Qm7T2q9SUtMQBi+AEwrJ5Fq446R1XpWoxnofUeuGnOtjA7wKp/X xXfh0kNTthRV0ONucmgTIAnU7joET+jpyTj6Nlvpo336lbKJxlOQrmXg9pHJkjig mykGKbRPV81GsgEfvHpmiwwL5UNk6V+DVNvPvhB4A= X-Sasl-enc: 1zHDXFkoAqQasH6CBta1GUJfjynJSCWFcfN6quOG351e 1312567736 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 68AB94181E8; Fri, 5 Aug 2011 14:08:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 5 Aug 2011 14:08:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53429C5B-FC54-4AA4-B3F7-686A4310F341@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 18:08:41 -0000 On Aug 5, 2011, at 9:53 AM, Philip Homburg wrote: > It is always possible that as an operating system designer, you miss = an operator perspective. True. It is also always possible that operators miss the perspective of = OS implementors, applications implementors, and users. Keith From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Aug 5 15:00:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB10E21F8ADC for ; Fri, 5 Aug 2011 15:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOMnNy+PB9Un for ; Fri, 5 Aug 2011 15:00:20 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2FADE21F8AD8 for ; Fri, 5 Aug 2011 15:00:20 -0700 (PDT) Received: from 219-90-209-53.ip.adam.com.au ([219.90.209.53] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QpSRT-0006wm-0M; Sat, 06 Aug 2011 07:30:31 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 5C50D3B34D; Sat, 6 Aug 2011 07:30:30 +0930 (CST) Date: Sat, 6 Aug 2011 07:30:30 +0930 From: Mark Smith To: Keith Moore Message-ID: <20110806073030.282f453b@opy.nosense.org> In-Reply-To: <53429C5B-FC54-4AA4-B3F7-686A4310F341@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699@apple.com> <87805FCBB- A7A9-43A@apple.com> <78E0CEA6-3E21-42ED-9704-64383CF9B83F@apple.com> <53429C5B-FC54-4AA4-B3F7-686A4310F341@network-heretics.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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 Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 22:00:20 -0000 On Fri, 5 Aug 2011 14:08:55 -0400 Keith Moore wrote: > On Aug 5, 2011, at 9:53 AM, Philip Homburg wrote: > > > It is always possible that as an operating system designer, you miss an operator perspective. > > True. It is also always possible that operators miss the perspective of OS implementors, applications implementors, and users. > +1 One of the best pieces of advice I got a long time ago was "think like a user". > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From frnkblk@iname.com Fri Aug 5 16:10:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128B321F881C for ; Fri, 5 Aug 2011 16:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX-i6cRDnxzK for ; Fri, 5 Aug 2011 16:10:16 -0700 (PDT) Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id 79CEA21F85DA for ; Fri, 5 Aug 2011 16:10:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from BULKFAMLAPTOP (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 29478004-1729245 for multiple; Fri, 05 Aug 2011 18:10:32 -0500 From: "Frank Bulk" To: "'George Michaelson'" References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <20110801053719.GA10524@srv03.cluenet.de> <20110801143949.GA18578@srv03.cluenet.de> <20110802122545.GA12922@srv03.cluenet.de> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@ap nic.net>X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=5 Friend=635 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 881, in=12559554, out=61170, spam=0 Known=true ip=199.120.69.27 Message-Id: <20110805231016.79CEA21F85DA@ietfa.amsl.com> Date: Fri, 5 Aug 2011 16:10:16 -0700 (PDT) Cc: IPv6 Operations Subject: [v6ops] (no subject) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 23:10:25 -0000 In-Reply-To: <07C4D7DC-C8A1-463D-8B52-9C9492F65EF6@apnic.net> Subject: RE: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. Date: Fri, 5 Aug 2011 18:10:26 -0500 Message-ID: <006701cc53c4$ddf7c600$99e75200$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxSXHQWcADk5g7mToqWJeF+eWUzcABaE0Qg Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net Then why hasn't Microsoft addressed the IPv6 issues around accidental use of ICS? That's been known for a long time, MSFT is aware of it, yet I'm still waiting for that patch... Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of George Michaelson Sent: Wednesday, August 03, 2011 11:10 PM To: Mark Andrews Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. On 04/08/2011, at 1:36 PM, Mark Andrews wrote: > > It all depends on when you think deployment of CGN/AFTR/NAT64 boxes > will happen. My feeling is you will see these boxes being widely > deployed within 3 years and ISP's scrambling to move IPv4 only > customers to IPv4 + IPv6 or IPv6 only to reduce the number of > CGN/AFTR/NAT64 boxes they need to deploy. Currently shipping code > shouldn't make the problem worse when this happens. Mark, consider both Apple, and Microsofts codebase 3 years ago, and the frequency of updates. Lion has been out precisely <1month, and has had one update already. Vista gets regular self-applied updates. You cannot seriously be saying that the consequential 'damage' to the v6 message stems from this deployment, because it only applies to people WHO GO ONLINE and if they go online with Apple they get FREE UPDATES. What am I missing? Do you think Apple owners stay on factory defaults? Really? -george _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From pthubert@cisco.com Sat Aug 6 06:43:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2C421F8764; Sat, 6 Aug 2011 06:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.832 X-Spam-Level: X-Spam-Status: No, score=-9.832 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIf619iAIVMm; Sat, 6 Aug 2011 06:43:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 79F9921F874E; Sat, 6 Aug 2011 06:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2509; q=dns/txt; s=iport; t=1312638257; x=1313847857; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jLm7Qu7efFKWoqsHN6g3/v8JXqGZ+a9rE60lcS6Qwmw=; b=PnFFcsWiC5xPcA9Q+Gj9JkSqmm7lai0QjXtervFx6qHMa2ZYi3qYkDQc a/SsVjjqQMUPdBmJXNb8vBKkHPGk/A1NgBc6t9jplPTwHXtzVWblvjfNN EedOBCCW8fiax1FbPyljm4DDL0P+7p1ldcaU/rCz+TQysLZm7ihdFDuaL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAMpEPU6Q/khM/2dsb2JhbABCmB+PS3eBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah0+gTwGeGoVnXwSYE4tZ X-IronPort-AV: E=Sophos;i="4.67,328,1309737600"; d="scan'208";a="47334881" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Aug 2011 13:44:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p76DiGBh016766; Sat, 6 Aug 2011 13:44:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 6 Aug 2011 15:44:16 +0200 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 Date: Sat, 6 Aug 2011 15:42:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A36FF@XMB-AMS-107.cisco.com> In-Reply-To: <73A004D0-2CC2-4B19-A3B2-0ADB79081582@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] [v6ops] default LAN routing protocol for IPv6CE router Thread-Index: AcxSCOdaebvljJzRRC+a0gjIWtZa+wCNCHpQ References: <9E2FAA01116B084A9B10EC34D6015A07482B9D9DB1@DENEXMAIL1.ARRS.ARRISI.COM><067E6CE33034954AAC05C9EC85E2577C0599B4A0@XMB-RCD-111.cisco.com><0EB9D7EF-7B37-45B3-B6E4-5F946B19AC45@bogus.com><80215711-1B7D-428C-9B7B-75D61BFAC66E@apple.com> <73A004D0-2CC2-4B19-A3B2-0ADB79081582@cisco.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms (rdroms)" , "james woodyatt" X-OriginalArrivalTime: 06 Aug 2011 13:44:16.0223 (UTC) FILETIME=[EF0D3EF0:01CC543E] Cc: IPv6 Operations , homenet@ietf.org Subject: Re: [v6ops] [homenet] default LAN routing protocol for IPv6CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 13:43:57 -0000 Hi James; As Ralph indicates, RFC4944 describes a L2.5 fragmentation mechanism and recommends a MTU of 1280 on 802.15.4 links. That fragmentation mechanism does not allow forwarding at L3 (each L3 hop needs to reassemble). It is also sensitive to frame loss, which sadly is frequent in 802.15.4 though it was mitigated in some environment such as industrial (see WiHART, ISA100.11a, 802.15.4e). Both issues (loss and forwarding) are addressed in http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover y but the draft is homeless at the moment. 4944 is also partially obsoleted by RFC-to-be 6282 for the header compression piece. Finally, I'd recommend to take a look at http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02. This work was initially a component of the registration based ND that was designed at 6LoWPAN, and was split in midflight. You'll see in the overview that the concept is to use a backbone router that proxies ND between the 802.15.4 meshes and a higher speed Ethernet (or emulated Ethernet such as WIFI infra mode), with the assumption that the backbone runs classical ND whereas the meshes use the registration-based ND. Cheers, Pascal > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On > Behalf Of Ralph Droms (rdroms) > Sent: Wednesday, August 03, 2011 8:12 PM > To: james woodyatt > Cc: Joel Jaeggli; IPv6 Operations; homenet@ietf.org > Subject: Re: [homenet] [v6ops] default LAN routing protocol for IPv6CE > router >=20 > RFC 4944 >=20 > - Ralph >=20 > On Aug 3, 2011, at 2:09 PM 8/3/11, james woodyatt wrote: >=20 > > On Aug 3, 2011, at 10:00 , Joel Jaeggli wrote: > >> > >> got a better idea for interconnecting 802.15.4 and 802.3 networks than at > layer-3? > > > > How does 802.15.4 achieve the 1280 octet minimum MTU size required by > IPv6? I'm sure this is explained in an RFC somewhere, but I don't know. > Hoping someone knows off the top of their head and can quickly rattle off a > citation from memory. > > > > > > -- > > james woodyatt > > member of technical staff, core os networking > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From despres.remi@laposte.net Sat Aug 6 07:43:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711F321F8565 for ; Sat, 6 Aug 2011 07:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkRsHZokCza9 for ; Sat, 6 Aug 2011 07:43:55 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5A121F855A for ; Sat, 6 Aug 2011 07:43:54 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id AEF727000085; Sat, 6 Aug 2011 16:44:13 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 805017000082; Sat, 6 Aug 2011 16:44:09 +0200 (CEST) X-SFR-UUID: 20110806144409525.805017000082@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> Date: Sat, 6 Aug 2011 16:44:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <032A834B-448A-4565-87EC-6DAF37CE2731@laposte.net> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 14:43:55 -0000 Le 4 ao=FBt 2011 =E0 23:00, james woodyatt a =E9crit : > On Aug 4, 2011, at 13:10 , Sander Steffann wrote: >>=20 >> I think it boils down to: >> - If it is used when it gives better performance to the user: great. >> - If it is used when the performance is roughly equal to IPv6: please = use IPv6. >=20 > I don't know how to say this differently, so I'm just going to repeat = myself. > If you provision your networks so that IPv4 paths have longer = round-trip times or are congested more often and/or to a greater degree, = then we will prefer less congested IPv6 paths. >=20 > Furthermore, if you provision your networks so that IPv6 paths have = longer round-trip times or are congested more often and/or to a greater = degree, then we will prefer less congested IPv4/NAT paths. Full agreement on these two (at least for applications that express = indifference about v4 or v6 being used). =20 > Finally, if you provision your networks so that IPv4 and IPv6 exhibit = "roughly equivalent" levels of path latency and congestion, then we're = going to try very, very hard to use both IPv4 and IPv6 in "roughly = equivalent" measure. Serious disagreement on this one. In this case, v6 MUST be preferred: - If both paths are "good" (as they should be!), preference for IPv6 = tends to increase the v6/v4 traffic ratio, which will lead to a visible = fading out of IPv4 use. - It's easier to implement, AFAIK, than trying hard to evenly split the = traffic between v4 and V6. Any solid argument against this? Regards, RD From moore@network-heretics.com Sat Aug 6 08:54:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26321F86EE for ; Sat, 6 Aug 2011 08:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x55W2q29tSI0 for ; Sat, 6 Aug 2011 08:54:51 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76C21F856B for ; Sat, 6 Aug 2011 08:54:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 966A42093C; Sat, 6 Aug 2011 11:55:05 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 06 Aug 2011 11:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=wv18rXJIvtfujeNfJ/Brj9og9Gs=; b=Lf g/QBqFQpDu2uQXoTr5AP4u87Ra3MHh/BTG/h8v0ktcZeiDWCH9OLBTsb8yFboqoy Kl/RiKx49ZX2+8NXWFqZjkJ0CQnN73Jie7wuMzoQDv6Jc4gygsRtsUs4HZ/c1spP 03HTycYfQFnFSMNjMYvTxYk3GPK3iiBCAHabky/mk= X-Sasl-enc: dVfe3y6ouwplfr97auITK2j7y0K6eRZWu54LkyXGlmA6 1312646105 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9173D418576; Sat, 6 Aug 2011 11:55:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <032A834B-448A-4565-87EC-6DAF37CE2731@laposte.net> Date: Sat, 6 Aug 2011 11:55:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <558460F8-51C7-4C20-9BFD-B8DADC834A6F@network-heretics.com> References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com> <032A834B-448A-4565-87EC-6DAF37CE2731@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 15:54:52 -0000 On Aug 6, 2011, at 10:44 AM, R=E9mi Despr=E9s wrote: >> Finally, if you provision your networks so that IPv4 and IPv6 exhibit = "roughly equivalent" levels of path latency and congestion, then we're = going to try very, very hard to use both IPv4 and IPv6 in "roughly = equivalent" measure. >=20 > Serious disagreement on this one. > In this case, v6 MUST be preferred: > - If both paths are "good" (as they should be!), preference for IPv6 = tends to increase the v6/v4 traffic ratio, which will lead to a visible = fading out of IPv4 use. > - It's easier to implement, AFAIK, than trying hard to evenly split = the traffic between v4 and V6. > Any solid argument against this? As far as I can tell, it's easier to implement if you don't try to bias = in favor of IPv6. Then the difference between v4 and v6 will amount to = random noise, and the choice between a v4 path and a v6 path will = essentially be random. I don't know that it's necessary to "try very, = very hard" to use both; I think this will happen fairly naturally. But it might be reasonable for the software to do something like: if = there's not a statistically significant difference between the measured = performance of the different paths available, fall back to an rfc = 3484-like policy table.=20 Keith From frnkblk@iname.com Sun Aug 7 21:22:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC121F877F; Sun, 7 Aug 2011 21:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D20pK9NAmZJ3; Sun, 7 Aug 2011 21:22:32 -0700 (PDT) Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40BD621F8548; Sun, 7 Aug 2011 21:22:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 29531710-1729245 for multiple; Sun, 07 Aug 2011 23:22:53 -0500 From: "Frank Bulk" To: "'Keith Moore'" References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <52599079-C6E9-48F9-AFAE-78E7989FB105@network-heretics.com> In-Reply-To: <52599079-C6E9-48F9-AFAE-78E7989FB105@network-heretics.com> Date: Sun, 7 Aug 2011 23:22:29 -0500 Message-ID: <009e01cc5582$d51bcc60$7f536520$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxMiriIWmxxIR09QDaIGoHS//aBGAIfH75Q Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=3 Friend=408 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 883, in=13688188, out=64386, spam=0 Known=true ip=199.120.69.26 Cc: IPv6 Operations , ietf@ietf.org, Philip Homburg Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 04:22:33 -0000 Hmmm...it's been well documented that 6to4 causes bad experiences, not decreases the chance of having them. Since much of the IPv6-accssible content is dual-stacked, unless you're using an application that implements HE, the odds are in your favor to use IPv4 rather than IPv4+6to4. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, July 27, 2011 1:25 PM To: Philip Homburg Cc: IPv6 Operations; Keith Moore; ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: > In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: >> In message <4E2F4491.30102@gmail.com>, Brian E Carpenter writes: >>> Of course, if implementors choose to drop the code you might not be >>> able to upgrade software versions - but hopefully by that time you >>> will have native IPv6 service anyway. >> >> Which is exactly why HISTORIC is NOT appropriate. > > With rfc3484-revise and the documented brokenness of 6to4, it doesn't make > any sense for implementors to offer 6to4 anyhow. False. It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts. Keith _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From rbonica@juniper.net Mon Aug 8 11:36:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF721F8BB1; Mon, 8 Aug 2011 11:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vFYzqTWNl8R; Mon, 8 Aug 2011 11:36:50 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD421F8BA2; Mon, 8 Aug 2011 11:36:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTkAs3OCtvcEJfEGRBcHNgvn823Po1nTK@postini.com; Mon, 08 Aug 2011 11:37:16 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Aug 2011 10:49:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 8 Aug 2011 13:49:06 -0400 From: Ronald Bonica To: "ietf@ietf.org" , "v6ops@ietf.org" Date: Mon, 8 Aug 2011 13:49:05 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic (yet again) Thread-Index: AcxK13EXQuzfLCzMQFivvvTkow95TgLG9cng Message-ID: <13205C286662DE4387D9AF3AC30EF456D43CF6CECA@EMBX01-WF.jnpr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic (yet again) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 18:36:50 -0000 Folks, After an active discussion, it is clear that there is no consensus. So, I w= ill transition draft-ietf-v6ops-6to4-to-historic to the DEAD state. Ron > -----Original Message----- > From: Ronald Bonica > Sent: Monday, July 25, 2011 10:31 AM > To: ietf@ietf.org > Subject: draft-ietf-v6ops-6to4-to-historic (yet again) >=20 > Folks, >=20 > After some discussion, the IESG is attempting to determine whether > there is IETF consensus to do the following: >=20 > - add a new section to draft-ietf-v6ops-6to4-to-historic > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL >=20 > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and > convert their status to HISTORIC. It will also contain a new section > describing what it means for RFCs 3056 and 3068 to be classified as > HISTORIC. The new section will say that: >=20 > - 6-to-4 should not be configured by default on any implementation > (hosts, cpe routers, other) > - vendors will decide whether/when 6-to-4 will be removed from > implementations. Likewise, operators will decide whether/when 6-to-4 > relays will be removed from their networks. The status of RFCs 3056 and > 3068 should not be interpreted as a recommendation to remove 6-to-4 at > any particular time. >=20 >=20 > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it > clarifies the meaning of "HISTORIC" in this particular case, it does > not set a precedent for any future case. >=20 > Please post your views on this course of action by August 8, 2011. >=20 >=20 > Ron > Bonica >=20 > From wwwrun@rfc-editor.org Mon Aug 8 20:20:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349B321F86DF; Mon, 8 Aug 2011 20:20:33 -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.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU+MemG-W-Hp; Mon, 8 Aug 2011 20:20:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B68F121F86DE; Mon, 8 Aug 2011 20:20:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4197398C51A; Mon, 8 Aug 2011 20:21:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110809032100.4197398C51A@rfc-editor.org> Date: Mon, 8 Aug 2011 20:21:00 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6343 on Advisory Guidelines for 6to4 Deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 03:20:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6343 Title: Advisory Guidelines for 6to4 Deployment Author: B. Carpenter Status: Informational Stream: IETF Date: August 2011 Mailbox: brian.e.carpenter@gmail.com Pages: 20 Characters: 51496 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-6to4-advisory-02.txt URL: http://www.rfc-editor.org/rfc/rfc6343.txt This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From phdgang@gmail.com Tue Aug 9 09:13:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB621F8C20; Tue, 9 Aug 2011 09:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vXDyoDiTKtk; Tue, 9 Aug 2011 09:13:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA921F8C1A; Tue, 9 Aug 2011 09:13:56 -0700 (PDT) Received: by vxi29 with SMTP id 29so142051vxi.31 for ; Tue, 09 Aug 2011 09:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L4SAryZ0/owXXo8VYcWV6BJW7PEVXhHp8Wsz6dwsXJg=; b=MF3KtqBv4ciSvTc8AoO1clSkAV4TiElysMDblVxnE7DBBjNCFAaKOnJ57GPTi+8S7r WcCk3/3pFZ6meCnAADwBJdeV7JeDEV3eMp9UKnch3MOU0v87DUuDyWkp+oZIMhBrHrxz Em7FAEKrXBrF1lwNTadTYsxBX+wD7RM0PbM7A= MIME-Version: 1.0 Received: by 10.52.180.102 with SMTP id dn6mr6442281vdc.51.1312906465150; Tue, 09 Aug 2011 09:14:25 -0700 (PDT) Received: by 10.52.169.129 with HTTP; Tue, 9 Aug 2011 09:14:25 -0700 (PDT) In-Reply-To: <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> Date: Wed, 10 Aug 2011 00:14:25 +0800 Message-ID: From: GangChen To: Jouni Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:13:57 -0000 Dear Jouni, In mobile CPE case, MT and TE are separated. That would need additional requirements in some particular cases, e.g. dynamic IPv6 address allocation. According to the 3GPP specification, the UE shall build the link-local address using the interface identifier provided by the PDN GW upon PDN connection establishment. However, MT may not be able to transfer the interface identifier to TE in the CPE cases. The only thing the IP devices can do is to select the interface identifier by some other means and then perform Duplicate Address Detection, as specified in RFC 4862. The PDN GW shall then perform the DAD check based on the Neighbor Solicitation messages sent by the UE. Therefore, there are some implementation factors that may change UE behaviour in the CPE context. IMHO, it would be beneficial to describe CPE consideration in section 5.3. CPE case has already appeared to be a valid scenario in 3GPP BRs Gang 2011/8/5, Jouni : > Dear Gang, > > I would be inclined to say that within the 3GPP scope the client is always > the "UE" and its form factor or the end usage scenario does not really > matter. It does not change the way the UE is expected to behave from the > 3GPP system point of view, unless there is a new functional requirement from > 3GPP. > > - Jouni > > > > On Aug 5, 2011, at 5:55 AM, GangChen wrote: > >> Hello Authors, >> >> I think it is worth adding some texts to describe mobile CPE case, in >> which CPEs with wireless modem use 3GPP access as uplink. >> >> Gang >> >> >> 2011/8/2, The IESG : >>> >>> The IESG has received a request from the IPv6 Operations WG (v6ops) to >>> consider the following document: >>> - 'IPv6 in 3GPP Evolved Packet System' >>> as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> Use of data services in smart phones and broadband services via HSPA >>> and HSPA+, in particular Internet services, has increased rapidly and >>> operators that have deployed networks based on 3GPP network >>> architectures are facing IPv4 address shortages at the Internet >>> registries and are feeling a pressure to migrate to IPv6. This >>> document describes the support for IPv6 in 3GPP network >>> architectures. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > From jounikor@gmail.com Tue Aug 9 11:48:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E1A21F8B34; Tue, 9 Aug 2011 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvaA5gBmDNkg; Tue, 9 Aug 2011 11:48:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8DA121F8B32; Tue, 9 Aug 2011 11:48:55 -0700 (PDT) Received: by fxe6 with SMTP id 6so341830fxe.31 for ; Tue, 09 Aug 2011 11:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ALWE83sZowNR2NyqMPlnO/aF0dsN0jC+2k7utjW+RpE=; b=PyL+RUumOMg9ny2UNWgQm0qHXagJJux3n69wu3gu/g/JqVhinnIUQyWu+4r9/ermW4 X6YZwOqaVTqM/TVb+Ywh8HGt9/QtW66KlrrKoqPNb5wVdyztSxCs/slNWKxA4brsjlXB /Gyp5IocLsBxghOp8/QlObvAUbIqR+TIjghEo= Received: by 10.223.76.71 with SMTP id b7mr9888772fak.30.1312915764501; Tue, 09 Aug 2011 11:49:24 -0700 (PDT) Received: from a88-114-69-10.elisa-laajakaista.fi (a88-114-69-10.elisa-laajakaista.fi [88.114.69.10]) by mx.google.com with ESMTPS id e10sm151765fak.18.2011.08.09.11.49.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 11:49:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 9 Aug 2011 21:49:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4E7AFA6A-0025-4FF4-B5CF-D32A0F3CFF4F@gmail.com> References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:48:57 -0000 Dear Gang, On Aug 9, 2011, at 7:14 PM, GangChen wrote: > Dear Jouni, >=20 > In mobile CPE case, MT and TE are separated. That would need > additional requirements in some particular cases, e.g. dynamic IPv6 > address allocation. Separate MT & TE is part of the existing 3GPP specifications. There is = nothing CPE specific in that. > According to the 3GPP specification, the UE shall build the link-local > address using the interface identifier provided by the PDN GW upon PDN > connection establishment. However, MT may not be able to transfer the > interface identifier to TE in the CPE cases. The only thing the IP See my earlier mail: = http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html This is again not specific to a CPE case but rather a driver framework = brokenness issue. > devices can do is to select the interface identifier by some other > means and then perform Duplicate Address Detection, as specified in > RFC 4862. The PDN GW shall then perform the DAD check based on the > Neighbor Solicitation messages sent by the UE. A GGSN/PPGW is already supposed to perform a DAD check. Referring to = 3GPP TS29.061 Section 11.2.1.3.4, which says: "For IPv6 Address Autoconfiguration to work properly, network entities = which act as an access router towards the MS/UE, i.e. PDN GW, Serving = GW, and ePDG, shall be consistent with the RFCs specifying this process = (for example RFC 4862 [83] and RFC 4861 [89]), unless stated otherwise = in this or other 3GPP specifications." And there is no text in specs that would state using "shall" that the = PGW/GGSN/SGW must not perform DAD check or not to answer to an NS.. on a = contrary (see text in Section 11.2.3.2 & 11.2.3.2a.. not that the text = is the best regarding handling an NS but still). > Therefore, there are some implementation factors that may change UE > behaviour in the CPE context. IMHO, it would be beneficial to describe > CPE consideration in section 5.3. CPE case has already appeared to be > a valid scenario in 3GPP I still cannot see any CPE specific considerations here. I witness same = thing almost daily with my 3G dongle, which was the reason for = http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html. - Jouni >=20 > BRs >=20 > Gang >=20 > 2011/8/5, Jouni : >> Dear Gang, >>=20 >> I would be inclined to say that within the 3GPP scope the client is = always >> the "UE" and its form factor or the end usage scenario does not = really >> matter. It does not change the way the UE is expected to behave from = the >> 3GPP system point of view, unless there is a new functional = requirement from >> 3GPP. >>=20 >> - Jouni >>=20 >>=20 >>=20 >> On Aug 5, 2011, at 5:55 AM, GangChen wrote: >>=20 >>> Hello Authors, >>>=20 >>> I think it is worth adding some texts to describe mobile CPE case, = in >>> which CPEs with wireless modem use 3GPP access as uplink. >>>=20 >>> Gang >>>=20 >>>=20 >>> 2011/8/2, The IESG : >>>>=20 >>>> The IESG has received a request from the IPv6 Operations WG (v6ops) = to >>>> consider the following document: >>>> - 'IPv6 in 3GPP Evolved Packet System' >>>> as an Informational RFC >>>>=20 >>>> The IESG plans to make a decision in the next few weeks, and = solicits >>>> final comments on this action. Please send substantive comments to = the >>>> ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments = may be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> Use of data services in smart phones and broadband services via = HSPA >>>> and HSPA+, in particular Internet services, has increased rapidly = and >>>> operators that have deployed networks based on 3GPP network >>>> architectures are facing IPv4 address shortages at the Internet >>>> registries and are feeling a pressure to migrate to IPv6. This >>>> document describes the support for IPv6 in 3GPP network >>>> architectures. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>>>=20 >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>>>=20 >>>>=20 >>>> No IPR declarations have been submitted directly on this I-D. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >>=20 From phdgang@gmail.com Wed Aug 10 03:11:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3754E21F84A5; Wed, 10 Aug 2011 03:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EOZspI-d6M2; Wed, 10 Aug 2011 03:11:56 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFF521F8698; Wed, 10 Aug 2011 03:11:56 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 829406FCC10; Wed, 10 Aug 2011 12:20:56 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 797286FCC0F; Wed, 10 Aug 2011 12:20:56 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 11:55:50 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:12:18 +0200 Received: from omfedm06.si.francetelecom.fr ([10.98.84.130]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:15:14 +0200 Received: from omfedm11.si.francetelecom.fr (unknown [10.98.62.19]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8607927C072; Tue, 9 Aug 2011 18:14:44 +0200 (CEST) Received: from omfedm11.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with SMTP id 769FF3B43DE; Tue, 9 Aug 2011 18:14:44 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 1EAA83B43DC; Tue, 9 Aug 2011 18:14:44 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761CA21F8C49; Tue, 9 Aug 2011 09:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312906439; bh=hLA8d1UKyannyQMRdKT75c2d6CHpYNjAQr1fo8HCojk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mywyDjbnS7SzDTrtzLupLYf4ppobcZZhhk4or9t9HEeBIWNakD2MoAuoS9HcCk5ZI DlQtsNeN8hXCt2eHfq/CLH533SfZZ7o+QEcq3p720sjXOUrfQbqZAOnAAU07Hk+hay tIuKr5mpdw+dJNnUPFbBEr7AHX2SBW+MurMLDonA= X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB621F8C20; Tue, 9 Aug 2011 09:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vXDyoDiTKtk; Tue, 9 Aug 2011 09:13:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA921F8C1A; Tue, 9 Aug 2011 09:13:56 -0700 (PDT) Received: by vxi29 with SMTP id 29so142051vxi.31 for ; Tue, 09 Aug 2011 09:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L4SAryZ0/owXXo8VYcWV6BJW7PEVXhHp8Wsz6dwsXJg=; b=MF3KtqBv4ciSvTc8AoO1clSkAV4TiElysMDblVxnE7DBBjNCFAaKOnJ57GPTi+8S7r WcCk3/3pFZ6meCnAADwBJdeV7JeDEV3eMp9UKnch3MOU0v87DUuDyWkp+oZIMhBrHrxz Em7FAEKrXBrF1lwNTadTYsxBX+wD7RM0PbM7A= MIME-Version: 1.0 Received: by 10.52.180.102 with SMTP id dn6mr6442281vdc.51.1312906465150; Tue, 09 Aug 2011 09:14:25 -0700 (PDT) Received: by 10.52.169.129 with HTTP; Tue, 9 Aug 2011 09:14:25 -0700 (PDT) In-Reply-To: <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> References: <20110801190301.16571.58632.idtracker@ietfa.amsl.com> <49A19FE6-7B0A-4876-8F1A-308F978CC8FC@gmail.com> Date: Wed, 10 Aug 2011 00:14:25 +0800 Message-ID: From: GangChen To: Jouni X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.160314 X-OriginalArrivalTime: 09 Aug 2011 16:15:14.0783 (UTC) FILETIME=[859D0EF0:01CC56AF] Cc: v6ops@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC X-BeenThere: v6ops@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:11:57 -0000 Dear Jouni, In mobile CPE case, MT and TE are separated. That would need additional requirements in some particular cases, e.g. dynamic IPv6 address allocation. According to the 3GPP specification, the UE shall build the link-local address using the interface identifier provided by the PDN GW upon PDN connection establishment. However, MT may not be able to transfer the interface identifier to TE in the CPE cases. The only thing the IP devices can do is to select the interface identifier by some other means and then perform Duplicate Address Detection, as specified in RFC 4862. The PDN GW shall then perform the DAD check based on the Neighbor Solicitation messages sent by the UE. Therefore, there are some implementation factors that may change UE behaviour in the CPE context. IMHO, it would be beneficial to describe CPE consideration in section 5.3. CPE case has already appeared to be a valid scenario in 3GPP BRs Gang 2011/8/5, Jouni : > Dear Gang, > > I would be inclined to say that within the 3GPP scope the client is always > the "UE" and its form factor or the end usage scenario does not really > matter. It does not change the way the UE is expected to behave from the > 3GPP system point of view, unless there is a new functional requirement from > 3GPP. > > - Jouni > > > > On Aug 5, 2011, at 5:55 AM, GangChen wrote: > >> Hello Authors, >> >> I think it is worth adding some texts to describe mobile CPE case, in >> which CPEs with wireless modem use 3GPP access as uplink. >> >> Gang >> >> >> 2011/8/2, The IESG : >>> >>> The IESG has received a request from the IPv6 Operations WG (v6ops) to >>> consider the following document: >>> - 'IPv6 in 3GPP Evolved Packet System' >>> as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> Use of data services in smart phones and broadband services via HSPA >>> and HSPA+, in particular Internet services, has increased rapidly and >>> operators that have deployed networks based on 3GPP network >>> architectures are facing IPv4 address shortages at the Internet >>> registries and are feeling a pressure to migrate to IPv6. This >>> document describes the support for IPv6 in 3GPP network >>> architectures. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From brian.e.carpenter@gmail.com Wed Aug 10 14:45:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1211E80B0 for ; Wed, 10 Aug 2011 14:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.601 X-Spam-Level: X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPoW8tKhmTDw for ; Wed, 10 Aug 2011 14:45:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1557211E80AA for ; Wed, 10 Aug 2011 14:45:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so1119676gwb.31 for ; Wed, 10 Aug 2011 14:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zxdqM+h7gXIeBzUx2Q/B83M8spLmqxi86V8Q1kwvksc=; b=dHkvfMjxiCrnHA1Kr5YQEzZXkJkPyXbrDP8rfK73q4FuircoIBPEG9xrlq6xyxGiAK /mCUW7VwyI+WXrM0P2QCofULvzREdkiStG5qZEyyXutVumI+qPrk9etELBXq+F3PrGP9 /SM01NWS/2hKB5SrbwkYy8wjOAk6+Efljba6M= Received: by 10.236.177.38 with SMTP id c26mr9090099yhm.120.1313012739138; Wed, 10 Aug 2011 14:45:39 -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 c6sm352374yhm.16.2011.08.10.14.45.37 (version=SSLv3 cipher=OTHER); Wed, 10 Aug 2011 14:45:38 -0700 (PDT) Message-ID: <4E42FBFE.5040001@gmail.com> Date: Thu, 11 Aug 2011 09:45:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20110810140458.30462.12113.idtracker@ietfa.amsl.com> In-Reply-To: <20110810140458.30462.12113.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-troan-v6ops-6to4-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:45:08 -0000 This looks fine to me. s/[I-D.ietf-v6ops-6to4-advisory]/[RFC6343]/ Regards Brian Carpenter From fred@cisco.com Thu Aug 11 06:54:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E713D21F8752 for ; Thu, 11 Aug 2011 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.144 X-Spam-Level: X-Spam-Status: No, score=-105.144 tagged_above=-999 required=5 tests=[AWL=-2.545, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epb4gO7RK5eN for ; Thu, 11 Aug 2011 06:54:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 512C621F865F for ; Thu, 11 Aug 2011 06:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=131; q=dns/txt; s=iport; t=1313070902; x=1314280502; h=date:from:message-id:to:subject:cc; bh=6ksuEGUSlTgZePTynel2ByiwOWgOWKkWw4jcgrAsxZA=; b=Ku942v1iIOrQW0BJHzoxRoarqIKyK118h8mF5Iel/5Gx1mH9oa/rXVhU 0SXF+t8WNUMXbSJD7KGaAtZKA9R2jsutJOf2vVTsowZKeh3vI4txFcRXU iX7R/MFtzkRs5b80oKQJw/aoMGPTDZbmlA1ydasn8uV5q1hSylPDrmw+a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsIAOTeQ06rRDoH/2dsb2JhbABBmEABAY8Fd4FZAWY8LYEKh1GdZgGefoZHBIdfnD4 X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208";a="12190242" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 11 Aug 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7BDt1Hi032378; Thu, 11 Aug 2011 13:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p7BDt1G05082; Thu, 11 Aug 2011 06:55:01 -0700 (PDT) Date: Thu, 11 Aug 2011 06:55:01 -0700 (PDT) From: Message-Id: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-troan-v6ops-6to4-update@tools.ietf.org Subject: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:54:28 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at it and comment. From ietfc@btconnect.com Thu Aug 11 08:07:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3D21F86D8 for ; Thu, 11 Aug 2011 08:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxWDAf9or7lK for ; Thu, 11 Aug 2011 08:07:47 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1083E21F85C0 for ; Thu, 11 Aug 2011 08:07:46 -0700 (PDT) Received: from host81-159-99-55.range81-159.btcentralplus.com (HELO pc6) ([81.159.99.55]) by c2beaomr07.btconnect.com with SMTP id DYM80050; Thu, 11 Aug 2011 16:08:17 +0100 (BST) Message-ID: <01ee01cc582f$a5de0580$4001a8c0@gateway.2wire.net> From: "t.petch" To: , References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> Date: Thu, 11 Aug 2011 16:04:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E43F061.00E9, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.11.134814:17:7.586, ip=81.159.99.55, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4E43F062.00D1,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:07:48 -0000 I still think that what we want is an applicability statement and so would like to see that in the title. Clouds I think wrong, since cloud computing is all the rage and while this use of the term is technically correct, I think that it will be widely misunderstood. eg Applicability Statement for 6to4; a Last Resort. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Thursday, August 11, 2011 3:55 PM Subject: [v6ops] new draft: draft-troan-v6ops-6to4-update > > A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Thu Aug 11 08:10:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D59721F89C1 for ; Thu, 11 Aug 2011 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBfsoOVE3hZz for ; Thu, 11 Aug 2011 08:10:43 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id 502A821F8749 for ; Thu, 11 Aug 2011 08:10:43 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 5393428425 for ; Thu, 11 Aug 2011 16:11:17 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLzGbR6UYd7m for ; Thu, 11 Aug 2011 16:11:15 +0100 (IST) Received: from cupcake.local (unknown [IPv6:2001:1bb8:2004:100:1d7d:1dc6:559e:1c0a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by prometheus.inex.ie (Postfix) with ESMTPSA id 92DB728423 for ; Thu, 11 Aug 2011 16:11:15 +0100 (IST) Message-ID: <4E43F112.3070009@inex.ie> Date: Thu, 11 Aug 2011 16:11:14 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> In-Reply-To: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> X-Enigmail-Version: 1.2 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 Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:10:44 -0000 > Implementations capable of acting as 6to4 routers MUST NOT enable > 6to4 without explicit user configuration. In particular, enabling > IPv6 forwarding on a device, MUST NOT automatically enable 6to4. Could I suggest that this text explicitly references the definitions in section 2 of RFC3068, and also that it should note that the guidelines here apply both to 6to4 routers and also 6to4 relay routers as defined in rfc3068? It would be unfortunate to see an implementer reading "6to4 router" as the relay device rather and then effectively ignoring the recommendations in this document. > When performing address selection, connections between an IPv4 source > and destination address SHOULD be preferred to connections either > between a 6to4 source address and a native v6 destination address, or > between a native v6 source address and a 6to4 destination address. nit: either "v4" and "v6" or preferably "IPv4" and "IPv6". Nick From Fred.L.Templin@boeing.com Thu Aug 11 08:12:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48F21F87FC for ; Thu, 11 Aug 2011 08:12:53 -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=[AWL=-0.442, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzHiPoKFBF91 for ; Thu, 11 Aug 2011 08:12:52 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1121F85F2 for ; Thu, 11 Aug 2011 08:12:49 -0700 (PDT) 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 p7BFD7lB005498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2011 08:13:10 -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 p7BFD7r7018705; Thu, 11 Aug 2011 08:13:07 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p7BFClx3017994 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Aug 2011 08:13:06 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 11 Aug 2011 08:13:04 -0700 From: "Templin, Fred L" To: "t.petch" , "fred@cisco.com" , "v6ops@ietf.org" Date: Thu, 11 Aug 2011 08:13:02 -0700 Thread-Topic: [v6ops] new draft: draft-troan-v6ops-6to4-update Thread-Index: AcxYOJPZgsiWa30VT62bptpeSGCWAgAADlcQ Message-ID: References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> <01ee01cc582f$a5de0580$4001a8c0@gateway.2wire.net> In-Reply-To: <01ee01cc582f$a5de0580$4001a8c0@gateway.2wire.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-troan-v6ops-6to4-update@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:12:53 -0000 Or even just: "6to4 Scenarios (SixthSense)" Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of t.petch > Sent: Thursday, August 11, 2011 7:05 AM > To: fred@cisco.com; v6ops@ietf.org > Cc: draft-troan-v6ops-6to4-update@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update >=20 > I still think that what we want is an applicability statement=20 > and so would like > to see that in the title. >=20 > Clouds I think wrong, since cloud computing is all the rage=20 > and while this use > of the term is technically correct, I think that it will be widely > misunderstood. >=20 > eg > Applicability Statement for 6to4; a Last Resort. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: > To: > Cc: > Sent: Thursday, August 11, 2011 3:55 PM > Subject: [v6ops] new draft: draft-troan-v6ops-6to4-update >=20 >=20 > > > > A new draft has been posted, at > http://tools.ietf.org/html/draft-troan-v6ops-6to4-update.=20 > Please take a look at > it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From cb.list6@gmail.com Thu Aug 11 09:12:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094E221F8BA4 for ; Thu, 11 Aug 2011 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmHejwHDv9sr for ; Thu, 11 Aug 2011 09:12:17 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 47EFA21F8B65 for ; Thu, 11 Aug 2011 09:12:17 -0700 (PDT) Received: by wwe5 with SMTP id 5so4247356wwe.1 for ; Thu, 11 Aug 2011 09:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qJDZGg0y/rom5yXsxoeTVJEf32Nivn5lBGFIm7e8u2U=; b=kA/j4v/775qa9UQXEE6azTXTlQOBMk6w1LABOY6mKsVEbe0DOr6L4KtVW1/fH1cy2P AM3ymNcN/93FZCFtChgX5abx7NhALCVG9Q42PJevM94lXqgX0vlGBnCp1yn6ojnAAkF0 468HTAxf3E+kCn5Lhq4SO9TbCo2aI9AAnUQZI= MIME-Version: 1.0 Received: by 10.216.168.193 with SMTP id k43mr7145336wel.95.1313079171229; Thu, 11 Aug 2011 09:12:51 -0700 (PDT) Received: by 10.216.185.11 with HTTP; Thu, 11 Aug 2011 09:12:51 -0700 (PDT) In-Reply-To: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> Date: Thu, 11 Aug 2011 09:12:51 -0700 Message-ID: From: Cameron Byrne To: fred@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:12:18 -0000 On Thu, Aug 11, 2011 at 6:55 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at it and comment. > Is there a need for this to be standards track or even a working group document? I strongly feel the IETF has spent too much time on this and any more time is waste of effort. RFC6343 is good enough. Cameron From despres.remi@laposte.net Thu Aug 11 10:00:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDDB21F8B22 for ; Thu, 11 Aug 2011 10:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehUfD61mJVkn for ; Thu, 11 Aug 2011 10:00:05 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4221F8B1F for ; Thu, 11 Aug 2011 10:00:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 4BA7770000A7; Thu, 11 Aug 2011 19:00:37 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 620C3700013E; Thu, 11 Aug 2011 19:00:32 +0200 (CEST) X-SFR-UUID: 20110811170032401.620C3700013E@msfrf2312.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 11 Aug 2011 19:00:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:00:05 -0000 Le 11 ao=FBt 2011 =E0 18:12, Cameron Byrne a =E9crit : > On Thu, Aug 11, 2011 at 6:55 AM, wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a = look at it and comment. >>=20 >=20 > Is there a need for this to be standards track or even a working group = document? >=20 > I strongly feel the IETF has spent too much time on this and any more > time is waste of effort. >=20 > RFC6343 is good enough. +1 RD >=20 > Cameron > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Thu Aug 11 10:10:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7515921F8BCB for ; Thu, 11 Aug 2011 10:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGgVIMQDFQm9 for ; Thu, 11 Aug 2011 10:10:47 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DA1F321F8BB8 for ; Thu, 11 Aug 2011 10:10:47 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id A2D5520E9B; Thu, 11 Aug 2011 13:11:22 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 11 Aug 2011 13:11:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=pIEop0fWHmwr9NxxQyVywLwJutA=; b=d2 5pT1uUus4hK9qMVSIq49bvpHlM4CQbvPcDpJY8vgmOOyHhIsy/XwqVth+PGTfL9z hJcbmn55yhwG5DDMuQWg5IzK294g55F7FE9/hfFy3ssyh9xLM+Qc9XivWzN9z0To EUGRXTlb7LzylwViXf4MO4Wyeb7Y4oclNnCfDkUZo= X-Sasl-enc: PUSGpFuy85lhwICcg52v7xE9bI0Wr6vKMxXJPkbhKtJ0 1313082681 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E7DE45CC4E; Thu, 11 Aug 2011 13:11:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 11 Aug 2011 13:11:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:10:48 -0000 On Aug 11, 2011, at 12:12 PM, Cameron Byrne wrote: > Is there a need for this to be standards track or even a working group = document? >=20 > I strongly feel the IETF has spent too much time on this and any more > time is waste of effort. >=20 > RFC6343 is good enough. Several people have expressed a strong desire for a document that = "updates" RFCs 3056 and 3068. =46rom a process point-of-view, it's not = clear (to me) that such an update has to be a standards-track document. = But having it be standards-track would make it clear to the public that = the statement represents (rough) IETF consensus. =46rom a process POV, this doesn't have to be a v6ops WG document. It = could be treated as an individual submission and given a 4-week = community-wide Last Call. That decision is up to the WG chairs and = AD. But even if it were treated as an individual submission, IESG = would certainly ask v6ops participants to comment on it. =20 For those who wish to minimize the amount of discussion on the v6ops = list, comments to the authors (without cc'ing the v6ops list) are = certainly welcome. Keith From pch-b29AA871B@u-1.phicoh.com Fri Aug 12 05:30:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B493221F8747 for ; Fri, 12 Aug 2011 05:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.505 X-Spam-Level: X-Spam-Status: No, score=-4.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S883AIuqi7sm for ; Fri, 12 Aug 2011 05:30:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E968C21F8752 for ; Fri, 12 Aug 2011 05:30:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qrqt5-0001iqC; Fri, 12 Aug 2011 14:30:55 +0200 Message-Id: To: fred@cisco.com From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com In-reply-to: Your message of "Thu, 11 Aug 2011 06:55:01 -0700 (PDT) ." <201108111355.p7BDt1G05082@ftpeng-update.cisco.com> Date: Fri, 12 Aug 2011 14:30:36 +0200 Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:30:27 -0000 In your letter dated Thu, 11 Aug 2011 06:55:01 -0700 (PDT) you wrote: >A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6 >to4-update. Please take a look at it and comment. I guess it can't hurt to say that 6to4 must be off by default. Then the draft proceeds to disucss address selection. And that's a bit curious. The text there is already covered by 3484bis. But the draft is strangely silent about whether to prefer an IPv4 connection over a connection between two 6to4 addresses. (This is also covered in 3484bis, so that text should at least refer to 3484bis) From tjc@ecs.soton.ac.uk Fri Aug 12 05:57:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F821F84E2 for ; Fri, 12 Aug 2011 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbHTJBSY-Vrp for ; Fri, 12 Aug 2011 05:57:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0121F84D7 for ; Fri, 12 Aug 2011 05:56:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CCvYbH008912 for ; Fri, 12 Aug 2011 13:57:34 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p7CCvYbH008912 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1313153855; bh=aKSTzm+cEdkYcoEHpzEUJVGxiQY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=xqKGaADCCfJeRARcc5JvNDM6zBC4mo+fTznpZYXGkApvWmnChSYT4U8SZl4NzlgT0 7DJlb9LyjeDExnFV3PMVHldjPD7e8t9YPTXmZOgil/S+nxbmqtNTjQX5ajM6mdy6c7 3uyngtBGvnGxf6mKx9cIMKPVjLRd0EFUgX844ccs= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n7BDvY0366105046Nc ret-id none; Fri, 12 Aug 2011 13:57:34 +0100 Received: from [IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927] ([IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CCvWBO032213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Aug 2011 13:57:32 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: Date: Fri, 12 Aug 2011 13:57:32 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: IPv6 Operations Working Group X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n7BDvY036610504600; tid=n7BDvY0366105046Nc; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p7CCvYbH008912 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:57:00 -0000 On 12 Aug 2011, at 13:30, Philip Homburg wrote: > In your letter dated Thu, 11 Aug 2011 06:55:01 -0700 (PDT) you wrote: >> A new draft has been posted, at = http://tools.ietf.org/html/draft-troan-v6ops-6 >> to4-update. Please take a look at it and comment. >=20 > I guess it can't hurt to say that 6to4 must be off by default. Which is already said in -advisory. > Then the draft proceeds to disucss address selection. And that's a bit=20= > curious. The text there is already covered by 3484bis. But the draft = is > strangely silent about whether to prefer an IPv4 connection over a=20 > connection between two 6to4 addresses. (This is also covered in = 3484bis, > so that text should at least refer to 3484bis) I noticed that too. This document adds little new, and if anything only = adds confusion. Tim= From moore@network-heretics.com Fri Aug 12 06:34:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D666A21F8A6F for ; Fri, 12 Aug 2011 06:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJHhEJWOsZEA for ; Fri, 12 Aug 2011 06:34:26 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 263E821F8A62 for ; Fri, 12 Aug 2011 06:34:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3F73A2156B; Fri, 12 Aug 2011 09:35:01 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 12 Aug 2011 09:35:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=3rz2cd8lNF68pCpw7K4XdYsTguk=; b=H1 RNB2xLNb/liT/LMQdaEaBiHGe/EF/7zBFmi0QUcnjJifp/mJQsxVz+sLhak6GhtQ K4lwMLcId0T/fU1XZruFdQE2xZzGnp8gn1fu2N/SThrcnX2jgeuIb04SkY/m72Rg Q1k6LfttlKtXM2PXMsqSY67sKW6I6EHUKaBZnWkNE= X-Sasl-enc: bmGyTLThwtj9rHHJhDOTc1UvzsnLaq+W37JO7KOA8WY5 1313156100 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4594545D32E; Fri, 12 Aug 2011 09:35:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 12 Aug 2011 09:34:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68862319-4CB9-46C7-91D0-9A0B9B142791@network-heretics.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:34:26 -0000 On Aug 12, 2011, at 8:30 AM, Philip Homburg wrote: > In your letter dated Thu, 11 Aug 2011 06:55:01 -0700 (PDT) you wrote: >> A new draft has been posted, at = http://tools.ietf.org/html/draft-troan-v6ops-6 >> to4-update. Please take a look at it and comment. >=20 > I guess it can't hurt to say that 6to4 must be off by default. >=20 > Then the draft proceeds to disucss address selection. And that's a bit=20= > curious. The text there is already covered by 3484bis. But the draft = is > strangely silent about whether to prefer an IPv4 connection over a=20 > connection between two 6to4 addresses. (This is also covered in = 3484bis, > so that text should at least refer to 3484bis) My impression from what I heard in Quebec City is that 3484-revise might = still take a while to get through the 6man WG, and it seems that many = people want an RFC that "updates" 6to4 to be issued as quickly as = possible. If 3484-revise were approved before -update is submitted, I = agree that an explicit reference to 3484bis in -update would be = appropriate.=20 Keith From pch-b29AA871B@u-1.phicoh.com Fri Aug 12 06:58:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED621F881C for ; Fri, 12 Aug 2011 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.339 X-Spam-Level: X-Spam-Status: No, score=-8.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcxz34ZKWhKr for ; Fri, 12 Aug 2011 06:58:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 63E4721F87ED for ; Fri, 12 Aug 2011 06:58:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QrsFy-0001iTC; Fri, 12 Aug 2011 15:58:38 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <68862319-4CB9-46C7-91D0-9A0B9B142791@network-heretics.com> In-reply-to: Your message of "Fri, 12 Aug 2011 09:34:59 -0400 ." <68862319-4CB9-46C7-91D0-9A0B9B142791@network-heretics.com> Date: Fri, 12 Aug 2011 15:58:13 +0200 Cc: v6ops@ietf.org, draft-troan-v6ops-6to4-update@tools.ietf.org Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:58:04 -0000 In your letter dated Fri, 12 Aug 2011 09:34:59 -0400 you wrote: >> so that text should at least refer to 3484bis) > >My impression from what I heard in Quebec City is that 3484-revise might = >still take a while to get through the 6man WG, and it seems that many = >people want an RFC that "updates" 6to4 to be issued as quickly as = >possible. If 3484-revise were approved before -update is submitted, I = >agree that an explicit reference to 3484bis in -update would be = >appropriate.=20 I don't think a non-normative reference to RFC3484-revise would hurt. It is directed at different products/parts of products anyhow. Keeping 6to4 off by default applies to routers implementing 6to4 functionality. (And in theory also hosts with 6to4 functionality). RFC3484-revise has to be implemented by each an every host even if the host doesn't do anything with 6to4 because a local router may provide 6to4 to the host. From tjc@ecs.soton.ac.uk Fri Aug 12 07:07:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD121F8A23 for ; Fri, 12 Aug 2011 07:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocmuHGLLbLXy for ; Fri, 12 Aug 2011 07:07:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D80721F89BE for ; Fri, 12 Aug 2011 07:07:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CE8Vt9028647 for ; Fri, 12 Aug 2011 15:08:31 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p7CE8Vt9028647 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1313158111; bh=fBUxugYBty2/oVpWZVIF+bnpj2g=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=3eUuLoxt3ZTxqp6TiltP+g90tXsqeKz/ie6AQweM/Jm5yenZ4isSLFXe5GRpAM1Yk 8vBqucoeWonqUV+E3C7XVBYrUoOzhN+jA2EipTfy+1l+Yv8mx0HuhzvNOKirhGBXG2 ooQp4Y0XVAnWX8jannuUngBGnR1Ch7FrhMQn43DY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n7BF8V03661055909z ret-id none; Fri, 12 Aug 2011 15:08:31 +0100 Received: from [IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927] ([IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CE8S5F015901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Aug 2011 15:08:28 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: Date: Fri, 12 Aug 2011 15:08:28 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <68862319-4CB9-46C7-91D0-9A0B9B142791@network-heretics.com> To: IPv6 Operations Working Group X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n7BF8V036610559000; tid=n7BF8V03661055909z; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p7CE8Vt9028647 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:07:57 -0000 3484-bis should be being last called. I'll pop Brian and Bob a mail. = The only slight question mark on it was a privacy bit indicator, but = that can be resolved in WGLC. Tim On 12 Aug 2011, at 14:58, Philip Homburg wrote: > In your letter dated Fri, 12 Aug 2011 09:34:59 -0400 you wrote: >>> so that text should at least refer to 3484bis) >>=20 >> My impression from what I heard in Quebec City is that 3484-revise = might =3D >> still take a while to get through the 6man WG, and it seems that many = =3D >> people want an RFC that "updates" 6to4 to be issued as quickly as =3D >> possible. If 3484-revise were approved before -update is submitted, = I =3D >> agree that an explicit reference to 3484bis in -update would be =3D >> appropriate.=3D20 >=20 > I don't think a non-normative reference to RFC3484-revise would hurt. >=20 > It is directed at different products/parts of products anyhow. Keeping=20= > 6to4 off by default applies to routers implementing 6to4 = functionality. > (And in theory also hosts with 6to4 functionality). >=20 > RFC3484-revise has to be implemented by each an every host even if the = host > doesn't do anything with 6to4 because a local router may provide 6to4 = to > the host. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rashmi@kth.se Sun Aug 14 07:13:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1FD21F8A56 for ; Sun, 14 Aug 2011 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY9UNOUXCMB8 for ; Sun, 14 Aug 2011 07:13:29 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87D21F8512 for ; Sun, 14 Aug 2011 07:13:28 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 7F33014FB17; Sun, 14 Aug 2011 16:13:40 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id MqhrpF5nzCGO; Sun, 14 Aug 2011 16:13:39 +0200 (CEST) X-KTH-Auth: rashmi [213.103.214.96] X-KTH-mail-from: rashmi@kth.se Received: from [127.0.0.1] (s213-103-214-96.cust.tele2.se [213.103.214.96]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 1647A14FAE2; Sun, 14 Aug 2011 16:13:39 +0200 (CEST) Message-ID: <4E47D811.6090107@kth.se> Date: Sun, 14 Aug 2011 16:13:37 +0200 From: Rashmi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org, dwing@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 14:13:29 -0000 Hello, In the presentation in the recent IETF meeting, (http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx) in the last but one slide, it is mentioned that "Existing Chrome and Firefox Implementations are compliant". Does this mean that Google chrome and firefox had "happy eyeballs" implementation? -- Regards, Rashmi Purushothama From joelja@bogus.com Sun Aug 14 07:35:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740E721F8A55 for ; Sun, 14 Aug 2011 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v86PiNAS83hh for ; Sun, 14 Aug 2011 07:35:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0721F8761 for ; Sun, 14 Aug 2011 07:35:47 -0700 (PDT) Received: from [192.168.43.44] ([206.29.182.138]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7EEaJB1088238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Aug 2011 14:36:25 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E47D811.6090107@kth.se> Date: Sun, 14 Aug 2011 07:36:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E47D811.6090107@kth.se> To: Rashmi X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Aug 2011 14:36:28 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 14:35:47 -0000 yes, they do. joel On Aug 14, 2011, at 7:13 AM, Rashmi wrote: > Hello, >=20 > In the presentation in the recent IETF meeting, = (http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx) in the last but = one slide, it is mentioned that "Existing Chrome and Firefox = Implementations are compliant". > Does this mean that Google chrome and firefox had "happy eyeballs" = implementation? >=20 > --=20 > Regards, > Rashmi Purushothama >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From rashmi@kth.se Sun Aug 14 07:59:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCBB21F8A51 for ; Sun, 14 Aug 2011 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkvXwgGxOGpC for ; Sun, 14 Aug 2011 07:59:03 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id ED8F921F8754 for ; Sun, 14 Aug 2011 07:59:02 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 5CB2214FB93; Sun, 14 Aug 2011 16:59:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 8r+JYDM59RBV; Sun, 14 Aug 2011 16:59:13 +0200 (CEST) X-KTH-Auth: rashmi [213.103.214.96] X-KTH-mail-from: rashmi@kth.se Received: from [127.0.0.1] (s213-103-214-96.cust.tele2.se [213.103.214.96]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E58C814FB8D; Sun, 14 Aug 2011 16:59:11 +0200 (CEST) Message-ID: <4E47E2BD.2020609@kth.se> Date: Sun, 14 Aug 2011 16:59:09 +0200 From: Rashmi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joel Jaeggli References: <4E47D811.6090107@kth.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 14:59:03 -0000 Hello Joel, Thank you for the quick response. Is there any document I could refer regarding these implementations? -- Regards, Rashmi Purushothama On 2011-Aug-14 Sun 4:36 PM, Joel Jaeggli wrote: > yes, they do. > > joel > > On Aug 14, 2011, at 7:13 AM, Rashmi wrote: > >> Hello, >> >> In the presentation in the recent IETF meeting, (http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx) in the last but one slide, it is mentioned that "Existing Chrome and Firefox Implementations are compliant". >> Does this mean that Google chrome and firefox had "happy eyeballs" implementation? >> >> -- >> Regards, >> Rashmi Purushothama >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From joelja@bogus.com Sun Aug 14 08:20:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0335721F8AED for ; Sun, 14 Aug 2011 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6GBHYBYJOb9 for ; Sun, 14 Aug 2011 08:20:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2697B21F8AEA for ; Sun, 14 Aug 2011 08:20:41 -0700 (PDT) Received: from [192.168.43.44] ([206.29.182.138]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7EFLCX8090608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Aug 2011 15:21:21 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E47E2BD.2020609@kth.se> Date: Sun, 14 Aug 2011 08:21:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <769E341E-BD9A-44B5-BD64-D75ACDCA9C35@bogus.com> References: <4E47D811.6090107@kth.se> <4E47E2BD.2020609@kth.se> To: Rashmi X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Aug 2011 15:21:23 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 15:20:42 -0000 think is started here in chromium... http://src.chromium.org/viewvc/chrome?view=3Drev&revision=3D85934 in firefox you can see it here. https://bugzilla.mozilla.org/show_bug.cgi?id=3D621558 On Aug 14, 2011, at 7:59 AM, Rashmi wrote: > Hello Joel, >=20 > Thank you for the quick response. Is there any document I could refer = regarding these implementations? >=20 > --=20 > Regards, > Rashmi Purushothama >=20 >=20 > On 2011-Aug-14 Sun 4:36 PM, Joel Jaeggli wrote: >> yes, they do. >>=20 >> joel >>=20 >> On Aug 14, 2011, at 7:13 AM, Rashmi wrote: >>=20 >>> Hello, >>>=20 >>> In the presentation in the recent IETF meeting, = (http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx) in the last but = one slide, it is mentioned that "Existing Chrome and Firefox = Implementations are compliant". >>> Does this mean that Google chrome and firefox had "happy eyeballs" = implementation? >>>=20 >>> --=20 >>> Regards, >>> Rashmi Purushothama >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >=20 From cpignata@cisco.com Sun Aug 14 10:02:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F84F21F8570 for ; Sun, 14 Aug 2011 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPgAWd5DuaLU for ; Sun, 14 Aug 2011 10:02:43 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4A21F8565 for ; Sun, 14 Aug 2011 10:02:43 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7EH3Pjn006196 for ; Sun, 14 Aug 2011 13:03:25 -0400 (EDT) Received: from [10.117.115.54] (rtp-cpignata-8915.cisco.com [10.117.115.54]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7EH3P7I002861 for ; Sun, 14 Aug 2011 13:03:25 -0400 (EDT) Message-ID: <4E47FFD4.5080307@cisco.com> Date: Sun, 14 Aug 2011 13:03:16 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 17:02:44 -0000 Hi, I believe there was one further point raised in regards to draft-elkins-6man-ipv6-diagnostic-header (though I don't recall if it was at the mike by Andrew Y., in a corridor, or only in my head): the Heisenbug principle -- if this is used in debugging (and diagnostics), the issue being studied or attempted to reproduce alters its behavior or goes away when modifying the packet (like compiling with different -o). I think this is one of the most important arguments against this proposal. The use of fragment header is interesting, a new header could show much more pronounced deviation of observed behaviour than without it. For completeness, I did ask some services escalation engineers about how they use the ip-id in IPv4 for troubleshooting, and basically got two main uses for very corner case situations in: i. identify middleboxes and their characteristics (by check IP ID increment patterns, find if packets generated by the same box), and ii. track set of packets along different points in the network (e.g., back-to-back packets and see rate, drops, out of order). But it's built into the v4 header. Thanks, -- Carlos. On 8/2/2011 1:24 PM, Joel Jaeggli wrote: > * Presentation - RFC for IPv6 IP identification field (header) - Mike Ackerman > http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header > > Fred B - Question for the group, do you use the IPID in ipv4? (no > respondants other than presenters) > > Weg G - We use it all the time? I've never heard of it... > > Francis D - it's potentially a covert channel, also why not use the > fregmentation header? > > Bob H - We diefintently want to hear if this is useful. I don't know > who puts this header in the packet? > > Nalini ? - The host clearly > > Andrei Y - typical use case for this header would be to see if a > middle box is modifying the packet. > > Fred B - What I'm out of this discussion is that the application isn't > a bad one, it could be simulated in a fregment. > > Fred Baker - Meeting complete, go to Lunch From nalini.elkins@insidethestack.com Sun Aug 14 13:32:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4011E8083 for ; Sun, 14 Aug 2011 13:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znBr+Rxjd3qY for ; Sun, 14 Aug 2011 13:32:16 -0700 (PDT) Received: from nm3.access.bullet.mail.mud.yahoo.com (nm3.access.bullet.mail.mud.yahoo.com [66.94.237.204]) by ietfa.amsl.com (Postfix) with SMTP id DE94E11E8070 for ; Sun, 14 Aug 2011 13:32:15 -0700 (PDT) Received: from [66.94.237.127] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Aug 2011 20:31:16 -0000 Received: from [66.94.237.121] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Aug 2011 20:31:16 -0000 Received: from [127.0.0.1] by omp1026.access.mail.mud.yahoo.com with NNFMP; 14 Aug 2011 20:31:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 928987.42007.bm@omp1026.access.mail.mud.yahoo.com Received: (qmail 90890 invoked by uid 60001); 14 Aug 2011 20:31:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313353876; bh=g98KoH2qaN011rJEnUEXCMUPNuBu0TG6h6HyS5emc8c=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wBuLePuCMmEgB62UETVxPiqHZ1aOepc3E5KyLzMbVkbPp/DZGMA0jyHgY+BNlHd2wZDCB7gTCXoyCWEcz6OX98am23ixHp/740lKNHCjCDj3MCXlzMoNGRM+uux0NmLdVhu1JZb3JUtprx3oiMP59agsn/Kpd09ab4JkH9xLSzM= X-YMail-OSG: GKTJ_4wVM1nInEr1OlZO4NICrG28U_3Em3b7gADhyxWVCue U5481dMe4GMAYo8kHvvc.tfHRtfhlHeijTCqnLz6fSjGaWCC7UW.bFI5yEWY Z1UGWoMTN14IsZm6kI65C7Fq.W4Yv38FM7Vv..acCmW1pAJM9H587DPfhwz6 X_Mr_0tjiujDhLLdBl8HSb0YYm_fOe25XSSG0cCsDDUwLq2Po7EI2jtMh0CW bWXGPK64wRvalZB4qVMKBCdRfuPmLjWST..Y0rYY8TrTJsdhIEuTc9Mz1kWf dZtgk50RTl_l7fipM99r.8MPGUYOOOG.si7tuY6beHxMMFQRvFWUY3vCgOTN RzbMYoxbwJ1IZG1zwbmduDCUkvEYPKiI7SdJ5TPEEUfcAgGSmmLR1ZorjjNa HXAJtC8tSaI9HKR8YlVWpKHJc5R0dslEdVOfpYY_PcNLmbWdfoAEIaVsZfgg 5wYdyRA-- Received: from [24.6.68.48] by web2812.biz.mail.ne1.yahoo.com via HTTP; Sun, 14 Aug 2011 13:31:16 PDT X-Mailer: YahooMailClassic/14.0.4 YahooMailWebService/0.8.113.313619 Message-ID: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> Date: Sun, 14 Aug 2011 13:31:16 -0700 (PDT) From: nalini.elkins@insidethestack.com To: v6ops@ietf.org In-Reply-To: <4E47FFD4.5080307@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 20:32:16 -0000 =0AI am working on contacting a number of our large corporate customers to = weigh in on this topic. I think that the biggest issue here is that when a= large commercial network is having problems, anything that can help speed = diagnostics is worth doing. Outages and poor performance can cost a great d= eal of money. =0A=0ASituations such as comparing packets at various points= on the network to determine packet loss is a necessary part of network pro= blem determination. I am working to get the technicians from the corporati= ons themselves to get onto this email list and tell their opinions themselv= es.=0A=0AI wish that the IPID was in the main IPv6 header. That would be t= he best place for it. That is not possible, so what we are looking at is d= oing our best under the circumstances. One problem with having a Fragmenta= tion Header generated is that it skews statistics on fragmentation. Many c= orporate networks keep track of how much fragmentation is on their networks= and if we generate a spurious indication, then this invalidates the real f= ragmentation.=0A=0ANalini=0A=0A=0A--- On Sun, 8/14/11, Carlos Pignataro wrote:=0A=0A> From: Carlos Pignataro = =0A> Subject: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft = minutes ietf 81, 3 meetings...)=0A> To: v6ops@ietf.org=0A> Date: Sunday, Au= gust 14, 2011, 10:03 AM=0A> Hi,=0A> =0A> I believe there was one further po= int raised in regards to=0A> draft-elkins-6man-ipv6-diagnostic-header (thou= gh I don't=0A> recall if it=0A> was at the mike by Andrew Y., in a corridor= , or only in my=0A> head): the=0A> Heisenbug principle -- if this is used i= n debugging (and=0A> diagnostics),=0A> the issue being studied or attempted= to reproduce alters=0A> its behavior or=0A> goes away when modifying the p= acket (like compiling with=0A> different -o).=0A> I think this is one of th= e most important arguments against=0A> this=0A> proposal. The use of fragme= nt header is interesting, a new=0A> header could=0A> show much more pronoun= ced deviation of observed behaviour=0A> than without it.=0A> =0A> For compl= eteness, I did ask some services escalation=0A> engineers about how=0A> the= y use the ip-id in IPv4 for troubleshooting, and=0A> basically got two=0A> = main uses for very corner case situations in: i. identify=0A> middleboxes= =0A> and their characteristics (by check IP ID increment=0A> patterns, find= if=0A> packets generated by the same box), and ii. track set of=0A> packet= s along=0A> different points in the network (e.g., back-to-back packets=0A>= and see=0A> rate, drops, out of order). But it's built into the v4=0A> hea= der.=0A> =0A> Thanks,=0A> =0A> -- Carlos.=0A> =0A> On 8/2/2011 1:24 PM, Joe= l Jaeggli wrote:=0A> > * Presentation - RFC for IPv6 IP identification fiel= d=0A> (header) - Mike Ackerman=0A> > =A0=A0=A0 =A0 =A0=A0=A0http://tools.ie= tf.org/agenda/81/slides/v6ops-7.ppt=0A> > =A0=A0=A0 =A0 =A0=A0=A0http://too= ls.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header=0A> > =0A> > Fred= B - Question for the group, do you use the IPID=0A> in ipv4? (no=0A> > res= pondants other than presenters)=0A> > =0A> > Weg G - We use it all the time= ? I've never heard of=0A> it...=0A> > =0A> > Francis D - it's potentially a= covert channel, also=0A> why not use the=0A> > fregmentation header?=0A> >= =0A> > Bob H - We diefintently want to hear if this is=0A> useful. I don't= know=0A> > who puts this header in the packet?=0A> > =0A> > Nalini ? - The= host clearly=0A> > =0A> > Andrei Y - typical use case for this header woul= d be=0A> to see if a=0A> > middle box is modifying the packet. =0A> > =0A> = > Fred B - What I'm out of this discussion is that the=0A> application isn'= t=0A> > a bad one, it could be simulated in a fregment.=0A> > =0A> > Fred B= aker - Meeting complete, go to Lunch=0A> __________________________________= _____________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.iet= f.org/mailman/listinfo/v6ops=0A> From moore@network-heretics.com Sun Aug 14 15:03:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875111E808A for ; Sun, 14 Aug 2011 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBbARv0L9jAz for ; Sun, 14 Aug 2011 15:03:52 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9611E8088 for ; Sun, 14 Aug 2011 15:03:52 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 554C42226B; Sun, 14 Aug 2011 18:04:36 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 14 Aug 2011 18:04:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=r/A2PC5w7u0acvG26uQKREQfgqY=; b=fK q6/pRf77lFc42lUAVgJekD0WHLKkxVi2H+2gxnK26rfqibj70TrijwisNUC+xK0B 4D7bttaq33z+swg6cx2/FVqbjePk2II3Akv1GEitVLrDbiudYPpO6W8z3zUFp0rr 8GhTy8pgVSqvnRFlDz3ehLGvd5cRoTpoBQadY2UY8= X-Sasl-enc: SqNNsgPPd4KpN42+fX+6gRtdeY1SMW94srtx+lCUvsYr 1313359475 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 80D1A41D712; Sun, 14 Aug 2011 18:04:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E47FFD4.5080307@cisco.com> Date: Sun, 14 Aug 2011 18:04:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <961433FA-6907-4D5E-BC74-CCA0F56EC9BA@network-heretics.com> References: <4E47FFD4.5080307@cisco.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 22:03:53 -0000 On Aug 14, 2011, at 1:03 PM, Carlos Pignataro wrote: > I believe there was one further point raised in regards to > draft-elkins-6man-ipv6-diagnostic-header (though I don't recall if it > was at the mike by Andrew Y., in a corridor, or only in my head): the > Heisenbug principle -- if this is used in debugging (and diagnostics), > the issue being studied or attempted to reproduce alters its behavior = or > goes away when modifying the packet (like compiling with different = -o). Yes, this can happen. But that doesn't mean the mechanism is useless. = It just means that the potential error introduced by the mechanism needs = to be taken into account when making measurements based on it. (Just as Heisenberg's principle doesn't prevent us from measuring either = present position or future momentum of a particle. It just says that = there's a limit to the precision with which both can be measured = simultaneously.) I basically think that it's a potentially good idea. The real trick is = understanding how to implement it in hosts so that it can be turned on = when appropriate without affecting (much) the applications generating = the affected traffic. Keith From ek@google.com Sun Aug 14 16:31:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122AC21F8A56 for ; Sun, 14 Aug 2011 16:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiK3UXZ0tees for ; Sun, 14 Aug 2011 16:31:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7D57421F8A55 for ; Sun, 14 Aug 2011 16:31:34 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p7ENWHP1009407 for ; Sun, 14 Aug 2011 16:32:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313364737; bh=ElWlSyIKMb0x2vA/OC/onpuH0bM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=C17LEysnv+25pAjdo501LQJ7GDVAH4IRycj49YunIXV+u6oVc5qatpwdwjM1yMMLW K6xDHx8XrsRk4a0YD/wMw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=n+Xb4SIKvNGCgzPirTLamEh61UBd55bLhd8lFVqCg6tcbtLO8H3+iIGw3uKyZoKyR /6d9Mj5tvoRAnsDnM1WiQ== Received: from qwi2 (qwi2.prod.google.com [10.241.195.2]) by wpaz29.hot.corp.google.com with ESMTP id p7ENWGCU020004 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 14 Aug 2011 16:32:16 -0700 Received: by qwi2 with SMTP id 2so3298578qwi.22 for ; Sun, 14 Aug 2011 16:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KoWKJjDVz7MWGuiGsrDGcZfu7j39+Q8mIa2AEm0Iud8=; b=jkHZLg/ARU/sqtlm406pEmio1OqAYWGV2PevNaJ9bCRXRMMpVgV/XdmELWbw/bD9fa o1CNqGNc2O6Qjan5CmXg== Received: by 10.229.8.5 with SMTP id f5mr2195478qcf.65.1313364736631; Sun, 14 Aug 2011 16:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.8.5 with SMTP id f5mr2195472qcf.65.1313364736504; Sun, 14 Aug 2011 16:32:16 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Sun, 14 Aug 2011 16:32:16 -0700 (PDT) In-Reply-To: <769E341E-BD9A-44B5-BD64-D75ACDCA9C35@bogus.com> References: <4E47D811.6090107@kth.se> <4E47E2BD.2020609@kth.se> <769E341E-BD9A-44B5-BD64-D75ACDCA9C35@bogus.com> Date: Mon, 15 Aug 2011 08:32:16 +0900 Message-ID: From: Erik Kline To: Joel Jaeggli Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org, Rashmi Subject: Re: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 23:31:35 -0000 Note that these are "Happy Eyeballs" implementations only the revised document sense. The original "Happy Eyeballs" specified an algorithm for connection statistics and so on. Niether Chrome nor Firefox implements this. Chrome and Firefox have "fast IPv4 fallback" when the destination is an IPv6 address. This can be considered "Happy Eyeballs", I believe, under the new banner of the draft, which aims not to specify an algorithm so much as a set of criteria for "how to have more user-appealing behaviour than just trying all addresses serially". From joelja@bogus.com Sun Aug 14 23:21:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AA411E80AE for ; Sun, 14 Aug 2011 23:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOTP+GQA4RF8 for ; Sun, 14 Aug 2011 23:21:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 617B511E80B0 for ; Sun, 14 Aug 2011 23:21:14 -0700 (PDT) Received: from [192.168.1.170] (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7F6LvR7038392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Aug 2011 06:21:58 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> Date: Sun, 14 Aug 2011 23:21:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 15 Aug 2011 06:21:58 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:21:15 -0000 On Aug 14, 2011, at 1:31 PM, nalini.elkins@insidethestack.com wrote: >=20 > I am working on contacting a number of our large corporate customers = to weigh in on this topic. I think that the biggest issue here is that = when a large commercial network is having problems, anything that can = help speed diagnostics is worth doing. Outages and poor performance can = cost a great deal of money. =20 >=20 > Situations such as comparing packets at various points on the network = to determine packet loss is a necessary part of network problem = determination. I am working to get the technicians from the = corporations themselves to get onto this email list and tell their = opinions themselves. >=20 > I wish that the IPID was in the main IPv6 header. That would be the = best place for it. That is not possible, so what we are looking at is = doing our best under the circumstances. One problem with having a = Fragmentation Header generated is that it skews statistics on = fragmentation. I presume that if one is parsing that far into the optional headers, = that you can distinguish between a fragment header that has an offset of = zero and a more fragments flag of 0 which would indicate the existence = of a fragmentation header but that no other fragments exist and the = other possible combinations. > Many corporate networks keep track of how much fragmentation is on = their networks and if we generate a spurious indication, then this = invalidates the real fragmentation. should be straight forward to distinguish between the two use-cases. > Nalini >=20 >=20 > --- On Sun, 8/14/11, Carlos Pignataro wrote: >=20 >> From: Carlos Pignataro >> Subject: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft = minutes ietf 81, 3 meetings...) >> To: v6ops@ietf.org >> Date: Sunday, August 14, 2011, 10:03 AM >> Hi, >>=20 >> I believe there was one further point raised in regards to >> draft-elkins-6man-ipv6-diagnostic-header (though I don't >> recall if it >> was at the mike by Andrew Y., in a corridor, or only in my >> head): the >> Heisenbug principle -- if this is used in debugging (and >> diagnostics), >> the issue being studied or attempted to reproduce alters >> its behavior or >> goes away when modifying the packet (like compiling with >> different -o). >> I think this is one of the most important arguments against >> this >> proposal. The use of fragment header is interesting, a new >> header could >> show much more pronounced deviation of observed behaviour >> than without it. >>=20 >> For completeness, I did ask some services escalation >> engineers about how >> they use the ip-id in IPv4 for troubleshooting, and >> basically got two >> main uses for very corner case situations in: i. identify >> middleboxes >> and their characteristics (by check IP ID increment >> patterns, find if >> packets generated by the same box), and ii. track set of >> packets along >> different points in the network (e.g., back-to-back packets >> and see >> rate, drops, out of order). But it's built into the v4 >> header. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> On 8/2/2011 1:24 PM, Joel Jaeggli wrote: >>> * Presentation - RFC for IPv6 IP identification field >> (header) - Mike Ackerman >>> http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt >>> = http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header >>>=20 >>> Fred B - Question for the group, do you use the IPID >> in ipv4? (no >>> respondants other than presenters) >>>=20 >>> Weg G - We use it all the time? I've never heard of >> it... >>>=20 >>> Francis D - it's potentially a covert channel, also >> why not use the >>> fregmentation header? >>>=20 >>> Bob H - We diefintently want to hear if this is >> useful. I don't know >>> who puts this header in the packet? >>>=20 >>> Nalini ? - The host clearly >>>=20 >>> Andrei Y - typical use case for this header would be >> to see if a >>> middle box is modifying the packet.=20 >>>=20 >>> Fred B - What I'm out of this discussion is that the >> application isn't >>> a bad one, it could be simulated in a fregment. >>>=20 >>> Fred Baker - Meeting complete, go to Lunch >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From mohacsi@niif.hu Mon Aug 15 00:24:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD6521F86A9 for ; Mon, 15 Aug 2011 00:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXDk9B8Bv-Co for ; Mon, 15 Aug 2011 00:24:06 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 015AA21F8678 for ; Mon, 15 Aug 2011 00:24:00 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 0B62E876BB; Mon, 15 Aug 2011 09:24:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id eNao5P47su5Q; Mon, 15 Aug 2011 09:24:41 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 6596D876BA; Mon, 15 Aug 2011 09:24:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 64175876B9; Mon, 15 Aug 2011 09:24:41 +0200 (CEST) Date: Mon, 15 Aug 2011 09:24:41 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Joel Jaeggli In-Reply-To: <769E341E-BD9A-44B5-BD64-D75ACDCA9C35@bogus.com> Message-ID: References: <4E47D811.6090107@kth.se> <4E47E2BD.2020609@kth.se> <769E341E-BD9A-44B5-BD64-D75ACDCA9C35@bogus.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Rashmi Subject: Re: [v6ops] Chrome and firefox - happy eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 07:24:07 -0000 On Sun, 14 Aug 2011, Joel Jaeggli wrote: > think is started here in chromium... > > http://src.chromium.org/viewvc/chrome?view=rev&revision=85934 > > in firefox you can see it here. > > https://bugzilla.mozilla.org/show_bug.cgi?id=621558 Can you enable/disable to use their own IP4 fall-back algorithms in their configuration interface? Best Regards, Janos Mohacsi? > > On Aug 14, 2011, at 7:59 AM, Rashmi wrote: > >> Hello Joel, >> >> Thank you for the quick response. Is there any document I could refer regarding these implementations? >> >> -- >> Regards, >> Rashmi Purushothama >> >> >> On 2011-Aug-14 Sun 4:36 PM, Joel Jaeggli wrote: >>> yes, they do. >>> >>> joel >>> >>> On Aug 14, 2011, at 7:13 AM, Rashmi wrote: >>> >>>> Hello, >>>> >>>> In the presentation in the recent IETF meeting, (http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx) in the last but one slide, it is mentioned that "Existing Chrome and Firefox Implementations are compliant". >>>> Does this mean that Google chrome and firefox had "happy eyeballs" implementation? >>>> >>>> -- >>>> Regards, >>>> Rashmi Purushothama >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cpignata@cisco.com Mon Aug 15 02:44:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196221F8B1E for ; Mon, 15 Aug 2011 02:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kjZWtsF98S7 for ; Mon, 15 Aug 2011 02:44:49 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id CD5EA21F8B0D for ; Mon, 15 Aug 2011 02:44:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7F9jXLJ005113; Mon, 15 Aug 2011 05:45:33 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7F9jT6G002958; Mon, 15 Aug 2011 05:45:30 -0400 (EDT) Message-ID: <4E48EAB0.4020903@cisco.com> Date: Mon, 15 Aug 2011 05:45:20 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Keith Moore References: <4E47FFD4.5080307@cisco.com> <961433FA-6907-4D5E-BC74-CCA0F56EC9BA@network-heretics.com> In-Reply-To: <961433FA-6907-4D5E-BC74-CCA0F56EC9BA@network-heretics.com> X-Enigmail-Version: 1.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 09:44:49 -0000 On 8/14/2011 6:04 PM, Keith Moore wrote: > On Aug 14, 2011, at 1:03 PM, Carlos Pignataro wrote: > >> I believe there was one further point raised in regards to >> draft-elkins-6man-ipv6-diagnostic-header (though I don't recall if >> it was at the mike by Andrew Y., in a corridor, or only in my >> head): the Heisenbug principle -- if this is used in debugging (and >> diagnostics), the issue being studied or attempted to reproduce >> alters its behavior or goes away when modifying the packet (like >> compiling with different -o). > > Yes, this can happen. But that doesn't mean the mechanism is > useless. It just means that the potential error introduced by the > mechanism needs to be taken into account when making measurements > based on it. I agree; I did not imply that the mechanism was "useless" -- just that it has (much?) more limited applicability than the v4 counterpart, because additionally, it is external instrumentation (if I have a packet trace capture of a problem happening, that does not help, I need to reproduce it again modifying the packet). However see below. > > (Just as Heisenberg's principle doesn't prevent us from measuring > either present position or future momentum of a particle. It just > says that there's a limit to the precision with which both can be > measured simultaneously.) > Similarly, since in the first sentence of the Abstract this is compared with: The IPv4 main header contained a 16-bit IPID for fragmentation and reassembly. This field was commonly used by network diagnosticians for tracking packets on multi-tier networks. In just pointing out that this is with less precision. Not to say it's useless but completing the minutes. > I basically think that it's a potentially good idea. The real trick > is understanding how to implement it in hosts so that it can be > turned on when appropriate without affecting (much) the applications > generating the affected traffic. Yes, that would be a requirement for host implementation. There is, however, an assumption being made which is that the mechanism to debug and troubleshoot needs to be carried in the packet -- that is ideal, but if that does not exist I'd actually compare this proposal (or just using fragment headers instead of a new header) to an offline trick (implemented in a network protocol analyzer instead of in a host). Thanks, -- Carlos. > > Keith > > From cpignata@cisco.com Mon Aug 15 02:54:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4044A21F8B2D for ; Mon, 15 Aug 2011 02:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INI3igBJ41mA for ; Mon, 15 Aug 2011 02:54:00 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7500521F8B02 for ; Mon, 15 Aug 2011 02:54:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7F9sjWT005927 for ; Mon, 15 Aug 2011 05:54:45 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7F9sgsI008108 for ; Mon, 15 Aug 2011 05:54:42 -0400 (EDT) Message-ID: <4E48ECD8.6090200@cisco.com> Date: Mon, 15 Aug 2011 05:54:32 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 09:54:01 -0000 On 8/15/2011 2:21 AM, Joel Jaeggli wrote: > > On Aug 14, 2011, at 1:31 PM, nalini.elkins@insidethestack.com wrote: > >> >> I am working on contacting a number of our large corporate >> customers to weigh in on this topic. I think that the biggest >> issue here is that when a large commercial network is having >> problems, anything that can help speed diagnostics is worth doing. >> Outages and poor performance can cost a great deal of money. >> >> Situations such as comparing packets at various points on the >> network to determine packet loss is a necessary part of network >> problem determination. I agree with this. To compare packets, we could potentially have the network protocol analyzer (e.g., Wireshark) compute a hash on invariant fields of the packet (i.e., exclude Hop Limit, etc), and present that as packet metadata that is not actually carried on the wire. This would work for packet traces not being instrumented. Would that help? >> I am working to get the technicians from >> the corporations themselves to get onto this email list and tell >> their opinions themselves. >> >> I wish that the IPID was in the main IPv6 header. That would be >> the best place for it. That is not possible, so what we are >> looking at is doing our best under the circumstances. One problem >> with having a Fragmentation Header generated is that it skews >> statistics on fragmentation. > > I presume that if one is parsing that far into the optional headers, > that you can distinguish between a fragment header that has an offset > of zero and a more fragments flag of 0 which would indicate the > existence of a fragmentation header but that no other fragments exist > and the other possible combinations. This would also be less disruptive as it's a known header instead of a new header (potentially for existing nodes.) Thanks, -- Carlos. > >> Many corporate networks keep track of how much fragmentation is on >> their networks and if we generate a spurious indication, then this >> invalidates the real fragmentation. > > should be straight forward to distinguish between the two use-cases. > >> Nalini >> >> >> --- On Sun, 8/14/11, Carlos Pignataro wrote: >> >>> From: Carlos Pignataro Subject: [v6ops] >>> draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf >>> 81, 3 meetings...) To: v6ops@ietf.org Date: Sunday, August 14, >>> 2011, 10:03 AM Hi, >>> >>> I believe there was one further point raised in regards to >>> draft-elkins-6man-ipv6-diagnostic-header (though I don't recall >>> if it was at the mike by Andrew Y., in a corridor, or only in my >>> head): the Heisenbug principle -- if this is used in debugging >>> (and diagnostics), the issue being studied or attempted to >>> reproduce alters its behavior or goes away when modifying the >>> packet (like compiling with different -o). I think this is one of >>> the most important arguments against this proposal. The use of >>> fragment header is interesting, a new header could show much more >>> pronounced deviation of observed behaviour than without it. >>> >>> For completeness, I did ask some services escalation engineers >>> about how they use the ip-id in IPv4 for troubleshooting, and >>> basically got two main uses for very corner case situations in: >>> i. identify middleboxes and their characteristics (by check IP ID >>> increment patterns, find if packets generated by the same box), >>> and ii. track set of packets along different points in the >>> network (e.g., back-to-back packets and see rate, drops, out of >>> order). But it's built into the v4 header. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> On 8/2/2011 1:24 PM, Joel Jaeggli wrote: >>>> * Presentation - RFC for IPv6 IP identification field >>> (header) - Mike Ackerman >>>> http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt >>>> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header >>>> >>>> >>>> Fred B - Question for the group, do you use the IPID >>> in ipv4? (no >>>> respondants other than presenters) >>>> >>>> Weg G - We use it all the time? I've never heard of >>> it... >>>> >>>> Francis D - it's potentially a covert channel, also >>> why not use the >>>> fregmentation header? >>>> >>>> Bob H - We diefintently want to hear if this is >>> useful. I don't know >>>> who puts this header in the packet? >>>> >>>> Nalini ? - The host clearly >>>> >>>> Andrei Y - typical use case for this header would be >>> to see if a >>>> middle box is modifying the packet. >>>> >>>> Fred B - What I'm out of this discussion is that the >>> application isn't >>>> a bad one, it could be simulated in a fregment. >>>> >>>> Fred Baker - Meeting complete, go to Lunch >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nalini.elkins@insidethestack.com Mon Aug 15 05:49:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BFD21F8B3C for ; Mon, 15 Aug 2011 05:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCTrRCAXqSg0 for ; Mon, 15 Aug 2011 05:49:46 -0700 (PDT) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by ietfa.amsl.com (Postfix) with SMTP id CBDD221F886A for ; Mon, 15 Aug 2011 05:49:46 -0700 (PDT) Received: from [66.94.237.194] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 12:50:31 -0000 Received: from [66.94.237.122] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 12:50:31 -0000 Received: from [127.0.0.1] by omp1027.access.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 12:50:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 387446.33078.bm@omp1027.access.mail.mud.yahoo.com Received: (qmail 59218 invoked by uid 60001); 15 Aug 2011 12:50:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313412631; bh=X9nbt6Y6pTXk5tv08AGhvZ08zYsMhOZCLD/1YSU2Lm0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ynAOXuYq48s2Ldn9uUXjkcxCcPmDIgD0fFUh42U+1Q3/A4ndFC4+QFZE/ob8Jnu+0wp1tzBSLX4OJ7Nl1bSvt0ti+ZV/c+7xAFrU21qKZzipOJ8aRkYlMDOJVyVkUKWX2ycb9YNnfJhsg59db8/+sXBlUTBrbXffz1KI9mbG2EI= X-YMail-OSG: QY7NI1UVM1nuDdILxbVKaHEWLBDoshwnPJtLeNQClHUVM3u EIyzShgDd Received: from [24.6.68.48] by web2818.biz.mail.ne1.yahoo.com via HTTP; Mon, 15 Aug 2011 05:50:30 PDT X-Mailer: YahooMailClassic/14.0.4 YahooMailWebService/0.8.113.313619 Message-ID: <1313412630.31712.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 05:50:30 -0700 (PDT) From: nalini.elkins@insidethestack.com To: v6ops@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:49:47 -0000 =0A=0A--- On Sun, 8/14/11, Joel Jaeggli wrote:=0A=0A> Fr= om: Joel Jaeggli =0A> Subject: Re: [v6ops] draft-elkins-6= man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)=0A> = To: nalini.elkins@insidethestack.com=0A> Cc: v6ops@ietf.org=0A> Date: Sunda= y, August 14, 2011, 11:21 PM=0A> =0A> On Aug 14, 2011, at 1:31 PM, nalini.e= lkins@insidethestack.com=0A> wrote:=0A> =0A> > =0A> > I am working on conta= cting a number of our large=0A> corporate customers to weigh in on this top= ic.=A0 I think=0A> that the biggest issue here is that when a large commerc= ial=0A> network is having problems, anything that can help speed=0A> diagno= stics is worth doing. Outages and poor performance can=0A> cost a great dea= l of money.=A0 =0A> > =0A> > Situations such as comparing packets at variou= s points=0A> on the network to determine packet loss is a necessary part=0A= > of network problem determination.=A0 I am working to get=0A> the technici= ans from the corporations themselves to get onto=0A> this email list and te= ll their opinions themselves.=0A> > =0A> > I wish that the IPID was in the = main IPv6=0A> header.=A0 That would be the best place for it.=A0=0A> That i= s not possible, so what we are looking at is doing our=0A> best under the c= ircumstances.=A0 One problem with having=0A> a Fragmentation Header generat= ed is that it skews statistics=0A> on fragmentation.=0A> =0A> I presume tha= t if one is parsing that far into the optional=0A> headers, that you can di= stinguish between a fragment header=0A> that has an offset of zero and a mo= re fragments flag of 0=0A> which would indicate the existence of a fragment= ation header=0A> but that no other fragments exist and the other possible= =0A> combinations.=0A> =0A> >=A0 Many corporate networks keep track of how = much=0A> fragmentation is on their networks and if we generate a=0A> spurio= us indication, then this invalidates the real=0A> fragmentation.=0A> =0A> s= hould be straight forward to distinguish between the two=0A> use-cases.=0A= =0A=0AStraight forward if you are using a packet analyzer. But, many peopl= e use SNMP to keep track of counters. With SNMP, the fragmentation counter= would just be incremented with no knowledge of if it was real or not.=0A= =0A=0A> =0A> > Nalini=0A> > =0A> > =0A> > --- On Sun, 8/14/11, Carlos Pigna= taro =0A> wrote:=0A> > =0A> >> From: Carlos Pignataro <= cpignata@cisco.com>=0A> >> Subject: [v6ops]=0A> draft-elkins-6man-ipv6-diag= nostic-header (Was: draft minutes=0A> ietf 81, 3 meetings...)=0A> >> To: v6= ops@ietf.org=0A> >> Date: Sunday, August 14, 2011, 10:03 AM=0A> >> Hi,=0A> = >> =0A> >> I believe there was one further point raised in=0A> regards to= =0A> >> draft-elkins-6man-ipv6-diagnostic-header (though I=0A> don't=0A> >>= recall if it=0A> >> was at the mike by Andrew Y., in a corridor, or=0A> on= ly in my=0A> >> head): the=0A> >> Heisenbug principle -- if this is used in= =0A> debugging (and=0A> >> diagnostics),=0A> >> the issue being studied or = attempted to reproduce=0A> alters=0A> >> its behavior or=0A> >> goes away w= hen modifying the packet (like=0A> compiling with=0A> >> different -o).=0A>= >> I think this is one of the most important=0A> arguments against=0A> >> = this=0A> >> proposal. The use of fragment header is=0A> interesting, a new= =0A> >> header could=0A> >> show much more pronounced deviation of observed= =0A> behaviour=0A> >> than without it.=0A> >> =0A> >> For completeness, I d= id ask some services=0A> escalation=0A> >> engineers about how=0A> >> they = use the ip-id in IPv4 for troubleshooting,=0A> and=0A> >> basically got two= =0A> >> main uses for very corner case situations in: i.=0A> identify=0A> >= > middleboxes=0A> >> and their characteristics (by check IP ID=0A> incremen= t=0A> >> patterns, find if=0A> >> packets generated by the same box), and i= i. track=0A> set of=0A> >> packets along=0A> >> different points in the net= work (e.g.,=0A> back-to-back packets=0A> >> and see=0A> >> rate, drops, out= of order). But it's built into=0A> the v4=0A> >> header.=0A> >> =0A> >> Th= anks,=0A> >> =0A> >> -- Carlos.=0A> >> =0A> >> On 8/2/2011 1:24 PM, Joel Ja= eggli wrote:=0A> >>> * Presentation - RFC for IPv6 IP=0A> identification fi= eld=0A> >> (header) - Mike Ackerman=0A> >>>=A0 =A0 =A0 =A0 =A0 http://tools= .ietf.org/agenda/81/slides/v6ops-7.ppt=0A> >>>=A0 =A0 =A0 =A0 =A0 http://to= ols.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header=0A> >>> =0A> >>>= Fred B - Question for the group, do you use=0A> the IPID=0A> >> in ipv4? (= no=0A> >>> respondants other than presenters)=0A> >>> =0A> >>> Weg G - We u= se it all the time? I've never=0A> heard of=0A> >> it...=0A> >>> =0A> >>> F= rancis D - it's potentially a covert channel,=0A> also=0A> >> why not use t= he=0A> >>> fregmentation header?=0A> >>> =0A> >>> Bob H - We diefintently w= ant to hear if this=0A> is=0A> >> useful. I don't know=0A> >>> who puts thi= s header in the packet?=0A> >>> =0A> >>> Nalini ? - The host clearly=0A> >>= > =0A> >>> Andrei Y - typical use case for this header=0A> would be=0A> >> = to see if a=0A> >>> middle box is modifying the packet. =0A> >>> =0A> >>> F= red B - What I'm out of this discussion is=0A> that the=0A> >> application = isn't=0A> >>> a bad one, it could be simulated in a=0A> fregment.=0A> >>> = =0A> >>> Fred Baker - Meeting complete, go to Lunch=0A> >> ________________= _______________________________=0A> >> v6ops mailing list=0A> >> v6ops@ietf= .org=0A> >> https://www.ietf.org/mailman/listinfo/v6ops=0A> >> =0A> > _____= __________________________________________=0A> > v6ops mailing list=0A> > v= 6ops@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/v6ops=0A> > =0A> = =0A> From nalini.elkins@insidethestack.com Mon Aug 15 06:13:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BF421F8B84 for ; Mon, 15 Aug 2011 06:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e8f7gdv4wEY for ; Mon, 15 Aug 2011 06:13:14 -0700 (PDT) Received: from nm22.access.bullet.mail.sp2.yahoo.com (nm22.access.bullet.mail.sp2.yahoo.com [98.139.44.149]) by ietfa.amsl.com (Postfix) with SMTP id D005621F8B83 for ; Mon, 15 Aug 2011 06:13:13 -0700 (PDT) Received: from [98.139.44.102] by nm22.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 13:13:59 -0000 Received: from [98.139.44.91] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 13:13:59 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 13:13:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 605012.13370.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 64962 invoked by uid 60001); 15 Aug 2011 13:13:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313414039; bh=Ath8T3NgdwUpZdjAnKPPzwoGwMOahRIdm09A+pI1E5k=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nlrhqeO0v6nXV4iDK85cbGXK1A5FuptvN6rsPzp8nMe2Do1mLCtwLPY99bq+wFxXLcSICWnpYsdyrWySdM5W3IYQ4/ylVm0YiMnyVnkoxPX5u10X/NwXeoSLLseahIFDfvlraFSqvjgS2xwlLknWsYrTQMRoRpZA1mJIyXxFDl8= X-YMail-OSG: M8xL74oVM1kgPzPiUYs.uSc98xOJyPVkjVuSKdXSg6dm4kc L5MuoNCXVdZ.gsC76c3mZpyw.AmM.MRY2GZHoqSWiJyqopCFKWUJoy8tz1Ay O.XvQM4ncCRWq0Tq_Mi_qhDtdaLbhbOOhb3Oi_bOP_1N6DO2ho4iVwVmNsgM PSNb0xpq1cn3YHTVJ_OYyJdGV7SvPnMwj3iUjHCwL8.EW13NrJ9nhG1ssyfD 5xYvl_LTAcKU7Hosk.a9_HLQUFVJ_R.tbeKUwYon9wcLWlWcwlYfySzXTQ.k M16pqtBkTSgpDx26brhQQp.GaFQaN96qPExFMvnvLt9acbdiMGh8PErCAMBI sIQ4q9OJY4UPVxaLLwnwuxoBuEmSQTgIhYdeqmoWbaZRh7bOG4MRQYBQxY_P rMMphdgNilYflnXmw.bVArgl2HfZAGGTKhjfB3DCfKuUoGPappv8ahCLxtkt L4luR.A-- Received: from [24.6.68.48] by web2814.biz.mail.ne1.yahoo.com via HTTP; Mon, 15 Aug 2011 06:13:59 PDT X-Mailer: YahooMailClassic/14.0.4 YahooMailWebService/0.8.113.313619 Message-ID: <1313414039.63643.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 06:13:59 -0700 (PDT) From: nalini.elkins@insidethestack.com To: v6ops@ietf.org In-Reply-To: <4E48ECD8.6090200@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:13:15 -0000 =0A=0A--- On Mon, 8/15/11, Carlos Pignataro wrote:=0A= =0A> From: Carlos Pignataro =0A> Subject: Re: [v6ops] d= raft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meet= ings...)=0A> To: v6ops@ietf.org=0A> Date: Monday, August 15, 2011, 2:54 AM= =0A> =0A> =0A> On 8/15/2011 2:21 AM, Joel Jaeggli wrote:=0A> > =0A> > On Au= g 14, 2011, at 1:31 PM, nalini.elkins@insidethestack.com=0A> wrote:=0A> > = =0A> >> =0A> >> I am working on contacting a number of our large=0A> corpor= ate=0A> >> customers to weigh in on this topic.=A0 I think=0A> that the big= gest=0A> >> issue here is that when a large commercial network=0A> is havin= g=0A> >> problems, anything that can help speed diagnostics=0A> is worth do= ing.=0A> >> Outages and poor performance can cost a great deal=0A> of money= .=0A> >> =0A> >> Situations such as comparing packets at various=0A> points= on the=0A> >> network to determine packet loss is a necessary=0A> part of = network=0A> >> problem determination.=0A> =0A> I agree with this. To compar= e packets, we could potentially=0A> have the=0A> network protocol analyzer = (e.g., Wireshark) compute a hash=0A> on invariant=0A> fields of the packet = (i.e., exclude Hop Limit, etc), and=0A> present that as=0A> packet metadata= that is not actually carried on the wire.=0A> This would=0A> work for pack= et traces not being instrumented. Would that=0A> help?=0A> =0A=0AWell, that= is a really good idea that we had explored also. Now, we ourselves make a= n intelligent packet analyzer and work with the WireShark folks. If I look= at this selfishly for having an extra selling point for my products, then = I can say, 'Yes, we allow you to do this! Buy my product!' But, I was try= ing to be a good citizen and allow all to do this without our products. No= w, if our proposal is not adopted, then we will do the checksum or hash on = the packets in our products as I think it is needed for diagnostics. =0A=0A= This idea also helps technicians who have taken a trace at one point using = multiple facilities - that is, WireShark and IBM mainframe CTrace. Then, i= t is useful to have the IPID shown in sequence.=0A=0ABut, the idea of the h= ash or checksum leaves aside the case where you have only one trace at one = point along the path. Being able to view the sequence of packet transmissi= on is useful even then. =0A=0AAlso, I really feel that down the road here,= the 32-bit IPID is going to run into scalability issues. We are proposing= a 64-bit IPID. The IPID is also not standardized. Some implementations = use the same IPID for all connections, others use a different IPID for each= connection. Some increment by 1, some by two.=0A=0AOur other future though= ts, and agenda, if you will, is that as networks and traffic grow, more and= more diagnostics and troubleshooting will have do be done by computer syst= ems rather than humans. So, we are looking at what metrics need to be save= d for that. I feel that the IPID is one such. There are others such as TC= P Window Scaling - but that belongs on another email list, so I did not wan= t to bring that up.=0A=0A=0A> >> I am working to get the technicians from= =0A> >> the corporations themselves to get onto this email=0A> list and tel= l=0A> >> their opinions themselves.=0A> >> =0A> >> I wish that the IPID was= in the main IPv6=0A> header.=A0 That would be=0A> >> the best place for it= .=A0 That is not possible,=0A> so what we are=0A> >> looking at is doing ou= r best under the=0A> circumstances.=A0 One problem=0A> >> with having a Fra= gmentation Header generated is=0A> that it skews=0A> >> statistics on fragm= entation.=0A> > =0A> > I presume that if one is parsing that far into the= =0A> optional headers,=0A> > that you can distinguish between a fragment he= ader=0A> that has an offset=0A> > of zero and a more fragments flag of 0 wh= ich would=0A> indicate the=0A> > existence of a fragmentation header but th= at no other=0A> fragments exist=0A> > and the other possible combinations.= =0A> =0A> This would also be less disruptive as it's a known header=0A> ins= tead of a=0A> new header (potentially for existing nodes.)=0A>=0A=0ANow, ac= tually, I am setting up a meeting with the IBM TCP/IP architects, as they a= re the host implementation that we work most closely with, to ask them what= exactly would their stack do if they got a fragmentation header with 0 in = the fragmentation header. I wonder if that would cause any problems.=0A=0A= And, yes, the fragmentation header is known. But, you know, we feel that d= iagnostics is very important and as we all grow in our sophistication and h= opefully ability to do network diagnostics and recovery automatically, we m= ay have other uses for a 'Diagnostic Header'. We see the IPID as potential= ly the first use of this.=0A =0A> Thanks,=0A> =0A> -- Carlos.=0A> =0A> > = =0A> >> Many corporate networks keep track of how much=0A> fragmentation is= on=0A> >> their networks and if we generate a spurious=0A> indication, the= n this=0A> >> invalidates the real fragmentation.=0A> > =0A> > should be st= raight forward to distinguish between the=0A> two use-cases.=0A> > =0A> >> = Nalini=0A> >> =0A> >> =0A> >> --- On Sun, 8/14/11, Carlos Pignataro =0A> wrote:=0A> >> =0A> >>> From: Carlos Pignataro =0A> Subject: [v6ops]=0A> >>> draft-elkins-6man-ipv6-diagnostic-he= ader (Was:=0A> draft minutes ietf=0A> >>> 81, 3 meetings...) To: v6ops@ietf= .org=0A> Date: Sunday, August 14,=0A> >>> 2011, 10:03 AM Hi,=0A> >>> =0A> >= >> I believe there was one further point raised=0A> in regards to =0A> >>> = draft-elkins-6man-ipv6-diagnostic-header=0A> (though I don't recall=0A> >>>= if it was at the mike by Andrew Y., in a=0A> corridor, or only in my =0A> = >>> head): the Heisenbug principle -- if this is=0A> used in debugging=0A> = >>> (and diagnostics), the issue being studied or=0A> attempted to=0A> >>> = reproduce alters its behavior or goes away=0A> when modifying the=0A> >>> p= acket (like compiling with different -o). I=0A> think this is one of=0A> >>= > the most important arguments against this=0A> proposal. The use of=0A> >>= > fragment header is interesting, a new header=0A> could show much more=0A>= >>> pronounced deviation of observed behaviour=0A> than without it.=0A> >>= > =0A> >>> For completeness, I did ask some services=0A> escalation enginee= rs=0A> >>> about how they use the ip-id in IPv4 for=0A> troubleshooting, an= d =0A> >>> basically got two main uses for very corner=0A> case situations = in:=0A> >>> i. identify middleboxes and their=0A> characteristics (by check= IP ID=0A> >>> increment patterns, find if packets generated=0A> by the sam= e box),=0A> >>> and ii. track set of packets along different=0A> points in = the=0A> >>> network (e.g., back-to-back packets and see=0A> rate, drops, ou= t of=0A> >>> order). But it's built into the v4 header.=0A> >>> =0A> >>> Th= anks,=0A> >>> =0A> >>> -- Carlos.=0A> >>> =0A> >>> On 8/2/2011 1:24 PM, Joe= l Jaeggli wrote:=0A> >>>> * Presentation - RFC for IPv6 IP=0A> identificati= on field=0A> >>> (header) - Mike Ackerman=0A> >>>> http://tools.ietf.org/ag= enda/81/slides/v6ops-7.ppt =0A> >>>> http://tools.ietf.org/html/draft-elkin= s-6man-ipv6-diagnostic-header=0A> >>>>=0A> >>>>=0A> >>>> =0A> Fred B - Ques= tion for the group, do you use the IPID=0A> >>> in ipv4? (no=0A> >>>> respo= ndants other than presenters)=0A> >>>> =0A> >>>> Weg G - We use it all the = time? I've never=0A> heard of=0A> >>> it...=0A> >>>> =0A> >>>> Francis D - = it's potentially a covert=0A> channel, also=0A> >>> why not use the=0A> >>>= > fregmentation header?=0A> >>>> =0A> >>>> Bob H - We diefintently want to = hear if=0A> this is=0A> >>> useful. I don't know=0A> >>>> who puts this hea= der in the packet?=0A> >>>> =0A> >>>> Nalini ? - The host clearly=0A> >>>> = =0A> >>>> Andrei Y - typical use case for this=0A> header would be=0A> >>> = to see if a=0A> >>>> middle box is modifying the packet.=0A> >>>> =0A> >>>>= Fred B - What I'm out of this discussion=0A> is that the=0A> >>> applicati= on isn't=0A> >>>> a bad one, it could be simulated in a=0A> fregment.=0A> >= >>> =0A> >>>> Fred Baker - Meeting complete, go to=0A> Lunch=0A> >>>=0A> __= _____________________________________________ v6ops=0A> mailing=0A> >>> lis= t v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops=0A> >>> =0A> >= > _______________________________________________=0A> v6ops mailing list = =0A> >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops=0A> >> = =0A> > =0A> > _______________________________________________ v6ops=0A> mai= ling list =0A> > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= =0A> > =0A> _______________________________________________=0A> v6ops maili= ng list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops= =0A> From tjc@ecs.soton.ac.uk Mon Aug 15 06:58:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19D021F8B3D for ; Mon, 15 Aug 2011 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxrxH4xpCWxv for ; Mon, 15 Aug 2011 06:58:03 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EF6CF21F8B30 for ; Mon, 15 Aug 2011 06:58:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7FDwfRT006979 for ; Mon, 15 Aug 2011 14:58:41 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p7FDwfRT006979 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1313416721; bh=cC9uHKnDM6+U3xRpXUBYWRiP5To=; h=Subject:Mime-Version:From:In-Reply-To:Date:References:To; b=FvONg1qonjKg/qLqTssDgIE8Wn1ZlGjzH+htndk9WgUhwLj3GV4AXhRrgQqBUkVsg /3RlFV5Ho0fvfdwdoIDpa4IpapKsu+nHNiylflYqTmgaTYqadGvcas0Uwnv/LLNH1h Ng1ZXLvhD+6YoO921h2VqhtLbuSk4ZzdOrs+PGcI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n7EEwf0366118173iY ret-id none; Mon, 15 Aug 2011 14:58:41 +0100 Received: from dhcp-152-78-94-241.ecs.soton.ac.uk (dhcp-152-78-94-241.ecs.soton.ac.uk [152.78.94.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7FDwZsJ002862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Aug 2011 14:58:35 +0100 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Tim Chown X-Priority: 3 In-Reply-To: <77328167-EA8B-4A6B-BF93-350D52348236@bogus.com> Date: Mon, 15 Aug 2011 14:58:34 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> <69C27A09-DE9A-47FA-A4EB-B90FE0926141@cisco.com> <004d01cc514c$8ebcbd40$4001a8c0@gateway.2wire.net> <77328167-EA8B-4A6B-BF93-350D52348236@bogus.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n7EEwf036611817300; tid=n7EEwf0366118173iY; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p7FDwfRT006979 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:58:04 -0000 On 2 Aug 2011, at 23:42, Joel Jaeggli wrote: >=20 > On Aug 2, 2011, at 12:44 PM, t.petch wrote: >=20 >> I think that for most people the expectation is that I-D leads to RFC = or else to >> disappointment. >=20 > realistically given that there have been something like 21795 drafts = since March 1996 when the tools archive begins and 4435 RFCs in the same = timeframe our success rate is way higher than say the publishing = industry. Sometimes it's useful to publish a -00 just to a) be a handy reference = for discussion when a topic comes up on multiple discussion lists, so = you don't have to repeat information that's then available in one place = and b) gauge support or interest in a topic. On draft-keranen-ipv6day-measurements, it could be published as an = individual submission or a separate paper. =20 If it's of interest to the authors on W6D I looked at the top 200 UK = Alexa sites and 16 had AAAA records added for www., all = accessible, though while all were available via http and ping, = traceroute failed for many. Most of the sites were global domains, = like Google, Yahoo and Facebook, with the BBC the only UK-specific site = participating in the Alexa UK 200. Tim From shane@castlepoint.net Mon Aug 15 07:41:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7233021F8BDE for ; Mon, 15 Aug 2011 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnW3BJA1KNLr for ; Mon, 15 Aug 2011 07:41:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8421F8BDC for ; Mon, 15 Aug 2011 07:41:15 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 7620526806D; Mon, 15 Aug 2011 08:41:56 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Aug 2011 08:41:56 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=53357; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <1313414039.63643.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 08:41:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313414039.63643.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:41:16 -0000 Nalini, All, On Aug 15, 2011, at 7:13 AM, nalini.elkins@insidethestack.com wrote: > Well, that is a really good idea that we had explored also. Now, we = ourselves make an intelligent packet analyzer and work with the = WireShark folks. If I look at this selfishly for having an extra = selling point for my products, then I can say, 'Yes, we allow you to do = this! Buy my product!' But, I was trying to be a good citizen and = allow all to do this without our products. Now, if our proposal is not = adopted, then we will do the checksum or hash on the packets in our = products as I think it is needed for diagnostics.=20 >=20 > This idea also helps technicians who have taken a trace at one point = using multiple facilities - that is, WireShark and IBM mainframe CTrace. = Then, it is useful to have the IPID shown in sequence. >=20 > But, the idea of the hash or checksum leaves aside the case where you = have only one trace at one point along the path. Being able to view the = sequence of packet transmission is useful even then. =20 >=20 > Also, I really feel that down the road here, the 32-bit IPID is going = to run into scalability issues. We are proposing a 64-bit IPID. The = IPID is also not standardized. Some implementations use the same IPID = for all connections, others use a different IPID for each connection. = Some increment by 1, some by two. >=20 > Our other future thoughts, and agenda, if you will, is that as = networks and traffic grow, more and more diagnostics and troubleshooting = will have do be done by computer systems rather than humans. So, we are = looking at what metrics need to be saved for that. I feel that the IPID = is one such. There are others such as TCP Window Scaling - but that = belongs on another email list, so I did not want to bring that up. Have you taken a look at flow-spec for IPv4: http://tools.ietf.org/html/rfc5575 ... and, flow-spec for IPv6: http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00 (Both the RFC and I-D are within the IDR WG). In summary, using flow-spec one can define an ACL that then get = distributed across all routers within an ASN, via BGP, that can then be = used to count matching packets, log packet header information, etc. = It's up to the operator to decide what ACL to be applied and what = 'action' (logging, counting, etc.) to be taken for packets that match a = given 'rule'. =20 =46rom where I'm sitting, this seems like it might already solve the = problem you're having, without having to invent a wholly new IPv6 = Destination Header Option. So, I would like to know if you have taken a = look at flow-spec and, if so, why it was ruled out? -shane= From nalini.elkins@insidethestack.com Mon Aug 15 07:56:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53AB21F8C1F for ; Mon, 15 Aug 2011 07:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7w38f7A9y-b for ; Mon, 15 Aug 2011 07:56:43 -0700 (PDT) Received: from nm14.access.bullet.mail.sp2.yahoo.com (nm14.access.bullet.mail.sp2.yahoo.com [98.139.44.141]) by ietfa.amsl.com (Postfix) with SMTP id 5BEA421F8C1D for ; Mon, 15 Aug 2011 07:56:43 -0700 (PDT) Received: from [98.139.44.99] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 14:57:26 -0000 Received: from [98.139.44.89] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 14:57:26 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 14:57:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831199.94672.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 27613 invoked by uid 60001); 15 Aug 2011 14:57:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313420246; bh=EH9/JInKoOYe0x+UF0erwcPT+NEJg7jZwuwcnNk5zOc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V5VR9Serd2VNAAn2QFfQTLNeDg9j2e2hqOxSpsPx/Ta8rTQw89PvbpbODulJX/g6ZPWcEA0EHf8BEADc6LVT0J42Mqfgd8iRYqpERSQuKVpWROe189rq1udYCktsRlhSmqGStFwf+0jRZdGj58h4Ly0fxmnJ/Zrb6Rc85n4kIuI= X-YMail-OSG: sJYOdJYVM1lzKpFZBoeL2cZwPNc4ufMXrEEg.8n_LYVlnUn TL5bnwJIQxF98PIu6b1Qpmgl1JQRi.n4y3SLu2B3kcIe6tpqNjwp00EXqO9O zy33jElaBDLrIUhlQN2F4U4Ema92ZDqrYAvMzSyX09FO3_KDMxg0OaCtTBYn ksFUap2kAKbZU_CWMKYwiIRcKMct.ElrfLmju_i6K6uQ6XInshwfOrqRXnJu XybFURgqaU9tA8IHTqgDuBWILdtDASbSZmJIIaOnVQxQG_BeRDxD.tg29YCD aYc_MPqv7XmBUvgORMy115o8VWb8Jf.u.7IF6qO58phxqoO6vdn25oTZS4ia dSQo9cwwVTa6C70gFvioIAUCG4Rggg7G7nZd8__bgueZFXNdli1Q7txZ9lXo moU0wOza6on_6pS2Ei.O5BFno6XBKdMWDEAqONYFZ55Psmr39CUrSDWB9vQH LKn8zf4asVoI8_SgH8hQZPZaWYEtXMFdC.HTwKMukGwvIjVq01uvtz_3z_lx y.DYKhMZstnzAgNlDNg-- Received: from [24.6.68.48] by web2818.biz.mail.ne1.yahoo.com via HTTP; Mon, 15 Aug 2011 07:57:25 PDT X-Mailer: YahooMailClassic/14.0.4 YahooMailWebService/0.8.113.313619 Message-ID: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 07:57:25 -0700 (PDT) From: nalini.elkins@insidethestack.com To: Shane Amante In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:56:43 -0000 Shane,=0A=0A=0A> =0A> Have you taken a look at flow-spec for IPv4:=0A> http= ://tools.ietf.org/html/rfc5575=0A> ... and, flow-spec for IPv6:=0A> http://= tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00=0A> (Both the RFC and I-= D are within the IDR WG).=0A> =0A> In summary, using flow-spec one can defi= ne an ACL that then=0A> get distributed across all routers within an ASN, v= ia BGP,=0A> that can then be used to count matching packets, log packet=0A>= header information, etc.=A0 It's up to the operator to=0A> decide what ACL= to be applied and what 'action' (logging,=0A> counting, etc.) to be taken = for packets that match a given=0A> 'rule'.=A0 =0A> =0A> From where I'm sitt= ing, this seems like it might already=0A> solve the problem you're having, = without having to invent a=0A> wholly new IPv6 Destination Header Option.= =A0 So, I would=0A> like to know if you have taken a look at flow-spec and,= if=0A> so, why it was ruled out?=0A=0ACertainly an interesting set of RFCs= but a few questions I would have:=0A=0A1. What if BGP is not being used?= =0A=0A2. What about matching packets at non-router devices (that is, hosts= )=0A=0A3. I believe what we need in diagnostics is the entire packet not j= ust a logging that such a packet existed. For example, the problem we are = looking for may be in the body of the protocol data. Ex. a problem with FT= P. So, we would need the entire packet as captured by a packet analyzer ra= ther than a log that says 'a packet from dest x to source y was sent'. I d= o not imagine that the log is going to keep the entire packet. Am I missin= g something?=0A=0A=0A> =0A> -shane From warren@kumari.net Mon Aug 15 08:08:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5813521F8B70 for ; Mon, 15 Aug 2011 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO2YULg-Yh6a for ; Mon, 15 Aug 2011 08:08:56 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 91F3021F8AB8 for ; Mon, 15 Aug 2011 08:08:56 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CB6761B4153B; Mon, 15 Aug 2011 11:09:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 11:09:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313353876.90887.YahooMailClassic@web2812.biz.mail.ne1.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:08:57 -0000 On Aug 14, 2011, at 4:31 PM, nalini.elkins@insidethestack.com wrote: >=20 > I am working on contacting a number of our large corporate customers = to weigh in on this topic. I think that the biggest issue here is that = when a large commercial network is having problems, anything that can = help speed diagnostics is worth doing. No. Anything that can help speed diagnostics, and that doesn't cause = collateral damage... or cost too much... or annoy the users... or = destabilize the control plane.... or involve mucking with physical = layer... or opens interesting security vectors... or.... > Outages and poor performance can cost a great deal of money. =20 >=20 Yes. > Situations such as comparing packets at various points on the network = to determine packet loss is a necessary part of network problem = determination. No -- again you are making blanket assertions with nothing to back them = up... Comparing packets at various points on the network to determine packet = loss is NOT a "necessary part of network problem determination." It's not even a necessary part of what I'm assuming you meant -- finding = packet loss. There are a huge number of way to do this, including such obvious things = as looking at SNMP / CLI packet counters (number of packets in should be = roughly number of packets out (roughly is to account for mgmt / routing = protocol overhead)), physical layer counters, netflow / sflow, flowspec, = traceroute, BFD / LACP, fabric sanity checks, etc. If for some reason you still feel the need to capture and compare = packets at various points on the network, whats wrong with simply = calculating a hash over relevant fields in the header / payload?=20 > I am working to get the technicians from the corporations themselves = to get onto this email list and tell their opinions themselves. >=20 Ok, I've been doing networking for 15+ years, and have worked on = networks from tiny ISPs to enterprise networks to startups to consulting = to large ISPs to things that don't quite fit in other buckets. The only = times (that I can remember!) that I have viewed IPID as an interesting = diagnostic during is to see if lots of packets have identical IDs, and = so are likely from a poorly written DoS tool. This seems to line up with = the views of other operators in the V6OPS meeting in Quebec. I'm not saying the idea might not be useful in some circumstances, but = rather that you are overselling the technique... > I wish that the IPID was in the main IPv6 header. That would be the = best place for it. That is not possible, so what we are looking at is = doing our best under the circumstances. One problem with having a = Fragmentation Header generated is that it skews statistics on = fragmentation. Many corporate networks keep track of how much = fragmentation is on their networks and if we generate a spurious = indication, then this invalidates the real fragmentation. >=20 > Nalini >=20 >=20 > --- On Sun, 8/14/11, Carlos Pignataro wrote: >=20 >> From: Carlos Pignataro >> Subject: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft = minutes ietf 81, 3 meetings...) >> To: v6ops@ietf.org >> Date: Sunday, August 14, 2011, 10:03 AM >> Hi, >>=20 >> I believe there was one further point raised in regards to >> draft-elkins-6man-ipv6-diagnostic-header (though I don't >> recall if it >> was at the mike by Andrew Y., in a corridor, or only in my >> head): the >> Heisenbug principle -- if this is used in debugging (and >> diagnostics), >> the issue being studied or attempted to reproduce alters >> its behavior or >> goes away when modifying the packet (like compiling with >> different -o). >> I think this is one of the most important arguments against >> this >> proposal. The use of fragment header is interesting, a new >> header could >> show much more pronounced deviation of observed behaviour >> than without it. >>=20 >> For completeness, I did ask some services escalation >> engineers about how >> they use the ip-id in IPv4 for troubleshooting, and >> basically got two >> main uses for very corner case situations in: i. identify >> middleboxes >> and their characteristics (by check IP ID increment >> patterns, find if >> packets generated by the same box), and ii. track set of >> packets along >> different points in the network (e.g., back-to-back packets >> and see >> rate, drops, out of order). But it's built into the v4 >> header. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> On 8/2/2011 1:24 PM, Joel Jaeggli wrote: >>> * Presentation - RFC for IPv6 IP identification field >> (header) - Mike Ackerman >>> http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt >>> = http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header >>>=20 >>> Fred B - Question for the group, do you use the IPID >> in ipv4? (no >>> respondants other than presenters) >>>=20 >>> Weg G - We use it all the time? I've never heard of >> it... >>>=20 >>> Francis D - it's potentially a covert channel, also >> why not use the >>> fregmentation header? >>>=20 >>> Bob H - We diefintently want to hear if this is >> useful. I don't know >>> who puts this header in the packet? >>>=20 >>> Nalini ? - The host clearly >>>=20 >>> Andrei Y - typical use case for this header would be >> to see if a >>> middle box is modifying the packet.=20 >>>=20 >>> Fred B - What I'm out of this discussion is that the >> application isn't >>> a bad one, it could be simulated in a fregment. >>>=20 >>> Fred Baker - Meeting complete, go to Lunch >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From warren@kumari.net Mon Aug 15 08:12:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCED521F8A69 for ; Mon, 15 Aug 2011 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtniMBo4grRW for ; Mon, 15 Aug 2011 08:12:27 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DE87321F8B61 for ; Mon, 15 Aug 2011 08:12:26 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DB6F11B4153B; Mon, 15 Aug 2011 11:13:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 11:13:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:12:27 -0000 On Aug 15, 2011, at 10:57 AM, nalini.elkins@insidethestack.com wrote: > Shane, >=20 >=20 >>=20 >> Have you taken a look at flow-spec for IPv4: >> http://tools.ietf.org/html/rfc5575 >> ... and, flow-spec for IPv6: >> http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00 >> (Both the RFC and I-D are within the IDR WG). >>=20 >> In summary, using flow-spec one can define an ACL that then >> get distributed across all routers within an ASN, via BGP, >> that can then be used to count matching packets, log packet >> header information, etc. It's up to the operator to >> decide what ACL to be applied and what 'action' (logging, >> counting, etc.) to be taken for packets that match a given >> 'rule'. =20 >>=20 >> =46rom where I'm sitting, this seems like it might already >> solve the problem you're having, without having to invent a >> wholly new IPv6 Destination Header Option. So, I would >> like to know if you have taken a look at flow-spec and, if >> so, why it was ruled out? >=20 > Certainly an interesting set of RFCs but a few questions I would have: >=20 > 1. What if BGP is not being used? >=20 > 2. What about matching packets at non-router devices (that is, hosts) If you are at the host you can simply match whatever tuple you are = interested in and log the entire packet, and then do whatever analysis = after the fact. >=20 > 3. I believe what we need in diagnostics is the entire packet not = just a logging that such a packet existed. For example, the problem we = are looking for may be in the body of the protocol data. Ex. a problem = with FTP. =20 > So, we would need the entire packet as captured by a packet analyzer = rather than a log that says 'a packet from dest x to source y was sent'. = I do not imagine that the log is going to keep the entire packet. Am I = missing something? So: A: Capture at the end host or B: Capture on the network if you really must (although having taps on = the physical layer causes most security minded operators to get the = heebie-jeebies) and match upon tuples... W >=20 >=20 >>=20 >> -shane > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nalini.elkins@insidethestack.com Mon Aug 15 08:31:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4786221F8C2F for ; Mon, 15 Aug 2011 08:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOh-XEA61mQz for ; Mon, 15 Aug 2011 08:31:16 -0700 (PDT) Received: from nm3.access.bullet.mail.mud.yahoo.com (nm3.access.bullet.mail.mud.yahoo.com [66.94.237.204]) by ietfa.amsl.com (Postfix) with SMTP id C775921F85B8 for ; Mon, 15 Aug 2011 08:31:16 -0700 (PDT) Received: from [66.94.237.127] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 15:32:02 -0000 Received: from [66.94.237.97] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 15:32:02 -0000 Received: from [127.0.0.1] by omp1002.access.mail.mud.yahoo.com with NNFMP; 15 Aug 2011 15:32:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 633068.75964.bm@omp1002.access.mail.mud.yahoo.com Received: (qmail 88751 invoked by uid 60001); 15 Aug 2011 15:32:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313422322; bh=AhA6qc2nQCL4fflgP/+R0kPaGWx00vJC7N2PZq0xLZk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rBP4/hg/MrN+6HBIFkjc1w6/tpXOQdg60CdLkfcU9SzcqgH54PycW4JMNV4n59J6hONZE6eBnDJ28PaiR9oyV+TbZp7QhbHM9Ws/Gcg5XT/o6pd+qambhJkqUbB0GVIM6L5HspBBReqvKMR9w9tz5scgyeJN/ngAKGW27bLYoR4= X-YMail-OSG: f97eujAVM1nQX0HtJwKO68aZissZpB8tnUVJE89KXsY.B_j 6bz2VReFszZi4uZ49._KR74NaslRbpm7uAYS2V9M9kYSkeIy_XqCmYwPZCI8 Oq2hdnLpYJU3ZBDFYJywvONt.Ny5CFWZZwmS.0AatxTcifAKBZv4ZD_IkHkY Qdkmlhy5CAT5sfTr7z0m4bA.qNRAxOhfL_GpqHR14fy_0rCgrFEacV20RCV9 jo7aGqjJ23p6g_EOtnA.MinshblgZokWInN05rtC16AX6kEWxygd25s1ByWl 5ozLv_unJ9l4g4PD6C7q7cWm5CTtZzYoYV6mrcJaYI6ELuSSJBNWmkXOSMDb pFFxIeIQCjnfIkshk0J06uQNShH83lL5ryQH66ioNXzqIkglo1TBbEwaxEPl TI.kuXptz7mMu4IIJgWSZTto3u1cnmhl1aCFNLpYRmoPlDcjY4zisHQNuZdE - Received: from [24.6.68.48] by web2804.biz.mail.ne1.yahoo.com via HTTP; Mon, 15 Aug 2011 08:32:01 PDT X-Mailer: YahooMailClassic/14.0.4 YahooMailWebService/0.8.113.313619 Message-ID: <1313422321.88518.YahooMailClassic@web2804.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 08:32:01 -0700 (PDT) From: nalini.elkins@insidethestack.com To: Warren Kumari In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:31:17 -0000 Warren,=0A=0A> Ok, I've been doing networking for 15+ years, and have=0A> w= orked on networks from tiny ISPs to enterprise networks to=0A> startups to = consulting to large ISPs to things that don't=0A> quite fit in other bucket= s. The only times (that I can=0A> remember!) that I have viewed IPID as an = interesting=0A> diagnostic during=A0 is to see if lots of packets have=0A> = identical IDs, and so are likely from a poorly written DoS=0A> tool. This s= eems to line up with the views of other=0A> operators in the V6OPS meeting = in Quebec.=0A>=0A=0A=0AThe people we work with have also done networking an= d diagnostics for 20 - 30 years and have a different way of doing diagnosti= cs than you do. I have talked to a number of organizations and they are all= surprised that the IPID is not in the main IPv6 header. We need to provid= e as many helpful ways to do diagnostics as possible.=0A=0A =0A> I'm not sa= ying the idea might not be useful in some=0A> circumstances, but rather tha= t you are overselling the=0A> technique...=0A> =0A=0AWell, I do think that = this has gotten a bit out of control in that I am not saying that the IPID = is the be-all and end-all of diagnostics. I am just saying that it is one = interesting and helpful piece of information. =0A=0AHaving said that, I do= think that better metrics need to be kept for automated network diagnostic= s and this kind of header is the start of one way to have the metrics that = we need. I think that exactly what metrics we need is still evolving.=0A= =0ANalini=0A From shane@castlepoint.net Mon Aug 15 10:01:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036F821F8C86 for ; Mon, 15 Aug 2011 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIERZPtJW6d9 for ; Mon, 15 Aug 2011 10:01:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5698321F8C85 for ; Mon, 15 Aug 2011 10:01:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 5EF0626806D; Mon, 15 Aug 2011 11:02:13 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Aug 2011 11:02:13 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54961; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> Date: Mon, 15 Aug 2011 11:02:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:01:28 -0000 Nalini, On Aug 15, 2011, at 8:57 AM, nalini.elkins@insidethestack.com wrote: >> Have you taken a look at flow-spec for IPv4: >> http://tools.ietf.org/html/rfc5575 >> ... and, flow-spec for IPv6: >> http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00 >> (Both the RFC and I-D are within the IDR WG). >>=20 >> In summary, using flow-spec one can define an ACL that then >> get distributed across all routers within an ASN, via BGP, >> that can then be used to count matching packets, log packet >> header information, etc. It's up to the operator to >> decide what ACL to be applied and what 'action' (logging, >> counting, etc.) to be taken for packets that match a given >> 'rule'. =20 >>=20 >> =46rom where I'm sitting, this seems like it might already >> solve the problem you're having, without having to invent a >> wholly new IPv6 Destination Header Option. So, I would >> like to know if you have taken a look at flow-spec and, if >> so, why it was ruled out? >=20 > Certainly an interesting set of RFCs but a few questions I would have: >=20 > 1. What if BGP is not being used? Turn it on? There are a plethora of books, training materials/sessions, know-how, = best practices, etc. documented and presented over the years, including = those given at various *NOG's ... if folks want/need pointers on where = to start, I (and others) would be happy to provide them. > 2. What about matching packets at non-router devices (that is, hosts) Use tcpdump and/or wireshark? > 3. I believe what we need in diagnostics is the entire packet not = just a logging that such a packet existed. For example, the problem we = are looking for may be in the body of the protocol data. Ex. a problem = with FTP. So, we would need the entire packet as captured by a packet = analyzer rather than a log that says 'a packet from dest x to source y = was sent'. I do not imagine that the log is going to keep the entire = packet. Am I missing something? Take a look at RFC 5575. It supports the idea of redirecting packets = that match a flow-spec 'rule' to an IPVPN VRF. I believe the reason = this was done was to ensure (a copy of) the packet would be sent to a = centralized collector(s) that could perform detailed packet analysis on = the contents/payload of recv'd packets that are being sampled. In short, I think this is a solved problem and there isn't a need for a = IPv6 Diagnostic Header Destination Option. -shane= From fred@cisco.com Mon Aug 15 10:14:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A778421F8C9F for ; Mon, 15 Aug 2011 10:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeTA5aWaMgQa for ; Mon, 15 Aug 2011 10:14:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BD43C21F8C7E for ; Mon, 15 Aug 2011 10:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=450; q=dns/txt; s=iport; t=1313428525; x=1314638125; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=TutQkXmlptL6V9EAsiDSk/MteIT7gagDdIOWRi6IGWE=; b=FaOZzSi6OBEaDfZBavrK9EmDNLOcLvmGCnI0erBm6b0ofgelIVHpq+tg iGxfk+OuMlcuaflEfAdctqoW1EXjiByrM3A0bMc9HoeFBjdp/rzUcngcF ZDI443KQC8c5GWjcOb7R2KvU4f09OC7lLryOI9X5d+SZ1GkUA2enhMMTz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOxTSU6rRDoH/2dsb2JhbABCqBN3gUABAQEBAgESASc/EAtGVwY1h06ZQgGeUYVoXwSHX4szhQyMCQ X-IronPort-AV: E=Sophos;i="4.67,375,1309737600"; d="scan'208";a="13267006" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2011 17:15:23 +0000 Received: from dhcp-64-101-108-129.cisco.com (dhcp-64-101-108-129.cisco.com [64.101.108.129]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7FHFNQa009055; Mon, 15 Aug 2011 17:15:23 GMT Received: from [127.0.0.1] by dhcp-64-101-108-129.cisco.com (PGP Universal service); Mon, 15 Aug 2011 10:15:23 -0700 X-PGP-Universal: processed; by dhcp-64-101-108-129.cisco.com on Mon, 15 Aug 2011 10:15:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> Date: Mon, 15 Aug 2011 10:15:15 -0700 Message-Id: References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:14:39 -0000 On Aug 15, 2011, at 10:02 AM, Shane Amante wrote: >> 1. What if BGP is not being used? >=20 > Turn it on? I don't think her question relates to how to turn it on. I think her = question relates to the fact that it is not universally needed. BGP is = used in inter-corporate networks including ISP-ISP and ISP-customer; it = is less commonly used within enterprise and especially data center = networks. So when it is not in use, ...= From shane@castlepoint.net Mon Aug 15 13:37:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8160721F8C1B for ; Mon, 15 Aug 2011 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIYfbfJEmuT2 for ; Mon, 15 Aug 2011 13:37:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4D21F8C17 for ; Mon, 15 Aug 2011 13:37:41 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 264A326806D; Mon, 15 Aug 2011 14:38:18 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Aug 2011 14:38:18 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56452; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 15 Aug 2011 14:38:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:37:42 -0000 On Aug 15, 2011, at 11:15 AM, Fred Baker wrote: > On Aug 15, 2011, at 10:02 AM, Shane Amante wrote: >=20 >>> 1. What if BGP is not being used? >>=20 >> Turn it on? >=20 > I don't think her question relates to how to turn it on. I think her = question relates to the fact that it is not universally needed. BGP is = used in inter-corporate networks including ISP-ISP and ISP-customer; it = is less commonly used within enterprise and especially data center = networks. So when it is not in use, ... But, in the case of flow-spec, we're talking about it being used as a = "policy distribution mechanism" and not as a routing protocol. In fact, = I think this is amplified by the fact that flow-spec uses an entirely = separate AFI/SAFI for flow-spec routes (1/133). So, in this case it's = entirely possible to (ab)use BGP as a information distribution = mechanism, without concerns that BGP must also used for routing. In = this case BGP is just used for automating the deployment of filters = through an ASN. And, best of all, it's already been in shipping code + = HW for a while now ... Look, if BGP is too onerous, then deploy/use sFlow/NetFlow/IPFIX. The = only concern with that may be that depending on the scale/size of = platform it may only be able to do statistical sampling, (not 1:1 = sampling), if you need to use the central RP. If that's a concern, take = it up with your favorite vendor, they have the ability to either sell = you HW (today) that will do 1:1, or close to it, sampling. I still maintain there are existing tools out there, today, that _are_ = already being used to trace these types of issues. Please let's use = them and/or improve upon them. -shane= From robert@raszuk.net Mon Aug 15 13:48:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A511E80F4 for ; Mon, 15 Aug 2011 13:48:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTCjrn+eAJrG for ; Mon, 15 Aug 2011 13:48:46 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 14BA911E80E3 for ; Mon, 15 Aug 2011 13:48:45 -0700 (PDT) Received: (qmail 30310 invoked by uid 399); 15 Aug 2011 20:49:31 -0000 Received: from unknown (HELO ?192.168.1.68?) (robert@raszuk.net@83.24.80.202) by mail37.opentransfer.com with SMTP; 15 Aug 2011 20:49:31 -0000 Message-ID: <4E498680.9030604@raszuk.net> Date: Mon, 15 Aug 2011 22:50:08 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Shane Amante References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:48:47 -0000 +1 Thx, R. > On Aug 15, 2011, at 11:15 AM, Fred Baker wrote: >> On Aug 15, 2011, at 10:02 AM, Shane Amante wrote: >> >>>> 1. What if BGP is not being used? >>> >>> Turn it on? >> >> I don't think her question relates to how to turn it on. I think >> her question relates to the fact that it is not universally needed. >> BGP is used in inter-corporate networks including ISP-ISP and >> ISP-customer; it is less commonly used within enterprise and >> especially data center networks. So when it is not in use, ... > > > But, in the case of flow-spec, we're talking about it being used as a > "policy distribution mechanism" and not as a routing protocol. In > fact, I think this is amplified by the fact that flow-spec uses an > entirely separate AFI/SAFI for flow-spec routes (1/133). So, in this > case it's entirely possible to (ab)use BGP as a information > distribution mechanism, without concerns that BGP must also used for > routing. In this case BGP is just used for automating the deployment > of filters through an ASN. And, best of all, it's already been in > shipping code + HW for a while now ... > > Look, if BGP is too onerous, then deploy/use sFlow/NetFlow/IPFIX. > The only concern with that may be that depending on the scale/size of > platform it may only be able to do statistical sampling, (not 1:1 > sampling), if you need to use the central RP. If that's a concern, > take it up with your favorite vendor, they have the ability to either > sell you HW (today) that will do 1:1, or close to it, sampling. > > I still maintain there are existing tools out there, today, that > _are_ already being used to trace these types of issues. Please > let's use them and/or improve upon them. > > -shane _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From fred@cisco.com Mon Aug 15 13:56:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2B21F8CF8 for ; Mon, 15 Aug 2011 13:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.838 X-Spam-Level: X-Spam-Status: No, score=-102.838 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jGLaBM+mNKJ for ; Mon, 15 Aug 2011 13:56:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AC10A21F8CEA for ; Mon, 15 Aug 2011 13:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2177; q=dns/txt; s=iport; t=1313441852; x=1314651452; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=8Y+3jrQQr8kTr0E74K85r63hjNhUX58wl+RVgAH5JfI=; b=OH2z5Vu/plPKy9DzLa2ophxMdF2FLawbdJs+/pw5jfGxCxrV1Gdfow80 Z2r/mEPjWDcec3IESoRdoKbAoOQ08lpFU8VEFMVnakZ+U3SIZ+0EZ6CsR UO4NjMc+u200ASLVdvSC3vX7vbLDc9MYWbS4B04pBgHV5/GmIJf4HgVCj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE6HSU6rRDoG/2dsb2JhbABCqBZ3gUABAQEBAgESASc/BQsLGC5XBi4Hh06aYAGfBYVoXwSHX4szhQyMCQ X-IronPort-AV: E=Sophos;i="4.67,376,1309737600"; d="scan'208";a="13335075" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2011 20:57:31 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7FKvVfv009145; Mon, 15 Aug 2011 20:57:31 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 15 Aug 2011 13:57:31 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 15 Aug 2011 13:57:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 15 Aug 2011 13:57:04 -0700 Message-Id: <88B750D9-3429-49A3-B283-BA1594406911@cisco.com> References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:56:46 -0000 On Aug 15, 2011, at 1:38 PM, Shane Amante wrote: >=20 > On Aug 15, 2011, at 11:15 AM, Fred Baker wrote: >> On Aug 15, 2011, at 10:02 AM, Shane Amante wrote: >>=20 >>>> 1. What if BGP is not being used? >>>=20 >>> Turn it on? >>=20 >> I don't think her question relates to how to turn it on. I think her = question relates to the fact that it is not universally needed. BGP is = used in inter-corporate networks including ISP-ISP and ISP-customer; it = is less commonly used within enterprise and especially data center = networks. So when it is not in use, ... >=20 >=20 > But, in the case of flow-spec, we're talking about it being used as a = "policy distribution mechanism" and not as a routing protocol. We could discuss "it slices, it dices, and it juliennes too." In my = experience, the implied exponential complexity is often of questionable = value. If she was using the routing protocol, having it also do = something else might make sense. If she is using a different routing = protocol or doesn't need one, turning on a routing protocol in order to = turn off its routing functionality but...=20 my head hurts. > Look, if BGP is too onerous, then deploy/use sFlow/NetFlow/IPFIX. Now, there's a sensible solution. At least it targets the intended = functionality. IPFIX, however, reports on sessions (in the target case, relatively = large sets of packets) after they happen. What she's looking for is = packet information while they're happening. > The only concern with that may be that depending on the scale/size of = platform it may only be able to do statistical sampling, (not 1:1 = sampling), if you need to use the central RP. ... packet ... while they're happening ... > If that's a concern, take it up with your favorite vendor, they have = the ability to either sell you HW (today) that will do 1:1, or close to = it, sampling. No doubt. > I still maintain there are existing tools out there, today, that _are_ = already being used to trace these types of issues. Please let's use = them and/or improve upon them. Well, and funny thing, she's building at least in part on wireshark. From shane@castlepoint.net Mon Aug 15 17:37:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BE321F8C0F for ; Mon, 15 Aug 2011 17:37:16 -0700 (PDT) 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, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRlOycYyluM4 for ; Mon, 15 Aug 2011 17:37:16 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3170621F8B54 for ; Mon, 15 Aug 2011 17:37:16 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id F38FC368199; Mon, 15 Aug 2011 18:38:02 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Aug 2011 18:38:02 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=57854; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <88B750D9-3429-49A3-B283-BA1594406911@cisco.com> Date: Mon, 15 Aug 2011 18:37:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <38E37A7F-AF37-4E36-A9BB-4F494BC8B9A2@castlepoint.net> References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com> <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net> <88B750D9-3429-49A3-B283-BA1594406911@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 00:37:17 -0000 Fred, On Aug 15, 2011, at 2:57 PM, Fred Baker wrote: >> But, in the case of flow-spec, we're talking about it being used as a = "policy distribution mechanism" and not as a routing protocol. >=20 > We could discuss "it slices, it dices, and it juliennes too." In my = experience, the implied exponential complexity is often of questionable = value. If she was using the routing protocol, having it also do = something else might make sense. If she is using a different routing = protocol or doesn't need one, turning on a routing protocol in order to = turn off its routing functionality but...=20 >=20 > my head hurts. So, does mine. :-) In any case, I think the key point to bear in mind, = there's only a one-time set-up of BGP flow-spec across all devices in = the network. After that's done, administrators can, on an ad-hoc basis, = easily inject a BGP flow-spec NLRI that gets automatically propagated = (and withdrawn) across all those devices. =20 I would argue that flow-spec is a superior tool in that regard, because = it's automating the deployment of the filters concurrently across a = [potentially large] set of devices. Any other method would either have = to rely on humans to manually deploy filters along a path of devices or = they would have to spend time creating a tool that would automate that = process, and keep it up-to-date. >> Look, if BGP is too onerous, then deploy/use sFlow/NetFlow/IPFIX. >=20 > Now, there's a sensible solution. At least it targets the intended = functionality. >=20 > IPFIX, however, reports on sessions (in the target case, relatively = large sets of packets) after they happen. What she's looking for is = packet information while they're happening. Depending on platform, this number could comfortably be 1:100 sampling. = That may be too large (or, too small) depending on one's network, HW and = other variables at play. =20 >> The only concern with that may be that depending on the scale/size of = platform it may only be able to do statistical sampling, (not 1:1 = sampling), if you need to use the central RP. >=20 > ... packet ... while they're happening ... Well, if IPFIX isn't sufficient, then how about RSPAN? Other vendors = typically refer to this as port or traffic mirroring. Some allow you to = apply ACL's on the routers/switches to allow you to filter the copied = traffic before it is sent toward the monitoring station, in order that = you're monitoring device is only recv'ing packets/frames of interest. = http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release= /12.1_13_ea1/configuration/guide/swspan.html ---snip--- You can apply an output access control list (ACL) to RSPAN traffic to = selectively filter or monitor specific packets. Specify these ACLs on = the RSPAN VLAN in the RSPAN source switches ---snip--- >> If that's a concern, take it up with your favorite vendor, they have = the ability to either sell you HW (today) that will do 1:1, or close to = it, sampling. >=20 > No doubt. >=20 >> I still maintain there are existing tools out there, today, that = _are_ already being used to trace these types of issues. Please let's = use them and/or improve upon them. >=20 > Well, and funny thing, she's building at least in part on wireshark. I think I've stated my piece on this and will now quietly retire from = this thread. Thanks, -shane= From dart@es.net Mon Aug 15 19:45:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5A21F8C4D for ; Mon, 15 Aug 2011 19:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1adRZ5fQSTf for ; Mon, 15 Aug 2011 19:45:01 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2E421F8C1B for ; Mon, 15 Aug 2011 19:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : subject : content-type : content-transfer-encoding; s=es.net; bh=sszG3Ss/3mqlRvilLp5J1RKEc7kyilNnmnwv+lkHTgM=; b=aZ5LM9ARbhN0CA1+yxPZUB2mu9kRqwGu7nKDJUUfVPMdu7ApLEP7NWPAqwHadxPF1HJ1 VPPWnDXt7OHNl4okl5bqlDnge4yO186AqN/kShBLYZr8z6ZVvFyFwU02tSDA5/HM/Yer RLNV7QFr5fV5mhRtPBVHFhWrYs038vNkEqo= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.81]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7G2jl8d014293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Aug 2011 19:45:47 -0700 Message-ID: <4E49D9DB.5060109@es.net> Date: Mon, 15 Aug 2011 19:45:47 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IETF v6ops list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-15_08:2011-08-15, 2011-08-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108150354 Subject: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 02:45:02 -0000 Hi all, We have run across an operational issue with IPv6 in backbone environments. The issue concerns Duplicate Address Detection (DAD). It is common in backbone environments to troubleshoot some transport system issues by installing soft loops in the middle of the problem circuit facing the ends, and walking the loops out toward the routers at the ends while checking for connectivity. This is a common fault-isolation technique. In an IPv4 network, connectivity on the circuit is restored when the loops are removed and the circuit is normalized. In an IPv6 network, this is not always the case. In an IPv6 network, when the loops are installed the routers at the ends see themselves and therefore believe that another host in the same broadcast domain has the same address. RFC 4862 section 5.4.5 states that when DAD detects a duplicate address that appears to be derived from a hardware address (e.g. duplicate link-local address), IPv6 operation on the interface SHOULD be disabled. Since the circuit is looped back on itself, the router sees itself and shuts down IPv6 processing on that interface. The result of this behavior is that transport-layer troubleshooting can break IPv6, and IPv6 can stay broken even after the circuit is normalized (soft loops can be installed and removed without causing the interface to bounce, so DAD is never reset). IPv4 does not have DAD, so IPv4 is self-healing under these circumstances. Therefore, you can get into a situation where IPv4 has self-healed, and IPv6 stays broken until somebody notices. ESnet has asked one of our router vendors for an interface config knob (off-by-default so as to avoid direct confrontation with standards) that would cause a router with an interface disabled due to DAD to re-run the DAD test on the interface periodically, subject to a timer. This would cause IPv6 to be self-healing in the same way that IPv4 is self-healing under troubleshooting conditions common in backbone environments. Note that the semantics here are very similar to the err-disable state timeout on Cisco routers. Please understand that this behavior is almost certainly not unique to one vendor - this is behavior that is specified by and conforms to current IPv6 standards. The standard behavior appears reasonable in a LAN environment. However, it appears suboptimal in a backbone/provider networking context. Many thanks, --eli -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From hoskuld@hotmail.com Mon Aug 15 23:19:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7728D11E8085 for ; Mon, 15 Aug 2011 23:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu6WYY1p6s-P for ; Mon, 15 Aug 2011 23:19:43 -0700 (PDT) Received: from col0-omc4-s14.col0.hotmail.com (col0-omc4-s14.col0.hotmail.com [65.55.34.216]) by ietfa.amsl.com (Postfix) with ESMTP id 7868021F871C for ; Mon, 15 Aug 2011 23:19:43 -0700 (PDT) Received: from COL114-W14 ([65.55.34.199]) by col0-omc4-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 23:20:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_66ca9d77-7f44-4fc4-be9d-59b8c11d20a1_" X-Originating-IP: [124.168.203.222] From: Greg Daley To: , Date: Tue, 16 Aug 2011 16:20:30 +1000 Importance: Normal In-Reply-To: <4E49D9DB.5060109@es.net> References: <4E49D9DB.5060109@es.net> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2011 06:20:30.0375 (UTC) FILETIME=[98F0C370:01CC5BDC] Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 06:19:44 -0000 --_66ca9d77-7f44-4fc4-be9d-59b8c11d20a1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eli=2C=20 I am concerned that the DAD timer isn't specifically the issue. An interface timer doesn't fix things because next time DAD NS is sent=20 the address is still "Duplicate" because the NS will be received=20 again by the interface. If another (4941 privacy=2C CGA) address is picked = it would also be seen as "Duplicate" whenever they are selected. This is because the duplicate DAD NS will be seen while the address is tent= ative. S5.4.3 of 4862 defines appropriate behaviour for the case where multicast m= essages may be looped back. This is effectively a case as defined there. =20 It also specifies the circumstances where a device is to believe the simult= aneous DAD NS indicates a duplicate attempt. An=20 in depth treatment of this is provided in Appendix A=2C which deals with th= e difficulty of identifying duplicate Link-layer addresses. The loopback semantics being defined within the network are not that there = is a duplicate device or that there is a duplicate MAC address but that the number of multicast NS messages received by an interfa= ce exceed that expected by the MAC. This is really only an issue with DAD NS while you are tentative of course= =2C since if you receive a DAD defense NA (to all-nodes)=2C you know you did not send it. Once you have completed DAD=2C any new DAD NS m= essages (with unspecified source) are defended against with multicast NA. So really on some media or environments=2C it may be necessary to ignore DA= D NS packets with the same source Link-Layer address while the interface comes up and is tentative. this could be specified wit= h a (Default=3Doff) interface level flag. This leads to a slight weakening of DAD in these circumstances=2C but as di= scussed in Appendix A=2C duplicate MAC addresses are a hard issue anyway. Greg Daley > Date: Mon=2C 15 Aug 2011 19:45:47 -0700 > From: dart@es.net > To: v6ops@ietf.org > Subject: [v6ops] DAD issues in IPv6 backbone environments >=20 > Hi all=2C >=20 > We have run across an operational issue with IPv6 in backbone=20 > environments. The issue concerns Duplicate Address Detection (DAD). >=20 > It is common in backbone environments to troubleshoot some transport=20 > system issues by installing soft loops in the middle of the problem=20 > circuit facing the ends=2C and walking the loops out toward the routers a= t=20 > the ends while checking for connectivity. This is a common=20 > fault-isolation technique. In an IPv4 network=2C connectivity on the=20 > circuit is restored when the loops are removed and the circuit is=20 > normalized. In an IPv6 network=2C this is not always the case. >=20 > In an IPv6 network=2C when the loops are installed the routers at the end= s=20 > see themselves and therefore believe that another host in the same=20 > broadcast domain has the same address. RFC 4862 section 5.4.5 states=20 > that when DAD detects a duplicate address that appears to be derived=20 > from a hardware address (e.g. duplicate link-local address)=2C IPv6=20 > operation on the interface SHOULD be disabled. Since the circuit is=20 > looped back on itself=2C the router sees itself and shuts down IPv6=20 > processing on that interface. >=20 > The result of this behavior is that transport-layer troubleshooting can=20 > break IPv6=2C and IPv6 can stay broken even after the circuit is=20 > normalized (soft loops can be installed and removed without causing the=20 > interface to bounce=2C so DAD is never reset). IPv4 does not have DAD=2C= so=20 > IPv4 is self-healing under these circumstances. Therefore=2C you can get= =20 > into a situation where IPv4 has self-healed=2C and IPv6 stays broken unti= l=20 > somebody notices. >=20 > ESnet has asked one of our router vendors for an interface config knob=20 > (off-by-default so as to avoid direct confrontation with standards) that= =20 > would cause a router with an interface disabled due to DAD to re-run the= =20 > DAD test on the interface periodically=2C subject to a timer. This would= =20 > cause IPv6 to be self-healing in the same way that IPv4 is self-healing=20 > under troubleshooting conditions common in backbone environments. Note=20 > that the semantics here are very similar to the err-disable state=20 > timeout on Cisco routers. >=20 > Please understand that this behavior is almost certainly not unique to=20 > one vendor - this is behavior that is specified by and conforms to=20 > current IPv6 standards. The standard behavior appears reasonable in a=20 > LAN environment. However=2C it appears suboptimal in a backbone/provider= =20 > networking context. >=20 > Many thanks=2C >=20 > --eli >=20 >=20 > --=20 > Eli Dart NOC: (510) 486-7600 > ESnet Network Engineering Group (AS293) (800) 333-7638 > Lawrence Berkeley National Laboratory > PGP Key fingerprint =3D C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --_66ca9d77-7f44-4fc4-be9d-59b8c11d20a1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Eli=2C

I am concerned that the DAD timer isn't specifically = the issue.

An interface timer doesn't fix things because next time DAD NS is sent=20 the address is still "Duplicate" because the NS will be received
again by the interface. If another (4941 privacy=2C CGA) address is picked = it would also be seen as "Duplicate" whenever they are selected.

This is because the duplicate DAD NS will be seen while the address is = tentative.

S5.4.3 of 4862 defines appropriate behaviour for the case where multicast m= essages may be looped back. =3B This is effectively
a case as defined there. =3B

It also specifies the circumstance= s where a device is to believe the simultaneous DAD NS indicates a duplicat= e attempt. =3B An
in depth treatment of this is provided in Appendi= x A=2C which deals with the difficulty of identifying duplicate Link-layer = addresses.

The loopback semantics being defined within the network a= re not that there is a duplicate device or that there is a duplicate MACaddress but that the number of multicast NS messages received by an interf= ace exceed that expected by the MAC.

This is really only an issue wi= th DAD NS while you are tentative of course=2C since if you receive a = =3B DAD defense NA (to all-nodes)=2C you
know you did not send it. = =3B =3B Once you have completed DAD=2C any new DAD NS messages (with un= specified source) are defended
against with multicast NA.

So real= ly on some media or environments=2C it may be necessary to ignore DAD NS pa= ckets with the same source Link-Layer address
while the interface comes = up and is tentative. =3B this could be specified with a (Default=3Doff)= interface level flag.

This leads to a slight weakening of DAD in th= ese circumstances=2C but as discussed in Appendix A=2C duplicate MAC addres= ses are a hard
issue anyway.

Greg Daley


>=3B Da= te: Mon=2C 15 Aug 2011 19:45:47 -0700
>=3B From: dart@es.net
>=3B= To: v6ops@ietf.org
>=3B Subject: [v6ops] DAD issues in IPv6 backbone = environments
>=3B
>=3B Hi all=2C
>=3B
>=3B We have ru= n across an operational issue with IPv6 in backbone
>=3B environments= . The issue concerns Duplicate Address Detection (DAD).
>=3B
>= =3B It is common in backbone environments to troubleshoot some transport >=3B system issues by installing soft loops in the middle of the proble= m
>=3B circuit facing the ends=2C and walking the loops out toward th= e routers at
>=3B the ends while checking for connectivity. This is = a common
>=3B fault-isolation technique. In an IPv4 network=2C conne= ctivity on the
>=3B circuit is restored when the loops are removed an= d the circuit is
>=3B normalized. In an IPv6 network=2C this is not = always the case.
>=3B
>=3B In an IPv6 network=2C when the loops = are installed the routers at the ends
>=3B see themselves and therefo= re believe that another host in the same
>=3B broadcast domain has th= e same address. RFC 4862 section 5.4.5 states
>=3B that when DAD det= ects a duplicate address that appears to be derived
>=3B from a hardw= are address (e.g. duplicate link-local address)=2C IPv6
>=3B operatio= n on the interface SHOULD be disabled. Since the circuit is
>=3B loo= ped back on itself=2C the router sees itself and shuts down IPv6
>=3B= processing on that interface.
>=3B
>=3B The result of this beha= vior is that transport-layer troubleshooting can
>=3B break IPv6=2C a= nd IPv6 can stay broken even after the circuit is
>=3B normalized (so= ft loops can be installed and removed without causing the
>=3B interf= ace to bounce=2C so DAD is never reset). IPv4 does not have DAD=2C so
= >=3B IPv4 is self-healing under these circumstances. Therefore=2C you ca= n get
>=3B into a situation where IPv4 has self-healed=2C and IPv6 st= ays broken until
>=3B somebody notices.
>=3B
>=3B ESnet ha= s asked one of our router vendors for an interface config knob
>=3B (= off-by-default so as to avoid direct confrontation with standards) that >=3B would cause a router with an interface disabled due to DAD to re-ru= n the
>=3B DAD test on the interface periodically=2C subject to a tim= er. This would
>=3B cause IPv6 to be self-healing in the same way th= at IPv4 is self-healing
>=3B under troubleshooting conditions common = in backbone environments. Note
>=3B that the semantics here are very= similar to the err-disable state
>=3B timeout on Cisco routers.
&= gt=3B
>=3B Please understand that this behavior is almost certainly n= ot unique to
>=3B one vendor - this is behavior that is specified by = and conforms to
>=3B current IPv6 standards. The standard behavior a= ppears reasonable in a
>=3B LAN environment. However=2C it appears s= uboptimal in a backbone/provider
>=3B networking context.
>=3B <= br>>=3B Many thanks=2C
>=3B
>=3B --eli
>=3B
>=3B =
>=3B --
>=3B Eli Dart = NOC: (510) 486-7600
>=3B ESnet Network Engineering Group (AS293) = (800) 333-7638
>=3B Lawrence Berkeley National Laborator= y
>=3B PGP Key fingerprint =3D C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478= 5F82 B2B3
>=3B _______________________________________________
>= =3B v6ops mailing list
>=3B v6ops@ietf.org
>=3B https://www.ietf.= org/mailman/listinfo/v6ops
= --_66ca9d77-7f44-4fc4-be9d-59b8c11d20a1_-- From swmike@swm.pp.se Tue Aug 16 01:09:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E6121F8B75 for ; Tue, 16 Aug 2011 01:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5qpWiF5-eJl for ; Tue, 16 Aug 2011 01:09:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3013C21F8B74 for ; Tue, 16 Aug 2011 01:09:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C01599C; Tue, 16 Aug 2011 10:09:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BED279A; Tue, 16 Aug 2011 10:09:57 +0200 (CEST) Date: Tue, 16 Aug 2011 10:09:57 +0200 (CEST) From: Mikael Abrahamsson To: Eli Dart In-Reply-To: <4E49D9DB.5060109@es.net> Message-ID: References: <4E49D9DB.5060109@es.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:09:22 -0000 On Mon, 15 Aug 2011, Eli Dart wrote: > Please understand that this behavior is almost certainly not unique to > one vendor - this is behavior that is specified by and conforms to > current IPv6 standards. The standard behavior appears reasonable in a > LAN environment. However, it appears suboptimal in a backbone/provider > networking context. I've seen this happening on POS interfaces (which by definition isn't even a LAN interface, it's a point-to-point interface). Haven't seen it in a while, so it might be that the vendor actually disabled DAD on this type of interface in newer versions. But yes, I agree, this is a problem. -- Mikael Abrahamsson email: swmike@swm.pp.se From gert@space.net Tue Aug 16 01:50:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DCC21F8B5B for ; Tue, 16 Aug 2011 01:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDWsXZkZUncg for ; Tue, 16 Aug 2011 01:50:03 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6B421F8AD2 for ; Tue, 16 Aug 2011 01:50:01 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 705A1F85EE for ; Tue, 16 Aug 2011 10:50:48 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 45BE9F860B for ; Tue, 16 Aug 2011 10:50:48 +0200 (CEST) Received: (qmail 91348 invoked by uid 1007); 16 Aug 2011 10:50:48 +0200 Date: Tue, 16 Aug 2011 10:50:48 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20110816085048.GN72014@Space.Net> References: <4E49D9DB.5060109@es.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.21 (2010-09-15) Cc: IETF v6ops list Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:50:04 -0000 Hi, On Tue, Aug 16, 2011 at 10:09:57AM +0200, Mikael Abrahamsson wrote: > I've seen this happening on POS interfaces (which by definition isn't even > a LAN interface, it's a point-to-point interface). Haven't seen it in a > while, so it might be that the vendor actually disabled DAD on this type > of interface in newer versions. > > But yes, I agree, this is a problem. Same here (on POS, because we don't usually loop ethernet interfaces, but I can see the problem there as well). Gert Doering -- Operator -- have you enabled IPv6 on something today...? 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 narten@us.ibm.com Tue Aug 16 06:23:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6351821F8A7A for ; Tue, 16 Aug 2011 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhx8saB4Tnxh for ; Tue, 16 Aug 2011 06:23:51 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id 85C8121F8A71 for ; Tue, 16 Aug 2011 06:23:51 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7GD0Kgt026708 for ; Tue, 16 Aug 2011 09:00:20 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7GDORCt3022880 for ; Tue, 16 Aug 2011 09:24:28 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7GDORnb001393 for ; Tue, 16 Aug 2011 10:24:27 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-60.mts.ibm.com [9.76.156.60]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7GDOO29001078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 10:24:26 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7GDOGXO015351; Tue, 16 Aug 2011 09:24:20 -0400 Message-Id: <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> To: dart@es.net In-reply-to: <4E49D9DB.5060109@es.net> References: <4E49D9DB.5060109@es.net> Comments: In-reply-to Eli Dart message dated "Mon, 15 Aug 2011 19:45:47 -0700." Date: Tue, 16 Aug 2011 09:24:16 -0400 From: Thomas Narten Cc: IETF v6ops list Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:23:52 -0000 Having a configuration knob to turn of DAD to deal with these sorts of issues seems perfectly reasonable to me. Fine for a router, seems unnecessary for a host. Disabled by default. I don't think any spec needs to be changed. This is an example of the kind of thing an implementation should just be able to do if necessary. Thomas Eli Dart writes: > Hi all, > We have run across an operational issue with IPv6 in backbone > environments. The issue concerns Duplicate Address Detection (DAD). > It is common in backbone environments to troubleshoot some transport > system issues by installing soft loops in the middle of the problem > circuit facing the ends, and walking the loops out toward the routers at > the ends while checking for connectivity. This is a common > fault-isolation technique. In an IPv4 network, connectivity on the > circuit is restored when the loops are removed and the circuit is > normalized. In an IPv6 network, this is not always the case. > In an IPv6 network, when the loops are installed the routers at the ends > see themselves and therefore believe that another host in the same > broadcast domain has the same address. RFC 4862 section 5.4.5 states > that when DAD detects a duplicate address that appears to be derived > from a hardware address (e.g. duplicate link-local address), IPv6 > operation on the interface SHOULD be disabled. Since the circuit is > looped back on itself, the router sees itself and shuts down IPv6 > processing on that interface. > The result of this behavior is that transport-layer troubleshooting can > break IPv6, and IPv6 can stay broken even after the circuit is > normalized (soft loops can be installed and removed without causing the > interface to bounce, so DAD is never reset). IPv4 does not have DAD, so > IPv4 is self-healing under these circumstances. Therefore, you can get > into a situation where IPv4 has self-healed, and IPv6 stays broken until > somebody notices. > ESnet has asked one of our router vendors for an interface config knob > (off-by-default so as to avoid direct confrontation with standards) that > would cause a router with an interface disabled due to DAD to re-run the > DAD test on the interface periodically, subject to a timer. This would > cause IPv6 to be self-healing in the same way that IPv4 is self-healing > under troubleshooting conditions common in backbone environments. Note > that the semantics here are very similar to the err-disable state > timeout on Cisco routers. > Please understand that this behavior is almost certainly not unique to > one vendor - this is behavior that is specified by and conforms to > current IPv6 standards. The standard behavior appears reasonable in a > LAN environment. However, it appears suboptimal in a backbone/provider > networking context. > Many thanks, > --eli > -- > Eli Dart NOC: (510) 486-7600 > ESnet Network Engineering Group (AS293) (800) 333-7638 > Lawrence Berkeley National Laboratory > PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sthaug@nethelp.no Tue Aug 16 06:47:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82F921F8A4B for ; Tue, 16 Aug 2011 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuKq6x58NLoz for ; Tue, 16 Aug 2011 06:47:45 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id B6D8E21F89BE for ; Tue, 16 Aug 2011 06:47:44 -0700 (PDT) Received: (qmail 43941 invoked from network); 16 Aug 2011 13:48:27 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Aug 2011 13:48:27 -0000 Date: Tue, 16 Aug 2011 15:48:27 +0200 (CEST) Message-Id: <20110816.154827.78743604.sthaug@nethelp.no> To: narten@us.ibm.com From: sthaug@nethelp.no In-Reply-To: <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:47:45 -0000 > Having a configuration knob to turn of DAD to deal with these sorts of > issues seems perfectly reasonable to me. Fine for a router, seems > unnecessary for a host. Disabled by default. > > I don't think any spec needs to be changed. This is an example of the > kind of thing an implementation should just be able to do if > necessary. The desire is not necessarily to turn off DAD, but to ensure that DAD is retried once in a while. I have at least two different use cases here: 1. An Ethernet circuit is looped (for instance, via Ethernet over SDH and a loop in the SDH network). The router sees itself via DAD, and disables the interface. When the loop is removed, the interface is *not* automatically enabled again. I would like DAD to be rerun after automatically after a while - this removes the need for manually bouncing the (sub)interface. 2. The customer on a point to point Ethernet circuit configures the same IPv6 address as the provider, and DAD disables the interface at the provider end. When the config error is corrected at the customer end, the interface is *not* automatically enabled again. As above, I I would like DAD to be rerun after automatically after a while - this removes the need for manually bouncing the (sub)interface. Particularly in the second case I absolutely *don't* want to turn off DAD permanently. In the first case turning off DAD might be a solution, but rerunning at intervals seems to me to be a *better* solution. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From narten@us.ibm.com Tue Aug 16 06:54:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCCF21F8ABD for ; Tue, 16 Aug 2011 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej2TlypYxiDL for ; Tue, 16 Aug 2011 06:54:54 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1D71B21F8AA8 for ; Tue, 16 Aug 2011 06:54:54 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7GDVXMg028208 for ; Tue, 16 Aug 2011 09:31:33 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7GDtfFe235456 for ; Tue, 16 Aug 2011 09:55:41 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7GDtekE026842 for ; Tue, 16 Aug 2011 10:55:41 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-60.mts.ibm.com [9.76.156.60]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7GDtdkp026809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 10:55:39 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7GDtcrW015509; Tue, 16 Aug 2011 09:55:38 -0400 Message-Id: <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> To: sthaug@nethelp.no In-reply-to: <20110816.154827.78743604.sthaug@nethelp.no> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> Comments: In-reply-to sthaug@nethelp.no message dated "Tue, 16 Aug 2011 15:48:27 +0200." Date: Tue, 16 Aug 2011 09:55:38 -0400 From: Thomas Narten Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:54:54 -0000 sthaug@nethelp.no writes: > > Having a configuration knob to turn of DAD to deal with these sorts of > > issues seems perfectly reasonable to me. Fine for a router, seems > > unnecessary for a host. Disabled by default. > > > > I don't think any spec needs to be changed. This is an example of the > > kind of thing an implementation should just be able to do if > > necessary. > The desire is not necessarily to turn off DAD, but to ensure that DAD > is retried once in a while. > I have at least two different use cases here: > 1. An Ethernet circuit is looped (for instance, via Ethernet over SDH > and a loop in the SDH network). The router sees itself via DAD, and > disables the interface. When the loop is removed, the interface is > *not* automatically enabled again. I would like DAD to be rerun after > automatically after a while - this removes the need for manually > bouncing the (sub)interface. So, it's OK for the interface to go down for an extended period of time (i.e., until DAD is rerun some time later)? Isn't this a case where you'd want to "kick" the interface to try again (once the loopback is disabled) > 2. The customer on a point to point Ethernet circuit configures the > same IPv6 address as the provider, and DAD disables the interface at > the provider end. When the config error is corrected at the customer > end, the interface is *not* automatically enabled again. As above, I > I would like DAD to be rerun after automatically after a while - this > removes the need for manually bouncing the (sub)interface. What kind of time frame are you talking about? I'd be worried if the "rerun DAD" timer was short, because it would increase the odds that DAD would succeed when it shouldn't. But if the time out is long, it seems to me you wouldn't really solve the customer problem. I.e, you can't tell them to "fix your address, and wait 3 hours". Right? > Particularly in the second case I absolutely *don't* want to turn off > DAD permanently. In the first case turning off DAD might be a solution, > but rerunning at intervals seems to me to be a *better* solution. Again, what time frames are you talking about? Thomas From gert@space.net Tue Aug 16 06:55:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA7121F8AFA for ; Tue, 16 Aug 2011 06:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NyylB003VGu for ; Tue, 16 Aug 2011 06:55:00 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id E969121F8AED for ; Tue, 16 Aug 2011 06:54:59 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 783DEF85DE for ; Tue, 16 Aug 2011 15:55:46 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5B42DF85DD for ; Tue, 16 Aug 2011 15:55:46 +0200 (CEST) Received: (qmail 6110 invoked by uid 1007); 16 Aug 2011 15:55:46 +0200 Date: Tue, 16 Aug 2011 15:55:46 +0200 From: Gert Doering To: sthaug@nethelp.no Message-ID: <20110816135546.GE72014@Space.Net> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110816.154827.78743604.sthaug@nethelp.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: narten@us.ibm.com, v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:55:00 -0000 Hi, On Tue, Aug 16, 2011 at 03:48:27PM +0200, sthaug@nethelp.no wrote: > Particularly in the second case I absolutely *don't* want to turn off > DAD permanently. In the first case turning off DAD might be a solution, > but rerunning at intervals seems to me to be a *better* solution. +1 (possibly combined with the "if it's coming from my own MAC address, assume it's me talking to myself and don't take it as DAD failure at all" approach) Gert Doering -- Operator -- have you enabled IPv6 on something today...? 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 narten@us.ibm.com Tue Aug 16 07:06:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550E321F8B43 for ; Tue, 16 Aug 2011 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXpV3RKo55x6 for ; Tue, 16 Aug 2011 07:06:21 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD321F8B37 for ; Tue, 16 Aug 2011 07:06:21 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7GDx90i004848 for ; Tue, 16 Aug 2011 07:59:09 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7GE57Fm118638 for ; Tue, 16 Aug 2011 08:05:23 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7GEAmJi009916 for ; Tue, 16 Aug 2011 08:10:48 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-60.mts.ibm.com [9.76.156.60]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7GEAlAQ009863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 08:10:48 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7GE53q9015556; Tue, 16 Aug 2011 10:05:04 -0400 Message-Id: <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> To: Gert Doering In-reply-to: <20110816135546.GE72014@Space.Net> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> Comments: In-reply-to Gert Doering message dated "Tue, 16 Aug 2011 15:55:46 +0200." Date: Tue, 16 Aug 2011 10:05:03 -0400 From: Thomas Narten Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:06:22 -0000 Gert Doering writes: > (possibly combined with the "if it's coming from my own MAC address, > assume it's me talking to myself and don't take it as DAD failure at > all" approach) If you see a packet with your own MAC address as the source, there are two possibilities: 1) You are seeing your own packet (e.g., a loopback) 2) There are interfaces with duplicate MAC addresses on your network. Fundamentally, DAD detects the second case (since stateless address autoconf generated address contains the embedded MAC address). If you assume that any received packet with a src MAC address that is the same as your own is in fact your own, you might as well not bother running DAD at all. But doing so opens up your network to even bigger problems, because things won't work right (when duplicate MAC addrs exist), but diagnosing the situtuation is difficult. IPv6 defined DAD the way it did to prefer disabling interfaces in such cases rather than trying to automatically do something different because fundamentally, when you have to machines using the same MAC addr you have problems that can't be fixed without operator intervention. Thomas From gert@space.net Tue Aug 16 07:17:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82221F8742 for ; Tue, 16 Aug 2011 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGL0Avr+Zykm for ; Tue, 16 Aug 2011 07:17:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2297B21F8B66 for ; Tue, 16 Aug 2011 07:17:00 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 19B42F85DE for ; Tue, 16 Aug 2011 16:17:49 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F2D7FF85EC for ; Tue, 16 Aug 2011 16:17:48 +0200 (CEST) Received: (qmail 12693 invoked by uid 1007); 16 Aug 2011 16:17:48 +0200 Date: Tue, 16 Aug 2011 16:17:48 +0200 From: Gert Doering To: Thomas Narten Message-ID: <20110816141748.GF72014@Space.Net> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OK5iW/qaYhrdVULs" Content-Disposition: inline In-Reply-To: <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:17:02 -0000 --OK5iW/qaYhrdVULs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 16, 2011 at 10:05:03AM -0400, Thomas Narten wrote: > Gert Doering writes: >=20 > > (possibly combined with the "if it's coming from my own MAC address,=20 > > assume it's me talking to myself and don't take it as DAD failure at=20 > > all" approach) >=20 > If you see a packet with your own MAC address as the source, there > are two possibilities: >=20 > 1) You are seeing your own packet (e.g., a loopback) >=20 > 2) There are interfaces with duplicate MAC addresses on your network. Indeed. > Fundamentally, DAD detects the second case (since stateless address > autoconf generated address contains the embedded MAC address). In ISP networks, the first case happens more often than the second case, and DAD-without-retries forces operator action, which is something to avoid. (One of the examples we saw was a transient failure on a STM-1, which=20 led to a "link down", "link up with loop", "link stays up but loop goes=20 away" situation - IPv4 recovered just fine, IPv6 died, because DAD disabled IPv6 and kept it down. Image this link flap being at 3 am in the morning, and someone having to get out of bed to fix something for IPv6 that wasn't needed for IPv4...) > If you assume that any received packet with a src MAC address that is > the same as your own is in fact your own, you might as well not bother > running DAD at all.=20 Having such a knob available for the ISP side of things would not something I'd object to... (or a DAD variant that will warn you, but=20 not disable the protocol - like what Cisco does for IPv4, warn that there is a duplicate address, but use it anyway) > But doing so opens up your network to even bigger > problems, because things won't work right (when duplicate MAC addrs > exist), but diagnosing the situtuation is difficult. IPv6 defined DAD > the way it did to prefer disabling interfaces in such cases rather > than trying to automatically do something different because > fundamentally, when you have to machines using the same MAC addr you > have problems that can't be fixed without operator intervention. In my network history, I have seen one case of duplicate MAC (which was indeed quite painful to diagnose), and numerous cases of links being looped for diagnosis. So for our application case, something that fixes a very rare problem by making a "nearly day-to-day" operation *break* is not the right answer. Of course DAD catches more than "duplicate MAC", but also "mis-typed static IPv6 configuration" - and that, indeed, happens every so often, so DAD should learn to discern the difference -=20 "same IPv6 address, different MAC -> not me, shutdown protocol"=20 "same IPv6 address, same MAC -> might be me, flag warning, don't=20 disable port, retry in regular intervals" (so if it's indeed a=20 duplicate MAC address, the logs will at least hint at the problem) Gert Doering -- Operator --=20 have you enabled IPv6 on something today...? 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 --OK5iW/qaYhrdVULs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTkp8DKkuBuNlUUl1AQLMLQP/WBsbZHSiN4Yj6ruPllkHP5/hmDPVreDw Og7lC/aiZLY3fbKw/a+fMqwsbwl6XU9QDJLjArC/puJTofNo0ETzn41lnqMJE3fe l6f+VtAgetIpA3PSnwcsgWFshcr0jwSXvq+FJrrCZoJhxoB6+SjOEHDkFthnR/me rt7N9b/lo5M= =qwSO -----END PGP SIGNATURE----- --OK5iW/qaYhrdVULs-- From pch-b29AA871B@u-1.phicoh.com Tue Aug 16 07:25:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3837E21F8B91 for ; Tue, 16 Aug 2011 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.511 X-Spam-Level: X-Spam-Status: No, score=-4.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZV2Xudy002N for ; Tue, 16 Aug 2011 07:25:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8D21F8B1E for ; Tue, 16 Aug 2011 07:24:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QtKaL-0001j9C; Tue, 16 Aug 2011 16:25:41 +0200 Message-Id: To: Thomas Narten From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> In-reply-to: Your message of "Tue, 16 Aug 2011 10:05:03 -0400 ." <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> Date: Tue, 16 Aug 2011 16:25:26 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:25:01 -0000 In your letter dated Tue, 16 Aug 2011 10:05:03 -0400 you wrote: >If you see a packet with your own MAC address as the source, there >are two possibilities: > >1) You are seeing your own packet (e.g., a loopback) > >2) There are interfaces with duplicate MAC addresses on your network. > >Fundamentally, DAD detects the second case (since stateless address >autoconf generated address contains the embedded MAC address). > >If you assume that any received packet with a src MAC address that is >the same as your own is in fact your own, you might as well not bother >running DAD at all. It's a little bit more subtle. That packet you would discard is identical to the one you just sent. If you just sent an NS, and you got an NA, then obviously there is something wrong. If you just sent an NS and got an extra NS, then it could be either a loop or a duplicate MAC. If, when adding systems to a link, you do it slowly enough that one node will have completed DAD before the next one starts, then you don't need to do anything special in case of duplicate MACs. For router networks, this is typically the case. From jmh@joelhalpern.com Tue Aug 16 07:39:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD021F8AF8 for ; Tue, 16 Aug 2011 07:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK8gtFgzX99h for ; Tue, 16 Aug 2011 07:39:21 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1421F87C5 for ; Tue, 16 Aug 2011 07:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B796C32280A0 for ; Tue, 16 Aug 2011 07:40:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-177.clppva.btas.verizon.net [71.161.51.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 7BCD1325C159 for ; Tue, 16 Aug 2011 07:40:08 -0700 (PDT) Message-ID: <4E4A813C.8080605@joelhalpern.com> Date: Tue, 16 Aug 2011 10:39:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 CC: v6ops@ietf.org References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:39:21 -0000 As I recall, the classic solution for this in the PPP case was to include a random nonce in the message. If you got your own nonce, you could assume it was a reflected message. It is not clear to me that is worth doing in this case. Yours, Joel On 8/16/2011 10:25 AM, Philip Homburg wrote: > In your letter dated Tue, 16 Aug 2011 10:05:03 -0400 you wrote: >> If you see a packet with your own MAC address as the source, there >> are two possibilities: >> >> 1) You are seeing your own packet (e.g., a loopback) >> >> 2) There are interfaces with duplicate MAC addresses on your network. >> >> Fundamentally, DAD detects the second case (since stateless address >> autoconf generated address contains the embedded MAC address). >> >> If you assume that any received packet with a src MAC address that is >> the same as your own is in fact your own, you might as well not bother >> running DAD at all. > > It's a little bit more subtle. That packet you would discard is identical to > the one you just sent. If you just sent an NS, and you got an NA, then > obviously there is something wrong. > > If you just sent an NS and got an extra NS, then it could be either a loop or > a duplicate MAC. > > If, when adding systems to a link, you do it slowly enough that one node will > have completed DAD before the next one starts, then you don't need to do > anything special in case of duplicate MACs. > > For router networks, this is typically the case. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From dougb@dougbarton.us Tue Aug 16 07:59:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C5A21F8B79 for ; Tue, 16 Aug 2011 07:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfEll7iIXwNq for ; Tue, 16 Aug 2011 07:59:00 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 553FE21F8B6F for ; Tue, 16 Aug 2011 07:59:00 -0700 (PDT) Received: (qmail 30250 invoked by uid 399); 16 Aug 2011 14:59:46 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 16 Aug 2011 14:59:46 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4E4A85E4.60400@dougbarton.us> Date: Tue, 16 Aug 2011 07:59:48 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> In-Reply-To: <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:59:01 -0000 On 8/16/2011 7:05 AM, Thomas Narten wrote: > Gert Doering writes: > >> > (possibly combined with the "if it's coming from my own MAC address, >> > assume it's me talking to myself and don't take it as DAD failure at >> > all" approach) > If you see a packet with your own MAC address as the source, there > are two possibilities: > > 1) You are seeing your own packet (e.g., a loopback) > > 2) There are interfaces with duplicate MAC addresses on your network. 3) Your network is under a DOS attack. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From narten@us.ibm.com Tue Aug 16 08:42:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5721F89BA for ; Tue, 16 Aug 2011 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMzOMDdo7a4D for ; Tue, 16 Aug 2011 08:42:23 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id A361521F8997 for ; Tue, 16 Aug 2011 08:42:23 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7GFIsGG005170 for ; Tue, 16 Aug 2011 11:18:54 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7GFh1ML224150 for ; Tue, 16 Aug 2011 11:43:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7GFh1XT028256 for ; Tue, 16 Aug 2011 11:43:01 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-60.mts.ibm.com [9.76.156.60]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7GFh0WW028196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 11:43:01 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7GFgxuE016064; Tue, 16 Aug 2011 11:43:00 -0400 Message-Id: <201108161543.p7GFgxuE016064@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" In-reply-to: <4E4A813C.8080605@joelhalpern.com> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <4E4A813C.8080605@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Tue, 16 Aug 2011 10:39:56 -0400." Date: Tue, 16 Aug 2011 11:42:59 -0400 From: Thomas Narten Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 15:42:24 -0000 "Joel M. Halpern" writes: > As I recall, the classic solution for this in the PPP case was to > include a random nonce in the message. If you got your own nonce, you > could assume it was a reflected message. > It is not clear to me that is worth doing in this case. Agreed. That said, it would not be very hard to define/add a Nonce option, that could (optionally) be included in NS (or other ND messages). Implementations would be required to ignore them (per existing specs). We'd then find out to what degree current implementations actually do ignore options that say "ignore if you don't understand". :-) Indeed, if you really wanted to properly "solve" the problem of detecting when loopback has been enabled/disabled, you could detect the condition (easily) and at fairly high frequency probe the link to see when the condition has been fixed. Thomas From sthaug@nethelp.no Tue Aug 16 09:05:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752921F8BF4 for ; Tue, 16 Aug 2011 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9au-IyYke+sR for ; Tue, 16 Aug 2011 09:05:17 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 04EA321F8B94 for ; Tue, 16 Aug 2011 09:05:16 -0700 (PDT) Received: (qmail 57576 invoked from network); 16 Aug 2011 16:06:03 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Aug 2011 16:06:03 -0000 Date: Tue, 16 Aug 2011 18:06:03 +0200 (CEST) Message-Id: <20110816.180603.41684832.sthaug@nethelp.no> To: narten@us.ibm.com From: sthaug@nethelp.no In-Reply-To: <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> References: <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:05:18 -0000 > > > I don't think any spec needs to be changed. This is an example of the > > > kind of thing an implementation should just be able to do if > > > necessary. > > > The desire is not necessarily to turn off DAD, but to ensure that DAD > > is retried once in a while. > > > I have at least two different use cases here: > > > 1. An Ethernet circuit is looped (for instance, via Ethernet over SDH > > and a loop in the SDH network). The router sees itself via DAD, and > > disables the interface. When the loop is removed, the interface is > > *not* automatically enabled again. I would like DAD to be rerun after > > automatically after a while - this removes the need for manually > > bouncing the (sub)interface. > > So, it's OK for the interface to go down for an extended period of > time (i.e., until DAD is rerun some time later)? I was thinking of rerunning DAD, say, every 5 to 10 minutes. If it takes 5 to 10 minutes for a problem to "fix itself" (i.e. we don't have to do something on our router) that's okay. > Isn't this a case where you'd want to "kick" the interface to try > again (once the loopback is disabled) If the delay is 5 to 10 minutes, I would much rather avoid "kicking" the interface, because that requires manual intervention on router. Also, note that the people removing the loop and the people who could "kick" an interface might very well be very different. > > 2. The customer on a point to point Ethernet circuit configures the > > same IPv6 address as the provider, and DAD disables the interface at > > the provider end. When the config error is corrected at the customer > > end, the interface is *not* automatically enabled again. As above, I > > I would like DAD to be rerun after automatically after a while - this > > removes the need for manually bouncing the (sub)interface. > > What kind of time frame are you talking about? I'd be worried if the > "rerun DAD" timer was short, because it would increase the odds that > DAD would succeed when it shouldn't. But if the time out is long, it > seems to me you wouldn't really solve the customer problem. I.e, you > can't tell them to "fix your address, and wait 3 hours". Right? 5 to 10 minutes is the timeframe I'm thinking of. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From dart@es.net Tue Aug 16 09:08:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB805E8001 for ; Tue, 16 Aug 2011 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x48U2Ers8M82 for ; Tue, 16 Aug 2011 09:08:08 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9969C21F8B74 for ; Tue, 16 Aug 2011 09:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=oRfvRHMWRaT1d97Ba83fQSdkWLULIVA4Won15Qp7lnw=; b=NALMWGKTIkDumR6eDzXbMWeSHst3hLOR2zt+mmg/LUI5zgcLTZTWh43RvVbJlRU47jSV K4b3UAmugNBC7F18bO2M9C6w+y0j8wVtbnY2AxmRJ/ZvPgS7cXbarVTPUpvxele7/6l9 RELUuw/KXdYWLFnkg7RAE1DDy2uX401dXTE= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.81]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7GG8rDK027824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2011 09:08:53 -0700 Message-ID: <4E4A9615.5020501@es.net> Date: Tue, 16 Aug 2011 09:08:53 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> In-Reply-To: <20110816.154827.78743604.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-16_04:2011-08-16, 2011-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108160183 Cc: narten@us.ibm.com, v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:08:09 -0000 On 8/16/11 6:48 AM, sthaug@nethelp.no wrote: >> Having a configuration knob to turn of DAD to deal with these sorts of >> issues seems perfectly reasonable to me. Fine for a router, seems >> unnecessary for a host. Disabled by default. >> >> I don't think any spec needs to be changed. This is an example of the >> kind of thing an implementation should just be able to do if >> necessary. > > The desire is not necessarily to turn off DAD, but to ensure that DAD > is retried once in a while. > > I have at least two different use cases here: > > 1. An Ethernet circuit is looped (for instance, via Ethernet over SDH > and a loop in the SDH network). The router sees itself via DAD, and > disables the interface. When the loop is removed, the interface is > *not* automatically enabled again. I would like DAD to be rerun after > automatically after a while - this removes the need for manually > bouncing the (sub)interface. Yes. This is especially problematic when the subinterface (or interface...the issue is the same) is carrying both IPv4 and IPv6 traffic. This means you take a hit in one address family to correct for an issue in another address family. > > 2. The customer on a point to point Ethernet circuit configures the > same IPv6 address as the provider, and DAD disables the interface at > the provider end. When the config error is corrected at the customer > end, the interface is *not* automatically enabled again. As above, I > I would like DAD to be rerun after automatically after a while - this > removes the need for manually bouncing the (sub)interface. > > Particularly in the second case I absolutely *don't* want to turn off > DAD permanently. In the first case turning off DAD might be a solution, > but rerunning at intervals seems to me to be a *better* solution. Yes. --eli > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From sthaug@nethelp.no Tue Aug 16 09:08:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BFF11E80A5 for ; Tue, 16 Aug 2011 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUZIJh3QiP51 for ; Tue, 16 Aug 2011 09:08:33 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id D59FC21F8BA8 for ; Tue, 16 Aug 2011 09:08:32 -0700 (PDT) Received: (qmail 57748 invoked from network); 16 Aug 2011 16:09:20 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Aug 2011 16:09:20 -0000 Date: Tue, 16 Aug 2011 18:09:20 +0200 (CEST) Message-Id: <20110816.180920.71139802.sthaug@nethelp.no> To: gert@space.net From: sthaug@nethelp.no In-Reply-To: <20110816141748.GF72014@Space.Net> References: <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@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 Cc: narten@us.ibm.com, v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:08:33 -0000 > Of course DAD catches more than "duplicate MAC", but also "mis-typed > static IPv6 configuration" - and that, indeed, happens every so often, > so DAD should learn to discern the difference - > > "same IPv6 address, different MAC -> not me, shutdown protocol" But I'd like DAD retry to be performed even here. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From dart@es.net Tue Aug 16 09:11:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC4C21F8BA8 for ; Tue, 16 Aug 2011 09:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9zm7MEjyJnb for ; Tue, 16 Aug 2011 09:11:35 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9443F21F8B74 for ; Tue, 16 Aug 2011 09:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=cLdrPTcSxwK10WDDGckvGgr10/mPJhf3cvIpmcihoQg=; b=Db5JvOwEal2UJdrdL7WAH1aFefOWTNfEUjLJnEnpyosRnJXVCY37HpfLVXHmK79ByzKP v+mU/iEQBXSK/CdHdaulitkG48L9ELr8lg/GKnAZoC+t7AvdYeAwnwzwUjUEFlFeWSfB wrp/5Q/lc8pqcyE3msugFYasjIsNRJUDrq4= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.81]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7GGCNLZ030917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2011 09:12:23 -0700 Message-ID: <4E4A96E7.9050502@es.net> Date: Tue, 16 Aug 2011 09:12:23 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Thomas Narten References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> In-Reply-To: <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-16_04:2011-08-16, 2011-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108160183 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:11:36 -0000 >> Particularly in the second case I absolutely *don't* want to turn off >> DAD permanently. In the first case turning off DAD might be a solution, >> but rerunning at intervals seems to me to be a *better* solution. > > Again, what time frames are you talking about? Something with reasonable utility on troubleshooting and maintenance window time scales. I know that's mushy, but really that's the need. I think tens of seconds to low single-digit minutes, configurable by operator (e.g. a timer specified in seconds, with acceptable values in the range 30 - 3600) is about right. It would also be desirable to have a CLI operational-mode command to kick DAD for real-time troubleshooting, but that's not a standards issue. --eli -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From sthaug@nethelp.no Tue Aug 16 09:16:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C565621F8C13 for ; Tue, 16 Aug 2011 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSWn3dhvC7mE for ; Tue, 16 Aug 2011 09:16:42 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id B01E421F8C0F for ; Tue, 16 Aug 2011 09:16:41 -0700 (PDT) Received: (qmail 57957 invoked from network); 16 Aug 2011 16:17:29 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Aug 2011 16:17:29 -0000 Date: Tue, 16 Aug 2011 18:17:29 +0200 (CEST) Message-Id: <20110816.181729.104082238.sthaug@nethelp.no> To: gert@space.net From: sthaug@nethelp.no In-Reply-To: <20110816141748.GF72014@Space.Net> References: <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@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 Cc: narten@us.ibm.com, v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:16:42 -0000 > In my network history, I have seen one case of duplicate MAC (which was > indeed quite painful to diagnose), and numerous cases of links being > looped for diagnosis. So for our application case, something that fixes > a very rare problem by making a "nearly day-to-day" operation *break* > is not the right answer. Agreed. Also, as you pointed out, it is important that IPv6 isn't seen as significantly more problematic than IPv4 operationally... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From Fred.L.Templin@boeing.com Tue Aug 16 09:24:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36B11E8084 for ; Tue, 16 Aug 2011 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PHPAlVrykBz for ; Tue, 16 Aug 2011 09:24:47 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0131011E80A5 for ; Tue, 16 Aug 2011 09:24:46 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p7GGPWwX008875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Aug 2011 11:25:33 -0500 (CDT) 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 p7GGPWcR018060; Tue, 16 Aug 2011 09:25:32 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p7GGPWAF018057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Aug 2011 09:25:32 -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; Tue, 16 Aug 2011 09:25:32 -0700 From: "Templin, Fred L" To: Thomas Narten , "Joel M. Halpern" Date: Tue, 16 Aug 2011 09:25:31 -0700 Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: AcxcK0du4neVsfeKRMOxDMFJAVAJJAABXQ3w Message-ID: References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <4E4A813C.8080605@joelhalpern.com> <201108161543.p7GFgxuE016064@cichlid.raleigh.ibm.com> In-Reply-To: <201108161543.p7GFgxuE016064@cichlid.raleigh.ibm.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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:24:47 -0000 =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Thomas Narten > Sent: Tuesday, August 16, 2011 8:43 AM > To: Joel M. Halpern > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > "Joel M. Halpern" writes: >=20 > > As I recall, the classic solution for this in the PPP case was to=20 > > include a random nonce in the message. If you got your own=20 > nonce, you=20 > > could assume it was a reflected message. >=20 > > It is not clear to me that is worth doing in this case. >=20 > Agreed. >=20 > That said, it would not be very hard to define/add a Nonce option, > that could (optionally) be included in NS (or other ND > messages). Implementations would be required to ignore them (per > existing specs). Can the nonce option defined in RFC3971 be used for this purpose? Fred fred.l.templin@boeing.com > We'd then find out to what degree current implementations actually do > ignore options that say "ignore if you don't understand". :-) >=20 > Indeed, if you really wanted to properly "solve" the problem of > detecting when loopback has been enabled/disabled, you could detect > the condition (easily) and at fairly high frequency probe the link to > see when the condition has been fixed. >=20 > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From gert@space.net Tue Aug 16 09:30:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB9711E80D1 for ; Tue, 16 Aug 2011 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU+PGRTdPvmm for ; Tue, 16 Aug 2011 09:30:16 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F411E80C3 for ; Tue, 16 Aug 2011 09:30:15 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E1D98F85DE for ; Tue, 16 Aug 2011 18:31:03 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BA04BF85EC for ; Tue, 16 Aug 2011 18:31:03 +0200 (CEST) Received: (qmail 50076 invoked by uid 1007); 16 Aug 2011 18:31:03 +0200 Date: Tue, 16 Aug 2011 18:31:03 +0200 From: Gert Doering To: sthaug@nethelp.no Message-ID: <20110816163103.GH72014@Space.Net> References: <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> <20110816.180920.71139802.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6GmZEm/yecYqWpE" Content-Disposition: inline In-Reply-To: <20110816.180920.71139802.sthaug@nethelp.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: narten@us.ibm.com, v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:30:17 -0000 --z6GmZEm/yecYqWpE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 16, 2011 at 06:09:20PM +0200, sthaug@nethelp.no wrote: > > Of course DAD catches more than "duplicate MAC", but also "mis-typed > > static IPv6 configuration" - and that, indeed, happens every so often, > > so DAD should learn to discern the difference -=20 > >=20 > > "same IPv6 address, different MAC -> not me, shutdown protocol"=20 >=20 > But I'd like DAD retry to be performed even here. No objections. A configurable knob would certainly be useful. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? 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 --z6GmZEm/yecYqWpE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTkqbR6kuBuNlUUl1AQIm/QQApvOUks7WgXbztVdnllQoZ8+FgRjQFxRw 6srgy9WqYPIq1350tRjG8X2O4HzwEqJMc1GEbIQ2VZZzFn1G0OhmZJOoHe4+K1P4 QvgVjuzmJvB4fI3RsBXN1Xw9vBP901Dt7fFKmu6MZr03TUjLDrnM8Mhr5RV5AyW9 wvwUOIMTZgk= =4PpE -----END PGP SIGNATURE----- --z6GmZEm/yecYqWpE-- From hoskuld@hotmail.com Tue Aug 16 12:26:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5621F8ACC for ; Tue, 16 Aug 2011 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM7-0D+ae93s for ; Tue, 16 Aug 2011 12:26:31 -0700 (PDT) Received: from col0-omc1-s9.col0.hotmail.com (col0-omc1-s9.col0.hotmail.com [65.55.34.19]) by ietfa.amsl.com (Postfix) with ESMTP id C50D321F8A35 for ; Tue, 16 Aug 2011 12:26:31 -0700 (PDT) Received: from COL114-W43 ([65.55.34.7]) by col0-omc1-s9.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 12:27:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7d57cc9c-c956-46ed-be47-da34a62d05f4_" X-Originating-IP: [124.168.203.222] From: Greg Daley To: , , Date: Wed, 17 Aug 2011 05:27:21 +1000 Importance: Normal In-Reply-To: References: <4E49D9DB.5060109@es.net>, <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com>, <20110816.154827.78743604.sthaug@nethelp.no>, <20110816135546.GE72014@Space.Net>, <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com>, <4E4A813C.8080605@joelhalpern.com>, <201108161543.p7GFgxuE016064@cichlid.raleigh.ibm.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2011 19:27:21.0119 (UTC) FILETIME=[84BC9AF0:01CC5C4A] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:26:32 -0000 --_7d57cc9c-c956-46ed-be47-da34a62d05f4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred=2C=20 Yes. The nonce from 3971 can be used for identification of the NS. I was thinking about using it in NA responses when working out potential so= lutions for/before the DNA working group. In the end we went for a mechanism that didn't require message content chan= ges. The essence here is that the nonce would have to (MUST) be decoupled from t= he IID and MAC address generation. Greg Daley > From: Fred.L.Templin@boeing.com > To: narten@us.ibm.com=3B jmh@joelhalpern.com > Date: Tue=2C 16 Aug 2011 09:25:31 -0700 > CC: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > =20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > > On Behalf Of Thomas Narten > > Sent: Tuesday=2C August 16=2C 2011 8:43 AM > > To: Joel M. Halpern > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments > >=20 > > "Joel M. Halpern" writes: > >=20 > > > As I recall=2C the classic solution for this in the PPP case was to=20 > > > include a random nonce in the message. If you got your own=20 > > nonce=2C you=20 > > > could assume it was a reflected message. > >=20 > > > It is not clear to me that is worth doing in this case. > >=20 > > Agreed. > >=20 > > That said=2C it would not be very hard to define/add a Nonce option=2C > > that could (optionally) be included in NS (or other ND > > messages). Implementations would be required to ignore them (per > > existing specs). >=20 > Can the nonce option defined in RFC3971 be used for > this purpose? >=20 > Fred > fred.l.templin@boeing.com >=20 > > We'd then find out to what degree current implementations actually do > > ignore options that say "ignore if you don't understand". :-) > >=20 > > Indeed=2C if you really wanted to properly "solve" the problem of > > detecting when loopback has been enabled/disabled=2C you could detect > > the condition (easily) and at fairly high frequency probe the link to > > see when the condition has been fixed. > >=20 > > Thomas > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --_7d57cc9c-c956-46ed-be47-da34a62d05f4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fred=2C

Yes. =3B The nonce from 3971 can be used for identif= ication of the NS.

I was thinking about using it in NA responses whe= n working out potential solutions for/before the DNA working group.

= In the end we went for a mechanism that didn't require message content chan= ges.

The essence here is that the nonce would have to (MUST) be deco= upled from the IID and MAC address generation.

Greg Daley

>=3B From: Fred.L.Templin@boeing.com
>=3B To: narten@us.ibm.com=3B= jmh@joelhalpern.com
>=3B Date: Tue=2C 16 Aug 2011 09:25:31 -0700
&= gt=3B CC: v6ops@ietf.org
>=3B Subject: Re: [v6ops] DAD issues in IPv6 = backbone environments
>=3B
>=3B
>=3B
>=3B >=3B --= ---Original Message-----
>=3B >=3B From: v6ops-bounces@ietf.org [mai= lto:v6ops-bounces@ietf.org]
>=3B >=3B On Behalf Of Thomas Narten>=3B >=3B Sent: Tuesday=2C August 16=2C 2011 8:43 AM
>=3B >=3B = To: Joel M. Halpern
>=3B >=3B Cc: v6ops@ietf.org
>=3B >=3B Su= bject: Re: [v6ops] DAD issues in IPv6 backbone environments
>=3B >= =3B
>=3B >=3B "Joel M. Halpern" <=3Bjmh@joelhalpern.com>=3B wri= tes:
>=3B >=3B
>=3B >=3B >=3B As I recall=2C the classic s= olution for this in the PPP case was to
>=3B >=3B >=3B include a = random nonce in the message. If you got your own
>=3B >=3B nonce= =2C you
>=3B >=3B >=3B could assume it was a reflected message.>=3B >=3B
>=3B >=3B >=3B It is not clear to me that is wort= h doing in this case.
>=3B >=3B
>=3B >=3B Agreed.
>=3B = >=3B
>=3B >=3B That said=2C it would not be very hard to define/a= dd a Nonce option=2C
>=3B >=3B that could (optionally) be included i= n NS (or other ND
>=3B >=3B messages). Implementations would be requ= ired to ignore them (per
>=3B >=3B existing specs).
>=3B
&g= t=3B Can the nonce option defined in RFC3971 be used for
>=3B this pur= pose?
>=3B
>=3B Fred
>=3B fred.l.templin@boeing.com
>= =3B
>=3B >=3B We'd then find out to what degree current implementat= ions actually do
>=3B >=3B ignore options that say "ignore if you do= n't understand". :-)
>=3B >=3B
>=3B >=3B Indeed=2C if you re= ally wanted to properly "solve" the problem of
>=3B >=3B detecting w= hen loopback has been enabled/disabled=2C you could detect
>=3B >=3B= the condition (easily) and at fairly high frequency probe the link to
&= gt=3B >=3B see when the condition has been fixed.
>=3B >=3B
&g= t=3B >=3B Thomas
>=3B >=3B _______________________________________= ________
>=3B >=3B v6ops mailing list
>=3B >=3B v6ops@ietf.or= g
>=3B >=3B https://www.ietf.org/mailman/listinfo/v6ops
>=3B &g= t=3B
>=3B _______________________________________________
>=3B v= 6ops mailing list
>=3B v6ops@ietf.org
>=3B https://www.ietf.org/m= ailman/listinfo/v6ops
= --_7d57cc9c-c956-46ed-be47-da34a62d05f4_-- From hoskuld@hotmail.com Tue Aug 16 12:48:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4CD11E80A9 for ; Tue, 16 Aug 2011 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUH4wMyBxlPC for ; Tue, 16 Aug 2011 12:48:14 -0700 (PDT) Received: from col0-omc1-s6.col0.hotmail.com (col0-omc1-s6.col0.hotmail.com [65.55.34.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9426911E808F for ; Tue, 16 Aug 2011 12:48:14 -0700 (PDT) Received: from COL114-W25 ([65.55.34.9]) by col0-omc1-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 12:49:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4a660c15-74c3-4ae6-a073-0fd924266afe_" X-Originating-IP: [124.168.203.222] From: Greg Daley To: , Date: Wed, 17 Aug 2011 05:49:03 +1000 Importance: Normal In-Reply-To: <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> References: <4E49D9DB.5060109@es.net>, <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com>, <20110816.154827.78743604.sthaug@nethelp.no>, <20110816135546.GE72014@Space.Net>, <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2011 19:49:04.0161 (UTC) FILETIME=[8D690910:01CC5C4D] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:48:15 -0000 --_4a660c15-74c3-4ae6-a073-0fd924266afe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas=2C=20 > If you assume that any received packet with a src MAC address that is > the same as your own is in fact your own=2C you might as well not bother > running DAD at all. But doing so opens up your network to even bigger > problems=2C because things won't work right (when duplicate MAC addrs > exist)=2C but diagnosing the situtuation is difficult. IPv6 defined DAD > the way it did to prefer disabling interfaces in such cases rather > than trying to automatically do something different because > fundamentally=2C when you have to machines using the same MAC addr you > have problems that can't be fixed without operator intervention. I think that the issue here is the period where duplicate MACs exist and II= Ds are both tentative=2C=20 since an existing address will not be tentative (will defend)=2C and will n= ot be shutdown. Where both are tentative and see the DAD-NS=2C the consequences of ignoring= it are that neither detects simultaneous DAD. If one of the devices completes DAD and state transitions from tentative=2C= it could then send all-nodes NA. We remain with a race condition where either could become non-tentative wit= hout having seen the other's NA. (which is a small chance given initial NS backoff timers). I think that comparison of Nonces as indicated by Fred is possibly better= =2C but the randomness of the Nonces need to be assured=2C so we don't pick another colliding identifier. Greg Daley >=20 > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --_4a660c15-74c3-4ae6-a073-0fd924266afe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Thomas=2C

>=3B If you assume that any received packet= with a src MAC address that is
>=3B the same as your own is in fact y= our own=2C you might as well not bother
>=3B running DAD at all. But d= oing so opens up your network to even bigger
>=3B problems=2C because = things won't work right (when duplicate MAC addrs
>=3B exist)=2C but d= iagnosing the situtuation is difficult. IPv6 defined DAD
>=3B the way = it did to prefer disabling interfaces in such cases rather
>=3B than t= rying to automatically do something different because
>=3B fundamental= ly=2C when you have to machines using the same MAC addr you
>=3B have = problems that can't be fixed without operator intervention.

I think = that the issue here is the period where duplicate MACs exist and IIDs are b= oth tentative=2C
since an existing address will not be tentative (will = defend)=2C and will not be shutdown.

Where both are tentative and se= e the DAD-NS=2C the consequences of ignoring it are that neither detectssimultaneous DAD.

If one of the devices completes DAD and state tra= nsitions from tentative=2C it could then send =3B all-nodes NA.

= We remain with a race condition where either could become non-tentative wit= hout having seen the other's NA.
(which is a small chance given initial = NS backoff timers).

I think that comparison of Nonces as indicated b= y Fred is possibly better=2C but the randomness of the Nonces
need to be= assured=2C so we don't pick another colliding identifier.

Greg Dale= y

>=3B
>=3B Thomas
>=3B _______________________________= ________________
>=3B v6ops mailing list
>=3B v6ops@ietf.org
&= gt=3B https://www.ietf.org/mailman/listinfo/v6ops
= --_4a660c15-74c3-4ae6-a073-0fd924266afe_-- From rajiva@cisco.com Tue Aug 16 14:43:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19B11E80FF for ; Tue, 16 Aug 2011 14:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPNt0wXi2aIq for ; Tue, 16 Aug 2011 14:43:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58611E80F9 for ; Tue, 16 Aug 2011 14:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4227; q=dns/txt; s=iport; t=1313531066; x=1314740666; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=I8MPqdzno3LCZimJHZaPoouNphsJfCZgRIOnM42B8YE=; b=dqd7bP48MbpR5jXPNc9NVB60gSXQkJdeDjqpHC6E515gYkyjDGQI3vVz HFSJUDfQ3TwbSQvL3A3LURd+a0alzJDceOJtEx9Z4cqCb3CR4o22QTTEf /5REbeH69eiWKWPsFBjiWVPeMVh1xKUORBzoNLNR/hWfZtF3NZzXm2Uqa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAJzjSk6tJV2a/2dsb2JhbAA+A5hvj1V3gUABAQEBAgEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIEweHTgSbTQGfKINBgihfBIdfkEiLfg X-IronPort-AV: E=Sophos;i="4.68,236,1312156800"; d="scan'208";a="13724569" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2011 21:44:25 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7GLiPcs000305; Tue, 16 Aug 2011 21:44:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 16:44:25 -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 Date: Tue, 16 Aug 2011 16:44:24 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05B1A8ED@XMB-RCD-111.cisco.com> In-Reply-To: <4E49D9DB.5060109@es.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: AcxbvqJhAwugtUOAQqK6sZWeRP+JegAncEdg References: <4E49D9DB.5060109@es.net> From: "Rajiv Asati (rajiva)" To: , "IETF v6ops list" X-OriginalArrivalTime: 16 Aug 2011 21:44:25.0004 (UTC) FILETIME=[AA8DDEC0:01CC5C5D] Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:43:37 -0000 Eli, > The result of this behavior is that transport-layer troubleshooting can > break IPv6, and IPv6 can stay broken even after the circuit is > normalized (soft loops can be installed and removed without causing the > interface to bounce, so DAD is never reset). =20 If the IPv6 enabled interface was up/functional before the soft loop was placed, then why should DAD/NS be firing up after the soft loop is placed (given that the interface didn't bounce)? > (off-by-default so as to avoid direct confrontation with standards) that > would cause a router with an interface disabled due to DAD to re-run the > DAD test on the interface periodically, subject to a timer. This would Well, the better solution would be for the node to check the src MAC addr, declare the packets getting looped back if matched, and log this event.=20 If not, then just disable DAD (e.g. rfc4862 section4) on a p2p interface.=20 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eli > Dart > Sent: Monday, August 15, 2011 10:46 PM > To: IETF v6ops list > Subject: [v6ops] DAD issues in IPv6 backbone environments >=20 > Hi all, >=20 > We have run across an operational issue with IPv6 in backbone > environments. The issue concerns Duplicate Address Detection (DAD). >=20 > It is common in backbone environments to troubleshoot some transport > system issues by installing soft loops in the middle of the problem > circuit facing the ends, and walking the loops out toward the routers at > the ends while checking for connectivity. This is a common > fault-isolation technique. In an IPv4 network, connectivity on the > circuit is restored when the loops are removed and the circuit is > normalized. In an IPv6 network, this is not always the case. >=20 > In an IPv6 network, when the loops are installed the routers at the ends > see themselves and therefore believe that another host in the same > broadcast domain has the same address. RFC 4862 section 5.4.5 states > that when DAD detects a duplicate address that appears to be derived > from a hardware address (e.g. duplicate link-local address), IPv6 > operation on the interface SHOULD be disabled. Since the circuit is > looped back on itself, the router sees itself and shuts down IPv6 > processing on that interface. >=20 > The result of this behavior is that transport-layer troubleshooting can > break IPv6, and IPv6 can stay broken even after the circuit is > normalized (soft loops can be installed and removed without causing the > interface to bounce, so DAD is never reset). IPv4 does not have DAD, so > IPv4 is self-healing under these circumstances. Therefore, you can get > into a situation where IPv4 has self-healed, and IPv6 stays broken until > somebody notices. >=20 > ESnet has asked one of our router vendors for an interface config knob > (off-by-default so as to avoid direct confrontation with standards) that > would cause a router with an interface disabled due to DAD to re-run the > DAD test on the interface periodically, subject to a timer. This would > cause IPv6 to be self-healing in the same way that IPv4 is self-healing > under troubleshooting conditions common in backbone environments. Note > that the semantics here are very similar to the err-disable state > timeout on Cisco routers. >=20 > Please understand that this behavior is almost certainly not unique to > one vendor - this is behavior that is specified by and conforms to > current IPv6 standards. The standard behavior appears reasonable in a > LAN environment. However, it appears suboptimal in a backbone/provider > networking context. >=20 > Many thanks, >=20 > --eli >=20 >=20 > -- > Eli Dart NOC: (510) 486-7600 > ESnet Network Engineering Group (AS293) (800) 333-7638 > Lawrence Berkeley National Laboratory > PGP Key fingerprint =3D C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Tue Aug 16 15:17:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103121F8B34 for ; Tue, 16 Aug 2011 15:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUQoBZPd6+lA for ; Tue, 16 Aug 2011 15:17:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB44C21F8A80 for ; Tue, 16 Aug 2011 15:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4890; q=dns/txt; s=iport; t=1313533075; x=1314742675; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KWmEI/26w2DFkXsDICv0U437WYx5SbnPM0attiBtVZg=; b=Rxmc78BIWMbi9LstzM/ju32fBnXm6x7jViqR2zfcJbaZWaP6+IdA9vGf JYapExADSBi0U3PQ8FUsJx2sa97pVm/wmBHABIcV3uggz/WZSxd5P0eae 9SDga1qpbQwl5EKIiXCJmhvvrd3/pv762X6UlzHSp/TZ3PD5n6etrfmTb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAEbsSk6tJV2a/2dsb2JhbABBmHWPVXeBQAEBAQECARIBFAkKPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEARIIGodOmzgBnyGFaV8Eh1+QSIt+ X-IronPort-AV: E=Sophos;i="4.68,236,1312156800"; d="scan'208";a="13738105" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 16 Aug 2011 22:17:55 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7GMHsSJ016361; Tue, 16 Aug 2011 22:17:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 17:17:54 -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 Date: Tue, 16 Aug 2011 17:17:53 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> In-Reply-To: <20110816141748.GF72014@Space.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: AcxcH1w17O/feGolSDWAZ2wMvDFGrgAQg0Ug References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> From: "Rajiv Asati (rajiva)" To: "Gert Doering" , "Thomas Narten" X-OriginalArrivalTime: 16 Aug 2011 22:17:54.0660 (UTC) FILETIME=[58670A40:01CC5C62] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:17:06 -0000 Gert, > looped for diagnosis. So for our application case, something that fixes > a very rare problem by making a "nearly day-to-day" operation *break* > is not the right answer.=09 +1 > Of course DAD catches more than "duplicate MAC", but also "mis-typed > static IPv6 configuration" - and that, indeed, happens every so often, > so DAD should learn to discern the difference - >=20 > "same IPv6 address, different MAC -> not me, shutdown protocol" >=20 > "same IPv6 address, same MAC -> might be me, flag warning, don't > disable port, retry in regular intervals" (so if it's indeed a > duplicate MAC address, the logs will at least hint at the problem) +1 (almost).=20 Well, there isn't any benefit in retrying for the sake of it, unless we want to shut down the protocol after few (5,10,..?) retrials. But the number would have to depend on the time-gap taken by the layer1-looping event. And that is very non-deterministic, making a headache to choose the right no (variable in every network). So, the logging part by itself is beneficial, of course, while recognizing it as a loopback.=20 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert > Doering > Sent: Tuesday, August 16, 2011 10:18 AM > To: Thomas Narten > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > Hi, >=20 > On Tue, Aug 16, 2011 at 10:05:03AM -0400, Thomas Narten wrote: > > Gert Doering writes: > > > > > (possibly combined with the "if it's coming from my own MAC address, > > > assume it's me talking to myself and don't take it as DAD failure at > > > all" approach) > > > > If you see a packet with your own MAC address as the source, there > > are two possibilities: > > > > 1) You are seeing your own packet (e.g., a loopback) > > > > 2) There are interfaces with duplicate MAC addresses on your network. >=20 > Indeed. >=20 > > Fundamentally, DAD detects the second case (since stateless address > > autoconf generated address contains the embedded MAC address). >=20 > In ISP networks, the first case happens more often than the second > case, and DAD-without-retries forces operator action, which is something > to avoid. >=20 > (One of the examples we saw was a transient failure on a STM-1, which > led to a "link down", "link up with loop", "link stays up but loop goes > away" situation - IPv4 recovered just fine, IPv6 died, because DAD > disabled IPv6 and kept it down. Image this link flap being at 3 am > in the morning, and someone having to get out of bed to fix something > for IPv6 that wasn't needed for IPv4...) >=20 > > If you assume that any received packet with a src MAC address that is > > the same as your own is in fact your own, you might as well not bother > > running DAD at all. >=20 > Having such a knob available for the ISP side of things would not > something I'd object to... (or a DAD variant that will warn you, but > not disable the protocol - like what Cisco does for IPv4, warn that > there is a duplicate address, but use it anyway) >=20 > > But doing so opens up your network to even bigger > > problems, because things won't work right (when duplicate MAC addrs > > exist), but diagnosing the situtuation is difficult. IPv6 defined DAD > > the way it did to prefer disabling interfaces in such cases rather > > than trying to automatically do something different because > > fundamentally, when you have to machines using the same MAC addr you > > have problems that can't be fixed without operator intervention. >=20 > In my network history, I have seen one case of duplicate MAC (which was > indeed quite painful to diagnose), and numerous cases of links being > looped for diagnosis. So for our application case, something that fixes > a very rare problem by making a "nearly day-to-day" operation *break* > is not the right answer.=09 >=20 > Of course DAD catches more than "duplicate MAC", but also "mis-typed > static IPv6 configuration" - and that, indeed, happens every so often, > so DAD should learn to discern the difference - >=20 > "same IPv6 address, different MAC -> not me, shutdown protocol" >=20 > "same IPv6 address, same MAC -> might be me, flag warning, don't > disable port, retry in regular intervals" (so if it's indeed a > duplicate MAC address, the logs will at least hint at the problem) >=20 > Gert Doering > -- Operator > -- > have you enabled IPv6 on something today...? >=20 > 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 dart@es.net Tue Aug 16 15:24:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3577B21F8B5B for ; Tue, 16 Aug 2011 15:24:00 -0700 (PDT) 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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiviBKWh-3nL for ; Tue, 16 Aug 2011 15:23:59 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25F21F8B5A for ; Tue, 16 Aug 2011 15:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=AkbuFmJ5zYEA8QVAplknFdmrBlPCmlDTVspFaU1p9CM=; b=JTcXjcNjyW6ttyItAB56oRyhQPru8PSTBsExvAEze2aQSX7cDvWjGSSTqCgLxYDXwkU+ M+LRnO9IwSAb/8ne+HQVxx9Ig7dRwtkV21k9ce3Md5vPFEMCeFxSchvBkVb95/wrk+el oFx26OLJ4oFTDNFHLv6llKb1rU1vsuF9+q4= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.81]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7GMOkTB030351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2011 15:24:47 -0700 Message-ID: <4E4AEE2E.4030000@es.net> Date: Tue, 16 Aug 2011 15:24:46 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-16_06:2011-08-17, 2011-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108160295 Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:24:00 -0000 >> Of course DAD catches more than "duplicate MAC", but also "mis-typed >> static IPv6 configuration" - and that, indeed, happens every so often, >> so DAD should learn to discern the difference - >> >> "same IPv6 address, different MAC -> not me, shutdown protocol" >> >> "same IPv6 address, same MAC -> might be me, flag warning, don't >> disable port, retry in regular intervals" (so if it's indeed a >> duplicate MAC address, the logs will at least hint at the problem) > > +1 (almost). > > Well, there isn't any benefit in retrying for the sake of it, unless we > want to shut down the protocol after few (5,10,..?) retrials. We should not do that - if we do that, we're back where we started, i.e. IPv6 goes down hard and stays down until a person touches it. In a circumstance where one part of the organization (the people who run the DWDM/Optical infrastructure) are doing work, this means that people from a potentially completely different part of the organization (the people who run the routing infrastructure) need to go restore service after the maintenance, or at least check to make sure IPv6 didn't wedge itself. > But the > number would have to depend on the time-gap taken by the layer1-looping > event. And that is very non-deterministic, making a headache to choose > the right no (variable in every network). What is wrong with retrying periodically? The point is to do this every few tens of seconds, or every minute or two, so as to avoid spending a lot of CPU on DAD. However, the desire is that layer 3 be self healing once layer 2 has been fixed. IPv4 is self-healing in this way. IPv6 is currently not. --eli > > So, the logging part by itself is beneficial, of course, while > recognizing it as a loopback. > > Cheers, > Rajiv > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Gert >> Doering >> Sent: Tuesday, August 16, 2011 10:18 AM >> To: Thomas Narten >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >> >> Hi, >> >> On Tue, Aug 16, 2011 at 10:05:03AM -0400, Thomas Narten wrote: >>> Gert Doering writes: >>> >>>> (possibly combined with the "if it's coming from my own MAC > address, >>>> assume it's me talking to myself and don't take it as DAD failure > at >>>> all" approach) >>> >>> If you see a packet with your own MAC address as the source, there >>> are two possibilities: >>> >>> 1) You are seeing your own packet (e.g., a loopback) >>> >>> 2) There are interfaces with duplicate MAC addresses on your > network. >> >> Indeed. >> >>> Fundamentally, DAD detects the second case (since stateless address >>> autoconf generated address contains the embedded MAC address). >> >> In ISP networks, the first case happens more often than the second >> case, and DAD-without-retries forces operator action, which is > something >> to avoid. >> >> (One of the examples we saw was a transient failure on a STM-1, which >> led to a "link down", "link up with loop", "link stays up but loop > goes >> away" situation - IPv4 recovered just fine, IPv6 died, because DAD >> disabled IPv6 and kept it down. Image this link flap being at 3 am >> in the morning, and someone having to get out of bed to fix something >> for IPv6 that wasn't needed for IPv4...) >> >>> If you assume that any received packet with a src MAC address that > is >>> the same as your own is in fact your own, you might as well not > bother >>> running DAD at all. >> >> Having such a knob available for the ISP side of things would not >> something I'd object to... (or a DAD variant that will warn you, but >> not disable the protocol - like what Cisco does for IPv4, warn that >> there is a duplicate address, but use it anyway) >> >>> But doing so opens up your network to even bigger >>> problems, because things won't work right (when duplicate MAC addrs >>> exist), but diagnosing the situtuation is difficult. IPv6 defined > DAD >>> the way it did to prefer disabling interfaces in such cases rather >>> than trying to automatically do something different because >>> fundamentally, when you have to machines using the same MAC addr you >>> have problems that can't be fixed without operator intervention. >> >> In my network history, I have seen one case of duplicate MAC (which > was >> indeed quite painful to diagnose), and numerous cases of links being >> looped for diagnosis. So for our application case, something that > fixes >> a very rare problem by making a "nearly day-to-day" operation *break* >> is not the right answer. >> >> Of course DAD catches more than "duplicate MAC", but also "mis-typed >> static IPv6 configuration" - and that, indeed, happens every so often, >> so DAD should learn to discern the difference - >> >> "same IPv6 address, different MAC -> not me, shutdown protocol" >> >> "same IPv6 address, same MAC -> might be me, flag warning, don't >> disable port, retry in regular intervals" (so if it's indeed a >> duplicate MAC address, the logs will at least hint at the problem) >> >> Gert Doering >> -- Operator >> -- >> have you enabled IPv6 on something today...? >> >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From ek@google.com Wed Aug 17 01:13:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDC21F8A36 for ; Wed, 17 Aug 2011 01:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.944 X-Spam-Level: X-Spam-Status: No, score=-105.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2GEMztTl7-h for ; Wed, 17 Aug 2011 01:13:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B7BCB21F8A35 for ; Wed, 17 Aug 2011 01:13:48 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p7H8Eco3019775 for ; Wed, 17 Aug 2011 01:14:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313568878; bh=Zmf0P07Qj7jleNrL11hVULSheSU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=sMFn8fRatVTrGAEoGJhT5ZD3b5EAwgpkbizEoQYOocObLDTygfBz+Mv2Gcaj5NWsn BfbLxerlLoFt4cbSIDPYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type:x-system-of-record; b=D81KCesq4cuSud/uF9APg4BFYlJQQ9tPbZBUxXCC6u2pcOxFXJ7FfhgZNsoSJmDaN B23oH2LyUthtC9BwIAvFg== Received: from qwf6 (qwf6.prod.google.com [10.241.194.70]) by hpaq2.eem.corp.google.com with ESMTP id p7H8EWjY007672 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 Aug 2011 01:14:37 -0700 Received: by qwf6 with SMTP id 6so708683qwf.16 for ; Wed, 17 Aug 2011 01:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=swD4bwlZmf3uIU34FkJKElAeSbANPQB8cXJ/fwfHrO8=; b=H/0qj6ZbZB/Q2M8y/IAEeeoFR5u8hBkghzeg415wst724ZMB1sPnHO26hZlLjFzv9h dwB790xruz5VhMgF4Mtw== Received: by 10.224.208.68 with SMTP id gb4mr771494qab.289.1313568877140; Wed, 17 Aug 2011 01:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.208.68 with SMTP id gb4mr771489qab.289.1313568877010; Wed, 17 Aug 2011 01:14:37 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Wed, 17 Aug 2011 01:14:36 -0700 (PDT) In-Reply-To: References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <4E4A813C.8080605@joelhalpern.com> <201108161543.p7GFgxuE016064@cichlid.raleigh.ibm.com> Date: Wed, 17 Aug 2011 17:14:36 +0900 Message-ID: From: Erik Kline To: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 08:13:49 -0000 > Can the nonce option defined in RFC3971 be used for > this purpose? +1 From prvs=203733c30=Scott.Beuker@sjrb.ca Wed Aug 17 14:11:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A76321F8B35 for ; Wed, 17 Aug 2011 14:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNJPTIskfvaE for ; Wed, 17 Aug 2011 14:11:10 -0700 (PDT) Received: from prdcg4ipta01x-ext.shaw.ca (prdcg4ipta01x-ext.shaw.ca [204.209.208.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0812321F8B16 for ; Wed, 17 Aug 2011 14:11:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,241,1312178400"; d="scan'208";a="72437312" From: Scott Beuker To: "dart@es.net" Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: AQHMXGNR1QRhtU7ISkqPjnTH2F5EfpUhiZRw Date: Wed, 17 Aug 2011 21:12:00 +0000 Message-ID: <1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> <4E4AEE2E.4030000@es.net> In-Reply-To: <4E4AEE2E.4030000@es.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.223.68] x-tm-as-product-ver: SMEX-10.0.0.1459-6.800.1017-18328.005 x-tm-as-result: No--42.818300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 21:11:11 -0000 > What is wrong with retrying periodically? The point is to do this > every > few tens of seconds, or every minute or two, so as to avoid spending a > lot of CPU on DAD. However, the desire is that layer 3 be self healing > once layer 2 has been fixed. IPv4 is self-healing in this way. IPv6 > is > currently not. +1 I'd use this timer, with a very high value of ~30 minutes or so. We've been= dealing with this issue for a while now, when I approached our vendor abou= t either a retry timer or even just a command to force another DAD attempt,= it went nowhere. Right now we use an anomaly report that compares the state of IPv4 and IPv6= on an interface, and alerts are operations staff if they're not equal (and= addresses are configured for both). Our non-IPv4 impacting solution to get= IPv6 unstuck is to manually assign an IPv6 link-local address, and then re= move it, which triggers DAD for the link-local to take place again. - Scott From david.freedman@uk.clara.net Thu Aug 18 05:02:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51BF21F8AB0 for ; Thu, 18 Aug 2011 05:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGNR22gRU6O3 for ; Thu, 18 Aug 2011 05:02:38 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by ietfa.amsl.com (Postfix) with ESMTP id 4331021F8A6C for ; Thu, 18 Aug 2011 05:02:38 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from ) id 1Qu1Jg-0004at-1X for v6ops@ietf.org; Thu, 18 Aug 2011 13:03:20 +0100 Message-ID: <4E4CFF87.8040403@uk.clara.net> Date: Thu, 18 Aug 2011 13:03:19 +0100 From: David Freedman Organization: Claranet Limited User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110704 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: v6ops@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: Message has been frozen because it contains sensitive words (ietf.org), please unfreeze it manually Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:02:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was about to say this, what happens if I replay what I receive from the router back to it (which will contain the same nonce if one is included) without a recovery timer, the router backs out of the subnet with no argument until operators step in. Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5M/4cACgkQtFWeqpgEZrJcLQCg31MQr4U7/pUmngfm6A4XhbKC DDAAoJxkbyMrp6W6Et8ks5aiep0S42Aa =GFrF -----END PGP SIGNATURE----- From pch-b29AA871B@u-1.phicoh.com Thu Aug 18 05:11:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D621F8B26 for ; Thu, 18 Aug 2011 05:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.363 X-Spam-Level: X-Spam-Status: No, score=-8.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIRa-5yRaLEM for ; Thu, 18 Aug 2011 05:11:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5321F871E for ; Thu, 18 Aug 2011 05:11:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qu1SH-0001h2C; Thu, 18 Aug 2011 14:12:13 +0200 Message-Id: To: David Freedman From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com In-reply-to: Your message of "Thu, 18 Aug 2011 13:03:19 +0100 ." <4E4CFF87.8040403@uk.clara.net> Date: Thu, 18 Aug 2011 14:12:08 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:11:22 -0000 In your letter dated Thu, 18 Aug 2011 13:03:19 +0100 you wrote: >I was about to say this, what happens if I replay what I receive from >the router back to it (which will contain the same nonce if one is >included) > >without a recovery timer, the router backs out of the subnet with no >argument until operators step in. That's a subset of the more general problem of allowing untrusted hosts on a network without any protection. From fred@cisco.com Thu Aug 18 11:47:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03C21F8B42 for ; Thu, 18 Aug 2011 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPC3wXJpPWKf for ; Thu, 18 Aug 2011 11:47:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 77D7E21F8B33 for ; Thu, 18 Aug 2011 11:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=31911; q=dns/txt; s=iport; t=1313693291; x=1314902891; h=from:subject:date:message-id:cc:to:mime-version; bh=dnRsgnf0DnTvMDRH1FT+w+cR4OrKKTYZirUv0E/8Fuc=; b=M/ePELIxBaapiE+r9npCDtAEH3BwvbIczGvZ+EM0hifFyUx8yFVbcQpe nDtj77XsOwX+6sTlpvkKRFOAXcuTVMZj8ifsvCnYjWvfGi2oJYvtDhaKL w9iimLLxvhydH2UATOlToOhjTq4odFXFiw4jH5CbDPzVuQ+2+QXC4xvTf Q=; X-Files: charter-diff.html, v6ops-charter.txt, v4ops-charter.txt : 22183, 3584, 3423 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADdeTU6rRDoH/2dsb2JhbAA4Cqd0d4E5IAEaTFMBahMUBweHU5h+AZ8fgyeCQl8Eh2CLM4UMjAk X-IronPort-AV: E=Sophos;i="4.68,246,1312156800"; d="txt'?html'217?scan'217,208,217";a="14429205" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 18 Aug 2011 18:48:02 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7IIm0I4005559; Thu, 18 Aug 2011 18:48:01 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 18 Aug 2011 11:48:01 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 18 Aug 2011 11:48:01 -0700 From: Fred Baker Date: Thu, 18 Aug 2011 11:47:32 -0700 Message-Id: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-41-378603118 Cc: Ron Bonica Subject: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:47:23 -0000 --Apple-Mail-41-378603118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks: I spent some time on the way home from IETF-81 trying to tease the v6ops = charter into two working groups. One, which continues to be called "IPv6 Operations (v6ops)", is is about = IPv6 and the IPv6 component of dual stack networks. The other I am = calling "IPv4 Operations (v4ops)" to play up the dualism; this one is = about IPv4 and the IPv4 component of dual stack networks. There will be = crossover issues that could fall in either category; one hopes that the = operators will entertain such discussions in either working group. I include two proposed charters and a diff between them. It may be most = instructive to start from the diff. I would appreciate your thoughts and = markups. If there is general buy-in here and the IESG agrees, we create a = v4ops@ietf.org list and invite people on v6ops@ to join it. We then = divide the documents (of which we now have ~40) between the two working = groups and ask the authors of the obvious subset to repost as = draft-*-v4ops-*.txt. A quick hash of the current set divides them = more-or-less evenly. For continuity, I have offered to chair v4ops with a co-chair from an = operator that is concerned with v4/v6 transition issues to be chosen by = Ron; I would continue to co-chair v6ops with Joel. That will likely = change over time, of course. At IETF 82, I would suggest that we have = two successive days with essentially four hour blocks (eg, two 2-hour = meetings), one for v6ops and one for v4ops, to make it easiest for the = operators to attend both sets of meetings. That both gives us more time = to hold the relevant discussions and a better organizing principle. =46rom= there, we can determine future plans. Fred --Apple-Mail-41-378603118 Content-Disposition: attachment; filename=charter-diff.html Content-Type: text/html; name="charter-diff.html" Content-Transfer-Encoding: 7bit Diff: v4ops-charter.txt - v6ops-charter.txt
 v4ops-charter.txt   v6ops-charter.txt 
Description of Working Group Description of Working Group
The global deployment of IPv6 is underway, creating an IPv4/IPv6 The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
and nodes. This deployment must be properly handled to avoid the and nodes. This deployment must be properly handled to avoid the
division of the Internet into separate IPv4 and IPv6 networks while division of the Internet into separate IPv4 and IPv6 networks while
ensuring addressing and connectivity for all IPv4 and IPv6 nodes. ensuring addressing and connectivity for all IPv4 and IPv6 nodes.
The IPv4 Operations Working Group (v4ops) develops guidelines for The IPv6 Operations Working Group (v6ops) develops guidelines for
the operation of a shared IPv4/IPv6 Internet and provides operational the operation of a shared IPv4/IPv6 Internet and provides operational
guidance on the use of IPv4 and IPv4/IPv6 transition mechanisms in guidance on deployment of IPv6 into existing IPv4-only networks,
IPv4/IPv6 networks. deployment of new IPv6-only networks, and the general operation of
IPv6 networks.
The main focus of the IPv4 Operations WG is to look at the current The main focus of the IPv6 Operations WG is to look at the current
and expected operational issues in the operation of IPv4 networks. and expected operational issues in the operation of IPv6 networks.
The goals of the IPv4 Operations Working Group are: The goals of the IPv6 Operations Working Group are:
1. Solicit input from network operators and users to identify 1. Solicit input from network operators and users to identify
operational issues in IPv4 networks or the IPv4 component of shared operational issues in IPv6 networks or the IPv6 component of shared
IPv4/IPv6 networks, and determine solutions or workarounds to those IPv4/IPv6 networks, and determine solutions or workarounds to those
issues. These issues will be documented in Informational or BCP issues. These issues will be documented in Informational or BCP
RFCs, or in Internet-Drafts. RFCs, or in Internet-Drafts.
This work should primarily be conducted by those areas and WGs which This work should primarily be conducted by those areas and WGs which
are responsible and best fit to analyze these problems, but IPv4 are responsible and best fit to analyze these problems, but IPv6
Operations may also cooperate in focusing such work. Operations may also cooperate in focusing such work.
2. Publish Informational or BCP RFCs that identify potential security 2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of IPv4 networks or the IPv4 component of risks in the operation of IPv6 networks or the IPv6 component of
shared IPv4/IPv6 networks, and document operational practices to shared IPv4/IPv6 networks, and document operational practices to
eliminate or mitigate those risks. eliminate or mitigate those risks.
This work will be done in cooperation with the Security area and This work will be done in cooperation with the Security area and
other relevant areas or Working Groups. other relevant areas or Working Groups.
3. As a particular instance of (1) and (2), provide feedback to the 3. As a particular instance of (1) and (2), provide feedback to the
Internet Area regarding portions of the IPv4 specifications that IPv6 Maintanence WG regarding portions of the IPv6 specifications
cause, or are likely to cause, operational or security concerns, that cause, or are likely to cause, operational or security concerns,
and work with the Internet Area to resolve those concerns. This and work with the IPv6 WG to resolve those concerns. This feedback
feedback will be published in Internet-Drafts or RFCs. will be published in Internet-Drafts or RFCs.
4. Publish Informational or BCP RFCs that identify and analyze 4. Publish Informational or BCP RFCs that identify and analyze
solutions for IPv4-related issues within common network environments, solutions for deploying IPv6 within common network environments,
such as ISP Networks, Enterprise Networks, Unmanaged Networks such as ISP Networks, Enterprise Networks, Unmanaged Networks
(Home/Small Office), and Cellular Networks. (Home/Small Office), and Cellular Networks.
These documents should serve as useful guides to IPv4 network These documents should serve as useful guides to network operators
operators and users. and users on strategies for IPv6 deployment within their existing
IPv4 networks, as well as in new network installations.
These documents should not be normative guides for IPv4 operation, These documents should not be normative guides for IPv6 operation,
nor are they about describing things of interest to only isolated nor are they about describing things of interest to only isolated
operators. The primary intent is to identify and specify approaches operators. The primary intent is to identify and specify approaches
that multiple operators find useful. that multiple operators find useful.
IPv4 operational and deployment issues with specific protocols or IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility Protocols, DNS or Sub-IP Protocols) are the primary responsibility
of the Groups or areas responsible for those protocols or technologies. of the Groups or areas responsible for those protocols or technologies.
However, the IPv4 Operations WG may provide input to those areas/Groups, However, the IPv6 Operations WG may provide input to those areas/Groups,
as needed, and cooperate with those areas/Groups in reviewing as needed, and cooperate with those areas/Groups in reviewing
solutions to IPv4 operational and deployment problems. solutions to IPv6 operational and deployment problems.
Work items within this scope will be adopted by the WG only if there Work items within this scope will be adopted by the WG only if there
is a substantial expression of interest from the community and if is a substantial expression of interest from the community and if
the work clearly does not fit elsewhere in the IETF. the work clearly does not fit elsewhere in the IETF.
There must be a continuous expression of interest for the WG to There must be a continuous expression of interest for the WG to
work on a particular work item. If there is no longer sufficient work on a particular work item. If there is no longer sufficient
interest in the WG in a work item, the item may be removed from the interest in the WG in a work item, the item may be removed from the
list of WG items. list of WG items.
 End of changes. 14 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-41-378603118 Content-Disposition: attachment; filename=v6ops-charter.txt Content-Type: text/plain; name="v6ops-charter.txt" Content-Transfer-Encoding: 7bit Description of Working Group The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on deployment of IPv6 into existing IPv4-only networks, deployment of new IPv6-only networks, and the general operation of IPv6 networks. The main focus of the IPv6 Operations WG is to look at the current and expected operational issues in the operation of IPv6 networks. The goals of the IPv6 Operations Working Group are: 1. Solicit input from network operators and users to identify operational issues in IPv6 networks or the IPv6 component of shared IPv4/IPv6 networks, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but IPv6 Operations may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of IPv6 networks or the IPv6 component of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or Working Groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 Maintanence WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on strategies for IPv6 deployment within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 operation, nor are they about describing things of interest to only isolated operators. The primary intent is to identify and specify approaches that multiple operators find useful. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the Groups or areas responsible for those protocols or technologies. However, the IPv6 Operations WG may provide input to those areas/Groups, as needed, and cooperate with those areas/Groups in reviewing solutions to IPv6 operational and deployment problems. Work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specification of protocols or transition mechanisms is out of scope of the WG. --Apple-Mail-41-378603118 Content-Disposition: attachment; filename=v4ops-charter.txt Content-Type: text/plain; name="v4ops-charter.txt" Content-Transfer-Encoding: 7bit Description of Working Group The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv4 Operations Working Group (v4ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on the use of IPv4 and IPv4/IPv6 transition mechanisms in IPv4/IPv6 networks. The main focus of the IPv4 Operations WG is to look at the current and expected operational issues in the operation of IPv4 networks. The goals of the IPv4 Operations Working Group are: 1. Solicit input from network operators and users to identify operational issues in IPv4 networks or the IPv4 component of shared IPv4/IPv6 networks, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but IPv4 Operations may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of IPv4 networks or the IPv4 component of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or Working Groups. 3. As a particular instance of (1) and (2), provide feedback to the Internet Area regarding portions of the IPv4 specifications that cause, or are likely to cause, operational or security concerns, and work with the Internet Area to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for IPv4-related issues within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to IPv4 network operators and users. These documents should not be normative guides for IPv4 operation, nor are they about describing things of interest to only isolated operators. The primary intent is to identify and specify approaches that multiple operators find useful. IPv4 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the Groups or areas responsible for those protocols or technologies. However, the IPv4 Operations WG may provide input to those areas/Groups, as needed, and cooperate with those areas/Groups in reviewing solutions to IPv4 operational and deployment problems. Work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specification of protocols or transition mechanisms is out of scope of the WG. --Apple-Mail-41-378603118-- From adahmed@cisco.com Thu Aug 18 13:22:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868D121F8B4A for ; Thu, 18 Aug 2011 13:22:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char AE hex): Subject: v6ops@ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -23.453 X-Spam-Level: X-Spam-Status: No, score=-23.453 tagged_above=-999 required=5 tests=[BAYES_60=1, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, SUBJECT_NEEDS_ENCODING=0.001, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmK-zB7ZK+82 for ; Thu, 18 Aug 2011 13:22:31 -0700 (PDT) Received: from amd-73cb3256bb5 (201-27-162-84.dsl.telesp.net.br [201.27.162.84]) by ietfa.amsl.com (Postfix) with SMTP id E93C121F8B17 for ; Thu, 18 Aug 2011 13:22:25 -0700 (PDT) From: v6ops@ietf.org To: v6ops@ietf.org Subject: v6ops@ietf.org VIAGRA ® Official Site 43% 0FF! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20110818202225.E93C121F8B17@ietfa.amsl.com> Date: Thu, 18 Aug 2011 13:22:25 -0700 (PDT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:22:37 -0000
Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. 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.

©2011 | Unsubscribe | More Newsletters | Privacy
From Tina.Tsou.Zouting@huawei.com Thu Aug 18 14:38:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C771621F85C6 for ; Thu, 18 Aug 2011 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.705 X-Spam-Level: X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgtDfPLCoFn6 for ; Thu, 18 Aug 2011 14:38:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 010F921F85B9 for ; Thu, 18 Aug 2011 14:38:29 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ5003ST85MGR@szxga05-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 05:39:22 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ5005A385LUP@szxga05-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 05:39:22 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH41894; Fri, 19 Aug 2011 05:39:21 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 05:39:14 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 05:39:20 +0800 Date: Thu, 18 Aug 2011 21:39:19 +0000 From: Tina TSOU In-reply-to: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> X-Originating-IP: [10.193.34.126] To: Fred Baker , IPv6 Operations Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxuM1Qg3P5LkWzt0bTTI9XMJUjInxg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> X-Mailman-Approved-At: Thu, 18 Aug 2011 14:40:49 -0700 Cc: Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:38:29 -0000 Fred, This reminds me the v4tov6transition (v4v6tran) work effort since Maastricht meeting. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Thursday, August 18, 2011 11:48 AM To: IPv6 Operations Cc: Ron Bonica Subject: [v6ops] How to divide v6ops Folks: I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. Fred From brian.e.carpenter@gmail.com Thu Aug 18 15:05:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63FF21F874E for ; Thu, 18 Aug 2011 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.236 X-Spam-Level: X-Spam-Status: No, score=-103.236 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1HY2G431CX7 for ; Thu, 18 Aug 2011 15:05:51 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C44421F871E for ; Thu, 18 Aug 2011 15:05:50 -0700 (PDT) Received: by yie12 with SMTP id 12so2042724yie.31 for ; Thu, 18 Aug 2011 15:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=QQ+49pGMhQfw4lGQfG7fPr5k0oiVt85ocSl7iP9QPy0=; b=VfzrZ0V3Fxblp+BkcMbnoglwXQ0xkvA+wb288QmszraZE1uwosV29MXrhV1XyK55T1 cnVil7yT12qeNaVmMKpm/1vUYBSaJgd0uvIRmOVnsTQ3fNGK97FH/0RrkQxt1GjLstAM YrwxzZZ0beV+CqU1DyV87MKFDsIlTorBT/XNk= Received: by 10.236.177.65 with SMTP id c41mr1809626yhm.16.1313705202967; Thu, 18 Aug 2011 15:06:42 -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 y6sm108266yhl.54.2011.08.18.15.06.39 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 15:06:42 -0700 (PDT) Message-ID: <4E4D8CE6.7050204@gmail.com> Date: Fri, 19 Aug 2011 10:06:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> In-Reply-To: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:05:52 -0000 Hi Fred, Will this reduce the total workload and/or reduce cross-posting? I have some doubts, since it seems likely that there will be crossover issues all the time. Nevertheless, dividing the workload does seem like a reasonable principle. However, it's only when we see a full list of the drafts to be assigned to the new WG that we can really see if it will work out. I don't like the name "v4ops". It seems somewhat contradictory to draft-george-ipv6-support, although the proposed charter is completely in line with that draft. Ideally, we'd call it "legacy-ip-ops" but that isn't possible, so how about "v46ops"? Regards Brian Carpenter On 2011-08-19 06:47, Fred Baker wrote: > Folks: > > I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. > > One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. > > I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. > > If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. > > For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. > > Fred > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Tina.Tsou.Zouting@huawei.com Thu Aug 18 15:20:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E191E11E80B5 for ; Thu, 18 Aug 2011 15:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYx3LiH1qkYG for ; Thu, 18 Aug 2011 15:20:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6877811E80AF for ; Thu, 18 Aug 2011 15:20:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ500ES5A47NY@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 06:21:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ500JTJA47L9@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 06:21:43 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH42832; Fri, 19 Aug 2011 06:21:43 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 06:21:35 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 06:21:42 +0800 Date: Thu, 18 Aug 2011 22:21:40 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.126] To: IPv6 Operations Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxuM1Qg3P5LkWzt0bTTI9XMJUjInxggAAMMAA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [v6ops] FW: How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:20:51 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Thursday, August 18, 2011 2:39 PM To: Fred Baker; IPv6 Operations Cc: Ron Bonica Subject: Re: [v6ops] How to divide v6ops Fred, This reminds me the v4tov6transition (v4v6tran) work effort since Maastricht meeting. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Thursday, August 18, 2011 11:48 AM To: IPv6 Operations Cc: Ron Bonica Subject: [v6ops] How to divide v6ops Folks: I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. Fred _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Thu Aug 18 15:33:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D537F21F8AEE for ; Thu, 18 Aug 2011 15:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPG2w3VeLZNQ for ; Thu, 18 Aug 2011 15:33:14 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3433721F8AED for ; Thu, 18 Aug 2011 15:33:14 -0700 (PDT) Received: by yie12 with SMTP id 12so2059151yie.31 for ; Thu, 18 Aug 2011 15:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=0hNtn3Jh++dRPSZ1YoWWH6Yda95+e1lG+Sf4wD0Zti4=; b=wID+lUcacDvJ8cIwVlJzx9OkXbx4HZ+UaSy+8cbQLVmXcI588K2WyKcpC9/iM87mGP urf1oAym1YV4O6njyouGpQOI4slxOukJ7PUukU8jY+2Ay4AMveNkanbRClaBPIscKvmU //oUbStQR1v1k8mfA+2Cd1htWeRWh4JKUyhZ4= Received: by 10.150.97.17 with SMTP id u17mr1349564ybb.92.1313706848998; Thu, 18 Aug 2011 15:34:08 -0700 (PDT) Received: from [192.168.1.101] (r186-48-231-80.dialup.adsl.anteldata.net.uy [186.48.231.80]) by mx.google.com with ESMTPS id 16sm4074416ybm.3.2011.08.18.15.34.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 15:34:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Arturo Servin In-Reply-To: <4E4D8CE6.7050204@gmail.com> Date: Thu, 18 Aug 2011 19:34:04 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:33:15 -0000 On 18 Aug 2011, at 19:06, Brian E Carpenter wrote: > Hi Fred, >=20 > Will this reduce the total workload and/or reduce cross-posting? I think it would do exactly the opposite. > I have some doubts, since it seems likely that there will be > crossover issues all the time. Nevertheless, dividing the > workload does seem like a reasonable principle. However, it's > only when we see a full list of the drafts to be assigned to the > new WG that we can really see if it will work out. >=20 > I don't like the name "v4ops". It seems somewhat contradictory > to draft-george-ipv6-support, although the proposed charter is > completely in line with that draft. Ideally, we'd call it > "legacy-ip-ops" but that isn't possible, so how about "v46ops"? >=20 > Regards > Brian Carpenter Regards, /as >=20 > On 2011-08-19 06:47, Fred Baker wrote: >> Folks: >>=20 >> I spent some time on the way home from IETF-81 trying to tease the = v6ops charter into two working groups. >>=20 >> One, which continues to be called "IPv6 Operations (v6ops)", is is = about IPv6 and the IPv6 component of dual stack networks. The other I am = calling "IPv4 Operations (v4ops)" to play up the dualism; this one is = about IPv4 and the IPv4 component of dual stack networks. There will be = crossover issues that could fall in either category; one hopes that the = operators will entertain such discussions in either working group. >>=20 >> I include two proposed charters and a diff between them. It may be = most instructive to start from the diff. I would appreciate your = thoughts and markups. >>=20 >> If there is general buy-in here and the IESG agrees, we create a = v4ops@ietf.org list and invite people on v6ops@ to join it. We then = divide the documents (of which we now have ~40) between the two working = groups and ask the authors of the obvious subset to repost as = draft-*-v4ops-*.txt. A quick hash of the current set divides them = more-or-less evenly. >>=20 >> For continuity, I have offered to chair v4ops with a co-chair from an = operator that is concerned with v4/v6 transition issues to be chosen by = Ron; I would continue to co-chair v6ops with Joel. That will likely = change over time, of course. At IETF 82, I would suggest that we have = two successive days with essentially four hour blocks (eg, two 2-hour = meetings), one for v6ops and one for v4ops, to make it easiest for the = operators to attend both sets of meetings. That both gives us more time = to hold the relevant discussions and a better organizing principle. =46rom= there, we can determine future plans. >>=20 >> Fred >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Aug 18 15:35:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A021F8B14 for ; Thu, 18 Aug 2011 15:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BAD_LINEBREAK=0.5, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbDYOq3pCI5x for ; Thu, 18 Aug 2011 15:35:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40421F8B0F for ; Thu, 18 Aug 2011 15:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=8197; q=dns/txt; s=iport; t=1313706999; x=1314916599; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DAThZ/5B90XkXSOe8NQCgKWIk7tx6VngucuP7eMDim8=; b=Dj8ZY2waWhnKI/y8BvqnBokn4VMGmV7cwugwrAGWZeFm2+g1gplwQE0W NjyHyHSWh0zvbCVfqNHQLFq3DjRyax1HXIt5/8E6MaestTJP5ny4EmrzV TXvmp4SjQXMLRUFXhdoTnu2/1nyLKbmocbYMvEjIlEye93e4b4PSHdlqF Y=; X-Files: v4v6ops.csv : 1821 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAWTTU6rRDoG/2dsb2JhbABCp3d3gUABAQEBAgEBAQEPAVsCCQULCxIGLiciDgYTFgyHTwSYDwGfCYVpXwSHYIszhQyMCQ X-IronPort-AV: E=Sophos;i="4.68,247,1312156800"; d="csv'?scan'208";a="14501485" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 18 Aug 2011 22:36:35 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7IMaYKE017715; Thu, 18 Aug 2011 22:36:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 18 Aug 2011 15:36:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 18 Aug 2011 15:36:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E4D8CE6.7050204@gmail.com> Date: Thu, 18 Aug 2011 15:36:21 -0700 Message-Id: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-215-392332671 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:35:45 -0000 --Apple-Mail-215-392332671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: > Hi Fred, >=20 > Will this reduce the total workload and/or reduce cross-posting? > I have some doubts, since it seems likely that there will be > crossover issues all the time. Nevertheless, dividing the > workload does seem like a reasonable principle. However, it's > only when we see a full list of the drafts to be assigned to the > new WG that we can really see if it will work out. >=20 > I don't like the name "v4ops". It seems somewhat contradictory > to draft-george-ipv6-support, although the proposed charter is > completely in line with that draft. Ideally, we'd call it > "legacy-ip-ops" but that isn't possible, so how about "v46ops"? My thought, which I'm not stuck on but is what I'm thinking right now, = is that this is actually not very much about anything with a "6" in it. = I'm in favor of pushing IPv6 as a technology, but... It's about the fact that networks that are deploying IPv6 still have to = stay in business, and as a result have v4 networks that have to stay = running until a certain percentage of their access customers have = upgraded CPEs, edge networks, and hosts. Host upgrade is a limited = timeframe problem, given that people buy new ones at some rate. CPEs etc = can be another discussion; if I have a working CPE, why do I spend $$ to = change it? It's in the ISP's interest for them to all go spend that = money; I doubt that the average consumer will see it as in their = interest also. Since Tina brought it up, let me comment on how this differs from = v4v6tran. It differs in that it is only partially about transition = issues or explaining to operators that have completely ignored IPv6 for = 15 years and gotten no education the issues brought up in v4v6tran: o How to decide the IPv6 address architecture in the network? o What is the recommended prefix length for a large operator? o What is the recommended prefix length for a medium operator? o What is the recommended prefix length to hand out to customers? o What is the recommended longest prefix length an operator should accept from customers? o If privacy is a concern and an operator wants to use ULA in the network, what are the guidelines? o How to deploy an IPv4 access network over an IPv6 core network? o How to deploy an IPv6 access network over an IPv4 core network? o Under what considerations, IS-IS should be used? o Under what considerations, OSPFv3 should be used? o What is the longest prefix to be allowed for peering? and so on. Those are, as the working group pointed out at IETF-79 with = very few punches pulled, *NOG questions or "go take one of the many fine = courses on the topic". And it is not at all about introducing someone's latest and greatest = tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet = into a tunnel, or slice and dice a port number, unless we're talking = about operational experience with deployed technologies. It is about operating the IPv4 side of a dual stack network. CGN, a+p, = and all that. Attached I have a spreadsheet (csv format) in which I tried to classify = where I thought existing documents might go. No comment on whether the = working group should actually be working on the draft; my question was = "if someone sent in this draft as a -00, which working group might they = choose and why". I might obviously be wrong. But it's on the basis of = this that I said that the breakout was in the neighborhood of even. --Apple-Mail-215-392332671 Content-Disposition: attachment; filename=v4v6ops.csv Content-Type: text/csv; name="v4v6ops.csv" Content-Transfer-Encoding: quoted-printable v4,discuss,,draft-chen-v6ops-nat64-cpe=0D= v4,discuss,,draft-deng-v6ops-aplusp-experiment-results=0D= v4,discuss,,draft-xli-v6ops-ivi-icmp-address=0D= v4,,,draft-andrews-v6ops-6to4-router-option=0D= v4,,,draft-kuarsingh-v6ops-6to4-provider-managed-tunnel=0D= v4,,,draft-li-v6ops-load-balancing-requirement=0D= v4,,,draft-sun-v6ops-laft6=0Dv4,,,draft-sunq-v6ops-contents-transition=0D= v4,,,draft-sunq-v6ops-ivi-sp=0Dv4,,,draft-tan-v6ops-nat64-experiences=0D= v4,,,draft-zhang-v6ops-cgn-source-trace=0D= v4&v6,,,draft-matsushima-v6ops-transition-experience=0D= v4&v6,,,draft-tan-v6ops-fast6-aaa=0Dv4&v6,,,draft-templin-v6ops-isops=0D= v4&v6,,,draft-tsou-v6ops-multicast-transition-v6only=0D= v4&v6,,,draft-yang-v6ops-fast6-pppoe=0D= v4&v6,,,draft-yang-v6ops-fast6-tools-selection=0D= v6,6man,draft-denog-v6ops-addresspartnaming,=0D= v6,6man,draft-gont-v6ops-ra-guard-evasion,=0D= v6,discuss,draft-chen-v6ops-ipv6-bearer-network-trials,=0D= v6,discuss,draft-chown-v6ops-address-accountability,=0D= v6,iesg,draft-ietf-v6ops-3gpp-eps,=0D= v6,iesg,draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat,=0D= v6,iesg,draft-ietf-v6ops-v6-aaaa-whitelisting-implications,=0D= v6,iesg,draft-ietf-v6ops-v6-in-mobile-networks,=0D= v6,iesg,,draft-ietf-v6ops-v4v6tran-framework=0D= v6,Jari,draft-gundavelli-v6ops-pmipv6-address-reservations,=0D= v6,rfc-ed,draft-ietf-v6ops-6to4-advisory,=0D= v6,rfc-ed,draft-ietf-v6ops-tunnel-loops,=0Dv6,Smart = Objects?,draft-vanrein-v6ops-6bed4,=0D= v6,wg,draft-hilliard-v6ops-ipv6-discard-prefix,=0D= v6,wg,draft-ietf-v6ops-6to4-to-historic,=0D= v6,wg,draft-ietf-v6ops-happy-eyeballs,=0D= v6,wg,draft-ietf-v6ops-ipv6-cpe-router-bis,=0D= v6,wg,draft-jjmb-v6ops-comcast-ipv6-experiences,=0D= v6,,draft-chown-v6ops-call-to-arms,=0D= v6,,draft-fling-v6ops-hybrid-bridged-routed,=0D= v6,,draft-hu-v6ops-radius-issues-ipv6,=0D= v6,,draft-kanizsai-v6ops-anycast-data-aggregation,=0D= v6,,draft-sarikaya-v6ops-prefix-delegation,=0D= v6,,draft-yang-v6ops-space6-icp,= --Apple-Mail-215-392332671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Regards > Brian Carpenter >=20 > On 2011-08-19 06:47, Fred Baker wrote: >> Folks: >>=20 >> I spent some time on the way home from IETF-81 trying to tease the = v6ops charter into two working groups. >>=20 >> One, which continues to be called "IPv6 Operations (v6ops)", is is = about IPv6 and the IPv6 component of dual stack networks. The other I am = calling "IPv4 Operations (v4ops)" to play up the dualism; this one is = about IPv4 and the IPv4 component of dual stack networks. There will be = crossover issues that could fall in either category; one hopes that the = operators will entertain such discussions in either working group. >>=20 >> I include two proposed charters and a diff between them. It may be = most instructive to start from the diff. I would appreciate your = thoughts and markups. >>=20 >> If there is general buy-in here and the IESG agrees, we create a = v4ops@ietf.org list and invite people on v6ops@ to join it. We then = divide the documents (of which we now have ~40) between the two working = groups and ask the authors of the obvious subset to repost as = draft-*-v4ops-*.txt. A quick hash of the current set divides them = more-or-less evenly. >>=20 >> For continuity, I have offered to chair v4ops with a co-chair from an = operator that is concerned with v4/v6 transition issues to be chosen by = Ron; I would continue to co-chair v6ops with Joel. That will likely = change over time, of course. At IETF 82, I would suggest that we have = two successive days with essentially four hour blocks (eg, two 2-hour = meetings), one for v6ops and one for v4ops, to make it easiest for the = operators to attend both sets of meetings. That both gives us more time = to hold the relevant discussions and a better organizing principle. =46rom= there, we can determine future plans. >>=20 >> Fred >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-215-392332671-- From Tina.Tsou.Zouting@huawei.com Thu Aug 18 15:48:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7700D11E809C for ; Thu, 18 Aug 2011 15:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysAgdieur1TI for ; Thu, 18 Aug 2011 15:48:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16E11E80C5 for ; Thu, 18 Aug 2011 15:48:24 -0700 (PDT) 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 <0LQ5000PDBE5V6@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 06:49:18 +0800 (CST) Received: from szxrg02-dlp.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 <0LQ500CKRBE5JX@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 06:49:17 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH43428; Fri, 19 Aug 2011 06:49:17 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 06:49:07 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 06:49:15 +0800 Date: Thu, 18 Aug 2011 22:49:13 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.126] To: Fred Baker , Brian E Carpenter Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxuM1Qg3P5LkWzt0bTTI9XMJUipF8AgAAIV4CAAIfwwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:48:25 -0000 Fred, The questions we listed below were just temporary appear in some of the v4v6tran discussions. I believe the v4v6tran motivation is pretty much in line with you, "operating the IPv4 side of a dual stack network", and transition to IPv6. Here is the framework I-D for v4v6tran. https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ Framework for IP Version Transition Scenarios I don't think it is just *NOG issues. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html http://www.huawei.com/en/solutions/expand-broadband/hw-092950-ipv6.htm -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Thursday, August 18, 2011 3:36 PM To: Brian E Carpenter Cc: IPv6 Operations; Ron Bonica Subject: Re: [v6ops] How to divide v6ops On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: > Hi Fred, > > Will this reduce the total workload and/or reduce cross-posting? > I have some doubts, since it seems likely that there will be crossover > issues all the time. Nevertheless, dividing the workload does seem > like a reasonable principle. However, it's only when we see a full > list of the drafts to be assigned to the new WG that we can really see > if it will work out. > > I don't like the name "v4ops". It seems somewhat contradictory to > draft-george-ipv6-support, although the proposed charter is completely > in line with that draft. Ideally, we'd call it "legacy-ip-ops" but > that isn't possible, so how about "v46ops"? My thought, which I'm not stuck on but is what I'm thinking right now, is that this is actually not very much about anything with a "6" in it. I'm in favor of pushing IPv6 as a technology, but... It's about the fact that networks that are deploying IPv6 still have to stay in business, and as a result have v4 networks that have to stay running until a certain percentage of their access customers have upgraded CPEs, edge networks, and hosts. Host upgrade is a limited timeframe problem, given that people buy new ones at some rate. CPEs etc can be another discussion; if I have a working CPE, why do I spend $$ to change it? It's in the ISP's interest for them to all go spend that money; I doubt that the average consumer will see it as in their interest also. Since Tina brought it up, let me comment on how this differs from v4v6tran. It differs in that it is only partially about transition issues or explaining to operators that have completely ignored IPv6 for 15 years and gotten no education the issues brought up in v4v6tran: o How to decide the IPv6 address architecture in the network? o What is the recommended prefix length for a large operator? o What is the recommended prefix length for a medium operator? o What is the recommended prefix length to hand out to customers? o What is the recommended longest prefix length an operator should accept from customers? o If privacy is a concern and an operator wants to use ULA in the network, what are the guidelines? o How to deploy an IPv4 access network over an IPv6 core network? o How to deploy an IPv6 access network over an IPv4 core network? o Under what considerations, IS-IS should be used? o Under what considerations, OSPFv3 should be used? o What is the longest prefix to be allowed for peering? and so on. Those are, as the working group pointed out at IETF-79 with very few punches pulled, *NOG questions or "go take one of the many fine courses on the topic". And it is not at all about introducing someone's latest and greatest tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into a tunnel, or slice and dice a port number, unless we're talking about operational experience with deployed technologies. It is about operating the IPv4 side of a dual stack network. CGN, a+p, and all that. Attached I have a spreadsheet (csv format) in which I tried to classify where I thought existing documents might go. No comment on whether the working group should actually be working on the draft; my question was "if someone sent in this draft as a -00, which working group might they choose and why". I might obviously be wrong. But it's on the basis of this that I said that the breakout was in the neighborhood of even. From cb.list6@gmail.com Thu Aug 18 16:22:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF321F84D6 for ; Thu, 18 Aug 2011 16:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68VcOVptcmtA for ; Thu, 18 Aug 2011 16:22:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8BCE21F84CF for ; Thu, 18 Aug 2011 16:22:19 -0700 (PDT) Received: by wyg8 with SMTP id 8so2045868wyg.31 for ; Thu, 18 Aug 2011 16:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vn1Ywd027kR/7nnB0qAXqjv/Ojjn1FkTk+mYE2+u280=; b=kSVU7d/WIaOq+6xE4r//3pjmFcGG9mrNjJb3z49d7d7Dauw0BNrEZYNOlKLH6NuQNJ XJBw0yknU6MbGqGorxDv4OUQpjEk7wea/oUGID7Ht7ThpuzRIjY4jdQYgxFzSdv6wPzd URCbAcjnUGWOHoFt6J6p0RRha1shxbza1zLYE= MIME-Version: 1.0 Received: by 10.216.135.208 with SMTP id u58mr1019629wei.110.1313709792837; Thu, 18 Aug 2011 16:23:12 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Thu, 18 Aug 2011 16:23:12 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Thu, 18 Aug 2011 16:23:12 -0700 (PDT) In-Reply-To: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> Date: Thu, 18 Aug 2011 16:23:12 -0700 Message-ID: From: Cameron Byrne To: Arturo Servin Content-Type: multipart/alternative; boundary=0016e6de03c48a3f1a04aacfe5fc Cc: IPv6 Operations Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:22:23 -0000 --0016e6de03c48a3f1a04aacfe5fc Content-Type: text/plain; charset=ISO-8859-1 On Aug 18, 2011 3:34 PM, "Arturo Servin" wrote: > > > On 18 Aug 2011, at 19:06, Brian E Carpenter wrote: > > > Hi Fred, > > > > Will this reduce the total workload and/or reduce cross-posting? > > I think it would do exactly the opposite. > +1 ... this may just be my knee jerk reaction to change. It's unclear to me who benefits from this.... but this kinda sounds like what behave is looking for as it attempts to wind down (on list response seems to opppose behave shutting down) I preffer having one community focused on moving v6 forward with ipv4 in mind ....instead of the v4 life support group and the v6ops group with lots of cross posting Cb > > I have some doubts, since it seems likely that there will be > > crossover issues all the time. Nevertheless, dividing the > > workload does seem like a reasonable principle. However, it's > > only when we see a full list of the drafts to be assigned to the > > new WG that we can really see if it will work out. > > > > I don't like the name "v4ops". It seems somewhat contradictory > > to draft-george-ipv6-support, although the proposed charter is > > completely in line with that draft. Ideally, we'd call it > > "legacy-ip-ops" but that isn't possible, so how about "v46ops"? > > > > Regards > > Brian Carpenter > > Regards, > /as > > > > > On 2011-08-19 06:47, Fred Baker wrote: > >> Folks: > >> > >> I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. > >> > >> One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. > >> > >> I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. > >> > >> If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. > >> > >> For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. > >> > >> Fred > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016e6de03c48a3f1a04aacfe5fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 18, 2011 3:34 PM, "Arturo Servin" <arturo.servin@gmail.com> wrote:
>
>
> On 18 Aug 2011, at 19:06, Brian E Carpenter wrote:
>
> > Hi Fred,
> >
> > Will this reduce the total workload and/or reduce cross-posting?<= br> >
> =A0 =A0 =A0 =A0I think it would do exactly the opposite.
>

+1 ... this may just be my knee jerk reaction to change.

It's unclear to me who benefits from this.... but this kinda sounds = like what behave is looking for as it attempts to wind down (on list respon= se seems to opppose behave shutting down)

I preffer having one community focused on moving v6 forward with ipv4 in= mind ....instead of the v4 life support group and the v6ops group with lot= s of cross posting

Cb
> > I have some doubts, since it seems likely that there will be
> > crossover issues all the time. Nevertheless, dividing the
> > workload does seem like a reasonable principle. However, it's=
> > only when we see a full list of the drafts to be assigned to the<= br> > > new WG that we can really see if it will work out.
> >
> > I don't like the name "v4ops". It seems somewhat co= ntradictory
> > to draft-george-ipv6-support, although the proposed charter is > > completely in line with that draft. Ideally, we'd call it
> > "legacy-ip-ops" but that isn't possible, so how abo= ut "v46ops"?
> >
> > Regards
> > =A0 Brian Carpenter
>
> Regards,
> /as
>
> >
> > On 2011-08-19 06:47, Fred Baker wrote:
> >> Folks:
> >>
> >> I spent some time on the way home from IETF-81 trying to teas= e the v6ops charter into two working groups.
> >>
> >> One, which continues to be called "IPv6 Operations (v6op= s)", is is about IPv6 and the IPv6 component of dual stack networks. T= he other I am calling "IPv4 Operations (v4ops)" to play up the du= alism; this one is about IPv4 and the IPv4 component of dual stack networks= . There will be crossover issues that could fall in either category; one ho= pes that the operators will entertain such discussions in either working gr= oup.
> >>
> >> I include two proposed charters and a diff between them. It m= ay be most instructive to start from the diff. I would appreciate your thou= ghts and markups.
> >>
> >> If there is general buy-in here and the IESG agrees, we creat= e a v4ops@ietf.org list and invite pe= ople on v6ops@ to join it. We then divide the documents (of which we now ha= ve ~40) between the two working groups and ask the authors of the obvious s= ubset to repost as draft-*-v4ops-*.txt. A quick hash of the current set div= ides them more-or-less evenly.
> >>
> >> For continuity, I have offered to chair v4ops with a co-chair= from an operator that is concerned with v4/v6 transition issues to be chos= en by Ron; I would continue to co-chair v6ops with Joel. That will likely c= hange over time, of course. At IETF 82, I would suggest that we have two su= ccessive days with essentially four hour blocks (eg, two 2-hour meetings), = one for v6ops and one for v4ops, to make it easiest for the operators to at= tend both sets of meetings. That both gives us more time to hold the releva= nt discussions and a better organizing principle. From there, we can determ= ine future plans.
> >>
> >> Fred
> >>
> >>
> >>
> >> -------------------------------------------------------------= -----------
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016e6de03c48a3f1a04aacfe5fc-- From moore@network-heretics.com Thu Aug 18 19:36:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64A11E8088 for ; Thu, 18 Aug 2011 19:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRqGx3qtFk9C for ; Thu, 18 Aug 2011 19:36:44 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0512B11E8085 for ; Thu, 18 Aug 2011 19:36:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id A7DF220EFF; Thu, 18 Aug 2011 22:37:36 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 18 Aug 2011 22:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=s32pfE5GCVAaQUJPR/7+c+edoTg=; b=AP sf+HzBLfnWq/iwCy4EoFCqiVWll6COkkT30Z33jtgH6YOFoYbiOnDBc5k7ocalbY 7To9swOHj1oh/MX2ckpKJVbJ/eUyvjMODnPjoSx3M1sgLVcGp0ewBIUuzUkxKeSp VBE9KE0KxtI+c17hrGku13NCP/quQ6yM6GzgzGb6I= X-Sasl-enc: aOc67RmA8XQ0AohRRtOCWNQbN0MSca5wLp2ae9brCNBs 1313721456 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 955297E0052; Thu, 18 Aug 2011 22:37:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> Date: Thu, 18 Aug 2011 22:37:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E8F17FB-6AAB-45E6-A7D3-507297482FEB@network-heretics.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:36:47 -0000 It's pretty clear to me that v6ops is overloaded with work. Though of = course, splitting the group into two groups that contain most of the = same people won't really help the load. It might create the illusion of = less load, but the principal resource constraint would still be there. So the first thing I'd recommend is triage - sort the work items into = urgent, necessary, and nonessential. And I'd strongly recommend that at = least the nonessential work and maybe some of the necessary work get = pursued elsewhere (other WGs when appropriate, otherwise as individual = submissions, or abandon as the authors see fit). Newly proposed work = needs to be subjected to the same criteria - not "does the group want to = adopt this as a work item?" but "is this work urgent, not urgent but = still necessary, or nonessential?" Keith On Aug 18, 2011, at 2:47 PM, Fred Baker wrote: > Folks: >=20 > I spent some time on the way home from IETF-81 trying to tease the = v6ops charter into two working groups. >=20 > One, which continues to be called "IPv6 Operations (v6ops)", is is = about IPv6 and the IPv6 component of dual stack networks. The other I am = calling "IPv4 Operations (v4ops)" to play up the dualism; this one is = about IPv4 and the IPv4 component of dual stack networks. There will be = crossover issues that could fall in either category; one hopes that the = operators will entertain such discussions in either working group. >=20 > I include two proposed charters and a diff between them. It may be = most instructive to start from the diff. I would appreciate your = thoughts and markups. >=20 > If there is general buy-in here and the IESG agrees, we create a = v4ops@ietf.org list and invite people on v6ops@ to join it. We then = divide the documents (of which we now have ~40) between the two working = groups and ask the authors of the obvious subset to repost as = draft-*-v4ops-*.txt. A quick hash of the current set divides them = more-or-less evenly. >=20 > For continuity, I have offered to chair v4ops with a co-chair from an = operator that is concerned with v4/v6 transition issues to be chosen by = Ron; I would continue to co-chair v6ops with Joel. That will likely = change over time, of course. At IETF 82, I would suggest that we have = two successive days with essentially four hour blocks (eg, two 2-hour = meetings), one for v6ops and one for v4ops, to make it easiest for the = operators to attend both sets of meetings. That both gives us more time = to hold the relevant discussions and a better organizing principle. =46rom= there, we can determine future plans. >=20 > Fred >=20 > = _________________= ______________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Thu Aug 18 19:41:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7721F85C0 for ; Thu, 18 Aug 2011 19:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0V4asX7XeBt for ; Thu, 18 Aug 2011 19:41:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2CB521F85F1 for ; Thu, 18 Aug 2011 19:41:17 -0700 (PDT) Received: by wyg8 with SMTP id 8so2120202wyg.31 for ; Thu, 18 Aug 2011 19:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o2dZ9St9U3M2/31WvHK/yBwgkAG3G9i55QZ/2RvnJ/k=; b=HptMg6FYOlqYxyXkImmtwpB8yVSL0JTesTx+tpzihTNwEIx1whsx4E0FUlEZW/eXJW yNqjJKM3JYBXOLbzvEoxU2qQUn02NLHBfXEUrsDxl/PkGTZRzXBCKMdUjFvFgFRtCt2l LlUhuxcK2Pnq+BPfm1Py++86soCan7QyV64pk= MIME-Version: 1.0 Received: by 10.216.60.73 with SMTP id t51mr5295905wec.65.1313721732793; Thu, 18 Aug 2011 19:42:12 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Thu, 18 Aug 2011 19:42:12 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Thu, 18 Aug 2011 19:42:12 -0700 (PDT) In-Reply-To: <2E8F17FB-6AAB-45E6-A7D3-507297482FEB@network-heretics.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <2E8F17FB-6AAB-45E6-A7D3-507297482FEB@network-heretics.com> Date: Thu, 18 Aug 2011 19:42:12 -0700 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cdf6b483785ac04aad2ada2 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:41:29 -0000 --000e0cdf6b483785ac04aad2ada2 Content-Type: text/plain; charset=ISO-8859-1 On Aug 18, 2011 7:37 PM, "Keith Moore" wrote: > > It's pretty clear to me that v6ops is overloaded with work. Though of course, splitting the group into two groups that contain most of the same people won't really help the load. It might create the illusion of less load, but the principal resource constraint would still be there. > > So the first thing I'd recommend is triage - sort the work items into urgent, necessary, and nonessential. And I'd strongly recommend that at least the nonessential work and maybe some of the necessary work get pursued elsewhere (other WGs when appropriate, otherwise as individual submissions, or abandon as the authors see fit). Newly proposed work needs to be subjected to the same criteria - not "does the group want to adopt this as a work item?" but "is this work urgent, not urgent but still necessary, or nonessential?" > > Keith > This sounds smart to me. Cb > On Aug 18, 2011, at 2:47 PM, Fred Baker wrote: > > > Folks: > > > > I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. > > > > One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. > > > > I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. > > > > If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. > > > > For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. > > > > Fred > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --000e0cdf6b483785ac04aad2ada2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 18, 2011 7:37 PM, "Keith Moore" <moore@network-heretics.com> wrote:
>
> It's pretty clear to me that v6ops is overloaded with work. =A0Tho= ugh of course, splitting the group into two groups that contain most of the= same people won't really help the load. =A0It might create the illusio= n of less load, but the principal resource constraint would still be there.=
>
> So the first thing I'd recommend is triage - sort the work items i= nto urgent, necessary, and nonessential. =A0And I'd strongly recommend = that at least the nonessential work and maybe some of the necessary work ge= t pursued elsewhere (other WGs when appropriate, otherwise as individual su= bmissions, or abandon as the authors see fit). =A0Newly proposed work needs= to be subjected to the same criteria - not "does the group want to ad= opt this as a work item?" but "is this work urgent, not urgent bu= t still necessary, or nonessential?"
>
> Keith
>

This sounds smart to me.

Cb

> On Aug 18, 2011, at 2:47 PM, Fred Baker wrote:
>
> > Folks:
> >
> > I spent some time on the way home from IETF-81 trying to tease th= e v6ops charter into two working groups.
> >
> > One, which continues to be called "IPv6 Operations (v6ops)&q= uot;, is is about IPv6 and the IPv6 component of dual stack networks. The o= ther I am calling "IPv4 Operations (v4ops)" to play up the dualis= m; this one is about IPv4 and the IPv4 component of dual stack networks. Th= ere will be crossover issues that could fall in either category; one hopes = that the operators will entertain such discussions in either working group.=
> >
> > I include two proposed charters and a diff between them. It may b= e most instructive to start from the diff. I would appreciate your thoughts= and markups.
> >
> > If there is general buy-in here and the IESG agrees, we create a = v4ops@ietf.org list and invite people= on v6ops@ to join it. We then divide the documents (of which we now have ~= 40) between the two working groups and ask the authors of the obvious subse= t to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides= them more-or-less evenly.
> >
> > For continuity, I have offered to chair v4ops with a co-chair fro= m an operator that is concerned with v4/v6 transition issues to be chosen b= y Ron; I would continue to co-chair v6ops with Joel. That will likely chang= e over time, of course. At IETF 82, I would suggest that we have two succes= sive days with essentially four hour blocks (eg, two 2-hour meetings), one = for v6ops and one for v4ops, to make it easiest for the operators to attend= both sets of meetings. That both gives us more time to hold the relevant d= iscussions and a better organizing principle. From there, we can determine = future plans.
> >
> > Fred
> >
> > <charter-diff.html><v6ops-charter.txt><v4ops-chart= er.txt>_______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--000e0cdf6b483785ac04aad2ada2-- From jiangsheng@huawei.com Thu Aug 18 23:40:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B321F84DF for ; Thu, 18 Aug 2011 23:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jda-92F+aXw for ; Thu, 18 Aug 2011 23:40:48 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A921F84DD for ; Thu, 18 Aug 2011 23:40:48 -0700 (PDT) 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 <0LQ500JXRX9I8G@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 14:41:42 +0800 (CST) Received: from szxrg02-dlp.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 <0LQ500FJOX98DN@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 19 Aug 2011 14:41:42 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH74842; Fri, 19 Aug 2011 14:41:40 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 14:41:32 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 14:41:40 +0800 Date: Fri, 19 Aug 2011 06:41:39 +0000 From: Sheng Jiang In-reply-to: <4E4D8CE6.7050204@gmail.com> X-Originating-IP: [10.110.98.152] To: Brian E Carpenter , Fred Baker Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201237A6E@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxmrKOgcbHi06D8ojiRdJRA5UipF8AgAEVfjA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 06:40:49 -0000 > I don't like the name "v4ops". It seems somewhat contradictory > to draft-george-ipv6-support, although the proposed charter is > completely in line with that draft. Ideally, we'd call it > "legacy-ip-ops" but that isn't possible, so how about "v46ops"? Support Brian's concern. We are talking about closing behave WG in order to give the world the right signal: v4 should be stopped, no more efforts will be put on v4. The name of "v4ops" will give out the opposite message. Sheng > Regards > Brian Carpenter > > On 2011-08-19 06:47, Fred Baker wrote: > > Folks: > > > > I spent some time on the way home from IETF-81 trying to tease the > v6ops charter into two working groups. > > > > One, which continues to be called "IPv6 Operations (v6ops)", is is > about IPv6 and the IPv6 component of dual stack networks. The other I > am calling "IPv4 Operations (v4ops)" to play up the dualism; this one > is about IPv4 and the IPv4 component of dual stack networks. There will > be crossover issues that could fall in either category; one hopes that > the operators will entertain such discussions in either working group. > > > > I include two proposed charters and a diff between them. It may be > most instructive to start from the diff. I would appreciate your > thoughts and markups. > > > > If there is general buy-in here and the IESG agrees, we create a > v4ops@ietf.org list and invite people on v6ops@ to join it. We then > divide the documents (of which we now have ~40) between the two working > groups and ask the authors of the obvious subset to repost as draft-*- > v4ops-*.txt. A quick hash of the current set divides them more-or-less > evenly. > > > > For continuity, I have offered to chair v4ops with a co-chair from an > operator that is concerned with v4/v6 transition issues to be chosen by > Ron; I would continue to co-chair v6ops with Joel. That will likely > change over time, of course. At IETF 82, I would suggest that we have > two successive days with essentially four hour blocks (eg, two 2-hour > meetings), one for v6ops and one for v4ops, to make it easiest for the > operators to attend both sets of meetings. That both gives us more time > to hold the relevant discussions and a better organizing principle. > From there, we can determine future plans. > > > > Fred > > > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Fri Aug 19 03:17:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1588921F86B1 for ; Fri, 19 Aug 2011 03:17:33 -0700 (PDT) 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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cSo0GM3oywC for ; Fri, 19 Aug 2011 03:17:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B393621F859E for ; Fri, 19 Aug 2011 03:17:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QuM9j-000Iaz-Ib; Fri, 19 Aug 2011 10:18:27 +0000 Date: Fri, 19 Aug 2011 06:18:26 -0400 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations , Arturo Servin Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 10:17:33 -0000 > I prefer having one community focused on moving v6 forward with ipv4 > in mind ....instead of the v4 life support group and the v6ops group > with lots of cross posting agree. randy From randy@psg.com Fri Aug 19 03:22:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE821F8A70 for ; Fri, 19 Aug 2011 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJTaLCAVniTD for ; Fri, 19 Aug 2011 03:22:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 15AE621F8A69 for ; Fri, 19 Aug 2011 03:22:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QuMEo-000IcF-Tq; Fri, 19 Aug 2011 10:23:43 +0000 Date: Fri, 19 Aug 2011 06:23:42 -0400 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 10:22:52 -0000 to amplify. we all have to live in a world with ipv4 and, if we are lucky, ipv6. and they interact. pretending otherwise is a fantasy around which i can not wrap my head. as operators, we have a set of problems that need to be solved in concert, and almost none of the hard ones are divisible. randy From wesley.george@twcable.com Fri Aug 19 06:49:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B121F89BA for ; Fri, 19 Aug 2011 06:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhNm4B-w1dxx for ; Fri, 19 Aug 2011 06:49:03 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 663DF21F888A for ; Fri, 19 Aug 2011 06:49:03 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.68,251,1312171200"; d="scan'208,217";a="249531394" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Aug 2011 09:46:21 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 19 Aug 2011 09:49:48 -0400 From: "George, Wesley" To: Fred Baker , Brian E Carpenter Date: Fri, 19 Aug 2011 09:49:48 -0400 Thread-Topic: [v6ops] How to divide v6ops Thread-Index: Acxd91Z1yRhxtu+0SROi2GkLGyvf1wAeszPw Message-ID: <34E4F50CAFA10349A41E0756550084FB0C49515D@PRVPEXVS04.corp.twcable.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.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: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB0C49515DPRVPEXVS04corpt_" MIME-Version: 1.0 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 13:49:06 -0000 --_000_34E4F50CAFA10349A41E0756550084FB0C49515DPRVPEXVS04corpt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Thursday, August 18, 2011 6:36 PM On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: > Will this reduce the total workload and/or reduce cross-posting? > I have some doubts, since it seems likely that there will be > crossover issues all the time. WEG] I share this concern. This WG's workload problem is not solved by divi= de and conquer unless it's very carefully done. I think it would be better = solved by a more focused charter for this WG that allows us to direct more = work to either the general ops area or to the individual submission stream = (or the bit bucket). So I support a charter change (as I stated in http://w= ww.ietf.org/mail-archive/web/v6ops/current/msg09975.html), but likely not i= n the interest of splitting the group. It's about the fact that networks that are deploying IPv6 still have to sta= y in business, and as a result have v4 networks that have to stay running u= ntil a certain percentage of their access customers have upgraded CPEs, edg= e networks, and hosts. WEG] while this is true, with the exception of address availability constra= ints, that's been the case for years. We already have a group to deal with = general IPv4 operational issues- OpsAWG. An IPv4 network that happens to be= dual-stack is operated pretty much the same way as an IPv4 network that is= n't, so I don't support making a distinction. What you're actually talking = about is IPv4 extension, and that's a space that IMO has been well-worn, be= tween Behave, this group, and softwires. Since Tina brought it up, let me comment on how this differs from v4v6tran.= It differs in that it is only partially about transition issues or explain= ing to operators that have completely ignored IPv6 for 15 years and gotten = no education the issues brought up in v4v6tran: Those are, as the working group pointed out at IETF-79 with very few= punches pulled, *NOG questions or "go take one of the many fine courses on= the topic". WEG] Agree. The proposal for v4v6tran was flawed. But... And it is not at all about introducing someone's latest and greatest tweak = on how to put an IPv6 packet into a tunnel, put an IPv4 packet into a tunne= l, or slice and dice a port number, unless we're talking about operational = experience with deployed technologies. WEG] I think that this is really the decision point: Either we need a new W= G (which probably should be called v4v6tran) that is explicitly chartered t= o deal with IPv4 transition and extension issues in operational networks be= cause there is still a good bit of work to be done there, or consensus is t= hat we are at a point where we should probably just call IPv4 transition an= d extension work complete. If it's believed to be complete, the burden of p= roof for new flavors and tweaks is to show why the existing solutions funda= mentally won't work in such a way that it's applicable as more than a one-o= ff. Personally, I think it's done, at least until we have significant deplo= yment experiences to examine. It is about operating the IPv4 side of a dual stack network. CGN, a+p, and = all that. WEG] No, that is about operating the IPv4 side of a network without adequat= e IPv4 resources, and that is far different than your proposed charter chan= ges. Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_34E4F50CAFA10349A41E0756550084FB0C49515DPRVPEXVS04corpt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker
Sent: Thursday, August 18, 2011 6:36 PM


On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote:

> Will this reduce the total workload and/or reduce cross-posting?
> I have some doubts, since it seems likely that there will be
> crossover issues all the time.

WEG] I share this concern. This WG’s workload problem is not so= lved by divide and conquer unless it’s very carefully done. I think it would be better solved by a more focused charter for this WG that allow= s us to direct more work to either the general ops area or to the individua= l submission stream (or the bit bucket). So I support a charter change (as = I stated in http://www.ietf.org/mail-archive/web/v6ops/current/msg09975.html), but likely not in the interest of splitting the group.

<snip>
It's about the fact that networks that are deploying IPv6 still have to sta= y in business, and as a result have v4 networks that have to stay running u= ntil a certain percentage of their access customers have upgraded CPEs, edg= e networks, and hosts. <snip>

WEG] while this is true, with the exception of address availability c= onstraints, that’s been the case for years. We already have a group to deal with general IPv4 operational issues- OpsAWG. An IPv4 netw= ork that happens to be dual-stack is operated pretty much the same way as a= n IPv4 network that isn’t, so I don’t support making a distinct= ion. What you’re actually talking about is IPv4 extension, and that’s a space that IMO has been well-worn, between B= ehave, this group, and softwires.
Since Tina brought it up, let me comment on how this differs from v4v6tran.= It differs in that it is only partially about transition issues or explain= ing to operators that have completely ignored IPv6 for 15 years and gotten = no education the issues brought up in v4v6tran:
<snip> Those are, as the working= group pointed out at IETF-79 with very few punches pulled, *NOG questions = or "go take one of the many fine courses on the topic".

WEG] Agree. The proposal for v4v6tran was flawed. But…

And it is not at all about introducing someone's latest and gre= atest tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet = into a tunnel, or slice and dice a port number, unless we're talking about operational experience with deployed te= chnologies.

WEG] I think that this is really the decision point: Either we need a= new WG (which probably should be called v4v6tran) that is explicitly chartered to deal with IPv4 transition and extension issues in = operational networks because there is still a good bit of work to be done t= here, or consensus is that we are at a point where we should probably just = call IPv4 transition and extension work complete. If it’s believed to be complete, the burden of proof = for new flavors and tweaks is to show why the existing solutions fundamenta= lly won’t work in such a way that it’s applicable as more than = a one-off. Personally, I think it’s done, at least until we have significant deployment experiences to examine.

It is about operating the IPv4 side of a dual stack network. CG= N, a+p, and all that.

WEG] No, that is about operating the IPv4= side of a network without adequate IPv4 resources, and that is far differe= nt than your proposed charter changes.

Wes George

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_34E4F50CAFA10349A41E0756550084FB0C49515DPRVPEXVS04corpt_-- From ietfc@btconnect.com Fri Aug 19 09:57:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6115E21F8802 for ; Fri, 19 Aug 2011 09:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh4yV+NVHvaA for ; Fri, 19 Aug 2011 09:57:34 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6D42221F85B8 for ; Fri, 19 Aug 2011 09:57:32 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr13.btconnect.com with SMTP id EAS63704; Fri, 19 Aug 2011 17:58:23 +0100 (BST) Message-ID: <016a01cc5e88$5434a040$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , "IPv6 Operations" References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> Date: Fri, 19 Aug 2011 17:54:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4E4E962D.0065, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.19.153018:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E4E9632.0159,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:57:35 -0000 ---- Original Message ----- From: "Fred Baker" To: "IPv6 Operations" Cc: "Ron Bonica" Sent: Thursday, August 18, 2011 8:47 PM I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups. One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group. I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups. If there is general buy-in here and the IESG agrees, we create a v4ops@ietf.org list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly. Fred ~40 documents sounds a lot, but I see only 9 draft-ietf-v6ops* of which one is dead, two are in the RFC Editor queue, two are with the IESG leaving only four documents active with the WG. There are 32 individual submissions listed on the charter page but I would not expect many of those to take up much time - eg those on 'Experiences ...' should either be published or forgotten. What I see on the v6ops list is intense discussion, more than any other list I subscribe to, about, mostly, one topic at a time, with no clear sense of where this is going. And my impression is that the most difficult discussions are not really v6ops at all, that is there is something that does not work, or does not work well, and the solution could be a protocol change; in which case, punt it to 6man, make them do more, in looking at a protocol solution for an operational problem. Tom Petch For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans. Fred -------------------------------------------------------------------------------- > Description of Working Group > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks > and nodes. This deployment must be properly handled to avoid the > division of the Internet into separate IPv4 and IPv6 networks while > ensuring addressing and connectivity for all IPv4 and IPv6 nodes. > > The IPv6 Operations Working Group (v6ops) develops guidelines for > the operation of a shared IPv4/IPv6 Internet and provides operational > guidance on deployment of IPv6 into existing IPv4-only networks, > deployment of new IPv6-only networks, and the general operation of > IPv6 networks. > > The main focus of the IPv6 Operations WG is to look at the current > and expected operational issues in the operation of IPv6 networks. > > The goals of the IPv6 Operations Working Group are: > > 1. Solicit input from network operators and users to identify > operational issues in IPv6 networks or the IPv6 component of shared > IPv4/IPv6 networks, and determine solutions or workarounds to those > issues. These issues will be documented in Informational or BCP > RFCs, or in Internet-Drafts. > > This work should primarily be conducted by those areas and WGs which > are responsible and best fit to analyze these problems, but IPv6 > Operations may also cooperate in focusing such work. > > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of IPv6 networks or the IPv6 component of > shared IPv4/IPv6 networks, and document operational practices to > eliminate or mitigate those risks. > > This work will be done in cooperation with the Security area and > other relevant areas or Working Groups. > > 3. As a particular instance of (1) and (2), provide feedback to the > IPv6 Maintanence WG regarding portions of the IPv6 specifications > that cause, or are likely to cause, operational or security concerns, > and work with the IPv6 WG to resolve those concerns. This feedback > will be published in Internet-Drafts or RFCs. > > 4. Publish Informational or BCP RFCs that identify and analyze > solutions for deploying IPv6 within common network environments, > such as ISP Networks, Enterprise Networks, Unmanaged Networks > (Home/Small Office), and Cellular Networks. > > These documents should serve as useful guides to network operators > and users on strategies for IPv6 deployment within their existing > IPv4 networks, as well as in new network installations. > > These documents should not be normative guides for IPv6 operation, > nor are they about describing things of interest to only isolated > operators. The primary intent is to identify and specify approaches > that multiple operators find useful. > > IPv6 operational and deployment issues with specific protocols or > technologies (such as Applications, Transport Protocols, Routing > Protocols, DNS or Sub-IP Protocols) are the primary responsibility > of the Groups or areas responsible for those protocols or technologies. > However, the IPv6 Operations WG may provide input to those areas/Groups, > as needed, and cooperate with those areas/Groups in reviewing > solutions to IPv6 operational and deployment problems. > > Work items within this scope will be adopted by the WG only if there > is a substantial expression of interest from the community and if > the work clearly does not fit elsewhere in the IETF. > > There must be a continuous expression of interest for the WG to > work on a particular work item. If there is no longer sufficient > interest in the WG in a work item, the item may be removed from the > list of WG items. > > Specification of protocols or transition mechanisms is out of scope > of the WG. > -------------------------------------------------------------------------------- > Description of Working Group > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks > and nodes. This deployment must be properly handled to avoid the > division of the Internet into separate IPv4 and IPv6 networks while > ensuring addressing and connectivity for all IPv4 and IPv6 nodes. > > The IPv4 Operations Working Group (v4ops) develops guidelines for > the operation of a shared IPv4/IPv6 Internet and provides operational > guidance on the use of IPv4 and IPv4/IPv6 transition mechanisms in > IPv4/IPv6 networks. > > The main focus of the IPv4 Operations WG is to look at the current > and expected operational issues in the operation of IPv4 networks. > > The goals of the IPv4 Operations Working Group are: > > 1. Solicit input from network operators and users to identify > operational issues in IPv4 networks or the IPv4 component of shared > IPv4/IPv6 networks, and determine solutions or workarounds to those > issues. These issues will be documented in Informational or BCP > RFCs, or in Internet-Drafts. > > This work should primarily be conducted by those areas and WGs which > are responsible and best fit to analyze these problems, but IPv4 > Operations may also cooperate in focusing such work. > > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of IPv4 networks or the IPv4 component of > shared IPv4/IPv6 networks, and document operational practices to > eliminate or mitigate those risks. > > This work will be done in cooperation with the Security area and > other relevant areas or Working Groups. > > 3. As a particular instance of (1) and (2), provide feedback to the > Internet Area regarding portions of the IPv4 specifications that > cause, or are likely to cause, operational or security concerns, > and work with the Internet Area to resolve those concerns. This > feedback will be published in Internet-Drafts or RFCs. > > 4. Publish Informational or BCP RFCs that identify and analyze > solutions for IPv4-related issues within common network environments, > such as ISP Networks, Enterprise Networks, Unmanaged Networks > (Home/Small Office), and Cellular Networks. > > These documents should serve as useful guides to IPv4 network > operators and users. > > These documents should not be normative guides for IPv4 operation, > nor are they about describing things of interest to only isolated > operators. The primary intent is to identify and specify approaches > that multiple operators find useful. > > IPv4 operational and deployment issues with specific protocols or > technologies (such as Applications, Transport Protocols, Routing > Protocols, DNS or Sub-IP Protocols) are the primary responsibility > of the Groups or areas responsible for those protocols or technologies. > However, the IPv4 Operations WG may provide input to those areas/Groups, > as needed, and cooperate with those areas/Groups in reviewing > solutions to IPv4 operational and deployment problems. > > Work items within this scope will be adopted by the WG only if there > is a substantial expression of interest from the community and if > the work clearly does not fit elsewhere in the IETF. > > There must be a continuous expression of interest for the WG to > work on a particular work item. If there is no longer sufficient > interest in the WG in a work item, the item may be removed from the > list of WG items. > > Specification of protocols or transition mechanisms is out of scope > of the WG. > From C.Donley@cablelabs.com Fri Aug 19 13:06:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5321F8A97 for ; Fri, 19 Aug 2011 13:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppCeqsQMYyxe for ; Fri, 19 Aug 2011 13:06:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id EAA0321F8A58 for ; Fri, 19 Aug 2011 13:06:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7JK7Qqj009278; Fri, 19 Aug 2011 14:07:26 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 19 Aug 2011 14:07:26 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 19 Aug 2011 14:07:26 -0600 From: Chris Donley To: Fred Baker , Brian E Carpenter Date: Fri, 19 Aug 2011 14:07:22 -0600 Thread-Topic: [v6ops] How to divide v6ops Thread-Index: Acxeq5zedUC7hyMxRLSZP1MrctDcAA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:06:36 -0000 I think there is a need for v4 coexstence/transition work, along what you are proposing: * How to deploy CGNs/other transition technologies with v4 components * transition technology experiences * How do we do CGN logging? What format do we use for the messages? * NAT444, 6to4, a+p issues, etc. With the proposed BEHAVE shut down, there isn't a clear place to take this work - v6ops, softwires, 6man, intarea, homenet, and opsarea all seem to fit pieces of it. I believe that this work would benefit from being in its own wg. However, I agree with others that v4ops is perhaps not the right name. Coexistence Ops (co-ops)? Also, I think that the charter should be tightened (per draft-george and other comments on the list) to focus on IPv4/IPv6 transition/coexistence operational and security issues, and not on general IPv4 network/security operations. Chris On 8/18/11 4:36 PM, "Fred Baker" wrote: > >On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: > >> Hi Fred, >>=20 >> Will this reduce the total workload and/or reduce cross-posting? >> I have some doubts, since it seems likely that there will be >> crossover issues all the time. Nevertheless, dividing the >> workload does seem like a reasonable principle. However, it's >> only when we see a full list of the drafts to be assigned to the >> new WG that we can really see if it will work out. >>=20 >> I don't like the name "v4ops". It seems somewhat contradictory >> to draft-george-ipv6-support, although the proposed charter is >> completely in line with that draft. Ideally, we'd call it >> "legacy-ip-ops" but that isn't possible, so how about "v46ops"? > >My thought, which I'm not stuck on but is what I'm thinking right now, is >that this is actually not very much about anything with a "6" in it. I'm >in favor of pushing IPv6 as a technology, but... > >It's about the fact that networks that are deploying IPv6 still have to >stay in business, and as a result have v4 networks that have to stay >running until a certain percentage of their access customers have >upgraded CPEs, edge networks, and hosts. Host upgrade is a limited >timeframe problem, given that people buy new ones at some rate. CPEs etc >can be another discussion; if I have a working CPE, why do I spend $$ to >change it? It's in the ISP's interest for them to all go spend that >money; I doubt that the average consumer will see it as in their interest >also. > >Since Tina brought it up, let me comment on how this differs from >v4v6tran. It differs in that it is only partially about transition issues >or explaining to operators that have completely ignored IPv6 for 15 years >and gotten no education the issues brought up in v4v6tran: > > o How to decide the IPv6 address architecture in the network? > o What is the recommended prefix length for a large operator? > o What is the recommended prefix length for a medium operator? > o What is the recommended prefix length to hand out to customers? > o What is the recommended longest prefix length an operator should > accept from customers? > o If privacy is a concern and an operator wants to use ULA in the > network, what are the guidelines? > o How to deploy an IPv4 access network over an IPv6 core network? > o How to deploy an IPv6 access network over an IPv4 core network? > o Under what considerations, IS-IS should be used? > o Under what considerations, OSPFv3 should be used? > o What is the longest prefix to be allowed for peering? > >and so on. Those are, as the working group pointed out at IETF-79 with >very few punches pulled, *NOG questions or "go take one of the many fine >courses on the topic". > >And it is not at all about introducing someone's latest and greatest >tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into >a tunnel, or slice and dice a port number, unless we're talking about >operational experience with deployed technologies. > >It is about operating the IPv4 side of a dual stack network. CGN, a+p, >and all that. > >Attached I have a spreadsheet (csv format) in which I tried to classify >where I thought existing documents might go. No comment on whether the >working group should actually be working on the draft; my question was >"if someone sent in this draft as a -00, which working group might they >choose and why". I might obviously be wrong. But it's on the basis of >this that I said that the breakout was in the neighborhood of even. > From Tina.Tsou.Zouting@huawei.com Fri Aug 19 13:46:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC7211E80DB for ; Fri, 19 Aug 2011 13:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.782 X-Spam-Level: X-Spam-Status: No, score=-5.782 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXkHKchAjKge for ; Fri, 19 Aug 2011 13:46:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AA44311E80C6 for ; Fri, 19 Aug 2011 13:46:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ70011J0EQAS@szxga05-in.huawei.com> for v6ops@ietf.org; Sat, 20 Aug 2011 04:47:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ7007430EPUH@szxga05-in.huawei.com> for v6ops@ietf.org; Sat, 20 Aug 2011 04:47:14 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI15413; Sat, 20 Aug 2011 04:47:12 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 20 Aug 2011 04:47:01 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Sat, 20 Aug 2011 04:47:12 +0800 Date: Fri, 19 Aug 2011 20:47:11 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.126] To: Chris Donley , Fred Baker , Brian E Carpenter Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxuM1Qg3P5LkWzt0bTTI9XMJUipF8AgAAIV4CAAWi0AIAAkNlw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:46:20 -0000 Chris, That's exactly the main part what v4v6tran work and the framework I-D asked. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Chris Donley Sent: Friday, August 19, 2011 1:07 PM To: Fred Baker; Brian E Carpenter Cc: IPv6 Operations; Ron Bonica Subject: Re: [v6ops] How to divide v6ops I think there is a need for v4 coexstence/transition work, along what you are proposing: * How to deploy CGNs/other transition technologies with v4 components * transition technology experiences * How do we do CGN logging? What format do we use for the messages? * NAT444, 6to4, a+p issues, etc. With the proposed BEHAVE shut down, there isn't a clear place to take this work - v6ops, softwires, 6man, intarea, homenet, and opsarea all seem to fit pieces of it. I believe that this work would benefit from being in its own wg. However, I agree with others that v4ops is perhaps not the right name. Coexistence Ops (co-ops)? Also, I think that the charter should be tightened (per draft-george and other comments on the list) to focus on IPv4/IPv6 transition/coexistence operational and security issues, and not on general IPv4 network/security operations. Chris On 8/18/11 4:36 PM, "Fred Baker" wrote: > >On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: > >> Hi Fred, >> >> Will this reduce the total workload and/or reduce cross-posting? >> I have some doubts, since it seems likely that there will be >> crossover issues all the time. Nevertheless, dividing the >> workload does seem like a reasonable principle. However, it's >> only when we see a full list of the drafts to be assigned to the >> new WG that we can really see if it will work out. >> >> I don't like the name "v4ops". It seems somewhat contradictory >> to draft-george-ipv6-support, although the proposed charter is >> completely in line with that draft. Ideally, we'd call it >> "legacy-ip-ops" but that isn't possible, so how about "v46ops"? > >My thought, which I'm not stuck on but is what I'm thinking right now, is >that this is actually not very much about anything with a "6" in it. I'm >in favor of pushing IPv6 as a technology, but... > >It's about the fact that networks that are deploying IPv6 still have to >stay in business, and as a result have v4 networks that have to stay >running until a certain percentage of their access customers have >upgraded CPEs, edge networks, and hosts. Host upgrade is a limited >timeframe problem, given that people buy new ones at some rate. CPEs etc >can be another discussion; if I have a working CPE, why do I spend $$ to >change it? It's in the ISP's interest for them to all go spend that >money; I doubt that the average consumer will see it as in their interest >also. > >Since Tina brought it up, let me comment on how this differs from >v4v6tran. It differs in that it is only partially about transition issues >or explaining to operators that have completely ignored IPv6 for 15 years >and gotten no education the issues brought up in v4v6tran: > > o How to decide the IPv6 address architecture in the network? > o What is the recommended prefix length for a large operator? > o What is the recommended prefix length for a medium operator? > o What is the recommended prefix length to hand out to customers? > o What is the recommended longest prefix length an operator should > accept from customers? > o If privacy is a concern and an operator wants to use ULA in the > network, what are the guidelines? > o How to deploy an IPv4 access network over an IPv6 core network? > o How to deploy an IPv6 access network over an IPv4 core network? > o Under what considerations, IS-IS should be used? > o Under what considerations, OSPFv3 should be used? > o What is the longest prefix to be allowed for peering? > >and so on. Those are, as the working group pointed out at IETF-79 with >very few punches pulled, *NOG questions or "go take one of the many fine >courses on the topic". > >And it is not at all about introducing someone's latest and greatest >tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into >a tunnel, or slice and dice a port number, unless we're talking about >operational experience with deployed technologies. > >It is about operating the IPv4 side of a dual stack network. CGN, a+p, >and all that. > >Attached I have a spreadsheet (csv format) in which I tried to classify >where I thought existing documents might go. No comment on whether the >working group should actually be working on the draft; my question was >"if someone sent in this draft as a -00, which working group might they >choose and why". I might obviously be wrong. But it's on the basis of >this that I said that the breakout was in the neighborhood of even. > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Fri Aug 19 14:05:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5B51F0C3B for ; Fri, 19 Aug 2011 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+L1iRXf7jyu for ; Fri, 19 Aug 2011 14:05:42 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id B118A1F0C34 for ; Fri, 19 Aug 2011 14:05:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6207420997; Fri, 19 Aug 2011 17:06:40 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 19 Aug 2011 17:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=b5v kT9+S6tVksPoLXOobss6rJtU=; b=CNdGaPB0QnUPHM13RKCu39AAgmLReTDkKo/ oRHLvK4s0HVBvlEZ7tHiLZMVbm51xsBNi6mJDYbhRhScGrlzq0LesLS6RhEVfFUT ghtQM/RCK5vMtd2DI8b9CcaBQx9uroF6sC6pJpjNuDyw5PxAvK856zokWbTifhIg 6Qe6RCx0= X-Sasl-enc: BU+1gbUAXXicab14aYJBvdsPD/c37YDWRW4M7V1eFUbf 1313787999 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 215D6900092; Fri, 19 Aug 2011 17:06:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30-473335681 From: Keith Moore In-Reply-To: Date: Fri, 19 Aug 2011 17:06:24 -0400 Message-Id: <339C24FB-88ED-4F9B-9AA9-B01C9BAF897A@network-heretics.com> References: To: Chris Donley X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:05:43 -0000 --Apple-Mail-30-473335681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2011, at 4:07 PM, Chris Donley wrote: > I think there is a need for v4 coexstence/transition work, along what = you > are proposing: > * How to deploy CGNs/other transition technologies with v4 components > * transition technology experiences > * How do we do CGN logging? What format do we use for the messages? > * NAT444, 6to4, a+p issues, etc. >=20 > With the proposed BEHAVE shut down, there isn't a clear place to take = this > work - v6ops, softwires, 6man, intarea, homenet, and opsarea all seem = to > fit pieces of it. That, at least, seems to indicate that simply splitting this group is = not a good idea. It might be that some sort of rearranging or = clarification of the scopes of several working groups is in order. = That exercise should make it clear if there are areas not adequately = covered for which one or more additional WGs might be appropriate. Keith --Apple-Mail-30-473335681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I think there = is a need for v4 coexstence/transition work, along what you
are = proposing:
* How to deploy CGNs/other transition technologies with v4 = components
* transition technology experiences
* How do we do CGN = logging? What format do we use for the messages?
* NAT444, 6to4, a+p = issues, etc.

With the proposed BEHAVE shut down, there isn't a = clear place to take this
work - v6ops, softwires, 6man, intarea, = homenet, and opsarea all seem to
fit pieces of = it.

That, at least, seems to indicate = that simply splitting this group is not a good idea.  It might be = that some sort of rearranging or clarification of the scopes of several = working groups is in order.   That exercise should make it clear if = there are areas not adequately covered for which one or more additional = WGs might be = appropriate.

Keith

= --Apple-Mail-30-473335681-- From internet-drafts@ietf.org Sat Aug 20 06:39:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39121F85B5; Sat, 20 Aug 2011 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf9azQgb8ssC; Sat, 20 Aug 2011 06:39:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A863B21F85AC; Sat, 20 Aug 2011 06:39:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110820133924.11018.90054.idtracker@ietfa.amsl.com> Date: Sat, 20 Aug 2011 06:39:24 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 13:39:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-04.txt Pages : 34 Date : 2011-08-20 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-04.txt From despres.remi@laposte.net Sat Aug 20 07:45:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAF521F86E0 for ; Sat, 20 Aug 2011 07:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBuUQP9IR7c9 for ; Sat, 20 Aug 2011 07:45:34 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E28D221F86C3 for ; Sat, 20 Aug 2011 07:45:31 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6E87394007F; Sat, 20 Aug 2011 16:46:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-536935265 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 20 Aug 2011 16:46:24 +0200 Message-Id: <66034795-73F9-4CAC-B44C-D3F047B5DE83@laposte.net> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <2E8F17FB-6AAB-45E6-A7D3-507297482FEB@network-heretics.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Keith Moore , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 14:45:34 -0000 --Apple-Mail-2-536935265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 19 ao=FBt 2011 =E0 04:42, Cameron Byrne a =E9crit : > On Aug 18, 2011 7:37 PM, "Keith Moore" = wrote: >=20 ... > > So the first thing I'd recommend is triage - sort the work items = into urgent, necessary, and nonessential. And I'd strongly recommend = that at least the nonessential work and maybe some of the necessary work = get pursued elsewhere (other WGs when appropriate, otherwise as = individual submissions, or abandon as the authors see fit). Newly = proposed work needs to be subjected to the same criteria - not "does the = group want to adopt this as a work item?" but "is this work urgent, not = urgent but still necessary, or nonessential?" > > > > Keith > > >=20 > This sounds smart to me. >=20 >=20 +1 RD --Apple-Mail-2-536935265 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Aug 18, 2011 7:37 PM, "Keith Moore" <moore@network-heretics.com&= gt; wrote:

...

> = So the first thing I'd recommend is triage - sort the work items into = urgent, necessary, and nonessential.  And I'd strongly recommend = that at least the nonessential work and maybe some of the necessary work = get pursued elsewhere (other WGs when appropriate, otherwise as = individual submissions, or abandon as the authors see fit).  Newly = proposed work needs to be subjected to the same criteria - not "does the = group want to adopt this as a work item?" but "is this work urgent, not = urgent but still necessary, or nonessential?"
>
> Keith
>

This sounds smart to = me.



+1

<= div>RD


= --Apple-Mail-2-536935265-- From despres.remi@laposte.net Sat Aug 20 07:45:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5121F8779 for ; Sat, 20 Aug 2011 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXScY5a7JUkR for ; Sat, 20 Aug 2011 07:45:37 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8115421F86DF for ; Sat, 20 Aug 2011 07:45:35 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9F16D9400AC; Sat, 20 Aug 2011 16:46:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 20 Aug 2011 16:46:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Arturo Servin , IPv6 Operations Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 14:45:38 -0000 Le 19 ao=FBt 2011 =E0 12:18, Randy Bush a =E9crit : >> I prefer having one community focused on moving v6 forward with ipv4 >> in mind ....instead of the v4 life support group and the v6ops group >> with lots of cross posting >=20 > agree. +1 RD From joelja@bogus.com Sat Aug 20 12:31:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D198121F85C0 for ; Sat, 20 Aug 2011 12:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.859 X-Spam-Level: X-Spam-Status: No, score=-101.859 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1K+DuKMqLa5 for ; Sat, 20 Aug 2011 12:31:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6413721F85AC for ; Sat, 20 Aug 2011 12:31:50 -0700 (PDT) Received: from [192.168.43.44] (mfc0536d0.tmodns.net [208.54.5.252]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7KJWeoU069357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 20 Aug 2011 19:32:47 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joel Jaeggli In-Reply-To: <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> Date: Sat, 20 Aug 2011 12:25:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 20 Aug 2011 19:32:47 +0000 (UTC) Cc: IPv6 Operations , Arturo Servin Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 19:31:50 -0000 On Aug 20, 2011, at 7:46 AM, R=E9mi Despr=E9s wrote: >=20 > Le 19 ao=FBt 2011 =E0 12:18, Randy Bush a =E9crit : >=20 >>> I prefer having one community focused on moving v6 forward with ipv4 >>> in mind ....instead of the v4 life support group and the v6ops group >>> with lots of cross posting >>=20 >> agree. >=20 > +1 One has to recognize that expectations of stack changes in existing ipv4 = speaking devices, particularly non-dual-stack devices are unrealistic. = So keeping ipv4 in mind, really means keeping our legacy in mind = because the hosts themselves aren't going to change. > RD >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From fred@cisco.com Sat Aug 20 18:13:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831B21F84F2 for ; Sat, 20 Aug 2011 18:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75IZbQ+JU1r1 for ; Sat, 20 Aug 2011 18:13:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C2DED21F84EC for ; Sat, 20 Aug 2011 18:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1942; q=dns/txt; s=iport; t=1313889267; x=1315098867; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+WvZsDMoU2lswF11wkxZFVIuS8MwZn802kIaCRGLW8w=; b=YEhObfWFxkJMRcCJFEuZCtRrUOvczfRi9mafCwC7s2kQFw8/iJRDBqOW D8ZDPPw0SFOsnrZIgubRpiP0TCTT1eW44pESvF2YsKksrdhoVrv/qpMcG XuZ8ftb8Wo50uql95M6c13Zyln5Ny0DfsSF0wrqt6NAx4oPBIRskJQ5uh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM9aUE6rRDoH/2dsb2JhbAA7BqgUd4FAAQEBAQMSASc/EAsYLkkBDQY1ogYBnWmDMoI3XwSHYIs0kRY X-IronPort-AV: E=Sophos;i="4.68,257,1312156800"; d="scan'208";a="15006005" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 21 Aug 2011 01:14:26 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7L1EOt8017862; Sun, 21 Aug 2011 01:14:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Sat, 20 Aug 2011 18:14:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82B95322-BD60-4B00-AD1A-B6F93356643D@cisco.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: Arturo Servin , IPv6 Operations Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 01:13:26 -0000 On Aug 20, 2011, at 12:25 PM, Joel Jaeggli wrote: > One has to recognize that expectations of stack changes in existing = ipv4 speaking devices, particularly non-dual-stack devices are = unrealistic. So keeping ipv4 in mind, really means keeping our legacy in = mind because the hosts themselves aren't going to change. It's not limited to the hosts. In my case, every host in the house = speaks IPv6 with the exception of my wife's printer, the Cisco 7960 on = my desk, and our various Android, Samsung, and Motorola telephones. The = 7960 could; it's a matter of a software upgrade. What prevents me from = speaking IPv6 anywhere else is my CPE router (I in fact upgraded the = software; however, the only reason I had to do so was that I wanted to), = my service provider (Cox), and the company I VPN into (Cisco IT runs = IPv6 in some places, but not everywhere and specifically not on DMVPN = access and not on internal telephones). I personally fixed the external = problem in part by getting an HE tunnel; again, I am motivated to, but = I'm unusual in that regard. Keeping IPv4 in mind is in part driving with the eyes glued on the = rearview mirror and looking at Windows XP. That said, I think the = biggest single impediment, given that the ISP offers IPv6 service, will = be the CPE Router, not the host. I suspect that getting people to = upgrade them will mean the ISPs getting somehow into cahoots with the = CPE Router vendors and offering an upgrade service to their = residential/SOHO customers. Ideally, that would be a software download, = but I'm not holding my breath for a number of obvious reasons. If we = want that to be an equipment upgrade - which the vendors will want it to = be - that's something ISPs and CPE router vendors will need to sell to = their customers. I'm going to shut up before some lawyer tells me I'm afoul of some = anti-anticompetitive-behavior law.=20= From ek@google.com Sat Aug 20 18:29:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8951221F86DF for ; Sat, 20 Aug 2011 18:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZneeCv5qxp2K for ; Sat, 20 Aug 2011 18:29:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EE45521F85B9 for ; Sat, 20 Aug 2011 18:29:28 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p7L1UT3G011829 for ; Sat, 20 Aug 2011 18:30:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313890229; bh=FQ7Hw6KfQD52wePOk4RWZhctoig=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=qxziXOGTFtIfo29A0wsSdsAeosGErWXLG1rDI4XuM5A+w6/NypMygpA7h6njurrs6 ZmHa5I2jvJ42yfED1h6Sg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=NBleqj6Dy8x8PLf7fl37IiuPmjwfXVdJKhcvaUkdWb4+75D5M/sw5OZZYllvEw8UG 8laesFw6dtCPSyRM8A+Uw== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by wpaz21.hot.corp.google.com with ESMTP id p7L1USlV025653 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 20 Aug 2011 18:30:28 -0700 Received: by qyk38 with SMTP id 38so895669qyk.12 for ; Sat, 20 Aug 2011 18:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jualjO96idhuUo/whZOaZwO+XAjTLNcd2XKTK2cjyhI=; b=dd3ukTAq67VMXwr4T2SQOIMwsUnmULAcIeXYLb0xcTYkKqQuheRWgGS2Nos4Ftmj4q tAJuscYVMqaJwwsu9ePw== Received: by 10.229.8.5 with SMTP id f5mr477238qcf.65.1313890228007; Sat, 20 Aug 2011 18:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.8.5 with SMTP id f5mr477231qcf.65.1313890227756; Sat, 20 Aug 2011 18:30:27 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Sat, 20 Aug 2011 18:30:27 -0700 (PDT) In-Reply-To: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> Date: Sun, 21 Aug 2011 10:30:27 +0900 Message-ID: From: Erik Kline To: Fred Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 01:29:32 -0000 > For continuity, I have offered to chair v4ops with a co-chair from an ope= rator that is concerned with v4/v6 transition issues to be chosen by Ron; I= would continue to co-chair v6ops with Joel. That will likely change over t= ime, of course. At IETF 82, I would suggest that we have two successive day= s with essentially four hour blocks (eg, two 2-hour meetings), one for v6op= s and one for v4ops, to make it easiest for the operators to attend both se= ts of meetings. That both gives us more time to hold the relevant discussio= ns and a better organizing principle. From there, we can determine future p= lans. +1 to giving the schedule split @82 a try. The general feeling could be partially gauged by attendance. I,for one, could very easily skip the v4ops-focused session. From joelja@bogus.com Sat Aug 20 18:30:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5FC21F8761 for ; Sat, 20 Aug 2011 18:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDG+wEZM4e4r for ; Sat, 20 Aug 2011 18:30:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 989E221F8713 for ; Sat, 20 Aug 2011 18:30:32 -0700 (PDT) Received: from [192.168.2.188] (173-164-199-186-SFBA.hfc.comcastbusiness.net [173.164.199.186]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7L1VSXX088113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 21 Aug 2011 01:31:29 GMT (envelope-from joelja@bogus.com) References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> <82B95322-BD60-4B00-AD1A-B6F93356643D@cisco.com> In-Reply-To: <82B95322-BD60-4B00-AD1A-B6F93356643D@cisco.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <586E3B0E-D4E2-4FA3-B612-8D198C45800B@bogus.com> X-Mailer: iPad Mail (8L1) From: Joel Jaeggli Date: Sat, 20 Aug 2011 18:31:32 -0700 To: Fred Baker X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 21 Aug 2011 01:31:30 +0000 (UTC) Cc: Arturo Servin , IPv6 Operations Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 01:30:33 -0000 Consumer owned CPE will be replaced eventually because they have in the past= and they do age out of the network, but it's not fast, and it's not coupled= to ISP activites when you talking about the installed base. If an ISP controls the CPE, they can control that outcome more directly (fre= e for example). =20 I'm fundamentally convinced that we don't get to mess with the installed bas= e, so we should be focused on devices that don't yet exist (as targets for i= nnovation), or those that exist and will in the near term, that have v6 as i= t is currently conceived rather than as we would like it to be (assuming the= re is variance). Joel's widget number 2 On Aug 20, 2011, at 18:14, Fred Baker wrote: >=20 > On Aug 20, 2011, at 12:25 PM, Joel Jaeggli wrote: >> One has to recognize that expectations of stack changes in existing ipv4 s= peaking devices, particularly non-dual-stack devices are unrealistic. So kee= ping ipv4 in mind, really means keeping our legacy in mind because the host= s themselves aren't going to change. >=20 > It's not limited to the hosts. In my case, every host in the house speaks I= Pv6 with the exception of my wife's printer, the Cisco 7960 on my desk, and o= ur various Android, Samsung, and Motorola telephones. The 7960 could; it's a= matter of a software upgrade. What prevents me from speaking IPv6 anywhere e= lse is my CPE router (I in fact upgraded the software; however, the only rea= son I had to do so was that I wanted to), my service provider (Cox), and the= company I VPN into (Cisco IT runs IPv6 in some places, but not everywhere a= nd specifically not on DMVPN access and not on internal telephones). I perso= nally fixed the external problem in part by getting an HE tunnel; again, I a= m motivated to, but I'm unusual in that regard. >=20 > Keeping IPv4 in mind is in part driving with the eyes glued on the rearvie= w mirror and looking at Windows XP. That said, I think the biggest single im= pediment, given that the ISP offers IPv6 service, will be the CPE Router, no= t the host. I suspect that getting people to upgrade them will mean the ISPs= getting somehow into cahoots with the CPE Router vendors and offering an up= grade service to their residential/SOHO customers. Ideally, that would be a s= oftware download, but I'm not holding my breath for a number of obvious reas= ons. If we want that to be an equipment upgrade - which the vendors will wan= t it to be - that's something ISPs and CPE router vendors will need to sell t= o their customers. >=20 > I'm going to shut up before some lawyer tells me I'm afoul of some anti-an= ticompetitive-behavior law.=20 >=20 From despres.remi@laposte.net Sun Aug 21 08:49:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3BA21F8A67 for ; Sun, 21 Aug 2011 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdXL1eziNAJf for ; Sun, 21 Aug 2011 08:49:40 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72121F8804 for ; Sun, 21 Aug 2011 08:49:38 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5DC91940108; Sun, 21 Aug 2011 17:50:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <82B95322-BD60-4B00-AD1A-B6F93356643D@cisco.com> Date: Sun, 21 Aug 2011 17:50:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62DD6DFC-46BB-4C14-8F31-88426AD3ADFF@laposte.net> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <4E4D8CE6.7050204@gmail.com> <7852761D-6BA3-4145-96A7-FC404C2C7F7E@laposte.net> <82B95322-BD60-4B00-AD1A-B6F93356643D@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Sheng Jiang Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 15:49:41 -0000 Hi, Fred, In view of your interesting comment below (now between ***'s), you = opinion, and that of v6ops contributors, on the 6a44 approach, will be = quite useful. The 6a44 proposal, co-authored with Brian Carpenter, Dan Wing, and Sheng = Jiang, is about offering IPv6, plug-and-play and in production-quality, = behind _unmodified_ CPEs, to all hosts that have the appropriate = upgrade.=20 The solution is operationally simple, and easily scalable because it is = stateless (per-customer states neither in ISP nodes nor in hosts). Ref is tools.ietf.org/html/draft-despres-6a44-00. (Since no WG found such a goal in its scope, it has been posted as = independent submission.)=20 Regards, RD Le 21 ao=FBt 2011 =E0 03:14, Fred Baker a =E9crit : >=20 > On Aug 20, 2011, at 12:25 PM, Joel Jaeggli wrote: >> One has to recognize that expectations of stack changes in existing = ipv4 speaking devices, particularly non-dual-stack devices are = unrealistic. So keeping ipv4 in mind, really means keeping our legacy in = mind because the hosts themselves aren't going to change. >=20 > It's not limited to the hosts. In my case, every host in the house = speaks IPv6 with the exception of my wife's printer, the Cisco 7960 on = my desk, and our various Android, Samsung, and Motorola telephones. The = 7960 could; it's a matter of a software upgrade. What prevents me from = speaking IPv6 anywhere else is my CPE router (I in fact upgraded the = software; however, the only reason I had to do so was that I wanted to), = my service provider (Cox), and the company I VPN into (Cisco IT runs = IPv6 in some places, but not everywhere and specifically not on DMVPN = access and not on internal telephones). I personally fixed the external = problem in part by getting an HE tunnel; again, I am motivated to, but = I'm unusual in that regard. >=20 > Keeping IPv4 in mind is in part driving with the eyes glued on the = rearview mirror and looking at Windows XP. *** > That said, I think the biggest single impediment, given that the ISP = offers IPv6 service, will be the CPE Router, not the host. I suspect = that getting people to upgrade them will mean the ISPs getting somehow = into cahoots with the CPE Router vendors and offering an upgrade service = to their residential/SOHO customers. Ideally, that would be a software = download, but I'm not holding my breath for a number of obvious reasons. = If we want that to be an equipment upgrade - which the vendors will want = it to be - that's something ISPs and CPE router vendors will need to = sell to their customers. *** > I'm going to shut up before some lawyer tells me I'm afoul of some = anti-anticompetitive-behavior law. From ietfc@btconnect.com Mon Aug 22 02:02:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47621F8B18 for ; Mon, 22 Aug 2011 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USfP3E3a65q3 for ; Mon, 22 Aug 2011 02:02:43 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01221F8B10 for ; Mon, 22 Aug 2011 02:02:41 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr10.btconnect.com with SMTP id EAB89933; Mon, 22 Aug 2011 10:03:43 +0100 (BST) Message-ID: <017a01cc60a1$821028c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com><4E4D8CE6.7050204@gmail.com> Date: Mon, 22 Aug 2011 10:00:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E521B6E.00DC, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.22.80018:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __FRAUD_AGREE, __INT_PROD_TV, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E521B70.00E0,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IPv6 Operations Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:02:43 -0000 ----- Original Message ----- From: "Fred Baker" To: "Brian E Carpenter" Cc: "IPv6 Operations" ; "Ron Bonica" Sent: Friday, August 19, 2011 12:36 AM On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote: My thought, which I'm not stuck on but is what I'm thinking right now, is that this is actually not very much about anything with a "6" in it. I'm in favor of pushing IPv6 as a technology, but... It's about the fact that networks that are deploying IPv6 still have to stay in business, and as a result have v4 networks that have to stay running until a certain percentage of their access customers have upgraded CPEs, edge networks, and hosts. Host upgrade is a limited timeframe problem, given that people buy new ones at some rate. CPEs etc can be another discussion; if I have a working CPE, why do I spend $$ to change it? It's in the ISP's interest for them to all go spend that money; I doubt that the average consumer will see it as in their interest also. My experience, probably atypical, is the opposite. I run an elderly PC with elderly software because the cost of transition to anything newer is so high; I occasionally have a problem - eg the IANA home page will not display correctly - but nothing I cannot live with. By contrast, in a parallel field, I have replaced a 'CPE', my digibox for terrestial TV, several times. The monetary cost is low (50 to 100 dollar), the functionality is improved with a new box, the user interface is almost a standard so I have little need for 're-training' etc. When I encounter a problem, I bin the box and replace it, and would do just the same for my ADSL CPE. The other parallel is the mobile phone, where every so often I get a message saying that when I switch the phone off, I will activate new software. This I do not want; I am deeply suspicious of an organisation I do not trust downloading new software onto my hardware to be activated at at time I do not really control (ie the battery going flat). Another beauty of the ADSL CPE is that I can buy one from a third party, and then my ISP cannot impose new software on me at a time of its choosing. Tom Petch From frnkblk@iname.com Mon Aug 22 15:48:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFF721F8C5F for ; Mon, 22 Aug 2011 15:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAOTKOZXjcf9 for ; Mon, 22 Aug 2011 15:48:42 -0700 (PDT) Received: from premieronline.net (smtp2-5.premieronline.net [96.31.0.30]) by ietfa.amsl.com (Postfix) with ESMTP id A25D721F8B87 for ; Mon, 22 Aug 2011 15:48:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 3295888-1729245 for ; Mon, 22 Aug 2011 17:49:48 -0500 From: "Frank Bulk" To: "'IPv6 Operations'" Date: Mon, 22 Aug 2011 17:49:49 -0500 Message-ID: <003101cc611d$cc0642d0$6412c870$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGgg== Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=6 Friend=895 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 895, in=14000072, out=52664, spam=0 Known=true ip=199.120.69.26 Subject: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 22:48:43 -0000 Should an RF issue a DHCPv6 solicit on its WAN interface only upon having received an RA message with the RA bits marked "M"? Or can/should it send one out regardless? We have a xPON vendor onsite to do some testing with their equipment in our production IPv6 network and only one of the five RGs are working. I suspect it's because the RG's are waiting for that RA. Any insight or pointers to RFCs would be appreciated. Frank From volz@cisco.com Mon Aug 22 17:17:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825C421F84F7 for ; Mon, 22 Aug 2011 17:17:32 -0700 (PDT) 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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkhe7n1LrdPn for ; Mon, 22 Aug 2011 17:17:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9064221F8B18 for ; Mon, 22 Aug 2011 17:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1295; q=dns/txt; s=iport; t=1314058718; x=1315268318; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=REjW7Zi0uUQ74kGso9W/rQ0jiqW+Ir2828hRF3zO6q8=; b=JHwGrMAd4m86l2IKJ8eyz4weTgMmYYzJ9fZmwdM3kELvCx7N2sgefOvC e2NbgxtSH1L5yWRnrWvbpP6kMjb3wRACCk/z2OLBGv/QO67uWjr3XLf3X aRgaRl+OdsT5/vlogtxDDEyimCE8i7N4D1Z4gbd2mjUxbdAr6uXs03Xvv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAADxUk6tJV2Z/2dsb2JhbABBmEWPXXeBOQcBAQEBAwEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHU5YMAZ8nhWlfBIdgkEuMAg X-IronPort-AV: E=Sophos;i="4.68,266,1312156800"; d="scan'208";a="15489218" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 23 Aug 2011 00:18:37 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7N0Ibws032053; Tue, 23 Aug 2011 00:18:37 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 19:18:36 -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 Date: Mon, 22 Aug 2011 19:18:37 -0500 Message-ID: In-Reply-To: <003101cc611d$cc0642d0$6412c870$@iname.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQ References: <003101cc611d$cc0642d0$6412c870$@iname.com> From: "Bernie Volz (volz)" To: , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 00:18:36.0996 (UTC) FILETIME=[33A65040:01CC612A] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:17:32 -0000 Ah ... the M (and O) bits ... that debate wasted a lot of bits. I think the summary was (though hopefully this won't start another debate -- great if someone corrects me if I erred though) is that *if* the M (or O) bit is set, a device SHOULD do DHCPv6. Whether it does DHCPv6 without the M or O bit set is up to the device itself (or the configuration). There is no requirement either way (I guess in RFC language this might be "a host MAY run DHCPv6"). - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Frank Bulk Sent: Monday, August 22, 2011 6:50 PM To: 'IPv6 Operations' Subject: [v6ops] When an RG should issue a DHCPv6 solicit Should an RF issue a DHCPv6 solicit on its WAN interface only upon having received an RA message with the RA bits marked "M"? Or can/should it send one out regardless? We have a xPON vendor onsite to do some testing with their equipment in our production IPv6 network and only one of the five RGs are working. I suspect it's because the RG's are waiting for that RA. Any insight or pointers to RFCs would be appreciated. Frank _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From frnkblk@iname.com Mon Aug 22 17:39:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5391021F8B7D for ; Mon, 22 Aug 2011 17:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B7XQlnng4Xd for ; Mon, 22 Aug 2011 17:39:47 -0700 (PDT) Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id 68C1921F8B6C for ; Mon, 22 Aug 2011 17:39:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from BULKFAMLAPTOP (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30215730-1729245 for multiple; Mon, 22 Aug 2011 19:40:50 -0500 From: "Frank Bulk" To: "'Bernie Volz \(volz\)'" , "IPv6 Operations" References: <003101cc611d$cc0642d0$6412c870$@iname.com> In-Reply-To: Date: Mon, 22 Aug 2011 19:40:49 -0500 Message-ID: <001f01cc612d$4dc88030$e9598090$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrA= Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=13 Friend=941 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 898, in=12863028, out=62343, spam=0 Known=true ip=199.120.69.27 Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:39:48 -0000 Thanks, but that doesn't really hit the core of my question. I believe TR-124i2 allows for a Router Solicitation and DHCPv6 to occur simultaneously, while previously the router waited for the RA before initiating a DHCPv6 Solicit. The access gear that a vendor is testing in our network appears to be blocking the RA, and so two of the three CPE I tested so far doesn't get a default IPv6 gateway and doesn't initiate DHCPv6 to get a prefix for the LAN interface. Obviously blocking the RA is an issue. =) Frank -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Monday, August 22, 2011 7:19 PM To: frnkblk@iname.com; IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Ah ... the M (and O) bits ... that debate wasted a lot of bits. I think the summary was (though hopefully this won't start another debate -- great if someone corrects me if I erred though) is that *if* the M (or O) bit is set, a device SHOULD do DHCPv6. Whether it does DHCPv6 without the M or O bit set is up to the device itself (or the configuration). There is no requirement either way (I guess in RFC language this might be "a host MAY run DHCPv6"). - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Frank Bulk Sent: Monday, August 22, 2011 6:50 PM To: 'IPv6 Operations' Subject: [v6ops] When an RG should issue a DHCPv6 solicit Should an RF issue a DHCPv6 solicit on its WAN interface only upon having received an RA message with the RA bits marked "M"? Or can/should it send one out regardless? We have a xPON vendor onsite to do some testing with their equipment in our production IPv6 network and only one of the five RGs are working. I suspect it's because the RG's are waiting for that RA. Any insight or pointers to RFCs would be appreciated. Frank _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Mon Aug 22 17:50:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3918321F86EC for ; Mon, 22 Aug 2011 17:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.639 X-Spam-Level: X-Spam-Status: No, score=-106.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyWg7yWRztLK for ; Mon, 22 Aug 2011 17:50:37 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1221F8549 for ; Mon, 22 Aug 2011 17:50:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQC00FBHVQ2BJ31@mail-out.apple.com> for v6ops@ietf.org; Mon, 22 Aug 2011 17:51:41 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-1a-4e52f803d968 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id AC.FA.05328.308F25E4; Mon, 22 Aug 2011 17:44:51 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQC00AFRVQ50080@kencur.apple.com> for v6ops@ietf.org; Mon, 22 Aug 2011 17:51:41 -0700 (PDT) From: james woodyatt In-reply-to: <001f01cc612d$4dc88030$e9598090$@iname.com> Date: Mon, 22 Aug 2011 17:51:40 -0700 Message-id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> To: frnkblk@iname.com X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiON1OTZf5R5CfwZJ+KYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+/sBcwFG5krnnXzNjBeYepi5OSQEDCROH/wGDOELSZx4d56 ti5GLg4hgXYmiclLG9hAErwCghI/Jt9j6WLk4GAWkJc4eF4WJMwsoCXx/VErC0T9BCaJ022X GEESwgK2Eq9+HwSz2QRUJL5dvgu2jFPAQmLp0UWsIDaLgKrExqVnmCBmqkj8b+AHMXkFbCR+ /VEDqRASWMEo8eNbOIgtIiAqceHATxaIM+UlFrd8ZpzAKDALyXGzEI6bheS4BYzMqxgFi1Jz EisNTfQSCwpyUvWS83M3MYJCrqHQZAfjwZ/8hxgFOBiVeHh/HgjyE2JNLCuuzD3EKMHBrCTC u/AOUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv/6tAKYH0xJLU7NTUgtQimCwTB6dUA6Nt625n 8T/zLgZpPDi3Jnb3qi8eCX1H09d9X3z086G8x9MXJ/5NrnrzqYpl8toc+Xn5dVW1Bi3X2tdv 2l1ay7jz3QKe6/MWOx6RMxF9qWTz+PbrD6cDLj6ck+N4PDXuz6KcoOA4Ha7u28n7BSIZuKb6 rFhQkXxn+fePLnwmmlscNBjmXfig1qunxFKckWioxVxUnAgA3QZc6zUCAAA= Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:50:38 -0000 On Aug 22, 2011, at 17:40 , Frank Bulk wrote: > > Obviously blocking the RA is an issue. Yes, a residential gateway MAY decide not to start the DHCPv6 client if there are no router advertisements to process. Without any default routers on the WAN link, a DHCPv6 lease from the network won't be very useful to a residential gateway. -- james woodyatt member of technical staff, core os networking From volz@cisco.com Mon Aug 22 18:21:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965F21F8B00 for ; Mon, 22 Aug 2011 18:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsiamT8Rb8nR for ; Mon, 22 Aug 2011 18:21:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2636121F8AFC for ; Mon, 22 Aug 2011 18:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2621; q=dns/txt; s=iport; t=1314062555; x=1315272155; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+tWobt1wrcE6LvbkT/l741oQ3cAqeA9XpaYQDZx+Chs=; b=PLG87XAOorel1hm+ejPhX5bM9iwrD5GqzG80XlDI4p44WnTPsMaHaapX F3V2UBtdooBTPJoBIPZNkMuGjKYLrFGzethZLjThIW0PruktPElLt9UHv BLCGUU6LrK5gv2bKllvbtjPfWIVDFp3VnFRu7dwsqad0NyyVsLqxOBAZL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAGEAU06tJV2Y/2dsb2JhbABBmEWPXXeBOQcBAQEBAQIBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah1OWOQGfLIVpXwSHYJBLjAI X-IronPort-AV: E=Sophos;i="4.68,266,1312156800"; d="scan'208";a="15506111" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2011 01:22:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7N1MYoF021402; Tue, 23 Aug 2011 01:22:34 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 20:22: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 Date: Mon, 22 Aug 2011 20:22:33 -0500 Message-ID: In-Reply-To: <001f01cc612d$4dc88030$e9598090$@iname.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwA== References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> From: "Bernie Volz (volz)" To: , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 01:22:34.0185 (UTC) FILETIME=[22CAE390:01CC6133] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 01:21:29 -0000 http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf Section A.2 - the flowchart seems to show both running in parallel which seems to imply that a TR124 compatible device does not need an RA (with M/O bits set) to start DHCPv6. Doing a quick look, I didn't see anything more that detailed the process. - Bernie -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com]=20 Sent: Monday, August 22, 2011 8:41 PM To: Bernie Volz (volz); IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Thanks, but that doesn't really hit the core of my question.=09 I believe TR-124i2 allows for a Router Solicitation and DHCPv6 to occur simultaneously, while previously the router waited for the RA before initiating a DHCPv6 Solicit. The access gear that a vendor is testing in our network appears to be blocking the RA, and so two of the three CPE I tested so far doesn't get a default IPv6 gateway and doesn't initiate DHCPv6 to get a prefix for the LAN interface. Obviously blocking the RA is an issue. =3D) Frank -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Monday, August 22, 2011 7:19 PM To: frnkblk@iname.com; IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Ah ... the M (and O) bits ... that debate wasted a lot of bits. I think the summary was (though hopefully this won't start another debate -- great if someone corrects me if I erred though) is that *if* the M (or O) bit is set, a device SHOULD do DHCPv6. Whether it does DHCPv6 without the M or O bit set is up to the device itself (or the configuration). There is no requirement either way (I guess in RFC language this might be "a host MAY run DHCPv6"). - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Frank Bulk Sent: Monday, August 22, 2011 6:50 PM To: 'IPv6 Operations' Subject: [v6ops] When an RG should issue a DHCPv6 solicit Should an RF issue a DHCPv6 solicit on its WAN interface only upon having received an RA message with the RA bits marked "M"? Or can/should it send one out regardless? We have a xPON vendor onsite to do some testing with their equipment in our production IPv6 network and only one of the five RGs are working. I suspect it's because the RG's are waiting for that RA. Any insight or pointers to RFCs would be appreciated. Frank _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Mon Aug 22 19:03:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F421F8B4D for ; Mon, 22 Aug 2011 19:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NjGI7FGgVkW for ; Mon, 22 Aug 2011 19:03:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9E621F8B48 for ; Mon, 22 Aug 2011 19:03:28 -0700 (PDT) Received: by wwf5 with SMTP id 5so3776416wwf.13 for ; Mon, 22 Aug 2011 19:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=yQxYbmyfOlaHnAaaxkzNfsiMvX2qXU0KsxBm69HIC+k=; b=qW2ZhAwFeqjcIM83mdsOmxrEtdR/SADSzJg59+cjHK8IkrnFRKneWLIZPDixm/B7mw c6AekErYGKvL3Y10vL5L05VFXhEnotVV99+Vx9aKkN/jyyoD28mV7wGI/VK5Nrt94Z3Y WcnTD4cqxBZqU1dL0PF2c37upER9iBiFeJEpY= Received: by 10.216.159.73 with SMTP id r51mr2787959wek.17.1314065074208; Mon, 22 Aug 2011 19:04:34 -0700 (PDT) Received: from dhcp-10-55-85-252.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ew4sm5289216wbb.42.2011.08.22.19.04.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 19:04:33 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <001f01cc612d$4dc88030$e9598090$@iname.com> Date: Tue, 23 Aug 2011 04:04:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DA00912-8CDC-4976-8BBD-B1B7F9C65892@employees.org> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> To: frnkblk@iname.com X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 02:03:29 -0000 Frank, > Thanks, but that doesn't really hit the core of my question.=09 >=20 > I believe TR-124i2 allows for a Router Solicitation and DHCPv6 to = occur > simultaneously, while previously the router waited for the RA before > initiating a DHCPv6 Solicit. >=20 > The access gear that a vendor is testing in our network appears to be > blocking the RA, and so two of the three CPE I tested so far doesn't = get a > default IPv6 gateway and doesn't initiate DHCPv6 to get a prefix for = the LAN > interface. Obviously blocking the RA is an issue. =3D) the can be done in parallel. the M bit is just a hint and in any case = not relevant to prefix delegation. see RFC6204, WPD-4 among other requirements in the draft. cheers, Ole > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Monday, August 22, 2011 7:19 PM > To: frnkblk@iname.com; IPv6 Operations > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > Ah ... the M (and O) bits ... that debate wasted a lot of bits. >=20 > I think the summary was (though hopefully this won't start another > debate -- great if someone corrects me if I erred though) is that *if* > the M (or O) bit is set, a device SHOULD do DHCPv6. Whether it does > DHCPv6 without the M or O bit set is up to the device itself (or the > configuration). There is no requirement either way (I guess in RFC > language this might be "a host MAY run DHCPv6"). >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Frank Bulk > Sent: Monday, August 22, 2011 6:50 PM > To: 'IPv6 Operations' > Subject: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > Should an RF issue a DHCPv6 solicit on its WAN interface only upon > having > received an RA message with the RA bits marked "M"? Or can/should it > send > one out regardless? >=20 > We have a xPON vendor onsite to do some testing with their equipment = in > our > production IPv6 network and only one of the five RGs are working. I > suspect > it's because the RG's are waiting for that RA. >=20 > Any insight or pointers to RFCs would be appreciated. >=20 > Frank >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Mon Aug 22 19:04:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE54821F8B5F for ; Mon, 22 Aug 2011 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt9tOY14HCGO for ; Mon, 22 Aug 2011 19:04:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A16F621F8B5B for ; Mon, 22 Aug 2011 19:04:48 -0700 (PDT) Received: by wyg8 with SMTP id 8so4559275wyg.31 for ; Mon, 22 Aug 2011 19:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=SCkb4f5jAXFdkMBfKmGTKZslx3PaWr+IpwUTdMWAg84=; b=symuJBVAjcCSJAbrcPbFeNSyFQlvq9IJmtJb1GU7SBp/slJI7paNmkoL51hdrMAzBO OAQRZp9yKV0StNS2nG0i0RL3UHRXxJRnx3yzVuT+xw+w1GGOROmpVpOxf29VzHlGqwV/ 6R94yb8uyEiGUnUP0GrFvHmxpj5vx/e0LrX90= Received: by 10.216.231.210 with SMTP id l60mr49486weq.63.1314065154564; Mon, 22 Aug 2011 19:05:54 -0700 (PDT) Received: from dhcp-10-55-85-252.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ew4sm5286286wbb.59.2011.08.22.19.05.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 19:05:53 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 23 Aug 2011 04:05:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 02:04:49 -0000 >> Obviously blocking the RA is an issue. >=20 > Yes, a residential gateway MAY decide not to start the DHCPv6 client = if there are no router advertisements to process. Without any default = routers on the WAN link, a DHCPv6 lease from the network won't be very = useful to a residential gateway. RAs are not the only mechanism to advertise a default route. RFC6204, W-3. cheers, Ole= From frnkblk@iname.com Mon Aug 22 19:58:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9702D21F8B27 for ; Mon, 22 Aug 2011 19:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwscIatuGjFg for ; Mon, 22 Aug 2011 19:58:00 -0700 (PDT) Received: from premieronline.net (smtp2-2.premieronline.net [96.31.0.27]) by ietfa.amsl.com (Postfix) with ESMTP id 045A121F8B01 for ; Mon, 22 Aug 2011 19:57:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from BULKFAMLAPTOP (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 3301805-1729245 for multiple; Mon, 22 Aug 2011 21:59:06 -0500 From: "Frank Bulk" To: "'Ole Troan'" References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> In-Reply-To: Date: Mon, 22 Aug 2011 21:59:03 -0500 Message-ID: <000101cc6140$9ddd0290$d99707b0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxhPnUKLn6OBzm8QCieRBTUADBwOgAAcELA Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=10 Friend=1039 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 898, in=12865160, out=49094, spam=0 Known=true ip=199.120.69.27 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 02:58:00 -0000 The packet captures show RS, but I only see MLDs, not Router responses. So I suspect that Router Discovery is not working, either, for the same reason RAs aren't coming through. Frank -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, August 22, 2011 9:06 PM To: james woodyatt Cc: frnkblk@iname.com; IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> Obviously blocking the RA is an issue. > > Yes, a residential gateway MAY decide not to start the DHCPv6 client if there are no router advertisements to process. Without any default routers on the WAN link, a DHCPv6 lease from the network won't be very useful to a residential gateway. RAs are not the only mechanism to advertise a default route. RFC6204, W-3. cheers, Ole From fred@cisco.com Tue Aug 23 08:34:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E621F8BBF for ; Tue, 23 Aug 2011 08:34:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz-csEaOA3qI for ; Tue, 23 Aug 2011 08:34:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 73F0421F8BB7 for ; Tue, 23 Aug 2011 08:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3329; q=dns/txt; s=iport; t=1314113714; x=1315323314; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=AxEOtDNPF+TJXQzJD4UdoHibaQNHdLLWf+Xe+ujjno0=; b=eqwpas0q7lqqAR6s44PD054wLwwxM5ia5B3MdqEC2hFZi40wXN0hGm+R SxKe02Grnh5RWWG9HhHD7CTq/0KXvixQgoaO5z/y+zwhylDRfaZgpetuy 7u7n0B8EXmK8SN2M3SmAXVD9JLgrTFEjesENH596EUNovtq+5G5H3LV7G A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAATIU06rRDoI/2dsb2JhbABBmEqPUneBQAEBAQEEAQEPAQodNBcPEQQBASguHwcBAQUJExQOh1OaYoEjAZ83hkgEh2GLOIUNjA0 X-IronPort-AV: E=Sophos;i="4.68,270,1312156800"; d="scan'208";a="15715273" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 23 Aug 2011 15:35:13 +0000 Received: from dhcp-171-70-217-36.cisco.com (dhcp-171-70-217-36.cisco.com [171.70.217.36]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7NFZCnp010670 for ; Tue, 23 Aug 2011 15:35:12 GMT Received: from [127.0.0.1] by dhcp-171-70-217-36.cisco.com (PGP Universal service); Tue, 23 Aug 2011 08:35:12 -0700 X-PGP-Universal: processed; by dhcp-171-70-217-36.cisco.com on Tue, 23 Aug 2011 08:35:12 -0700 From: Fred Baker Date: Tue, 23 Aug 2011 08:35:02 -0700 Message-Id: <9FD4AE01-D262-41BF-A651-9496485DDBBC@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [v6ops] FW: Nomcom 2011-2012: Call for Nominations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 15:34:06 -0000 We encourage you to participate. The Chairs -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, August 23, 2011 1:30 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Call for Nominations Hi All, The 2011-2012 Nominating committee is seeking nominations from now until October 2, 2011. The list of open positions can be found at: https://www.ietf.org/group/nomcom/2011/ Nominations may be made directly on the NomCom 2011-2012 pages by selecting the Nominate link at the top of the page. The URL for NomCom 2011-2012 pages is: https://www.ietf.org/group/nomcom/2011/ Nominations may also be made by email to nomcom11@ietf.org. If you do so, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self nomination is welcome. NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed. The public nominee list will be updated at least once a week and possibly more often as nominations are received. With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and not disclosed. Because the list of nominees this year is public, we will accept feedback on the nominees starting August 23, 2011. Per RFC 5680, we will accept feedback from the entire IETF community on all the nominees. If you wish to provide anonymous feedback, the chair or any of the members will be happy to handle this for you. The Nominating Committee chair can be reached at nomcom-chair@ietf.org and the entire nominating committee can be reached at nomcom11@ietf.org. The email addresses of individual NomCom members is also on the NomCom 2011-2012 pages. In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2011/iab-requirements https://www.ietf.org/group/nomcom/2011/iesg-requirements https://www.ietf.org/group/nomcom/2011/iaoc-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom11@ietf.org. Thank you, Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ From narten@us.ibm.com Tue Aug 23 08:45:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431AE21F852E for ; Tue, 23 Aug 2011 08:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.154 X-Spam-Level: X-Spam-Status: No, score=-106.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHn4HTnst9SD for ; Tue, 23 Aug 2011 08:45:47 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id A239B21F850E for ; Tue, 23 Aug 2011 08:45:47 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7NFNiVZ029797 for ; Tue, 23 Aug 2011 11:23:44 -0400 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7NFkqgh111474 for ; Tue, 23 Aug 2011 11:46:52 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7NFqXZA001437 for ; Tue, 23 Aug 2011 09:52:33 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-216-244.mts.ibm.com [9.65.216.244]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7NFqWmg001089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 09:52:33 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7NFkk41008416; Tue, 23 Aug 2011 11:46:46 -0400 Message-Id: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> To: Fred Baker In-reply-to: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> Comments: In-reply-to Fred Baker message dated "Thu, 18 Aug 2011 11:47:32 -0700." Date: Tue, 23 Aug 2011 11:46:46 -0400 From: Thomas Narten Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 15:45:48 -0000 IMO, the real elephant in the room is that there are too many drafts covering marginal work topics. But rather than tell people "no", we allow work to continue, even enable it (e.g., by saying "we'll discuss further on the list", when in fact, little useful discussion happens but the ID gets respun and gets presented again at the next meeting). And given the that the WG (and in fact any WG) has a finite amount of clue/cycles, if you stretch that too thin, you start thrashing, and then you are really in a fix. The WG needs to focus on stuff that matters, and say "no" to everything else. Absent a real willingness to do this, splitting the WG up is nothing more then rearranging the deck chairs... Thomas From narten@us.ibm.com Tue Aug 23 09:30:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614721F8B4E for ; Tue, 23 Aug 2011 09:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8mUnaUq0ZNC for ; Tue, 23 Aug 2011 09:30:30 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67021F855B for ; Tue, 23 Aug 2011 09:30:30 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7NG8PA3022620 for ; Tue, 23 Aug 2011 12:08:25 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7NGAODo216638 for ; Tue, 23 Aug 2011 12:31:35 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7N9UbVT008874 for ; Tue, 23 Aug 2011 03:30:37 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-216-244.mts.ibm.com [9.65.216.244]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7N9Uafi008755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 03:30:36 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7NFURkL008288; Tue, 23 Aug 2011 11:30:27 -0400 Message-Id: <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> To: Scott Beuker In-reply-to: <1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> <4E4AEE2E.4030000@es.net> <1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> Comments: In-reply-to Scott Beuker message dated "Wed, 17 Aug 2011 21:12:00 -0000." Date: Tue, 23 Aug 2011 11:30:27 -0400 From: Thomas Narten Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 16:30:31 -0000 > > What is wrong with retrying periodically? The point is to do this > > every few tens of seconds, or every minute or two, so as to avoid > > spending a lot of CPU on DAD. However, the desire is that layer 3 > > be self healing once layer 2 has been fixed. IPv4 is self-healing > > in this way. IPv6 is currently not. > +1 I agree. The other thing to keep in mind is that if an interface is in loopback mode, the interface is effectively not working (i.e,. not forwarding traffic), and any "load" caused by such probes is pretty much irrelevant. What I'd suggest as a next step is that someone write a short ID that describes the problem, and sketches out a recommended algorithm for handling this situation. E.g., use NS/ND probes to detect the condition, switch to periodic probing mode when the interface is in loopback, and then describe how/when to switch back to normal mode. This appears to be doable using existing packet/option formats, so no new protocol extensions are needed. We can then publish it as a short BCP or informational document (we can figure out later which once the actual content has been worked out). Do we have a taker? Thomas From cb.list6@gmail.com Tue Aug 23 09:53:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325221F8B1D for ; Tue, 23 Aug 2011 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAuGSijaxyxp for ; Tue, 23 Aug 2011 09:53:52 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 662B021F85C0 for ; Tue, 23 Aug 2011 09:53:52 -0700 (PDT) Received: by wyg8 with SMTP id 8so276129wyg.31 for ; Tue, 23 Aug 2011 09:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XxfsOnOeLk/2jtG967jHYUt81Lpnd8w0aRmRy+ninsU=; b=joxcnw/GhgP9fB5BebtoRmymMShkSbrX3ndXyay57iptlcYzYbf1nJQHZQE5KRB4TY 4IZcb78pi6A9sUtPzuV9Lp9+Qtg6XmG7J7GfZQs8ef35EmHSKMxbBadrAWbpgrSUhXU9 e2PISfJHx48U1e3k8lgyX+qnEW9lGBQcgWS/U= MIME-Version: 1.0 Received: by 10.216.170.8 with SMTP id o8mr843380wel.101.1314118497144; Tue, 23 Aug 2011 09:54:57 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Tue, 23 Aug 2011 09:54:57 -0700 (PDT) Received: by 10.216.155.199 with HTTP; Tue, 23 Aug 2011 09:54:57 -0700 (PDT) In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> Date: Tue, 23 Aug 2011 09:54:57 -0700 Message-ID: From: Cameron Byrne To: Thomas Narten Content-Type: multipart/alternative; boundary=0016e657b1cc37114d04ab2f0e7f Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 16:53:53 -0000 --0016e657b1cc37114d04ab2f0e7f Content-Type: text/plain; charset=ISO-8859-1 On Aug 23, 2011 8:47 AM, "Thomas Narten" wrote: > > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. > > The WG needs to focus on stuff that matters, and say "no" to > everything else. > > Absent a real willingness to do this, splitting the WG up is nothing > more then rearranging the deck chairs... > > Thomas Fully agree. We need to 'fast fail' marginal work out of the group. Cb > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016e657b1cc37114d04ab2f0e7f Content-Type: text/html; charset=ISO-8859-1


On Aug 23, 2011 8:47 AM, "Thomas Narten" <narten@us.ibm.com> wrote:
>
> IMO, the real elephant in the room is that there are too many drafts
> covering marginal work topics. But rather than tell people "no", we
> allow work to continue, even enable it (e.g., by saying "we'll discuss
> further on the list", when in fact, little useful discussion happens
> but the ID gets respun and gets presented again at the next
> meeting). And given the that the WG (and in fact any WG) has a finite
> amount of clue/cycles, if you stretch that too thin, you start
> thrashing, and then you are really in a fix.
>
> The WG needs to focus on stuff that matters, and say "no" to
> everything else.
>
> Absent a real willingness to do this, splitting the WG up is nothing
> more then rearranging the deck chairs...
>
> Thomas

Fully agree. We need to 'fast fail' marginal work out of the group.

Cb
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--0016e657b1cc37114d04ab2f0e7f-- From bs7652@att.com Tue Aug 23 09:57:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9921F8B89 for ; Tue, 23 Aug 2011 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBJ+an2I7ZZ8 for ; Tue, 23 Aug 2011 09:57:39 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2918021F8B1D for ; Tue, 23 Aug 2011 09:57:39 -0700 (PDT) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1314118725!35438471!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30545 invoked from network); 23 Aug 2011 16:58:46 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Aug 2011 16:58:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7NGvUGW019501; Tue, 23 Aug 2011 12:57:31 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p7NGvHGm019138; Tue, 23 Aug 2011 12:57:23 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 12:57:59 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 12:57:59 -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 Date: Tue, 23 Aug 2011 12:58:36 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwAAad+ig References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> From: "STARK, BARBARA H (ATTSI)" To: "Bernie Volz (volz)" , , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 16:57:59.0180 (UTC) FILETIME=[CFE57CC0:01CC61B5] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 16:57:40 -0000 > http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf=20 >=20 > Section A.2 - the flowchart seems to show both running in parallel > which > seems to imply that a TR124 compatible device does not need an RA (with > M/O bits set) to start DHCPv6. >=20 > Doing a quick look, I didn't see anything more that detailed the > process. >=20 > - Bernie The flowchart in BBF TR-124i2 A.2 is mandatory/normative: WAN.IPv6. 1 The device MUST support automated establishment of an IPv6 connection according to the flow in Annex A.2. Yes, in BBF we concluded that the quickest connectivity establishment by a CE router would be achieved through simultaneous RS and DHCPv6 solicit, and we couldn't identify any good reason why this shouldn't be done.=20 As Ole mentioned on this thread, there are other ways to determine the default route, so the RA often isn't even needed. However... As TR-124i2 A.2 is currently written, not getting the RA is a failure case. It was so long ago, that I can't remember the discussion, but I think that it was thought that there was nothing we knew of preventing a service provider from sending RA messages. This blocking of RA is curious. But the flow chart A.2 seems pretty clear that the WAN IP interface is considered "down" in the absence of an RA. I thought there had been discussion around changing that, but that is what the published doc says. [Note that since this doc was liaised to IETF with request for feedback, if any, I do consider discussion of this liaised doc to be a valid topic, here. Thank you for the feedback.] But to bring the discussion back to IETF docs... Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message without having received the RA (implicit in WPD-5), but it doesn't mandate that behavior. Barbara From dart@es.net Tue Aug 23 10:01:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649DD21F8B8A for ; Tue, 23 Aug 2011 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQxDjWk8Tyd2 for ; Tue, 23 Aug 2011 10:01:02 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC321F8B25 for ; Tue, 23 Aug 2011 10:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=P/1NJ/fyLSZE4T5LkUDs15V90oJvQCQIUC//hIl6dNw=; b=MUGD3k0GqAa7Q6Bi+UKVOusHr3QPYrG101EltAOO9XsmFi5JRmunEkX9e+UjlIUUAqd8 8jqCBFK7yQyOjovlN4vaNzzBqL8pMzrLQN6J05hAjmUTTdnV50hpWw3DsCiFqXPs6VKC 34ymv+k1eu99pDb/8NOtDVtMjkq6swdvhNo= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.60]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7NH287N027183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2011 10:02:09 -0700 Message-ID: <4E53DD13.4070907@es.net> Date: Tue, 23 Aug 2011 10:02:11 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Thomas Narten References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> <20110816141748.GF72014@Space.Net> <067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com> <4E4AEE2E.4030000@es.net> <1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> In-Reply-To: <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-23_07:2011-08-23, 2011-08-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108230179 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 17:01:03 -0000 On 8/23/11 8:30 AM, Thomas Narten wrote: >>> What is wrong with retrying periodically? The point is to do this >>> every few tens of seconds, or every minute or two, so as to avoid >>> spending a lot of CPU on DAD. However, the desire is that layer 3 >>> be self healing once layer 2 has been fixed. IPv4 is self-healing >>> in this way. IPv6 is currently not. > >> +1 > > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. > > What I'd suggest as a next step is that someone write a short ID that > describes the problem, and sketches out a recommended algorithm for > handling this situation. > > E.g., use NS/ND probes to detect the condition, switch to periodic > probing mode when the interface is in loopback, and then describe > how/when to switch back to normal mode. > > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. > > We can then publish it as a short BCP or informational document (we > can figure out later which once the actual content has been worked > out). > > Do we have a taker? Yes - I'll take it. I have never written an ID before, so I'll need the help that a newbie would be expected to need. However, I'm happy to contribute. Many thanks, --eli -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From warren@kumari.net Tue Aug 23 11:03:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271A21F8BAD for ; Tue, 23 Aug 2011 11:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lscwGfwP2ykW for ; Tue, 23 Aug 2011 11:03:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFAB21F8BAB for ; Tue, 23 Aug 2011 11:03:38 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B9EFF1B4153B; Tue, 23 Aug 2011 14:04:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> Date: Tue, 23 Aug 2011 14:04:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:03:38 -0000 On Aug 23, 2011, at 11:46 AM, Thomas Narten wrote: > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. >=20 > The WG needs to focus on stuff that matters, and say "no" to > everything else. >=20 > Absent a real willingness to do this, splitting the WG up is nothing > more then rearranging the deck chairs... Fully agree. We should also keep in mind that, even if we do say "No" to a bunch of = things, there is *still* going to be a huge amount of work for the = Chairs to deal with, and they deserve some recognition and support for = handling this... W >=20 > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From rajiva@cisco.com Tue Aug 23 11:18:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FC21F8BD8 for ; Tue, 23 Aug 2011 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcaIuUmyi5fd for ; Tue, 23 Aug 2011 11:18:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AF24921F8B8A for ; Tue, 23 Aug 2011 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1808; q=dns/txt; s=iport; t=1314123593; x=1315333193; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7+KhAbfb+pAqNqGn+TbBIpW/yuxouc8WkSXhDpuvunA=; b=aV20XjOoTS4hV2h8xVkpz8JzymLOAHmoy1spkLOw89ILrvwivjQfHRSf J9Pud40DT5fyGZjdB5b4XlgNfERvCSEexHlQlR3bbjUaDa1SbkZNpjd/2 cvAYaBd2CgrWVE63jN3N363IK94UWJf1McTk76DcLEzNKPzO/C40GCb0V U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAEDuU06tJV2d/2dsb2JhbABCmBKPUneBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHU51LAZ9chWlfBIdhkE6MAg X-IronPort-AV: E=Sophos;i="4.68,270,1312156800"; d="scan'208";a="15777559" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2011 18:19:53 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7NIJqMM028978; Tue, 23 Aug 2011 18:19:52 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 13:19:52 -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 Date: Tue, 23 Aug 2011 13:19:51 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCAC6@XMB-RCD-111.cisco.com> In-Reply-To: <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: Acxhsilucsrw0kpvTdawYS9qU1tK5wADwNVg References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com><20110816141748.GF72014@Space.Net><067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com><4E4AEE2E.4030000@es.net><1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> From: "Rajiv Asati (rajiva)" To: "Thomas Narten" , "Scott Beuker" X-OriginalArrivalTime: 23 Aug 2011 18:19:52.0622 (UTC) FILETIME=[40893CE0:01CC61C1] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:18:45 -0000 Thomas, I started the ID already. Would appreciate the participation/contribution. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Tuesday, August 23, 2011 11:30 AM > To: Scott Beuker > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > > > What is wrong with retrying periodically? The point is to do this > > > every few tens of seconds, or every minute or two, so as to avoid > > > spending a lot of CPU on DAD. However, the desire is that layer 3 > > > be self healing once layer 2 has been fixed. IPv4 is self-healing > > > in this way. IPv6 is currently not. >=20 > > +1 >=20 > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. >=20 > What I'd suggest as a next step is that someone write a short ID that > describes the problem, and sketches out a recommended algorithm for > handling this situation. >=20 > E.g., use NS/ND probes to detect the condition, switch to periodic > probing mode when the interface is in loopback, and then describe > how/when to switch back to normal mode. >=20 > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. >=20 > We can then publish it as a short BCP or informational document (we > can figure out later which once the actual content has been worked > out). >=20 > Do we have a taker? >=20 > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Tue Aug 23 11:33:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF8B21F8BF0 for ; Tue, 23 Aug 2011 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZnwDXyqTRld for ; Tue, 23 Aug 2011 11:33:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DFB4321F8BEC for ; Tue, 23 Aug 2011 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2991; q=dns/txt; s=iport; t=1314124451; x=1315334051; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YNtu2VWB7GuQMsdxV2uLXrjk+0eZiKARZvnzvEMlPY8=; b=ANHMQeAD7HuB+PL9V7Wdf67L5axAxrS/8sL2C4sBPWxHvteZHaARs75u yjsRUWkjEVIh5XRSlcf+Q5jYHJkAZzmQcpmAAxwBPGi3Peh4PT+Oc0ws+ 12KfcXGE0OBIpHo+T4d9k/YhEwBH3nul50pPmwSAh+bvQATNLCbA9+Lr1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAM3xU06tJXG9/2dsb2JhbAA4CpgSj1J3gTkHAQEBAQECAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah1OdeQGfWIMngkJfBIcyL5BOjAI X-IronPort-AV: E=Sophos;i="4.68,270,1312156800"; d="scan'208";a="15783331" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2011 18:34:11 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7NIYAjM004374; Tue, 23 Aug 2011 18:34:10 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 13:34:10 -0500 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 Date: Tue, 23 Aug 2011 13:34:09 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwAAad+igAAmlnFA= References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> From: "Rajiv Asati (rajiva)" To: "STARK, BARBARA H (ATTSI)" , "Bernie Volz (volz)" , , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 18:34:10.0685 (UTC) FILETIME=[3FFB42D0:01CC61C3] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:33:03 -0000 IMO, it is na=EFve for a node to issue DHCPv6 SOLICIT without knowing = where to send it to. IOW, the node must know where the router is = reachable. Receiving RA is one sure way to resolve that, but not the = only way.=20 However, RFC 6204 doesn't list what other ways could be possible in W-3: W-3: Absent other routing information, the IPv6 CE router MUST use Router Discovery as specified in [RFC4861] to discover a default router(s) and install default route(s) in its routing table with the discovered router's address as the next hop. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > STARK, BARBARA H (ATTSI) > Sent: Tuesday, August 23, 2011 12:59 PM > To: Bernie Volz (volz); frnkblk@iname.com; IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > > http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf > > > > Section A.2 - the flowchart seems to show both running in parallel > > which > > seems to imply that a TR124 compatible device does not need an RA > (with > > M/O bits set) to start DHCPv6. > > > > Doing a quick look, I didn't see anything more that detailed the > > process. > > > > - Bernie >=20 > The flowchart in BBF TR-124i2 A.2 is mandatory/normative: > WAN.IPv6. 1 The device MUST support automated establishment of an IPv6 > connection according to the flow in Annex A.2. >=20 > Yes, in BBF we concluded that the quickest connectivity establishment = by > a CE router would be achieved through simultaneous RS and DHCPv6 > solicit, and we couldn't identify any good reason why this shouldn't = be > done. >=20 > As Ole mentioned on this thread, there are other ways to determine the > default route, so the RA often isn't even needed. >=20 > However... > As TR-124i2 A.2 is currently written, not getting the RA is a failure > case. It was so long ago, that I can't remember the discussion, but I > think that it was thought that there was nothing we knew of preventing = a > service provider from sending RA messages. This blocking of RA is > curious. But the flow chart A.2 seems pretty clear that the WAN IP > interface is considered "down" in the absence of an RA. I thought = there > had been discussion around changing that, but that is what the = published > doc says. [Note that since this doc was liaised to IETF with request = for > feedback, if any, I do consider discussion of this liaised doc to be a > valid topic, here. Thank you for the feedback.] >=20 > But to bring the discussion back to IETF docs... > Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message without > having received the RA (implicit in WPD-5), but it doesn't mandate = that > behavior. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From volz@cisco.com Tue Aug 23 11:49:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D287521F844F for ; Tue, 23 Aug 2011 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIwjoR8yPBLa for ; Tue, 23 Aug 2011 11:49:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88421F8438 for ; Tue, 23 Aug 2011 11:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3376; q=dns/txt; s=iport; t=1314125435; x=1315335035; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+nCh5x2nwyb54kKtrVzKiqLlyn9yGwSp+Vec9msy6wg=; b=C1MraZmDHUBbAacO6AYkBxwYUHV90/MFjXfJDW4quuDYHbg9pkuycwAN LM7rD04yZIU2goF7W4Z3BRgx1MMmpacN5MC6vl11gUhCH9tAwHhqe4YL7 VcdkYy7RMHbVC2yVPus7D2EXdiPWEWsh1UEXrfYLhc9BJYLjOVN/Np2U1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAO/1U06tJV2a/2dsb2JhbAA4CpgSj1J3gTkHAQEBAQECAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHU54FAZ9egyeCQl8EhzIvkE6MAg X-IronPort-AV: E=Sophos;i="4.68,270,1312156800"; d="scan'208";a="15788421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 23 Aug 2011 18:50:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7NIoYEK023023; Tue, 23 Aug 2011 18:50:34 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 13:50: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 13:50:33 -0500 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwAAad+igAAmlnFAAAL418A== References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> From: "Bernie Volz (volz)" To: "Rajiv Asati (rajiva)" , "STARK, BARBARA H (ATTSI)" , , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 18:50:34.0776 (UTC) FILETIME=[8A8BA180:01CC61C5] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:49:27 -0000 >where to send it Huh? A node always sends SOLICIT messages to ff02::1:2 so it knows = exactly where to send it. - Bernie -----Original Message----- From: Rajiv Asati (rajiva)=20 Sent: Tuesday, August 23, 2011 2:34 PM To: STARK, BARBARA H (ATTSI); Bernie Volz (volz); frnkblk@iname.com; = IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit IMO, it is na=EFve for a node to issue DHCPv6 SOLICIT without knowing = where to send it to. IOW, the node must know where the router is = reachable. Receiving RA is one sure way to resolve that, but not the = only way.=20 However, RFC 6204 doesn't list what other ways could be possible in W-3: W-3: Absent other routing information, the IPv6 CE router MUST use Router Discovery as specified in [RFC4861] to discover a default router(s) and install default route(s) in its routing table with the discovered router's address as the next hop. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > STARK, BARBARA H (ATTSI) > Sent: Tuesday, August 23, 2011 12:59 PM > To: Bernie Volz (volz); frnkblk@iname.com; IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > > http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf > > > > Section A.2 - the flowchart seems to show both running in parallel > > which > > seems to imply that a TR124 compatible device does not need an RA > (with > > M/O bits set) to start DHCPv6. > > > > Doing a quick look, I didn't see anything more that detailed the > > process. > > > > - Bernie >=20 > The flowchart in BBF TR-124i2 A.2 is mandatory/normative: > WAN.IPv6. 1 The device MUST support automated establishment of an IPv6 > connection according to the flow in Annex A.2. >=20 > Yes, in BBF we concluded that the quickest connectivity establishment = by > a CE router would be achieved through simultaneous RS and DHCPv6 > solicit, and we couldn't identify any good reason why this shouldn't = be > done. >=20 > As Ole mentioned on this thread, there are other ways to determine the > default route, so the RA often isn't even needed. >=20 > However... > As TR-124i2 A.2 is currently written, not getting the RA is a failure > case. It was so long ago, that I can't remember the discussion, but I > think that it was thought that there was nothing we knew of preventing = a > service provider from sending RA messages. This blocking of RA is > curious. But the flow chart A.2 seems pretty clear that the WAN IP > interface is considered "down" in the absence of an RA. I thought = there > had been discussion around changing that, but that is what the = published > doc says. [Note that since this doc was liaised to IETF with request = for > feedback, if any, I do consider discussion of this liaised doc to be a > valid topic, here. Thank you for the feedback.] >=20 > But to bring the discussion back to IETF docs... > Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message without > having received the RA (implicit in WPD-5), but it doesn't mandate = that > behavior. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Tue Aug 23 12:15:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3A121F8CE3 for ; Tue, 23 Aug 2011 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9AGoB15XwKa for ; Tue, 23 Aug 2011 12:15:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE521F8CE0 for ; Tue, 23 Aug 2011 12:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3996; q=dns/txt; s=iport; t=1314127009; x=1315336609; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=wqiBJR9D39y1pjviy6ph4fwgC+erlM9JTYWDPbx1fHY=; b=leQQA3vY6h6FWhiKGiNU54iv41JC+63StDB3sqA1ogItDTqXwa1bZuE0 m/2er/4CtccGLkW/QFbsH1ZVYS0fQB0jMla+zxU7sHfaf0pRNkUqQ40Tb uZmX/Xsfp9IAyR8pAA/xKcVEhMyZc0iaWOJRxuC8m1Pz4gliF1RDTbd4j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAFP8U06tJV2c/2dsb2JhbAA4CpgTj1J3gTkHAQEBAQECAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHU54QAZ9YgyeCQl8EhzIvkE6MAg X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15801244" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2011 19:16:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7NJGLjO028295; Tue, 23 Aug 2011 19:16:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:15:51 -0500 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 Date: Tue, 23 Aug 2011 14:15:50 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCB1B@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwAAad+igAAmlnFAAAL418AAA458Q References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Bernie Volz (volz)" , "STARK, BARBARA H (ATTSI)" , , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 19:15:51.0548 (UTC) FILETIME=[129CABC0:01CC61C9] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:15:41 -0000 It wasn't about the destination IP address, rather about selecting the = right port/interface (if there are 2+ interfaces on the node). Cheers, Rajiv > -----Original Message----- > From: Bernie Volz (volz) > Sent: Tuesday, August 23, 2011 2:51 PM > To: Rajiv Asati (rajiva); 'STARK, BARBARA H (ATTSI)'; = 'frnkblk@iname.com'; > 'IPv6 Operations' > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > >where to send it >=20 > Huh? A node always sends SOLICIT messages to ff02::1:2 so it knows = exactly > where to send it. >=20 > - Bernie >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) > Sent: Tuesday, August 23, 2011 2:34 PM > To: STARK, BARBARA H (ATTSI); Bernie Volz (volz); frnkblk@iname.com; = IPv6 > Operations > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > IMO, it is na=EFve for a node to issue DHCPv6 SOLICIT without knowing = where to > send it to. IOW, the node must know where the router is reachable. = Receiving > RA is one sure way to resolve that, but not the only way. >=20 > However, RFC 6204 doesn't list what other ways could be possible in = W-3: >=20 >=20 > W-3: Absent other routing information, the IPv6 CE router MUST use > Router Discovery as specified in [RFC4861] to discover a > default router(s) and install default route(s) in its routing > table with the discovered router's address as the next hop. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of > > STARK, BARBARA H (ATTSI) > > Sent: Tuesday, August 23, 2011 12:59 PM > > To: Bernie Volz (volz); frnkblk@iname.com; IPv6 Operations > > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > > > > = http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf > > > > > > Section A.2 - the flowchart seems to show both running in parallel > > > which > > > seems to imply that a TR124 compatible device does not need an RA > > (with > > > M/O bits set) to start DHCPv6. > > > > > > Doing a quick look, I didn't see anything more that detailed the > > > process. > > > > > > - Bernie > > > > The flowchart in BBF TR-124i2 A.2 is mandatory/normative: > > WAN.IPv6. 1 The device MUST support automated establishment of an = IPv6 > > connection according to the flow in Annex A.2. > > > > Yes, in BBF we concluded that the quickest connectivity = establishment by > > a CE router would be achieved through simultaneous RS and DHCPv6 > > solicit, and we couldn't identify any good reason why this shouldn't = be > > done. > > > > As Ole mentioned on this thread, there are other ways to determine = the > > default route, so the RA often isn't even needed. > > > > However... > > As TR-124i2 A.2 is currently written, not getting the RA is a = failure > > case. It was so long ago, that I can't remember the discussion, but = I > > think that it was thought that there was nothing we knew of = preventing a > > service provider from sending RA messages. This blocking of RA is > > curious. But the flow chart A.2 seems pretty clear that the WAN IP > > interface is considered "down" in the absence of an RA. I thought = there > > had been discussion around changing that, but that is what the = published > > doc says. [Note that since this doc was liaised to IETF with request = for > > feedback, if any, I do consider discussion of this liaised doc to be = a > > valid topic, here. Thank you for the feedback.] > > > > But to bring the discussion back to IETF docs... > > Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message = without > > having received the RA (implicit in WPD-5), but it doesn't mandate = that > > behavior. > > Barbara > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From volz@cisco.com Tue Aug 23 12:18:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2F721F8CFC for ; Tue, 23 Aug 2011 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34Vm0sASogGN for ; Tue, 23 Aug 2011 12:18:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FD21F8CF7 for ; Tue, 23 Aug 2011 12:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=4336; q=dns/txt; s=iport; t=1314127173; x=1315336773; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=WDPW7zvcsHQTGV7DgIhgvQVLonVv2fWbp5Y/qTVZXEM=; b=GCMNb/KLseXS9y98NYK0uk4n9sTw+MjboYdrCoTMURXklk868G6vDgOr W0xVzQHkRyaSuzqu5dnbUoQlBCW5F6i0wJn3tF+/yhCEM5jhmmpKkkLKV WnZ4iET8uYkpZusQ7fcLHchtp/mpPi+g5X9gE4dwiQHDh/CMIF1Olqq8W 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAA/8U06tJV2d/2dsb2JhbAA4CpgTj1J3gTkHAQEBAQECAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHU54QAZ9YgyeCQl8EhzIvkE6MAg X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15799198" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 23 Aug 2011 19:19:33 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7NJJWWL025410; Tue, 23 Aug 2011 19:19:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:19:24 -0500 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 Date: Tue, 23 Aug 2011 14:19:20 -0500 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCB1B@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhHToTEGG4SJJsQregMAyjwJPGggADJwXQAACMWrAAAXwbwAAad+igAAmlnFAAAL418AAA458QAAAjW3A= References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB1B@XMB-RCD-111.cisco.com> From: "Bernie Volz (volz)" To: "Rajiv Asati (rajiva)" , "STARK, BARBARA H (ATTSI)" , , "IPv6 Operations" X-OriginalArrivalTime: 23 Aug 2011 19:19:24.0726 (UTC) FILETIME=[91AD0D60:01CC61C9] Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:18:25 -0000 For some devices it is obvious ... like for a device with a WAN = interface. -----Original Message----- From: Rajiv Asati (rajiva)=20 Sent: Tuesday, August 23, 2011 3:16 PM To: Bernie Volz (volz); 'STARK, BARBARA H (ATTSI)'; 'frnkblk@iname.com'; = 'IPv6 Operations' Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit It wasn't about the destination IP address, rather about selecting the = right port/interface (if there are 2+ interfaces on the node). Cheers, Rajiv > -----Original Message----- > From: Bernie Volz (volz) > Sent: Tuesday, August 23, 2011 2:51 PM > To: Rajiv Asati (rajiva); 'STARK, BARBARA H (ATTSI)'; = 'frnkblk@iname.com'; > 'IPv6 Operations' > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > >where to send it >=20 > Huh? A node always sends SOLICIT messages to ff02::1:2 so it knows = exactly > where to send it. >=20 > - Bernie >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) > Sent: Tuesday, August 23, 2011 2:34 PM > To: STARK, BARBARA H (ATTSI); Bernie Volz (volz); frnkblk@iname.com; = IPv6 > Operations > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > IMO, it is na=EFve for a node to issue DHCPv6 SOLICIT without knowing = where to > send it to. IOW, the node must know where the router is reachable. = Receiving > RA is one sure way to resolve that, but not the only way. >=20 > However, RFC 6204 doesn't list what other ways could be possible in = W-3: >=20 >=20 > W-3: Absent other routing information, the IPv6 CE router MUST use > Router Discovery as specified in [RFC4861] to discover a > default router(s) and install default route(s) in its routing > table with the discovered router's address as the next hop. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of > > STARK, BARBARA H (ATTSI) > > Sent: Tuesday, August 23, 2011 12:59 PM > > To: Bernie Volz (volz); frnkblk@iname.com; IPv6 Operations > > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > > > > = http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf > > > > > > Section A.2 - the flowchart seems to show both running in parallel > > > which > > > seems to imply that a TR124 compatible device does not need an RA > > (with > > > M/O bits set) to start DHCPv6. > > > > > > Doing a quick look, I didn't see anything more that detailed the > > > process. > > > > > > - Bernie > > > > The flowchart in BBF TR-124i2 A.2 is mandatory/normative: > > WAN.IPv6. 1 The device MUST support automated establishment of an = IPv6 > > connection according to the flow in Annex A.2. > > > > Yes, in BBF we concluded that the quickest connectivity = establishment by > > a CE router would be achieved through simultaneous RS and DHCPv6 > > solicit, and we couldn't identify any good reason why this shouldn't = be > > done. > > > > As Ole mentioned on this thread, there are other ways to determine = the > > default route, so the RA often isn't even needed. > > > > However... > > As TR-124i2 A.2 is currently written, not getting the RA is a = failure > > case. It was so long ago, that I can't remember the discussion, but = I > > think that it was thought that there was nothing we knew of = preventing a > > service provider from sending RA messages. This blocking of RA is > > curious. But the flow chart A.2 seems pretty clear that the WAN IP > > interface is considered "down" in the absence of an RA. I thought = there > > had been discussion around changing that, but that is what the = published > > doc says. [Note that since this doc was liaised to IETF with request = for > > feedback, if any, I do consider discussion of this liaised doc to be = a > > valid topic, here. Thank you for the feedback.] > > > > But to bring the discussion back to IETF docs... > > Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message = without > > having received the RA (implicit in WPD-5), but it doesn't mandate = that > > behavior. > > Barbara > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Tue Aug 23 12:19:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC121F8CFC for ; Tue, 23 Aug 2011 12:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmR9CzzsY01e for ; Tue, 23 Aug 2011 12:19:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 557CC21F8D0B for ; Tue, 23 Aug 2011 12:19:22 -0700 (PDT) Received: by wwf5 with SMTP id 5so323125wwf.13 for ; Tue, 23 Aug 2011 12:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=Wec3KuMnvNvS2E4prggCJg8PbfqjF5WSZdofcFyD200=; b=UofIynZ+92ZeJmtPxfzW6xZDW0ZxLsZe1HEw6CPLqUjwS79b2qAOd6lUBlI/P0vR6p wSZ6Zff66QIuiULJ0aRbXHnhyGYiaVEnxjf8/wlUHJHemaMyxLiUZNRKzc7vqyqTxkY2 JUJwuNen+Xt4+J2g/tnJkT5grZgOfKYZzf3Bk= Received: by 10.227.209.21 with SMTP id ge21mr605704wbb.42.1314127228231; Tue, 23 Aug 2011 12:20:28 -0700 (PDT) Received: from ams3-vpn-dhcp7760.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fg5sm229095wbb.6.2011.08.23.12.20.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 12:20:27 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan In-Reply-To: Date: Tue, 23 Aug 2011 21:20:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C048EEA-D14B-4827-9139-6434C213B3D2@employees.org> References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB1B@XMB-RCD-111.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:19:23 -0000 > For some devices it is obvious ... like for a device with a WAN = interface. indeed, and that's the whole model for RFC6204. cheers, Ole >=20 > -----Original Message----- > From: Rajiv Asati (rajiva)=20 > Sent: Tuesday, August 23, 2011 3:16 PM > To: Bernie Volz (volz); 'STARK, BARBARA H (ATTSI)'; = 'frnkblk@iname.com'; 'IPv6 Operations' > Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > It wasn't about the destination IP address, rather about selecting the = right port/interface (if there are 2+ interfaces on the node). >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Tuesday, August 23, 2011 2:51 PM >> To: Rajiv Asati (rajiva); 'STARK, BARBARA H (ATTSI)'; = 'frnkblk@iname.com'; >> 'IPv6 Operations' >> Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >>=20 >>> where to send it >>=20 >> Huh? A node always sends SOLICIT messages to ff02::1:2 so it knows = exactly >> where to send it. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: Rajiv Asati (rajiva) >> Sent: Tuesday, August 23, 2011 2:34 PM >> To: STARK, BARBARA H (ATTSI); Bernie Volz (volz); frnkblk@iname.com; = IPv6 >> Operations >> Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit >>=20 >> IMO, it is na=EFve for a node to issue DHCPv6 SOLICIT without knowing = where to >> send it to. IOW, the node must know where the router is reachable. = Receiving >> RA is one sure way to resolve that, but not the only way. >>=20 >> However, RFC 6204 doesn't list what other ways could be possible in = W-3: >>=20 >>=20 >> W-3: Absent other routing information, the IPv6 CE router MUST use >> Router Discovery as specified in [RFC4861] to discover a >> default router(s) and install default route(s) in its routing >> table with the discovered router's address as the next hop. >>=20 >> Cheers, >> Rajiv >>=20 >>=20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >>> STARK, BARBARA H (ATTSI) >>> Sent: Tuesday, August 23, 2011 12:59 PM >>> To: Bernie Volz (volz); frnkblk@iname.com; IPv6 Operations >>> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >>>=20 >>>> = http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf >>>>=20 >>>> Section A.2 - the flowchart seems to show both running in parallel >>>> which >>>> seems to imply that a TR124 compatible device does not need an RA >>> (with >>>> M/O bits set) to start DHCPv6. >>>>=20 >>>> Doing a quick look, I didn't see anything more that detailed the >>>> process. >>>>=20 >>>> - Bernie >>>=20 >>> The flowchart in BBF TR-124i2 A.2 is mandatory/normative: >>> WAN.IPv6. 1 The device MUST support automated establishment of an = IPv6 >>> connection according to the flow in Annex A.2. >>>=20 >>> Yes, in BBF we concluded that the quickest connectivity = establishment by >>> a CE router would be achieved through simultaneous RS and DHCPv6 >>> solicit, and we couldn't identify any good reason why this shouldn't = be >>> done. >>>=20 >>> As Ole mentioned on this thread, there are other ways to determine = the >>> default route, so the RA often isn't even needed. >>>=20 >>> However... >>> As TR-124i2 A.2 is currently written, not getting the RA is a = failure >>> case. It was so long ago, that I can't remember the discussion, but = I >>> think that it was thought that there was nothing we knew of = preventing a >>> service provider from sending RA messages. This blocking of RA is >>> curious. But the flow chart A.2 seems pretty clear that the WAN IP >>> interface is considered "down" in the absence of an RA. I thought = there >>> had been discussion around changing that, but that is what the = published >>> doc says. [Note that since this doc was liaised to IETF with request = for >>> feedback, if any, I do consider discussion of this liaised doc to be = a >>> valid topic, here. Thank you for the feedback.] >>>=20 >>> But to bring the discussion back to IETF docs... >>> Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message = without >>> having received the RA (implicit in WPD-5), but it doesn't mandate = that >>> behavior. >>> Barbara >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Tue Aug 23 12:38:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E620B21F8C35 for ; Tue, 23 Aug 2011 12:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.637 X-Spam-Level: X-Spam-Status: No, score=-106.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjLwS-QQkn3O for ; Tue, 23 Aug 2011 12:38:46 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E521F8C1C for ; Tue, 23 Aug 2011 12:38:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LQE00MA4BXSN0Y0@mail-out.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 12:39:28 -0700 (PDT) X-AuditID: 11807137-b7c4bae0000013e5-05-4e54030b1331 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 73.CF.05093.B03045E4; Tue, 23 Aug 2011 12:44:11 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQE00BTPBXRU830@koseret.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 12:39:28 -0700 (PDT) From: james woodyatt In-reply-to: <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> Date: Tue, 23 Aug 2011 12:39:27 -0700 Message-id: <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OXZebOcTPYM8XDovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro7PrAGvBMbaKn+vvMzYwrmTtYuTkkBAwkdj+oocNwhaTuHBv PZDNxSEk0Mkk8X5dDwtIgldAUOLH5HtANgcHs4C8xMHzsiBhZgEtie+PWlkg6qcwSRzY2wc2 SFjAVuLV74OMIDabgIrEt8t3mUB6OQV8JRZPdQcJswioSpxe+40VYqSKxP8GfohNNhIXv76F GvmESeLL6wVgJ4gIaEvMOvOOHeJOeYnFLZ8ZJzAKzEJy3SyE62YhuW4BI/MqRsGi1JzESkMz vcSCgpxUveT83E2MoLBrKDTfwbj9r9whRgEORiUe3qZzwX5CrIllxZW5hxglOJiVRHifXQAK 8aYkVlalFuXHF5XmpBYfYpTmYFES5914I8hPSCA9sSQ1OzW1ILUIJsvEwSnVwKhbGHbASuX4 5UtXJ1fGyYQc1prJnGMgIu2TsnbXxt7N2f/0z96V+rDeX2HapDXNl0vMeks+Fjf5KBx6f1rA rNKIddndn5bhPw0CFvO6Z2jlFgY+mztRdb/oHU9G7fUcDZW868QF2loUmXeUTYlONS9KFD38 pbtDNujk+mL5vS2eYokVW9epKbEUZyQaajEXFScCAKOEH2w3AgAA Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:38:47 -0000 On Aug 23, 2011, at 11:34 , Rajiv Asati (rajiva) wrote: > > However, RFC 6204 doesn't list what other ways could be possible in W-3 Consider the case where the WAN interface is attached to a point-to-point link. For a residential gateway device, it's probably a reasonable assumption that the other end of such a link is always a default router. For a multi-purpose gateway device, however, it's not be a reasonable assumption that the other end of an otherwise unidentifiable point-to-point link is a default router. Hence, the express permission for a residential gateway, which may happen to be a multi-function device deployed in a residential setting, to wait for a router advertisement before proceeding to the DHCPv6 solicit. -- james woodyatt member of technical staff, core os networking From rajiva@cisco.com Tue Aug 23 12:45:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E31C21F85AB for ; Tue, 23 Aug 2011 12:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuZM5ClUY7Z6 for ; Tue, 23 Aug 2011 12:45:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CCB1F21F85A4 for ; Tue, 23 Aug 2011 12:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2086; q=dns/txt; s=iport; t=1314128815; x=1315338415; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wp/e3LWo1MErpUgnbVGeW/uRiwnPzo7DCcm3vfuqOF4=; b=fB6id0iwpFxZ0BZW1aeHi/AjaVZBJestgaM4SP69VpslX8+UKpVaFSMz 5G3WeCaoHU89PFIUThs2ARPCUTh9NpZKKx/jFlt89KyxukMZkqrk0Z4Tg 9k80uTWlgTK6bdEkiVFMmQWtKAGTDsQJJBLp5pW0Gi3B7MpZ7047Y4Rlm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAGUDVE6tJV2a/2dsb2JhbABCmBOPUneBOQcBAQEBAgESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah0+eFQGfUYVpXwSHYZBOjAI X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15814486" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 23 Aug 2011 19:46:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7NJktbN017185; Tue, 23 Aug 2011 19:46:55 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:46: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 Date: Tue, 23 Aug 2011 14:46:54 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> In-Reply-To: <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhzHLefZRBQ7bsSgiDoQDVBd3l/wAABuZA References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> From: "Rajiv Asati (rajiva)" To: "james woodyatt" X-OriginalArrivalTime: 23 Aug 2011 19:46:55.0124 (UTC) FILETIME=[6963CD40:01CC61CD] Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:45:47 -0000 James, > Consider the case where the WAN interface is attached to a point-to-point > link. For a residential gateway device, it's probably a reasonable assumption > that the other end of such a link is always a default router. Sure. And xDSL would well qualify as that point-to-point WAN interface. Can we make that assumption for Wireless and Cable/DOCSIS?=20 > For a multi-purpose gateway device, however, it's not be a reasonable > assumption that the other end of an otherwise unidentifiable point-to-point > link is a default router. Hence, the express permission for a residential > gateway, which may happen to be a multi-function device deployed in a > residential setting, to wait for a router advertisement before proceeding to > the DHCPv6 solicit. Agreed. That's surely the de facto method. BTW, do we allow static config of the next-hop router for triggering the DHCPv6 solicit? Cheers, Rajiv > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com] > Sent: Tuesday, August 23, 2011 3:39 PM > To: Rajiv Asati (rajiva) > Cc: IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > On Aug 23, 2011, at 11:34 , Rajiv Asati (rajiva) wrote: > > > > However, RFC 6204 doesn't list what other ways could be possible in W-3 >=20 > Consider the case where the WAN interface is attached to a point-to-point > link. For a residential gateway device, it's probably a reasonable assumption > that the other end of such a link is always a default router. >=20 > For a multi-purpose gateway device, however, it's not be a reasonable > assumption that the other end of an otherwise unidentifiable point-to-point > link is a default router. Hence, the express permission for a residential > gateway, which may happen to be a multi-function device deployed in a > residential setting, to wait for a router advertisement before proceeding to > the DHCPv6 solicit. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 From Fred.L.Templin@boeing.com Tue Aug 23 12:59:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55DE21F8CEF for ; Tue, 23 Aug 2011 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87aXcthal2wx for ; Tue, 23 Aug 2011 12:59:47 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5FA21F853E for ; Tue, 23 Aug 2011 12:59:47 -0700 (PDT) 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 p7NK0kR6014173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Aug 2011 15:00:51 -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 p7NK0jLK010964 for ; Tue, 23 Aug 2011 15:00:45 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p7NK08FL008374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 23 Aug 2011 15:00:44 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 23 Aug 2011 13:00:23 -0700 From: "Templin, Fred L" CC: IPv6 Operations Date: Tue, 23 Aug 2011 13:00:22 -0700 Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxhzHLefZRBQ7bsSgiDoQDVBd3l/wAABuZAAABvoWA= Message-ID: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.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 Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:59:47 -0000 AFAICT, the RA 'M' bit is just one way the RG can learn that stateful services are available. If the RG has some other way of knowing that stateful services are available, then I don't see a problem for it to invoke DHCPv6 whether or not it ever gets an RA. Do I have that right? Thanks - Fred fred.l.templin@boeing.com= From wwwrun@rfc-editor.org Tue Aug 23 13:03:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416B321F8D00; Tue, 23 Aug 2011 13:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYyzJLIR0N0d; Tue, 23 Aug 2011 13:03:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8F63A21F8CEF; Tue, 23 Aug 2011 13:03:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4EAF498C253; Tue, 23 Aug 2011 13:04:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110823200431.4EAF498C253@rfc-editor.org> Date: Tue, 23 Aug 2011 13:04:28 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6324 on Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:03:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6324 Title: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations Author: G. Nakibly, F. Templin Status: Informational Stream: IETF Date: August 2011 Mailbox: gnakibly@yahoo.com, fltemplin@acm.org Pages: 19 Characters: 47385 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-tunnel-loops-07.txt URL: http://www.rfc-editor.org/rfc/rfc6324.txt This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jhw@apple.com Tue Aug 23 13:04:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82A21F8D24 for ; Tue, 23 Aug 2011 13:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.636 X-Spam-Level: X-Spam-Status: No, score=-106.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWGPQ+RXWlO9 for ; Tue, 23 Aug 2011 13:04:05 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B653D21F8D23 for ; Tue, 23 Aug 2011 13:04:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LQE00MRDD4GN0Z0@mail-out.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 13:05:14 -0700 (PDT) X-AuditID: 11807136-b7c35ae000001055-2c-4e540b140587 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 71.B2.04181.41B045E4; Tue, 23 Aug 2011 13:18:28 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQE009QND4PS160@kencur.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 13:05:14 -0700 (PDT) From: james woodyatt In-reply-to: <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> Date: Tue, 23 Aug 2011 13:05:13 -0700 Message-id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUiON1OTVeEO8TPoPWNqsXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMf8hS8F6joqOLSdYGhifs3UxcnJICJhITN23kxXCFpO4cG89 WFxIoJ1JovWtEIjNKyAo8WPyPZYuRg4OZgF5iYPnZUHCzAJaEt8ftbJAlE9gkli3hRnEFhaw lXj1+yAjiM0moCLx7fJdJpBWTgFfiTPH+UDCLAKqElOfLWCFmKgi8b+BH2KRjcSxK3OBqrmA Jt5ilmh785MdJCEioC0x68w7dogr5SUWt3xmnMAoMAvJcbMQjpuF5LgFjMyrGAWLUnMSKw1N 9RILCnJS9ZLzczcxggKuodBsB+OOv3KHGAU4GJV4eG9cCPYTYk0sK67MPcQowcGsJML7DCTE m5JYWZValB9fVJqTWnyIUZqDRUmcd+WtID8hgfTEktTs1NSC1CKYLBMHp1QD46qKxxMPtS7R 87i0bsYFsVVHLBYt/XXEL25/oJTGjO5Iq/8/niySFZi2IDdQbuklVu8fQlLr1/yTntQrfbiT tbrs+QqrZ4cthP/lZ8Qb7Ft4ap/vrcx/lzg0eEycFX13ywr3TrfcOr0gW2ZC08TwWYpqsxL+ H7X4cYtNX/uT3hRm+dgDAgfmRSixFGckGmoxFxUnAgDtBOObNAIAAA== Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:04:06 -0000 On Aug 23, 2011, at 12:46 , Rajiv Asati (rajiva) wrote: > > do we allow static config of the next-hop router for triggering the DHCPv6 solicit? Yes, we allow that. We neither forbid it with "MUST NOT" keywords, nor require any conflicting contingency condition with a "MUST" keyword, in any standards track documents. The correct answer to the question in the subject line is "when the RG has a reasonable expectation that its DHCPv6 Solicit multicasts will welcomed on the network." Receiving an M=1 or O=1 in a Router Advertisement is one way of confirming that a DHCPv6 Solicit is welcome on the network. RFC 6204 mainly addressed to the implementers of dedicated residential gateways. One of my complaints about that document is that it isn't really suitable for more general application, i.e. for implementers of multi-purpose gateways that can be used in residential settings, which are still quite common in some markets. I was in the minority about that. -- james woodyatt member of technical staff, core os networking From frnkblk@iname.com Tue Aug 23 13:18:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B215B21F8C0F for ; Tue, 23 Aug 2011 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEO7M2zdbWCp for ; Tue, 23 Aug 2011 13:18:30 -0700 (PDT) Received: from premieronline.net (mail.premieronline.net [96.31.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 23E7621F8BDC for ; Tue, 23 Aug 2011 13:18:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30262934-1729245 for multiple; Tue, 23 Aug 2011 15:19:36 -0500 From: "Frank Bulk" To: "'Templin, Fred L'" References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> In-Reply-To: Date: Tue, 23 Aug 2011 15:19:35 -0500 Message-ID: <000501cc61d1$f9b74b20$ed25e160$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxhzHLefZRBQ7bsSgiDoQDVBd3l/wAABuZAAABvoWAAAN39sA== Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=13 Friend=765 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 899, in=14019046, out=65744, spam=0 Known=true ip=199.120.69.26 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:18:30 -0000 The RG doesn't need it to be stateful for DHCPv6 to be triggered. The RFC allow for DHCPv6 Solicit on an O=1. And TR-124i2 without an RA at all. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Tuesday, August 23, 2011 3:00 PM Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit AFAICT, the RA 'M' bit is just one way the RG can learn that stateful services are available. If the RG has some other way of knowing that stateful services are available, then I don't see a problem for it to invoke DHCPv6 whether or not it ever gets an RA. Do I have that right? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Tue Aug 23 13:22:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53A921F8D08 for ; Tue, 23 Aug 2011 13:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa8hmwQSbLUq for ; Tue, 23 Aug 2011 13:22:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E11A421F8CE7 for ; Tue, 23 Aug 2011 13:22:22 -0700 (PDT) Received: by wyg8 with SMTP id 8so428315wyg.31 for ; Tue, 23 Aug 2011 13:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=otg8FRGWa28Byo6Ef3X8YxJr+RjjzexftuUEkFsFtx4=; b=RxY5t2NL8lFV1WK6ze9f6M7q0/MHHdSkKwZdYM/G08y/X5ZLZ+q3cqxDMXr/f4iyTY v1qiVU5O/a15VQtfp2cKiGQCRqhQYnPRVi5hke3OJxXVrPVr7bv2A0or5eZr8mLzDEUn Op0tGgf8zmBhwnbmrkol6mb+iY8pCFbyCjcLc= Received: by 10.227.208.132 with SMTP id gc4mr650479wbb.48.1314131010826; Tue, 23 Aug 2011 13:23:30 -0700 (PDT) Received: from ams3-vpn-dhcp7760.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id el9sm263397wbb.41.2011.08.23.13.23.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 13:23:30 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <000501cc61d1$f9b74b20$ed25e160$@iname.com> Date: Tue, 23 Aug 2011 22:23:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> <000501cc61d1$f9b74b20$ed25e160$@iname.com> To: frnkblk@iname.com X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:22:23 -0000 > The RG doesn't need it to be stateful for DHCPv6 to be triggered. The RFC > allow for DHCPv6 Solicit on an O=1. > > And TR-124i2 without an RA at all. as does RFC3633. cheers, Ole > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Tuesday, August 23, 2011 3:00 PM > Cc: IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > AFAICT, the RA 'M' bit is just one way the RG can > learn that stateful services are available. If the > RG has some other way of knowing that stateful > services are available, then I don't see a problem > for it to invoke DHCPv6 whether or not it ever gets > an RA. Do I have that right? > > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Aug 23 13:50:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE44A21F8CDF for ; Tue, 23 Aug 2011 13:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDyWy2UNwrcJ for ; Tue, 23 Aug 2011 13:50:03 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD421F8CD2 for ; Tue, 23 Aug 2011 13:50:03 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p7NKp5tL022145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Aug 2011 15:51:08 -0500 (CDT) 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 p7NKp5mp029118; Tue, 23 Aug 2011 13:51:05 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p7NKp5GD029104 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Aug 2011 13:51:05 -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; Tue, 23 Aug 2011 13:51:05 -0700 From: "Templin, Fred L" To: Ole Troan , "frnkblk@iname.com" Date: Tue, 23 Aug 2011 13:51:03 -0700 Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: Acxh0oxetSq5nEX4QUuaNLUm1Eof4QAAtnqg Message-ID: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> <000501cc61d1$f9b74b20$ed25e160$@iname.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 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:50:04 -0000 Right - I forgot about stateless as well as stateful. Still, if no RS/RA exchange takes place I think the RG should at least have some inkling that the service is available. Either that, or the RG should be able to deal with failure if it blindly invokes the service and gets no reply. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 > Ole Troan > Sent: Tuesday, August 23, 2011 1:23 PM > To: frnkblk@iname.com > Cc: Templin, Fred L; IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > > The RG doesn't need it to be stateful for DHCPv6 to be=20 > triggered. The RFC > > allow for DHCPv6 Solicit on an O=3D1. =20 > >=20 > > And TR-124i2 without an RA at all. >=20 > as does RFC3633. >=20 > cheers, > Ole >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of > > Templin, Fred L > > Sent: Tuesday, August 23, 2011 3:00 PM > > Cc: IPv6 Operations > > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > >=20 > > AFAICT, the RA 'M' bit is just one way the RG can > > learn that stateful services are available. If the > > RG has some other way of knowing that stateful > > services are available, then I don't see a problem > > for it to invoke DHCPv6 whether or not it ever gets > > an RA. Do I have that right? > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From brian.e.carpenter@gmail.com Tue Aug 23 14:04:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBEC21F8D2E for ; Tue, 23 Aug 2011 14:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.293 X-Spam-Level: X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOWjQp5QX6Uj for ; Tue, 23 Aug 2011 14:04:06 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9C4B21F8D2D for ; Tue, 23 Aug 2011 14:04:06 -0700 (PDT) Received: by qyk34 with SMTP id 34so2297013qyk.10 for ; Tue, 23 Aug 2011 14:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=H+jHrnATmEIhPP9qaP42Wuv1+THX1uC4y5DFV0+T8N8=; b=oCDJY5+XhiYFyKqsvJ8R/wSFdNZ1HJY18GhJfUm9s836H6XVMQ5cTI7ZoyuvPawlHs pP0dSdoHV2YnlIMeKdNyy3WZRXkXG6+vDY/eZRmMC/rVipwZRRzw7QSFtuw8IniPgNy+ U4QczrZIwtTP48z/PKMp4V73oEBG17FCuuWEo= Received: by 10.229.101.164 with SMTP id c36mr2772070qco.74.1314133513409; Tue, 23 Aug 2011 14:05:13 -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 a18sm222106qcu.5.2011.08.23.14.05.10 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 14:05:12 -0700 (PDT) Message-ID: <4E541604.9090201@gmail.com> Date: Wed, 24 Aug 2011 09:05:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:04:07 -0000 +1. I just said something similar on softwires. Regards Brian On 2011-08-24 03:46, Thomas Narten wrote: > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. > > The WG needs to focus on stuff that matters, and say "no" to > everything else. > > Absent a real willingness to do this, splitting the WG up is nothing > more then rearranging the deck chairs... > > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From dart@es.net Tue Aug 23 14:15:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2D21F8634 for ; Tue, 23 Aug 2011 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItT51dLcw-sT for ; Tue, 23 Aug 2011 14:15:35 -0700 (PDT) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0121F8D5C for ; Tue, 23 Aug 2011 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=bDkvmIrWy1pUsKUxiVa2XqydThYJz/63TVOEWQovlhw=; b=Bo1ICsxpi/4tsBaxc3NVD1vXwVqKngc8pe3p3aOY0GYwLEAhAxkDbT3kM+5yxuTJSlCy lXgTWOqpJZWSwyoWND4C01IHvA+IBUXZ6OARRQZUHfaeBSO1coq39roRDP63gXbj3mZM TGt9G5hVRLQ9C1krn4TpzZXynIcebKeRzsU= Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.26.60]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7NLGeVm031602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2011 14:16:41 -0700 Message-ID: <4E5418B8.9020705@es.net> Date: Tue, 23 Aug 2011 14:16:40 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com><20110816141748.GF72014@Space.Net><067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com><4E4AEE2E.4030000@es.net><1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> <067E6CE33034954AAC05C9EC85E2577C05BBCAC6@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCAC6@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-23_09:2011-08-23, 2011-08-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108230261 Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dart@es.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:15:36 -0000 Hi Rajiv, On 8/23/11 11:19 AM, Rajiv Asati (rajiva) wrote: > Thomas, > > I started the ID already. Would appreciate the > participation/contribution. OK - sounds fine. Thanks, --eli > > Cheers, > Rajiv > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of >> Thomas Narten >> Sent: Tuesday, August 23, 2011 11:30 AM >> To: Scott Beuker >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >> >>>> What is wrong with retrying periodically? The point is to do this >>>> every few tens of seconds, or every minute or two, so as to avoid >>>> spending a lot of CPU on DAD. However, the desire is that layer 3 >>>> be self healing once layer 2 has been fixed. IPv4 is self-healing >>>> in this way. IPv6 is currently not. >> >>> +1 >> >> I agree. The other thing to keep in mind is that if an interface is in >> loopback mode, the interface is effectively not working (i.e,. not >> forwarding traffic), and any "load" caused by such probes is >> pretty much irrelevant. >> >> What I'd suggest as a next step is that someone write a short ID that >> describes the problem, and sketches out a recommended algorithm for >> handling this situation. >> >> E.g., use NS/ND probes to detect the condition, switch to periodic >> probing mode when the interface is in loopback, and then describe >> how/when to switch back to normal mode. >> >> This appears to be doable using existing packet/option formats, so no >> new protocol extensions are needed. >> >> We can then publish it as a short BCP or informational document (we >> can figure out later which once the actual content has been worked >> out). >> >> Do we have a taker? >> >> Thomas >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From jhw@apple.com Tue Aug 23 14:15:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEE821F8C60 for ; Tue, 23 Aug 2011 14:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.635 X-Spam-Level: X-Spam-Status: No, score=-106.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1bI1++oxbqQ for ; Tue, 23 Aug 2011 14:15:51 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6213F21F8C4A for ; Tue, 23 Aug 2011 14:15:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQE00FO8FI0L7H0@mail-out.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 14:16:59 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-d2-4e54172a7876 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id D4.89.05328.B27145E4; Tue, 23 Aug 2011 14:10:03 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQE001P6GG9KR00@kencur.apple.com> for v6ops@ietf.org; Tue, 23 Aug 2011 14:16:57 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 23 Aug 2011 14:16:57 -0700 Message-id: <085249EE-B201-49A4-8A5D-F4FCB1A988AA@apple.com> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> <000501cc61d1$f9b74b20$ed25e160$@iname.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OTVdbPMTPoOm5hcXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXXBGtaCdtaKuV8esTQwtrJ0MXJySAiYSPQ3nWeEsMUkLtxb z9bFyMUhJNDOJNGz6BVYgldAUOLH5HtADRwczALyEgfPy4KEmQW0JL4/ApkDUj+BSeL3nylg 9cICthKvfh8Es9kEVCS+Xb7LBGJzCkRIXN7RxA4yh0VAVWL7xyiIOYUSc65NZoZYZSOx4coN JoiZ11klXv1cCpYQETCUaDz3lhXiUHmJxS2fGScwCsxCct4shPNmITlvASPzKkbBotScxEpD E73EgoKcVL3k/NxNjKDAayg02cF48Cf/IUYBDkYlHl7NM8F+QqyJZcWVuYcYJTiYlUR4v/KE +AnxpiRWVqUW5ccXleakFh9ilOZgURLn/X81yE9IID2xJDU7NbUgtQgmy8TBKdXAKOfP57XS cfLdC3b7WF18WTiN/uxqjnlzweWI3owlHF9uH9xyYv8Cuz/3ujbrf0haqiNcE6eYJvtAmknu 7jq2RbsbnD0Y299wfTW/9C5aMWzzLoPqzYaFfFVGi3UZnm4+1Co661m28os5/GdzPdO/Hq4y T3zyO2uBksH2BysXXk1sZvw68yJHihJLcUaioRZzUXEiAD37bSE4AgAA Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:15:52 -0000 On Aug 23, 2011, at 13:51 , Templin, Fred L wrote: > > Either that, or the RG should be able to deal with failure if it blindly invokes the service and gets no reply. Yeah. The way the BBF has written their specifications, the way I'm going to "deal with failure" is to keep retrying forever. The specification doesn't give me any alternative. Don't plug residential gateways into networks where DHCPv6 solicits are unwelcome. The network administrators will disable your port, and there isn't anything I can do about it. Thanks for playing. -- james woodyatt member of technical staff, core os networking From frnkblk@iname.com Tue Aug 23 15:24:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3AF21F8C2A for ; Tue, 23 Aug 2011 15:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2KOevmwH1EU for ; Tue, 23 Aug 2011 15:24:17 -0700 (PDT) Received: from premieronline.net (smtp1-5.premieronline.net [96.31.0.25]) by ietfa.amsl.com (Postfix) with ESMTP id EF14921F8C10 for ; Tue, 23 Aug 2011 15:24:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30268382-1729245 for multiple; Tue, 23 Aug 2011 17:25:24 -0500 From: "Frank Bulk" To: "'Templin, Fred L'" , "Ole Troan" References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com> <000501cc61d1$f9b74b20$ed25e160$@iname.com> In-Reply-To: Date: Tue, 23 Aug 2011 17:25:22 -0500 Message-ID: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acxh0oxetSq5nEX4QUuaNLUm1Eof4QAAtnqgAADHWJA= Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=14 Friend=954 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 899, in=14021370, out=65751, spam=0 Known=true ip=199.120.69.26 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 22:24:17 -0000 According to the specs, RGs may blindly make that DHCPv6 Solicit. Frank -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Tuesday, August 23, 2011 3:51 PM To: Ole Troan; frnkblk@iname.com Cc: IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Right - I forgot about stateless as well as stateful. Still, if no RS/RA exchange takes place I think the RG should at least have some inkling that the service is available. Either that, or the RG should be able to deal with failure if it blindly invokes the service and gets no reply. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of > Ole Troan > Sent: Tuesday, August 23, 2011 1:23 PM > To: frnkblk@iname.com > Cc: Templin, Fred L; IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > > The RG doesn't need it to be stateful for DHCPv6 to be > triggered. The RFC > > allow for DHCPv6 Solicit on an O=1. > > > > And TR-124i2 without an RA at all. > > as does RFC3633. > > cheers, > Ole > > > -----Original Message----- > > From: v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] On Behalf Of > > Templin, Fred L > > Sent: Tuesday, August 23, 2011 3:00 PM > > Cc: IPv6 Operations > > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > > > AFAICT, the RA 'M' bit is just one way the RG can > > learn that stateful services are available. If the > > RG has some other way of knowing that stateful > > services are available, then I don't see a problem > > for it to invoke DHCPv6 whether or not it ever gets > > an RA. Do I have that right? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From jiangsheng@huawei.com Tue Aug 23 17:53:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC75A21F8565 for ; Tue, 23 Aug 2011 17:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q0ELsNZ8Uku for ; Tue, 23 Aug 2011 17:53:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2E21F8564 for ; Tue, 23 Aug 2011 17:53:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00GRDQJAKU@szxga05-in.huawei.com> for v6ops@ietf.org; Wed, 24 Aug 2011 08:54:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE005OXQJ747@szxga05-in.huawei.com> for v6ops@ietf.org; Wed, 24 Aug 2011 08:54:46 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ65680; Wed, 24 Aug 2011 08:54:44 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 08:54:40 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 08:54:44 +0800 Date: Wed, 24 Aug 2011 00:54:43 +0000 From: Sheng Jiang In-reply-to: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> X-Originating-IP: [10.110.98.152] To: Thomas Narten , Fred Baker Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012395AD@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [v6ops] How to divide v6ops Thread-index: AQHMXddxmrKOgcbHi06D8ojiRdJRA5UqFe4AgAEeciA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 00:53:40 -0000 Fully agree. In some observation, v6ops has developed towards a forum, which allows any IPv6-relevant topics to be presented. It will work well if the chairs can simply say "no" to these works that stands no/minimum change to become v6ops wg drafts. Sheng > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Thomas Narten > Sent: Tuesday, August 23, 2011 11:47 PM > To: Fred Baker > Cc: IPv6 Operations; Ron Bonica > Subject: Re: [v6ops] How to divide v6ops > > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. > > The WG needs to focus on stuff that matters, and say "no" to > everything else. > > Absent a real willingness to do this, splitting the WG up is nothing > more then rearranging the deck chairs... > > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From pch-b29AA871B@u-1.phicoh.com Wed Aug 24 05:22:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB421F85FF for ; Wed, 24 Aug 2011 05:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.516 X-Spam-Level: X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa4BJ0LI19yP for ; Wed, 24 Aug 2011 05:22:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6851921F843B for ; Wed, 24 Aug 2011 05:22:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QwCUf-0001fpC; Wed, 24 Aug 2011 14:23:41 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> In-reply-to: Your message of "Tue, 23 Aug 2011 12:39:27 -0700 ." <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> Date: Wed, 24 Aug 2011 14:23:37 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:22:37 -0000 In your letter dated Tue, 23 Aug 2011 12:39:27 -0700 you wrote: >On Aug 23, 2011, at 11:34 , Rajiv Asati (rajiva) wrote: >> >> However, RFC 6204 doesn't list what other ways could be possible in W-3 > >Consider the case where the WAN interface is attached to a point-to-point link >. For a residential gateway device, it's probably a reasonable assumption tha >t the other end of such a link is always a default router. > >For a multi-purpose gateway device, however, it's not be a reasonable assumpti >on that the other end of an otherwise unidentifiable point-to-point link is a >default router. Hence, the express permission for a residential gateway, whic >h may happen to be a multi-function device deployed in a residential setting, >to wait for a router advertisement before proceeding to the DHCPv6 solicit. What's the point of not sending those DHCPv6 solicitations? It can't be security. It can't be the cost of the network traffic. You have to send the router solicitations anyhow. From narten@us.ibm.com Wed Aug 24 07:42:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9121F8B2D for ; Wed, 24 Aug 2011 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.161 X-Spam-Level: X-Spam-Status: No, score=-106.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9jiDWbdGY2a for ; Wed, 24 Aug 2011 07:42:07 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id D91DC21F8AD9 for ; Wed, 24 Aug 2011 07:42:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7O76CgR005769 for ; Wed, 24 Aug 2011 01:06:13 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7OEh1wq160406 for ; Wed, 24 Aug 2011 08:43:03 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7O8gxRa015905 for ; Wed, 24 Aug 2011 02:43:00 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-237.mts.ibm.com [9.65.218.237]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7O8gwEL015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 02:42:59 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7OEgsgi007367; Wed, 24 Aug 2011 10:42:58 -0400 Message-Id: <201108241442.p7OEgsgi007367@cichlid.raleigh.ibm.com> To: Sheng Jiang In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B92012395AD@SZXEML506-MBS.china.huawei.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> <5D36713D8A4E7348A7E10DF7437A4B92012395AD@SZXEML506-MBS.china.huawei.com> Comments: In-reply-to Sheng Jiang message dated "Wed, 24 Aug 2011 00:54:43 -0000." Date: Wed, 24 Aug 2011 10:42:54 -0400 From: Thomas Narten Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:42:08 -0000 Sheng Jiang writes: > Fully agree. In some observation, v6ops has developed towards a > forum, which allows any IPv6-relevant topics to be presented. > It will work well if the chairs can simply say "no" to these works > that stands no/minimum change to become v6ops wg drafts. Not fair to push all of this onto the chairs. The WG has been very much an enabler of the current behavior, and the chairs (rightly) are limited in how much they can go against the flow of a WG. I would like to see stronger pushback from the chairs on taking on work (unless there is clear and strong support for doing the work), but the WG needs to get on board with such an approach as well. We really need to come up with some concrete guidelines for deciding how to evaluate whether there is sufficient WG support for a document. It needs to reflect the reality that: - given the size of the v6ops WG (and the topic of v4/v6 transition/coexistance/keep-existing-stuff-alive-a-little-longer), you will always find a small number of folk willing to support a document. But that should not be good enough, it needs to be a significant fraction of the WG. The document needs to be deemed as actually useful/important, as opposed to just "harmless" or "maybe useful" - this WG (not unlike others) has succumbed to the practice where folk won't oppose a document, presumably because if they do, they won't later get support for documents of their own. I.e., I'll scratch your back if you scratch mine. The result (again) is that any document will get *some* support and the WG collectively shares responsibility for accepting marginal documents. But we need to get back to the IETF's core purpose, which is producing useful documents. It is not to pad CVs, or justify one's attendance. I'd suggest the development of some more concrete/objective criteria for deciding whether to take on documents. One that makes it clear that not all work that *might* be useful to *someone* needs to be done. Also, we have a broader problem of many documents that are "WG shopping". Rather than discuss the merits of the work, the discussion is more about finding what WG the work should be done in. I.e., if one WG doesn't want it, go find another WG that might. We see that problem in spades in the v6ops/softwire/behave area. Also, we have too many documents on what seems like the same basic topic/issue. But because there are so many of them, we (collectively) are effectively overwhelmed and then rather than either killing them or merging them, we let them continue on in a sort of twilight zone where they are neither accepted nor rejected items. Curmudgeonly yours, Thomas From moore@network-heretics.com Wed Aug 24 09:09:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED99721F8C59 for ; Wed, 24 Aug 2011 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM-It0rWSH6b for ; Wed, 24 Aug 2011 09:09:43 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9231221F8C53 for ; Wed, 24 Aug 2011 09:09:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 75D9C20AB1; Wed, 24 Aug 2011 12:10:54 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 24 Aug 2011 12:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=NLU CynnpCqlDC0IAYI/jWPIGQv0=; b=Qt0PP6PTF3j8OwfgvzuNQsFiUv31VD8/8RA iXOVMNx+A8aJi0ReaaiS/60NnEo33f4Vpb8hJSi0ui8bX7NBL7gG6u1XBoA/IWhj Ux0C9k+674MxCg+QkzcjT9vrERkmzoBfrUgk0x0jz4FGd721f3MV+Fd6B6lgnMeq QeR8B7ew= X-Sasl-enc: tZYVKfRrI32rRK0DgqiUCLiaz4NUGGYWBemgYdRNB1Ow 1314202253 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D95DB920037; Wed, 24 Aug 2011 12:10:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-887580823 From: Keith Moore In-Reply-To: <201108241442.p7OEgsgi007367@cichlid.raleigh.ibm.com> Date: Wed, 24 Aug 2011 12:10:29 -0400 Message-Id: <18CAFF06-A5C9-4D20-A64E-E61D07790200@network-heretics.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> <5D36713D8A4E7348A7E10DF7437A4B92012395AD@SZXEML506-MBS.china.huawei.com> <201108241442.p7OEgsgi007367@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:09:45 -0000 --Apple-Mail-11-887580823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 24, 2011, at 10:42 AM, Thomas Narten wrote: > We really need to come up with some concrete guidelines for deciding > how to evaluate whether there is sufficient WG support for a > document. It needs to reflect the reality that: >=20 > - given the size of the v6ops WG (and the topic of v4/v6 > transition/coexistance/keep-existing-stuff-alive-a-little-longer), > you will always find a small number of folk willing to support a > document. But that should not be good enough, it needs to be a > significant fraction of the WG. The document needs to be deemed as > actually useful/important, as opposed to just "harmless" or "maybe > useful" >=20 > - this WG (not unlike others) has succumbed to the practice where > folk won't oppose a document, presumably because if they do, they > won't later get support for documents of their own. I.e., I'll > scratch your back if you scratch mine. The result (again) is that > any document will get *some* support and the WG collectively > shares responsibility for accepting marginal documents. But we > need to get back to the IETF's core purpose, which is producing > useful documents. It is not to pad CVs, or justify one's > attendance. >=20 > I'd suggest the development of some more concrete/objective criteria > for deciding whether to take on documents. One that makes it clear > that not all work that *might* be useful to *someone* needs to be > done. A broader problem is that few individual WG members see the total cost = of the WG taking on another document. It's not just the amount of time = spent by those editing the WG document and reviewing it in detail. It = also takes up the attention of the WG for as long as the document = remains a topic of conversation. It also takes up the shepherd's time = and attention, the principal AD's time and attention, perhaps the time = and attention of members of the directorate, and sometimes the time and = attention of other ADs or all of IESG. All of that translates to the = inability of the WG and IESG and the community in general to work on = what might be more important (in the long run) or urgent matters. So when the WG is being polled to ask "who is interested in working on = this document" that's arguably the least of the cost. And at least for = WG documents, the bar should probably be _much_ higher than "might = someday be useful to someone". For the latter category documents, = there remain other means of publication: individual submissions for new = RFCs (especially informational or experimental), RFC errata for existing = RFCs, and avenues outside of IETF. Keith --Apple-Mail-11-887580823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
We really = need to come up with some concrete guidelines for deciding
how to = evaluate whether there is sufficient WG support for a
document. It = needs to reflect the reality that:

 - given the size of the = v6ops WG (and the topic of = v4/v6
   transition/coexistance/keep-existing-stuff-aliv= e-a-little-longer),
   you will always find a small = number of folk willing to support a
   document. But = that should not be good enough, it needs to be = a
   significant fraction of the WG. The document = needs to be deemed as
   actually useful/important, as = opposed to just "harmless" or = "maybe
   useful"

 - this WG (not unlike = others) has succumbed to the practice where
   folk = won't oppose a document, presumably because if they do, = they
   won't later get support for documents of their = own. I.e., I'll
   scratch your back if you scratch = mine. The result (again) is that
   any document will = get *some* support and the WG collectively
   shares = responsibility for accepting marginal documents. But = we
   need to get back to the IETF's core purpose, = which is producing
   useful documents. It is not to = pad CVs, or justify one's
   attendance.

I'd = suggest the development of some more concrete/objective criteria
for = deciding whether to take on documents. One that makes it clear
that = not all work that *might* be useful to *someone* needs to = be
done.

A broader problem is = that few individual WG members see the total cost of the WG taking on = another document.  It's not just the amount of time spent by those = editing the WG document and reviewing it in detail.   It also takes = up the attention of the WG for as long as the document remains a topic = of conversation.  It also takes up the shepherd's time and = attention, the principal AD's time and attention, perhaps the time and = attention of members of the directorate, and sometimes the time and = attention of other ADs or all of IESG.  All of that translates to = the inability of the WG and IESG and the community in general to work on = what might be more important (in the long run) or urgent = matters.

So when the WG is being polled to ask = "who is interested in working on this document" that's arguably the = least of the cost.   And at least for WG documents, the bar should = probably be _much_ higher than "might someday be useful to someone". =   For the latter category documents, there remain other means of = publication: individual submissions for new RFCs (especially = informational or experimental), RFC errata for existing RFCs, and = avenues outside of = IETF.

Keith

= --Apple-Mail-11-887580823-- From bs7652@att.com Wed Aug 24 11:55:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDB821F8586 for ; Wed, 24 Aug 2011 11:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zldsa5Ykpzxp for ; Wed, 24 Aug 2011 11:55:57 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4821F8582 for ; Wed, 24 Aug 2011 11:55:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1314212227!34532592!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17773 invoked from network); 24 Aug 2011 18:57:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2011 18:57:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7OItpLX006455; Wed, 24 Aug 2011 14:55:52 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p7OItkhe006358; Wed, 24 Aug 2011 14:55:46 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 14:56:23 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 14:56:22 -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 Date: Wed, 24 Aug 2011 14:56:59 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1EBC0CD4@crexc50p> In-Reply-To: <085249EE-B201-49A4-8A5D-F4FCB1A988AA@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: Acxh2fZX5dhAsH4wQkiTsAsMRQte+gAr+a8A References: <003101cc611d$cc0642d0$6412c870$@iname.com><001f01cc612d$4dc88030$e9598090$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p><067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com><79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com><067E6CE33034954AAC05C9EC85E2577C05BBCB54@XMB-RCD-111.cisco.com><000501cc61d1$f9b74b20$ed25e160$@iname.com> <085249EE-B201-49A4-8A5D-F4FCB1A988AA@apple.com> From: "STARK, BARBARA H (ATTSI)" To: "james woodyatt" , "Templin, Fred L" X-OriginalArrivalTime: 24 Aug 2011 18:56:22.0838 (UTC) FILETIME=[846B6D60:01CC628F] Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:55:58 -0000 > > Either that, or the RG should be able to deal with failure if it > blindly invokes the service and gets no reply. >=20 > Yeah. The way the BBF has written their specifications, the way I'm > going to "deal with failure" is to keep retrying forever. The > specification doesn't give me any alternative. Don't plug residential > gateways into networks where DHCPv6 solicits are unwelcome. The > network administrators will disable your port, and there isn't anything > I can do about it. Thanks for playing. BBF TR-124i2 is written to (a) provide guidance to vendors who supply RG-type devices to service providers who consider BBF specs useful to their access network architecture, and (b) provide those same service providers with a set of requirements that they can use in procuring RG-type devices for use in their networks. Which means: If you don't want an RG that is developed per TR-124i2, don't ask for it; and if you don't want to supply to such service providers, the document is irrelevant to you. There are many service providers who consider BBF specs useful who are deploying PON technology in their access networks. I would indeed suspect that many RGs that are intending to be used with PON access networks would abide by TR-124i2. The service providers who participate in BBF all stated that they wanted to use IA_PD for prefix assignment to RGs. Thus, for automated setup, they want the RG to always request IA_PD. IA_PD is stateful. The RA "M" flag is not considered relevant to IA_PD. To reduce time needed to get configured, it was decided that IA_PD needed to be requested as soon as the layer below IP (Ethernet or PPPoE in most BBF cases) was "up". To reduce the number of Solicit messages and keep the decision tree as small as possible, it was decided that IA_NA needed to be requested in the same message. The RG logic doesn't care whether or not IA_NA is returned. It's happy either way, as long as it gets IA_PD. The RG logic does care if it doesn't get IA_PD. You are correct that the RG will continue requesting IA_PD. And that is the behavior service providers wanted. If an RG is not receiving IA_PD from a BBF-defined IPv6-enabled access network, then the assumption is that either the access link is down, or the access network elements aren't responding. Once the service provider fixes whatever the problem is, the service provider wants the RG to have its IPv6 connection established / re-established ASAP. BBF-defined RGs are intended to work in BBF-defined access networks. You are absolutely correct that they were not defined with "networks where DHCPv6 solicits are unwelcome" in mind. Perhaps providers of such networks, together with the vendors of such networks, need to get together and define their own set of requirements.=20 Barbara From jhw@apple.com Wed Aug 24 12:20:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85DD21F8C1D for ; Wed, 24 Aug 2011 12:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.333 X-Spam-Level: X-Spam-Status: No, score=-106.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9aM0QdjWENh for ; Wed, 24 Aug 2011 12:20:10 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 237BB21F8B81 for ; Wed, 24 Aug 2011 12:20:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQG003HE5QQM321@mail-out.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 12:21:19 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-4c-4e554eb0f9d9 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 13.D2.04993.1BE455E4; Wed, 24 Aug 2011 12:19:13 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQG005S45RIUX10@cardamom.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 12:21:18 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 24 Aug 2011 12:21:18 -0700 Message-id: <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OVXejX6ifwdzZXBanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo+3K9gKPnNXTLu4nK2B8R5nFyMnh4SAicTsvm9sELaYxIV7 64FsLg4hgVYmib0vL4AleAUEJX5MvsfSxcjBwSwgL3HwvCxImFlAS+L7o1YWEFtIYBqTxIfF qiC2sICtxKvfBxlBbDYBFYlvl+8ygdicAsYSt3rWgsVZBFQltv3pZYYYqSLxv4EfYpONxJSp jSwQJxxglli7YiorSEJEQF/i49397BB3ykssbvnMOIFRYBaS62YhXDcLyXULGJlXMQoWpeYk Vhoa6iUWFOSk6iXn525iBIVdQ6HBDsa1P/kPMQpwMCrx8F5wCPUTYk0sK67MPcQowcGsJMJ7 6lyInxBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe2etBfkIC6YklqdmpqQWpRTBZJg5OqQZGhwcb 56gZHlrzeNF+1vv5tQckjMzKq55O14q6+Tv9iuOXm6rXw0X2FtUXTxS7PeG8rYtWlVjR3Skv C3Jjy2vEFt0O1/r/R2OL37u0b3ZPbjcfr1DMOXYxRoBn/cFTTl26HF+nmBwXKDDi7uRSvXzL +W3O4XWGjSXZCYGOH+Y+4z3xa82zJJO7SizFGYmGWsxFxYkA06KTPTcCAAA= Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:20:11 -0000 On Aug 24, 2011, at 05:23 , Philip Homburg wrote: > > What's the point of not sending those DHCPv6 solicitations? It can't be security. It can't be the cost of the network traffic. You have to send the router solicitations anyhow. Router solicitations are limited in number. On a network where DHCPv6 is persistently unavailable, I'm going to send solicit multicasts to ff02::1:2 at the maximum allowed rate indefinitely, i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section 17.1.2 recommends. Many enterprise network administrators discourage overly chatty devices that send unwelcome multicast packets, even to groups without any members, by shutting down layer-2 ports with devices connected to them that exhibit inappropriate behavior. Believe it or not, some of these enterprise networks do not use DHCPv6 servers, and do not plan to do so. Our products that are required to comply with the recommendations of RFC 6204 will be unwelcome on those networks unless we burden the user with additional configuration complexity by forcing them to make an incomprehensible choice of DHCPv6 client behaviors. That will never happen in a million years, so the answer will be: don't plug those boxes into those ports if you don't want to make IS&T mad at you. Either that, or we decide not to comply with RFC 6204. Not sure which way we will go. Probably the one that the marketing people decide is right. -- james woodyatt member of technical staff, core os networking From rajiva@cisco.com Wed Aug 24 12:55:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6921F86C1 for ; Wed, 24 Aug 2011 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXKcKVS0xIw9 for ; Wed, 24 Aug 2011 12:55:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B852021F86B6 for ; Wed, 24 Aug 2011 12:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2391; q=dns/txt; s=iport; t=1314215816; x=1315425416; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+XdEpkSKCiOpE56SBvmJKsZcUY15rRC1LlF191bDrQU=; b=nKstZRDtzfFY/czIymyZ7AJU2/JckeZyXXn2iA+lirqU9gVyzcO5XJMw y4u8WEyXsOoNjJWu5ePKacoVoxFWLHlj4oJLOpaTSAzeM6bRZXxwGuGme yPDlbekEVpZyBFVaFPK/oruZbn//4DLol1SPlJc8eefevbzIfiYtgQIz2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAPJWVU6tJXG8/2dsb2JhbABCmCePWXeBQAEBAQECAQEBAQ8BHQo0CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodPBJsnAZ8dhWpfBIdhkE6MAw X-IronPort-AV: E=Sophos;i="4.68,277,1312156800"; d="scan'208";a="16183757" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 24 Aug 2011 19:56:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7OJutNH006117; Wed, 24 Aug 2011 19:56:55 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 14:56: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 Date: Wed, 24 Aug 2011 14:56:54 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCEA2@XMB-RCD-111.cisco.com> In-Reply-To: <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: Acxhsilucsrw0kpvTdawYS9qU1tK5wA5YWbw References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com><20110816141748.GF72014@Space.Net><067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com><4E4AEE2E.4030000@es.net><1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> From: "Rajiv Asati (rajiva)" To: "Thomas Narten" , "Scott Beuker" X-OriginalArrivalTime: 24 Aug 2011 19:56:55.0311 (UTC) FILETIME=[F98AD1F0:01CC6297] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:55:45 -0000 Thomas, Please see inline, > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. Well, the ND messages are likely handled by the CPU, which may not get involved for forwarding packets. So, whether or not the interface is being used (for forwarding packets) is irrelevant for ND messages handling. > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. Agreed. I have drafted the ID and would submit in a week or so. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Tuesday, August 23, 2011 11:30 AM > To: Scott Beuker > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > > > What is wrong with retrying periodically? The point is to do this > > > every few tens of seconds, or every minute or two, so as to avoid > > > spending a lot of CPU on DAD. However, the desire is that layer 3 > > > be self healing once layer 2 has been fixed. IPv4 is self-healing > > > in this way. IPv6 is currently not. >=20 > > +1 >=20 > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. >=20 > What I'd suggest as a next step is that someone write a short ID that > describes the problem, and sketches out a recommended algorithm for > handling this situation. >=20 > E.g., use NS/ND probes to detect the condition, switch to periodic > probing mode when the interface is in loopback, and then describe > how/when to switch back to normal mode. >=20 > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. >=20 > We can then publish it as a short BCP or informational document (we > can figure out later which once the actual content has been worked > out). >=20 > Do we have a taker? >=20 > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Wed Aug 24 13:38:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203221F8D1E for ; Wed, 24 Aug 2011 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OfDw0SNpQTq for ; Wed, 24 Aug 2011 13:38:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85A1F21F8D1D for ; Wed, 24 Aug 2011 13:38:12 -0700 (PDT) Received: by wwf5 with SMTP id 5so1141072wwf.13 for ; Wed, 24 Aug 2011 13:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=U648kfxuKvrvt/nq/Serud7p2/EfGh3r8XHShVgA3ZQ=; b=dvlr/WqMUCxFtpKOPdivwORkAe92RKzpa/ly8JR/YbvHWoMBjnT5oojP/uoF7mTwTm Ckspkx9mmM2lH6dnRK1TlFMxkII0tT4iVH1+xXReybdeVsR8tPmJFIvgI/71xi7AXfSA 8ZMGQFKlTiVHh2oLKRbx4ZAjn+pQn8W/jgnxk= Received: by 10.227.199.16 with SMTP id eq16mr685670wbb.48.1314218363375; Wed, 24 Aug 2011 13:39:23 -0700 (PDT) Received: from dhcp-10-55-83-221.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fg5sm1141175wbb.57.2011.08.24.13.39.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 13:39:21 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> Date: Wed, 24 Aug 2011 22:39:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:38:13 -0000 James, I haven't met any Enterprise IT manager who is overly happy about random = users plugging in routers and building their own shadow network. RFC6204 is written for a very specific scenario. it is not a general = solution for "how to build a self organising network". cheers, Ole On Aug 24, 2011, at 21:21 , james woodyatt wrote: > On Aug 24, 2011, at 05:23 , Philip Homburg wrote: >>=20 >> What's the point of not sending those DHCPv6 solicitations? It can't = be security. It can't be the cost of the network traffic. You have to = send the router solicitations anyhow. >=20 > Router solicitations are limited in number. On a network where DHCPv6 = is persistently unavailable, I'm going to send solicit multicasts to = ff02::1:2 at the maximum allowed rate indefinitely, i.e. with = MRT=3DSOL_MAX_RT(120 s) and MRC=3D0 as RFC 3315, section 17.1.2 = recommends. >=20 > Many enterprise network administrators discourage overly chatty = devices that send unwelcome multicast packets, even to groups without = any members, by shutting down layer-2 ports with devices connected to = them that exhibit inappropriate behavior. Believe it or not, some of = these enterprise networks do not use DHCPv6 servers, and do not plan to = do so. Our products that are required to comply with the = recommendations of RFC 6204 will be unwelcome on those networks unless = we burden the user with additional configuration complexity by forcing = them to make an incomprehensible choice of DHCPv6 client behaviors. = That will never happen in a million years, so the answer will be: don't = plug those boxes into those ports if you don't want to make IS&T mad at = you. Either that, or we decide not to comply with RFC 6204. >=20 > Not sure which way we will go. Probably the one that the marketing = people decide is right. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From robert@raszuk.net Wed Aug 24 13:45:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3232C21F8D3E for ; Wed, 24 Aug 2011 13:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7jPof3yC5A9 for ; Wed, 24 Aug 2011 13:45:26 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 67F0321F8CC5 for ; Wed, 24 Aug 2011 13:45:26 -0700 (PDT) Received: (qmail 22252 invoked by uid 399); 24 Aug 2011 20:46:36 -0000 Received: from unknown (HELO ?192.168.1.68?) (robert@raszuk.net@83.24.92.58) by mail37.opentransfer.com with SMTP; 24 Aug 2011 20:46:36 -0000 Message-ID: <4E55632C.1030806@raszuk.net> Date: Wed, 24 Aug 2011 22:46:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Ole Troan References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:45:27 -0000 Hi Ole, My observation here is that what you call "a router" today is a piece of brick like equipment. I think routing functionality can be build into and present in much more variety of equipment types which we like it or not will be randomly plugged in and what's worse .. expected to work :) I think perhaps piece of that vision is what James had in mind. Cheers, R. > James, > > I haven't met any Enterprise IT manager who is overly happy about > random users plugging in routers and building their own shadow > network. RFC6204 is written for a very specific scenario. it is not a > general solution for "how to build a self organising network". > > cheers, Ole > > > On Aug 24, 2011, at 21:21 , james woodyatt wrote: > >> On Aug 24, 2011, at 05:23 , Philip Homburg wrote: >>> >>> What's the point of not sending those DHCPv6 solicitations? It >>> can't be security. It can't be the cost of the network traffic. >>> You have to send the router solicitations anyhow. >> >> Router solicitations are limited in number. On a network where >> DHCPv6 is persistently unavailable, I'm going to send solicit >> multicasts to ff02::1:2 at the maximum allowed rate indefinitely, >> i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section >> 17.1.2 recommends. >> >> Many enterprise network administrators discourage overly chatty >> devices that send unwelcome multicast packets, even to groups >> without any members, by shutting down layer-2 ports with devices >> connected to them that exhibit inappropriate behavior. Believe it >> or not, some of these enterprise networks do not use DHCPv6 >> servers, and do not plan to do so. Our products that are required >> to comply with the recommendations of RFC 6204 will be unwelcome on >> those networks unless we burden the user with additional >> configuration complexity by forcing them to make an >> incomprehensible choice of DHCPv6 client behaviors. That will >> never happen in a million years, so the answer will be: don't plug >> those boxes into those ports if you don't want to make IS&T mad at >> you. Either that, or we decide not to comply with RFC 6204. >> >> Not sure which way we will go. Probably the one that the marketing >> people decide is right. >> >> >> -- james woodyatt member of technical staff, core >> os networking >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From ichiroumakino@gmail.com Wed Aug 24 13:50:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FD21F8BEF for ; Wed, 24 Aug 2011 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB0zjFuA1SA8 for ; Wed, 24 Aug 2011 13:50:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3B21F8BE5 for ; Wed, 24 Aug 2011 13:50:48 -0700 (PDT) Received: by wwf5 with SMTP id 5so1148196wwf.13 for ; Wed, 24 Aug 2011 13:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=SAPjil/Wvni9gVq20jj0+CGycMkeQmp83qYTKkDkLGI=; b=SHD92zRdw5K/SJoLPzLA2pj+EeyuzyogzE5iguD/Vq+PWqwV2zLRc2wRIEiNi66pl5 o52cVelpbD6S//X4lKMfp28ItkeGZnAV//T1BFsr1AqZFQW3pMAY+hLWSX1mNsHM2RLq CGsL5f91Fc07tBsZBdwSWBWkeVkUj3rE7e0KI= Received: by 10.227.24.146 with SMTP id v18mr1825260wbb.84.1314219116745; Wed, 24 Aug 2011 13:51:56 -0700 (PDT) Received: from dhcp-10-55-83-221.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fb2sm1155386wbb.28.2011.08.24.13.51.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 13:51:55 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E55632C.1030806@raszuk.net> Date: Wed, 24 Aug 2011 22:51:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <41962BB8-62C4-4AD4-B433-4F6EC240E94B@employees.org> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> <4E55632C.1030806@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:50:50 -0000 Robert, > My observation here is that what you call "a router" today is a piece of > brick like equipment. > > I think routing functionality can be build into and present in much more > variety of equipment types which we like it or not will be randomly > plugged in and what's worse .. expected to work :) I think perhaps piece > of that vision is what James had in mind. sure, that's what homenet is going to work on, at least partly. but, specifically out of scope for 6204/TR124i2 that was discussed here. that James still would have liked it within scope is another discussion. ;-) cheers, Ole > > Cheers, > R. > >> James, >> >> I haven't met any Enterprise IT manager who is overly happy about >> random users plugging in routers and building their own shadow >> network. RFC6204 is written for a very specific scenario. it is not a >> general solution for "how to build a self organising network". >> >> cheers, Ole >> >> >> On Aug 24, 2011, at 21:21 , james woodyatt wrote: >> >>> On Aug 24, 2011, at 05:23 , Philip Homburg wrote: >>>> >>>> What's the point of not sending those DHCPv6 solicitations? It >>>> can't be security. It can't be the cost of the network traffic. >>>> You have to send the router solicitations anyhow. >>> >>> Router solicitations are limited in number. On a network where >>> DHCPv6 is persistently unavailable, I'm going to send solicit >>> multicasts to ff02::1:2 at the maximum allowed rate indefinitely, >>> i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section >>> 17.1.2 recommends. >>> >>> Many enterprise network administrators discourage overly chatty >>> devices that send unwelcome multicast packets, even to groups >>> without any members, by shutting down layer-2 ports with devices >>> connected to them that exhibit inappropriate behavior. Believe it >>> or not, some of these enterprise networks do not use DHCPv6 >>> servers, and do not plan to do so. Our products that are required >>> to comply with the recommendations of RFC 6204 will be unwelcome on >>> those networks unless we burden the user with additional >>> configuration complexity by forcing them to make an >>> incomprehensible choice of DHCPv6 client behaviors. That will >>> never happen in a million years, so the answer will be: don't plug >>> those boxes into those ports if you don't want to make IS&T mad at >>> you. Either that, or we decide not to comply with RFC 6204. >>> >>> Not sure which way we will go. Probably the one that the marketing >>> people decide is right. >>> >>> >>> -- james woodyatt member of technical staff, core >>> os networking >>> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > From jhw@apple.com Wed Aug 24 15:46:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D821F8CC6 for ; Wed, 24 Aug 2011 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.622 X-Spam-Level: X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPkfaXbsn0oc for ; Wed, 24 Aug 2011 15:46:55 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id DC6D221F8CB9 for ; Wed, 24 Aug 2011 15:46:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LQG00ABWFC168B1@mail-out.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 15:48:06 -0700 (PDT) X-AuditID: 11807136-b7c35ae000001055-ce-4e5582cd2a33 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B8.3F.04181.DC2855E4; Wed, 24 Aug 2011 16:01:33 -0700 (PDT) Received: from ba0301b-dhcp202.apple.com ([17.193.15.202]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQG00GKIFC6BK20@kencur.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 15:48:06 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 24 Aug 2011 15:48:05 -0700 Message-id: <06B0B160-F24A-4DFF-AE49-AA2F03E35E35@apple.com> References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUiON1OTfdsU6ifwdduXYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8Gld8wFy5kq1s7+z9bA+ISxi5GTQ0LARGJn41MWCFtM4sK9 9WxdjFwcQgLtTBKXuxaxgSR4BQQlfky+B1TEwcEsIC9x8LwsSJhZQEvi+6NWsF4hgRlMElcu K4PYwgK2Eq9+HwSbzyagIvHt8l0mEJtTwFFi7vZzYPUsAqoSBxdtYgIZyStgIzHxqzPE2lUs Ense7wCrFwHqnXLmPhvEbfISi1s+M05g5J+F5KJZCBfNQnLRAkbmVYyCRak5iZWGpnqJBQU5 qXrJ+bmbGEHh1VBotoNxx1+5Q4wCHIxKPLyazqF+QqyJZcWVuYcYJTiYlUR4c2qAQrwpiZVV qUX58UWlOanFhxilOViUxHlX3gryExJITyxJzU5NLUgtgskycXBKNTCune68eG3T/TucqibJ +Tw+E8y2rq2y320tm6HkLXjORtRlIlPsui0/Hqu8fCG/ZMf8e5kG2scervvbrv9ejm2F+lZj iacvr7leDTjyx/XUkdCvYTM4Rf5v1PQw5f5yyCE/UaT51o/bKsfutJSkcnvnt7ues5/cdW9h c+/OfWLt396711pb7CtRYinOSDTUYi4qTgQAfrmpWCsCAAA= Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 22:46:56 -0000 On Aug 24, 2011, at 1:39 PM, Ole Troan wrote: > > RFC6204 is written for a very specific scenario. As I predicted would happen, it's being weaponized for more general scenarios even as we speak. -- james woodyatt member of technical staff, core os networking From john_brzozowski@cable.comcast.com Wed Aug 24 17:53:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0711A21F8C17 for ; Wed, 24 Aug 2011 17:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.563 X-Spam-Level: X-Spam-Status: No, score=-107.563 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW71fNGdOOAI for ; Wed, 24 Aug 2011 17:53:47 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C521F8BE5 for ; Wed, 24 Aug 2011 17:53:46 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138170764; Wed, 24 Aug 2011 20:54:53 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 20:54:53 -0400 From: "Brzozowski, John" To: "frnkblk@iname.com" , Fred Templin , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYsGZSdqOmTc9JUqJWDYZ1ozwNQ== Date: Thu, 25 Aug 2011 00:54:52 +0000 Message-ID: In-Reply-To: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.249.124.101] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 00:53:48 -0000 FWIW this scenario has the opportunity to introduce some interesting challenges when deploying IPv6. Certain operating system do as described below and send DHCPv6 at some interval and if they are not responded to a number of retries are attempted with an exponential back off between each. When this is multiplied by a large number this creates an even larger volume of DHCPv6 requests. As such I have a bit stronger of an opinion regarding the use of the M and O bits, in particular the lengthy debate that occurred some time ago. I believe there is value in having M and/or O trigger the use of DHCPv6. When we specified IPv6 for DOCSIS we decided to use the M bit to trigger DHCPv6 for cable modems, this works rather nicely. I am thinking it might be useful to take this a step further and suggest that the interval which a device receives an RA with M and/or O be factored into the frequency of DHCPv6 attempts (not just the retries). The same would also apply to a RG/IGD via its WAN interface. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/23/11 6:25 PM, "Frank Bulk" wrote: > >According to the specs, RGs may blindly make that DHCPv6 Solicit. > >Frank > >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, August 23, 2011 3:51 PM >To: Ole Troan; frnkblk@iname.com >Cc: IPv6 Operations >Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit > >Right - I forgot about stateless as well as stateful. >Still, if no RS/RA exchange takes place I think the >RG should at least have some inkling that the service >is available. Either that, or the RG should be able >to deal with failure if it blindly invokes the >service and gets no reply. > >Thanks - Fred >fred.l.templin@boeing.com >=20 > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of >> Ole Troan >> Sent: Tuesday, August 23, 2011 1:23 PM >> To: frnkblk@iname.com >> Cc: Templin, Fred L; IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >>=20 >> > The RG doesn't need it to be stateful for DHCPv6 to be >> triggered. The RFC >> > allow for DHCPv6 Solicit on an O=3D1. >> >=20 >> > And TR-124i2 without an RA at all. >>=20 >> as does RFC3633. >>=20 >> cheers, >> Ole >>=20 >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> > Templin, Fred L >> > Sent: Tuesday, August 23, 2011 3:00 PM >> > Cc: IPv6 Operations >> > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> >=20 >> > AFAICT, the RA 'M' bit is just one way the RG can >> > learn that stateful services are available. If the >> > RG has some other way of knowing that stateful >> > services are available, then I don't see a problem >> > for it to invoke DHCPv6 whether or not it ever gets >> > an RA. Do I have that right? >> >=20 >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From john_brzozowski@cable.comcast.com Wed Aug 24 17:57:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E6D21F8C46 for ; Wed, 24 Aug 2011 17:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.013 X-Spam-Level: X-Spam-Status: No, score=-108.013 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p0D1jqq5W2W for ; Wed, 24 Aug 2011 17:57:26 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5581421F8BE5 for ; Wed, 24 Aug 2011 17:57:26 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138170962; Wed, 24 Aug 2011 20:58:32 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 20:58:32 -0400 From: "Brzozowski, John" To: james woodyatt , Philip Homburg Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYpMJSdqOmTc9JUqJWDYZ1ozwNZUsvzwA Date: Thu, 25 Aug 2011 00:58:32 +0000 Message-ID: In-Reply-To: <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.249.124.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <34169525D593F14484F55B42F46438E5@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 00:57:27 -0000 James, Add exponential back offs and the volume of DHCPv6 messages grows exponentially. Just sent some mail on this when replying to another thread. John On 8/24/11 3:21 PM, "james woodyatt" wrote: >Router solicitations are limited in number. On a network where DHCPv6 is >persistently unavailable, I'm going to send solicit multicasts to >ff02::1:2 at the maximum allowed rate indefinitely, i.e. with >MRT=3DSOL_MAX_RT(120 s) and MRC=3D0 as RFC 3315, section 17.1.2 recommends= . From frnkblk@iname.com Wed Aug 24 18:24:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0008D21F8AC3 for ; Wed, 24 Aug 2011 18:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZmIzQtKbLwl for ; Wed, 24 Aug 2011 18:24:38 -0700 (PDT) Received: from premieronline.net (smtp1-4.premieronline.net [96.31.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7621F8A96 for ; Wed, 24 Aug 2011 18:24:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30330141-1729245 for multiple; Wed, 24 Aug 2011 20:25:48 -0500 From: "Frank Bulk" To: "'Brzozowski, John'" References: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> In-Reply-To: Date: Wed, 24 Aug 2011 20:25:47 -0500 Message-ID: <002d01cc62c5$eab372d0$c01a5870$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMYsGZSdqOmTc9JUqJWDYZ1ozwNZUsxBOg Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=14 Friend=927 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 900, in=14049272, out=65868, spam=0 Known=true ip=199.120.69.26 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 01:24:39 -0000 I think the cat is out of the bag with the (more liberal) specifications that already release and devices in production. =20 Is your concern a DHCPv6 multicast storm? Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: Wednesday, August 24, 2011 7:55 PM To: frnkblk@iname.com; Fred Templin; Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit FWIW this scenario has the opportunity to introduce some interesting challenges when deploying IPv6. Certain operating system do as = described below and send DHCPv6 at some interval and if they are not responded to = a number of retries are attempted with an exponential back off between = each. When this is multiplied by a large number this creates an even larger volume of DHCPv6 requests. As such I have a bit stronger of an opinion regarding the use of the M = and O bits, in particular the lengthy debate that occurred some time ago. I believe there is value in having M and/or O trigger the use of DHCPv6. When we specified IPv6 for DOCSIS we decided to use the M bit to trigger DHCPv6 for cable modems, this works rather nicely. I am thinking it = might be useful to take this a step further and suggest that the interval = which a device receives an RA with M and/or O be factored into the frequency = of DHCPv6 attempts (not just the retries). The same would also apply to a RG/IGD via its WAN interface. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/23/11 6:25 PM, "Frank Bulk" wrote: > >According to the specs, RGs may blindly make that DHCPv6 Solicit. > >Frank > >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, August 23, 2011 3:51 PM >To: Ole Troan; frnkblk@iname.com >Cc: IPv6 Operations >Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit > >Right - I forgot about stateless as well as stateful. >Still, if no RS/RA exchange takes place I think the >RG should at least have some inkling that the service >is available. Either that, or the RG should be able >to deal with failure if it blindly invokes the >service and gets no reply. > >Thanks - Fred >fred.l.templin@boeing.com >=20 > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of >> Ole Troan >> Sent: Tuesday, August 23, 2011 1:23 PM >> To: frnkblk@iname.com >> Cc: Templin, Fred L; IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >>=20 >> > The RG doesn't need it to be stateful for DHCPv6 to be >> triggered. The RFC >> > allow for DHCPv6 Solicit on an O=3D1. >> >=20 >> > And TR-124i2 without an RA at all. >>=20 >> as does RFC3633. >>=20 >> cheers, >> Ole >>=20 >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> > Templin, Fred L >> > Sent: Tuesday, August 23, 2011 3:00 PM >> > Cc: IPv6 Operations >> > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> >=20 >> > AFAICT, the RA 'M' bit is just one way the RG can >> > learn that stateful services are available. If the >> > RG has some other way of knowing that stateful >> > services are available, then I don't see a problem >> > for it to invoke DHCPv6 whether or not it ever gets >> > an RA. Do I have that right? >> >=20 >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Wed Aug 24 20:17:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3229E21F8B00 for ; Wed, 24 Aug 2011 20:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.622 X-Spam-Level: X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioUJqffA7-+a for ; Wed, 24 Aug 2011 20:17:25 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6293421F8AF5 for ; Wed, 24 Aug 2011 20:17:24 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQG001ZFRUZ7RQ1@mail-out.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 20:18:35 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-f8-4e55bd64ed77 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 5C.C6.05328.46DB55E4; Wed, 24 Aug 2011 20:11:32 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQG00B2ZRUYIT00@koseret.apple.com> for v6ops@ietf.org; Wed, 24 Aug 2011 20:18:35 -0700 (PDT) From: james woodyatt In-reply-to: <4E55632C.1030806@raszuk.net> Date: Wed, 24 Aug 2011 20:18:34 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> <4E55632C.1030806@raszuk.net> To: IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUiON1OXTdlb6ifwfY+JYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+WNh4wFU4QrXu6YydLAuJK/i5GTQ0LAROLZxJ1sELaYxIV7 64FsLg4hgU4miTMPnrGDJHgFBCV+TL7HAmIzC2hJfH/UygJRNIVJYt35RcwgCWEBW4lXvw8y gthsAioS3y7fZQKxOYEaJvzbzQpiswioSuz88Z0JYpC2xJN3F1ghFthIbH7zB2roKRaJvTse ghWJAA2acuY+1HnyEotbPjNOYOSfheSoWUiOmoVk7gJG5lWMgkWpOYmVhiZ6iQUFOal6yfm5 mxhBYdZQaLKD8eBP/kOMAhyMSjy8lXahfkKsiWXFlbmHGCU4mJVEeCftBArxpiRWVqUW5ccX leakFh9ilOZgURLn/X81yE9IID2xJDU7NbUgtQgmy8TBKdXA2K9S+2nbmdnN6jNv6331X3b3 Z+WMcK0X0w437p/MuOG6+5b3Hu0Nm4s18jSD36vY9YqcU9+ypfxV9xS26vbGtQb+PRJrj/Tr ue+z5WmUV8rPOCexucjUnYvLpuxu3ItejoMMZ35885BwPrq/e+ehPtPdyt7aHrsboteaKmUx sU2UfxVm/fe3EktxRqKhFnNRcSIARKYgWy8CAAA= Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:17:26 -0000 On Aug 24, 2011, at 13:46 , Robert Raszuk wrote: >=20 > ...which we like it or not will be randomly plugged in and what's = worse .. expected to work :) One of the design principles I learned early on in my career is that = when most ordinary people find a jack that will accept a plug, or = likewise they find a plug that will fit a jack, they will often form = very powerful expectations in their minds about what should happen if = they insert the plug into the jack. Perhaps, more significantly, I = learned that ignoring or defying these expectations is not a good way to = make your designs more acceptable to them. The best way to signal to said ordinary people that they shouldn't = expect anything useful to happen by inserting this plug into that jack = is to assign the job to a mechanical engineer. People seem to = understand that delicate electronics gear shouldn't require a hammer and = pliers to close the network connection loops. Sadly, this is not the design principle one finds employed most often in = the engineering of devices with IEEE 802.1 interfaces. The common = practice in our field is to put identical connectors on everything, = occasionally label them with cryptic terminology-- but often we leave = them entirely unlabeled. Next, we give people configuration menus that = make the space shuttle cockpit look like a child's toy, and we require = them to read a corpus of documentation that weighs in at the kilograms = and describes whole new languages and obscure protocols, like some kind = of crazy technocratic freemasonry on an acid bender. Finally, after = abusing them in this fashion, we then have the exceedingly poor taste to = invite them to *enjoy* all these wonderful opportunities to build = puzzles for themselves, their family and friends, and their neighbors, = these *beautiful* puzzles which we have gifted to them in our glorious = magnanimity. When they object to this, we call them stupid and = ungrateful-- sometimes even in public places, where strangely, we often = believe they don't see us doing it-- but, oh, they see us. They do. = They most certainly do. I suspect trained psychologists would describe our usual design mode as = a form of sociopathic behavior. > I think perhaps piece of that vision is what James had in mind. Absolutely. -- james woodyatt member of technical staff, core os networking From john_brzozowski@cable.comcast.com Wed Aug 24 20:47:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06CE21F8BB7 for ; Wed, 24 Aug 2011 20:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=1.960, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARx4epf1jTLr for ; Wed, 24 Aug 2011 20:47:04 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id D7FFD21F8AEA for ; Wed, 24 Aug 2011 20:47:03 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138177604; Wed, 24 Aug 2011 23:48:14 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 23:48:14 -0400 From: "Brzozowski, John" To: "frnkblk@iname.com" Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYsGZSdqOmTc9JUqJWDYZ1ozwNZUsxBOggAAqC1Y= Date: Thu, 25 Aug 2011 03:48:14 +0000 Message-ID: <6u7cadic39et446kbsrf9m3w.1314244104168@email.android.com> References: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> , <002d01cc62c5$eab372d0$c01a5870$@iname.com> In-Reply-To: <002d01cc62c5$eab372d0$c01a5870$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:47:04 -0000 Concern is not multicast storms. High volumes of relayed unicast DHCPv6. Not sure what you are referring to WRT specifications, etc. Frank Bulk wrote: I think the cat is out of the bag with the (more liberal) specifications that already release and devices in production. Is your concern a DHCPv6 multicast storm? Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com] Sent: Wednesday, August 24, 2011 7:55 PM To: frnkblk@iname.com; Fred Templin; Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit FWIW this scenario has the opportunity to introduce some interesting challenges when deploying IPv6. Certain operating system do as described below and send DHCPv6 at some interval and if they are not responded to a number of retries are attempted with an exponential back off between each. When this is multiplied by a large number this creates an even larger volume of DHCPv6 requests. As such I have a bit stronger of an opinion regarding the use of the M and O bits, in particular the lengthy debate that occurred some time ago. I believe there is value in having M and/or O trigger the use of DHCPv6. When we specified IPv6 for DOCSIS we decided to use the M bit to trigger DHCPv6 for cable modems, this works rather nicely. I am thinking it might be useful to take this a step further and suggest that the interval which a device receives an RA with M and/or O be factored into the frequency of DHCPv6 attempts (not just the retries). The same would also apply to a RG/IGD via its WAN interface. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/23/11 6:25 PM, "Frank Bulk" wrote: > >According to the specs, RGs may blindly make that DHCPv6 Solicit. > >Frank > >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, August 23, 2011 3:51 PM >To: Ole Troan; frnkblk@iname.com >Cc: IPv6 Operations >Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit > >Right - I forgot about stateless as well as stateful. >Still, if no RS/RA exchange takes place I think the >RG should at least have some inkling that the service >is available. Either that, or the RG should be able >to deal with failure if it blindly invokes the >service and gets no reply. > >Thanks - Fred >fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of >> Ole Troan >> Sent: Tuesday, August 23, 2011 1:23 PM >> To: frnkblk@iname.com >> Cc: Templin, Fred L; IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> >> > The RG doesn't need it to be stateful for DHCPv6 to be >> triggered. The RFC >> > allow for DHCPv6 Solicit on an O=3D1. >> > >> > And TR-124i2 without an RA at all. >> >> as does RFC3633. >> >> cheers, >> Ole >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> > Templin, Fred L >> > Sent: Tuesday, August 23, 2011 3:00 PM >> > Cc: IPv6 Operations >> > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> > >> > AFAICT, the RA 'M' bit is just one way the RG can >> > learn that stateful services are available. If the >> > RG has some other way of knowing that stateful >> > services are available, then I don't see a problem >> > for it to invoke DHCPv6 whether or not it ever gets >> > an RA. Do I have that right? >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From frnkblk@iname.com Wed Aug 24 20:50:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E25D21F85A1 for ; Wed, 24 Aug 2011 20:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS0TQ+2q7oM7 for ; Wed, 24 Aug 2011 20:50:46 -0700 (PDT) Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id B2CA721F85A3 for ; Wed, 24 Aug 2011 20:50:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from BULKFAMLAPTOP (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30333676-1729245 for multiple; Wed, 24 Aug 2011 22:51:57 -0500 From: "Frank Bulk" To: "'Brzozowski, John'" References: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> , <002d01cc62c5$eab372d0$c01a5870$@iname.com> <6u7cadic39et446kbsrf9m3w.1314244104168@email.android.com> In-Reply-To: <6u7cadic39et446kbsrf9m3w.1314244104168@email.android.com> Date: Wed, 24 Aug 2011 22:51:56 -0500 Message-ID: <003301cc62da$556e3420$004a9c60$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMYsGZSdqOmTc9JUqJWDYZ1ozwNZUsxBOggAAqC1aAAADLAA== Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=7 Friend=982 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 900, in=12913675, out=62552, spam=0 Known=true ip=199.120.69.27 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:50:47 -0000 DHCPv6 Solicits are multicast. I don't know myself, but I'm guessing = then that the CMTS has a relay agent that converts it to unicast. Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: Wednesday, August 24, 2011 10:48 PM To: frnkblk@iname.com Cc: IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Concern is not multicast storms. High volumes of relayed unicast DHCPv6. Not sure what you are referring to WRT specifications, etc. Frank Bulk wrote: I think the cat is out of the bag with the (more liberal) specifications that already release and devices in production. Is your concern a DHCPv6 multicast storm? Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com] Sent: Wednesday, August 24, 2011 7:55 PM To: frnkblk@iname.com; Fred Templin; Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit FWIW this scenario has the opportunity to introduce some interesting challenges when deploying IPv6. Certain operating system do as = described below and send DHCPv6 at some interval and if they are not responded to = a number of retries are attempted with an exponential back off between = each. When this is multiplied by a large number this creates an even larger volume of DHCPv6 requests. As such I have a bit stronger of an opinion regarding the use of the M = and O bits, in particular the lengthy debate that occurred some time ago. I believe there is value in having M and/or O trigger the use of DHCPv6. When we specified IPv6 for DOCSIS we decided to use the M bit to trigger DHCPv6 for cable modems, this works rather nicely. I am thinking it = might be useful to take this a step further and suggest that the interval = which a device receives an RA with M and/or O be factored into the frequency = of DHCPv6 attempts (not just the retries). The same would also apply to a RG/IGD via its WAN interface. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/23/11 6:25 PM, "Frank Bulk" wrote: > >According to the specs, RGs may blindly make that DHCPv6 Solicit. > >Frank > >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, August 23, 2011 3:51 PM >To: Ole Troan; frnkblk@iname.com >Cc: IPv6 Operations >Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit > >Right - I forgot about stateless as well as stateful. >Still, if no RS/RA exchange takes place I think the >RG should at least have some inkling that the service >is available. Either that, or the RG should be able >to deal with failure if it blindly invokes the >service and gets no reply. > >Thanks - Fred >fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of >> Ole Troan >> Sent: Tuesday, August 23, 2011 1:23 PM >> To: frnkblk@iname.com >> Cc: Templin, Fred L; IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> >> > The RG doesn't need it to be stateful for DHCPv6 to be >> triggered. The RFC >> > allow for DHCPv6 Solicit on an O=3D1. >> > >> > And TR-124i2 without an RA at all. >> >> as does RFC3633. >> >> cheers, >> Ole >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> > Templin, Fred L >> > Sent: Tuesday, August 23, 2011 3:00 PM >> > Cc: IPv6 Operations >> > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> > >> > AFAICT, the RA 'M' bit is just one way the RG can >> > learn that stateful services are available. If the >> > RG has some other way of knowing that stateful >> > services are available, then I don't see a problem >> > for it to invoke DHCPv6 whether or not it ever gets >> > an RA. Do I have that right? >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Wed Aug 24 20:57:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B6721F8C19 for ; Wed, 24 Aug 2011 20:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLvBp9tJPY2E for ; Wed, 24 Aug 2011 20:57:02 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 268C821F8C16 for ; Wed, 24 Aug 2011 20:57:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTlXITw14aXnfel+qasuW+gYDAJ+zyBjv@postini.com; Wed, 24 Aug 2011 20:58:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7860B1B827A for ; Wed, 24 Aug 2011 20:58:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 67B4A190064; Wed, 24 Aug 2011 20:58:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 20:58:07 -0700 From: Ted Lemon To: "Brzozowski, John" Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYlimEGG4SJJsQregMAyjwJPGgpUs1qYAgABeOQCAADIpAA== Date: Thu, 25 Aug 2011 03:58:06 +0000 Message-ID: <2255BAD1-C498-4F08-AC5E-8676091E697C@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_2255BAD1C4984F08AC5E8676091E697Cnominumcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:57:03 -0000 --_000_2255BAD1C4984F08AC5E8676091E697Cnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote: Add exponential back offs and the volume of DHCPv6 messages grows exponentially. Just sent some mail on this when replying to another thread. This doesn't make sense. The point of exponential backoff is that traffic= should shrink over time, not grow. --_000_2255BAD1C4984F08AC5E8676091E697Cnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote:
Add exponential back offs and the volume of DHCPv6 messages grows
exponentially.  Just sent some mail on this when replying to another thread.

This doesn't make sense.   The point of exponential backoff is th= at traffic should shrink over time, not grow.

--_000_2255BAD1C4984F08AC5E8676091E697Cnominumcom_-- From Ted.Lemon@nominum.com Wed Aug 24 20:59:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776521F8C5B for ; Wed, 24 Aug 2011 20:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH67noQHqdEJ for ; Wed, 24 Aug 2011 20:59:43 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7B21F8C58 for ; Wed, 24 Aug 2011 20:59:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTlXI9w25D0hgyPne733fqSgJh6JWBXgE@postini.com; Wed, 24 Aug 2011 21:00:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B8BD91B8278 for ; Wed, 24 Aug 2011 21:00:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B1899190064; Wed, 24 Aug 2011 21:00:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 21:00:54 -0700 From: Ted Lemon To: james woodyatt Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYlimEGG4SJJsQregMAyjwJPGgpUs1qYAgAAVyICAAAINAIAAbYQAgAAL1AA= Date: Thu, 25 Aug 2011 04:00:54 +0000 Message-ID: References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> <4E55632C.1030806@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_F2CE78F849044DD48187204CF9A879EDnominumcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:59:43 -0000 --_000_F2CE78F849044DD48187204CF9A879EDnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 24, 2011, at 11:18 PM, james woodyatt wrote: The best way to signal to said ordinary people that they shouldn't expect a= nything useful to happen by inserting this plug into that jack is to assign= the job to a mechanical engineer. People seem to understand that delicate= electronics gear shouldn't require a hammer and pliers to close the networ= k connection loops. Yeah, this has been weighing on my mind a bit lately. Why *don't* we use = different connectors for different purposes? --_000_F2CE78F849044DD48187204CF9A879EDnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5723930C388B9745A18BC1FC19D9D5B3@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 24, 2011, at 11:18 PM, james woodyatt wrote:
The best way to signal to said ordinary people that they shouldn't expect anyt= hing useful to happen by inserting this plug into that jack is to assign th= e job to a mechanical engineer.  People seem to understand that delica= te electronics gear shouldn't require a hammer and pliers to close the network connection loops.

Yeah, this has been weighing on my mind a bit lately.   Why *don'= t* we use different connectors for different purposes?

--_000_F2CE78F849044DD48187204CF9A879EDnominumcom_-- From john_brzozowski@cable.comcast.com Wed Aug 24 21:00:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E689121F8C6D for ; Wed, 24 Aug 2011 21:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.784 X-Spam-Level: X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAiBu5eCWZfW for ; Wed, 24 Aug 2011 21:00:22 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id F0F7521F8C16 for ; Wed, 24 Aug 2011 21:00:21 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.50264587; Wed, 24 Aug 2011 22:07:09 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 25 Aug 2011 00:01:28 -0400 From: "Brzozowski, John" To: "frnkblk@iname.com" Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYsGZSdqOmTc9JUqJWDYZ1ozwNZUsxBOggAAqC1aAAADLAIAAAugD Date: Thu, 25 Aug 2011 04:01:27 +0000 Message-ID: References: <000a01cc61e3$8c728e50$a557aaf0$@iname.com> , <002d01cc62c5$eab372d0$c01a5870$@iname.com> <6u7cadic39et446kbsrf9m3w.1314244104168@email.android.com>, <003301cc62da$556e3420$004a9c60$@iname.com> In-Reply-To: <003301cc62da$556e3420$004a9c60$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 04:00:23 -0000 This is what I was loosely referring to, sorry for not being clear. Regardl= ess, the M and/or O is what I was referring to relative to DHCPv6. Frank Bulk wrote: DHCPv6 Solicits are multicast. I don't know myself, but I'm guessing then that the CMTS has a relay agent that converts it to unicast. Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com] Sent: Wednesday, August 24, 2011 10:48 PM To: frnkblk@iname.com Cc: IPv6 Operations Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit Concern is not multicast storms. High volumes of relayed unicast DHCPv6. Not sure what you are referring to WRT specifications, etc. Frank Bulk wrote: I think the cat is out of the bag with the (more liberal) specifications that already release and devices in production. Is your concern a DHCPv6 multicast storm? Frank -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com] Sent: Wednesday, August 24, 2011 7:55 PM To: frnkblk@iname.com; Fred Templin; Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit FWIW this scenario has the opportunity to introduce some interesting challenges when deploying IPv6. Certain operating system do as described below and send DHCPv6 at some interval and if they are not responded to a number of retries are attempted with an exponential back off between each. When this is multiplied by a large number this creates an even larger volume of DHCPv6 requests. As such I have a bit stronger of an opinion regarding the use of the M and O bits, in particular the lengthy debate that occurred some time ago. I believe there is value in having M and/or O trigger the use of DHCPv6. When we specified IPv6 for DOCSIS we decided to use the M bit to trigger DHCPv6 for cable modems, this works rather nicely. I am thinking it might be useful to take this a step further and suggest that the interval which a device receives an RA with M and/or O be factored into the frequency of DHCPv6 attempts (not just the retries). The same would also apply to a RG/IGD via its WAN interface. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/23/11 6:25 PM, "Frank Bulk" wrote: > >According to the specs, RGs may blindly make that DHCPv6 Solicit. > >Frank > >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, August 23, 2011 3:51 PM >To: Ole Troan; frnkblk@iname.com >Cc: IPv6 Operations >Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit > >Right - I forgot about stateless as well as stateful. >Still, if no RS/RA exchange takes place I think the >RG should at least have some inkling that the service >is available. Either that, or the RG should be able >to deal with failure if it blindly invokes the >service and gets no reply. > >Thanks - Fred >fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of >> Ole Troan >> Sent: Tuesday, August 23, 2011 1:23 PM >> To: frnkblk@iname.com >> Cc: Templin, Fred L; IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> >> > The RG doesn't need it to be stateful for DHCPv6 to be >> triggered. The RFC >> > allow for DHCPv6 Solicit on an O=3D1. >> > >> > And TR-124i2 without an RA at all. >> >> as does RFC3633. >> >> cheers, >> Ole >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> > Templin, Fred L >> > Sent: Tuesday, August 23, 2011 3:00 PM >> > Cc: IPv6 Operations >> > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >> > >> > AFAICT, the RA 'M' bit is just one way the RG can >> > learn that stateful services are available. If the >> > RG has some other way of knowing that stateful >> > services are available, then I don't see a problem >> > for it to invoke DHCPv6 whether or not it ever gets >> > an RA. Do I have that right? >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Thu Aug 25 03:04:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB921F85AE for ; Thu, 25 Aug 2011 03:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNhCxv0fb12P for ; Thu, 25 Aug 2011 03:04:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5F21F8569 for ; Thu, 25 Aug 2011 03:04:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QwWoR-000HNP-VY; Thu, 25 Aug 2011 10:05:28 +0000 Date: Thu, 25 Aug 2011 19:05:26 +0900 Message-ID: From: Randy Bush To: Thomas Narten In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:04:21 -0000 > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. this problem is far from limited to this wg. it is endemic and very damaging. "It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful." -- Jon Postel randy From pch-b29AA871B@u-1.phicoh.com Thu Aug 25 04:35:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72CD21F85FE for ; Thu, 25 Aug 2011 04:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkfncZEdjaQK for ; Thu, 25 Aug 2011 04:35:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1B21F85B8 for ; Thu, 25 Aug 2011 04:35:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QwYEO-0001iJC; Thu, 25 Aug 2011 13:36:20 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> In-reply-to: Your message of "Wed, 24 Aug 2011 12:21:18 -0700 ." <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> Date: Thu, 25 Aug 2011 13:36:20 +0200 Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 11:35:10 -0000 In your letter dated Wed, 24 Aug 2011 12:21:18 -0700 you wrote: >On Aug 24, 2011, at 05:23 , Philip Homburg wrote: >> >> What's the point of not sending those DHCPv6 solicitations? It can't be secu >rity. It can't be the cost of the network traffic. You have to send the router > solicitations anyhow. > >Router solicitations are limited in number. On a network where DHCPv6 is pers >istently unavailable, I'm going to send solicit multicasts to ff02::1:2 at the > maximum allowed rate indefinitely, i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 >as RFC 3315, section 17.1.2 recommends. > >Many enterprise network administrators discourage overly chatty devices that s >end unwelcome multicast packets, even to groups without any members, by shutti >ng down layer-2 ports with devices connected to them that exhibit inappropriat >e behavior. I don't know how that is defined. But if you would disable able any device that multicasts more than DHCPv6 then would quickly have an network without Windows or OSX. I assume that when a router is connected, it is meant to be used. If it isn't it doesn't really matter if the router's ports are shutdown at the l2. One exception maybe an IPv6 capable router in an IPv4-only environment. I'd say, let the router just try to do IPv6 and have someone explictly disable IPv6 if that causes to much noise. But I can also imagine vendors implementing that the other way around for the moment. ------- End of Forwarded Message From john_brzozowski@cable.comcast.com Thu Aug 25 06:51:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2035021F8512 for ; Thu, 25 Aug 2011 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.874 X-Spam-Level: X-Spam-Status: No, score=-104.874 tagged_above=-999 required=5 tests=[AWL=-3.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h86dVwRsuqKq for ; Thu, 25 Aug 2011 06:51:55 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC5321F86FF for ; Thu, 25 Aug 2011 06:51:54 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.50304830; Thu, 25 Aug 2011 07:58:42 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Thu, 25 Aug 2011 09:53:02 -0400 From: "Brzozowski, John" To: Ted Lemon Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYpMJSdqOmTc9JUqJWDYZ1ozwNZUsvzwAgAB1DwCAAGOHgA== Date: Thu, 25 Aug 2011 13:53:01 +0000 Message-ID: In-Reply-To: <2255BAD1-C498-4F08-AC5E-8676091E697C@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.249.124.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <994257FFB1191241A0461BB1011CE74D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:51:56 -0000 I understand, however as enablement progresses more devices that are IPv6 enabled continue to transmit requests. This multiplied by the fact that these devices systematically attempt to reinitialize DHCPv6 every "n" minutes generates a lot of traffic. Even with the exponential back off between SOLICITs. Consider the following: * every "n" minutes * a series of DHCPv6 SOLICITs are sent exponentially backing off between each The more devices doing this generates lots of traffic. If M and O were in place to influence the behavior the same could be set to influence the behavior of the clients. Further, if the rate or frequency of RAs with M and/or O set to 1 further altered the rate of DHCPv6 requests there could be added benefit. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/24/11 11:58 PM, "Ted Lemon" wrote: >On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote: > >Add > exponential back offs and the volume of DHCPv6 messages grows >exponentially. Just sent some mail on this when replying to another >thread. > > > >This doesn't make sense. The point of exponential backoff is that >traffic should shrink over time, not grow. > > From rajiva@cisco.com Thu Aug 25 07:08:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BC121F8781 for ; Thu, 25 Aug 2011 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur3nQwkYpncz for ; Thu, 25 Aug 2011 07:08:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2D221F8772 for ; Thu, 25 Aug 2011 07:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2484; q=dns/txt; s=iport; t=1314281380; x=1315490980; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RuExT2xjGUI1IWxGsQjFdn7GzuMpaYUxEtljXaUgdIQ=; b=DtCndDjTNQFpJUect9MGDIxw8Z1Y+tpP1pUC5ZyObLhiROoJGbUyPslV Li3xKuUjT4KC2KydQvQjugIXeZepD44dqy/RbWaXLBcSxJs7wRAjOoAtv 7VupcCjP2wULq0UWlK4Uw6MO9+BpGjNBGFzUi9vF/4UGmaSjNL0PVXp1B g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAHhXVk6tJXHB/2dsb2JhbAA/A5gpj1h3gTkHAQEBAQMBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAIEARIIGodUnAQBnwuDQoIqYASHYZBOjAM X-IronPort-AV: E=Sophos;i="4.68,281,1312156800"; d="scan'208";a="16431609" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 25 Aug 2011 14:09:28 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7PE9Scl017177; Thu, 25 Aug 2011 14:09:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 09:09:27 -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 Date: Thu, 25 Aug 2011 09:09:27 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBD05E@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AQHMYpMJSdqOmTc9JUqJWDYZ1ozwNZUsvzwAgAB1DwCAAGOHgIAAA4/Q References: <2255BAD1-C498-4F08-AC5E-8676091E697C@nominum.com> From: "Rajiv Asati (rajiva)" To: "Brzozowski, John" , "Ted Lemon" X-OriginalArrivalTime: 25 Aug 2011 14:09:27.0905 (UTC) FILETIME=[99EEDD10:01CC6330] Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 14:08:27 -0000 +1, and in the access, the bandwidth is not always cheap. So, whatever we can do to save bandwidth from unnecessary usage, we should seriously consider that. I continue to think that keep sending SOLICIT without even knowing where the router is, and whether the router is available for serving DHCPv6, is not an optimal recipe. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Brzozowski, John > Sent: Thursday, August 25, 2011 9:53 AM > To: Ted Lemon > Cc: IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >=20 > I understand, however as enablement progresses more devices that are IPv6 > enabled continue to transmit requests. This multiplied by the fact that > these devices systematically attempt to reinitialize DHCPv6 every "n" > minutes generates a lot of traffic. Even with the exponential back off > between SOLICITs. >=20 > Consider the following: >=20 > * every "n" minutes > * a series of DHCPv6 SOLICITs are sent exponentially backing off between > each >=20 > The more devices doing this generates lots of traffic. If M and O were in > place to influence the behavior the same could be set to influence the > behavior of the clients. Further, if the rate or frequency of RAs with M > and/or O set to 1 further altered the rate of DHCPv6 requests there could > be added benefit. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > On 8/24/11 11:58 PM, "Ted Lemon" wrote: >=20 > >On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote: > > > >Add > > exponential back offs and the volume of DHCPv6 messages grows > >exponentially. Just sent some mail on this when replying to another > >thread. > > > > > > > >This doesn't make sense. The point of exponential backoff is that > >traffic should shrink over time, not grow. > > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Thu Aug 25 07:43:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881AC21F86B1 for ; Thu, 25 Aug 2011 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYxa9ndkk8FZ for ; Thu, 25 Aug 2011 07:43:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC5E21F86FF for ; Thu, 25 Aug 2011 07:43:53 -0700 (PDT) Received: by wyg8 with SMTP id 8so1976462wyg.31 for ; Thu, 25 Aug 2011 07:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=jJQuH/qoYWENNP70Lcd4Ohsk6e5ZrpRgHe2NTKjEecg=; b=OTW0swLV6m6XSf3sBj/8X26ZHq3oAyuOhN4HoXbMSvPH1qvzupPCa8ZUK/ozV3uOT9 eqmrQlW0a9a5dKUVxShbSvHQ17sAWAYkTw0Rnz5+Pov53dQ1MbJxh5FndOBTZzigfdL+ 1h9w1SdGUj7qmzgGn3qt6gPlNrtkwGwGhKVow= Received: by 10.216.162.134 with SMTP id y6mr716046wek.43.1314283325165; Thu, 25 Aug 2011 07:42:05 -0700 (PDT) Received: from ams3-vpn-dhcp6574.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fm9sm508025wbb.44.2011.08.25.07.42.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 07:42:03 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBD05E@XMB-RCD-111.cisco.com> Date: Thu, 25 Aug 2011 16:41:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2255BAD1-C498-4F08-AC5E-8676091E697C@nominum.com> <067E6CE33034954AAC05C9EC85E2577C05BBD05E@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 14:43:54 -0000 > +1, and in the access, the bandwidth is not always cheap. So, whatever > we can do to save bandwidth from unnecessary usage, we should = seriously > consider that. one packet every 120 seconds, that gets discarded at the first hop? if we're that concerned about saving bandwidth I would pick a few lower = hanging fruits. > I continue to think that keep sending SOLICIT without even knowing = where > the router is, and whether the router is available for serving DHCPv6, > is not an optimal recipe. "the router", what router? cheers, Ole >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > Of >> Brzozowski, John >> Sent: Thursday, August 25, 2011 9:53 AM >> To: Ted Lemon >> Cc: IPv6 Operations >> Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit >>=20 >> I understand, however as enablement progresses more devices that are > IPv6 >> enabled continue to transmit requests. This multiplied by the fact > that >> these devices systematically attempt to reinitialize DHCPv6 every "n" >> minutes generates a lot of traffic. Even with the exponential back > off >> between SOLICITs. >>=20 >> Consider the following: >>=20 >> * every "n" minutes >> * a series of DHCPv6 SOLICITs are sent exponentially backing off > between >> each >>=20 >> The more devices doing this generates lots of traffic. If M and O > were in >> place to influence the behavior the same could be set to influence = the >> behavior of the clients. Further, if the rate or frequency of RAs > with M >> and/or O set to 1 further altered the rate of DHCPv6 requests there > could >> be added benefit. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >> On 8/24/11 11:58 PM, "Ted Lemon" wrote: >>=20 >>> On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote: >>>=20 >>> Add >>> exponential back offs and the volume of DHCPv6 messages grows >>> exponentially. Just sent some mail on this when replying to another >>> thread. >>>=20 >>>=20 >>>=20 >>> This doesn't make sense. The point of exponential backoff is that >>> traffic should shrink over time, not grow. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ek@google.com Thu Aug 25 08:19:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBDA21F857D for ; Thu, 25 Aug 2011 08:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAk4rBJYlTwV for ; Thu, 25 Aug 2011 08:19:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B1E4F21F8574 for ; Thu, 25 Aug 2011 08:19:42 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p7PFKldo024692 for ; Thu, 25 Aug 2011 08:20:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314285649; bh=zXtYeW/ynrp+9ghW4q8bqGdZheQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=tlLQThLs/23IT6qVuRiVdItvyt/ADe5NwBItMzXTPQk5rix//ij6dopszf3b9CiYQ tgGKJ7SrXeTkBOu8c/58Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=yN+xVlM2pbeKJP5jEU7QmquEqF+UV8chB1LPPe+YVfF0daC+u+QrTdR7ii4o9HYDW v1EYza7T0gHpA8owFPD4g== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by wpaz24.hot.corp.google.com with ESMTP id p7PFKdRv008729 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 25 Aug 2011 08:20:46 -0700 Received: by qyk9 with SMTP id 9so1823956qyk.13 for ; Thu, 25 Aug 2011 08:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z7RU0dz2nAZxgaihnFtCoGqOdcFCdizGWapn3uoCkWU=; b=XSGU6Y7YNoGxmSD611h7TGZtfKRk4nMCdj6NB/ebtcCxePXrAYfZ+EY02YV9JkC93D 39pECLxbL0DT6DFjMaBA== Received: by 10.229.44.41 with SMTP id y41mr674450qce.217.1314285646477; Thu, 25 Aug 2011 08:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.41 with SMTP id y41mr674443qce.217.1314285646340; Thu, 25 Aug 2011 08:20:46 -0700 (PDT) Received: by 10.229.158.7 with HTTP; Thu, 25 Aug 2011 08:20:46 -0700 (PDT) In-Reply-To: References: <2255BAD1-C498-4F08-AC5E-8676091E697C@nominum.com> Date: Fri, 26 Aug 2011 00:20:46 +0900 Message-ID: From: Erik Kline To: "Brzozowski, John" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:19:43 -0000 On 25 August 2011 22:53, Brzozowski, John wrote: > I understand, however as enablement progresses more devices that are IPv6 > enabled continue to transmit requests. =C2=A0This multiplied by the fact = that > these devices systematically attempt to reinitialize DHCPv6 every "n" > minutes generates a lot of traffic. =C2=A0Even with the exponential back = off > between SOLICITs. > > Consider the following: > > * every "n" minutes > * a series of DHCPv6 SOLICITs are sent exponentially backing off between > each > > The more devices doing this generates lots of traffic. =C2=A0If M and O w= ere in > place to influence the behavior the same could be set to influence the > behavior of the clients. =C2=A0Further, if the rate or frequency of RAs w= ith M > and/or O set to 1 further altered the rate of DHCPv6 requests there could > be added benefit. And how much traffic is generated if you just answer these requests? ;-) From john_brzozowski@cable.comcast.com Thu Aug 25 09:55:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844221F8AFD for ; Thu, 25 Aug 2011 09:55:05 -0700 (PDT) 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=[AWL=-1.466, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUcuyRQ0RxMC for ; Thu, 25 Aug 2011 09:55:05 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19821F8AF9 for ; Thu, 25 Aug 2011 09:55:04 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.50352455; Thu, 25 Aug 2011 11:01:52 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 25 Aug 2011 12:56:11 -0400 From: "Brzozowski, John" To: Erik Kline Thread-Topic: [v6ops] When an RG should issue a DHCPv6 solicit Thread-Index: AcxjR+QqSdqOmTc9JUqJWDYZ1ozwNQ== Date: Thu, 25 Aug 2011 16:56:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_hqhn17cxtakyphcdaisgdld71314291123577emailandroidcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:55:05 -0000 --_000_hqhn17cxtakyphcdaisgdld71314291123577emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXVjaCBsZXNzIG9mIGNvdXJzZSBkZXBlbmRpbmcgb24gcmVuZXcvcmViaW5kIHRpbWVycy4NCg0K VGhlIGtub2JzIHJlcXVpcmVkIHRvIGFsbG93IGZvciBhIGNvbnRyb2xsZWQgaW50cm9kdWN0aW9u IGFyZSBzdGlsbCBtaXNzaW5nIHdoaWNoIHNob3VsZCBiZSBhZGRyZXNzZWQuDQoNCkpvaG4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFcmlrIEtsaW5lDQpTZW50OiBU aHUsIEF1ZyAyNSwgMjAxMSAxMToyMCBBTQ0KVG86ICJCcnpvem93c2tpLCBKb2huIg0KQ0M6VGVk IExlbW9uICxJUHY2IE9wZXJhdGlvbnMNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFdoZW4gYW4gUkcg c2hvdWxkIGlzc3VlIGEgREhDUHY2IHNvbGljaXQNCk9uIDI1IEF1Z3VzdCAyMDExIDIyOjUzLCBC cnpvem93c2tpLCBKb2huDQo8Sm9obl9Ccnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPiB3cm90 ZToNCj4gSSB1bmRlcnN0YW5kLCBob3dldmVyIGFzIGVuYWJsZW1lbnQgcHJvZ3Jlc3NlcyBtb3Jl IGRldmljZXMgdGhhdCBhcmUgSVB2Ng0KPiBlbmFibGVkIGNvbnRpbnVlIHRvIHRyYW5zbWl0IHJl cXVlc3RzLiAgVGhpcyBtdWx0aXBsaWVkIGJ5IHRoZSBmYWN0IHRoYXQNCj4gdGhlc2UgZGV2aWNl cyBzeXN0ZW1hdGljYWxseSBhdHRlbXB0IHRvIHJlaW5pdGlhbGl6ZSBESENQdjYgZXZlcnkgIm4i DQo+IG1pbnV0ZXMgZ2VuZXJhdGVzIGEgbG90IG9mIHRyYWZmaWMuICBFdmVuIHdpdGggdGhlIGV4 cG9uZW50aWFsIGJhY2sgb2ZmDQo+IGJldHdlZW4gU09MSUNJVHMuDQo+DQo+IENvbnNpZGVyIHRo ZSBmb2xsb3dpbmc6DQo+DQo+ICogZXZlcnkgIm4iIG1pbnV0ZXMNCj4gKiBhIHNlcmllcyBvZiBE SENQdjYgU09MSUNJVHMgYXJlIHNlbnQgZXhwb25lbnRpYWxseSBiYWNraW5nIG9mZiBiZXR3ZWVu DQo+IGVhY2gNCj4NCj4gVGhlIG1vcmUgZGV2aWNlcyBkb2luZyB0aGlzIGdlbmVyYXRlcyBsb3Rz IG9mIHRyYWZmaWMuICBJZiBNIGFuZCBPIHdlcmUgaW4NCj4gcGxhY2UgdG8gaW5mbHVlbmNlIHRo ZSBiZWhhdmlvciB0aGUgc2FtZSBjb3VsZCBiZSBzZXQgdG8gaW5mbHVlbmNlIHRoZQ0KPiBiZWhh dmlvciBvZiB0aGUgY2xpZW50cy4gIEZ1cnRoZXIsIGlmIHRoZSByYXRlIG9yIGZyZXF1ZW5jeSBv ZiBSQXMgd2l0aCBNDQo+IGFuZC9vciBPIHNldCB0byAxIGZ1cnRoZXIgYWx0ZXJlZCB0aGUgcmF0 ZSBvZiBESENQdjYgcmVxdWVzdHMgdGhlcmUgY291bGQNCj4gYmUgYWRkZWQgYmVuZWZpdC4NCg0K PHNuYXJreT4NCkFuZCBob3cgbXVjaCB0cmFmZmljIGlzIGdlbmVyYXRlZCBpZiB5b3UganVzdCBh bnN3ZXIgdGhlc2UgcmVxdWVzdHM/ICA7LSkNCjwvc25hcmt5Pg0K --_000_hqhn17cxtakyphcdaisgdld71314291123577emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KTXVjaCBsZXNzIG9m IGNvdXJzZSBkZXBlbmRpbmcgb24gcmVuZXcvcmViaW5kIHRpbWVycy4gPGJyPg0KPGJyPg0KVGhl IGtub2JzIHJlcXVpcmVkIHRvIGFsbG93IGZvciBhIGNvbnRyb2xsZWQgaW50cm9kdWN0aW9uIGFy ZSBzdGlsbCBtaXNzaW5nIHdoaWNoIHNob3VsZCBiZSBhZGRyZXNzZWQuPGJyPg0KPGJyPg0KSm9o biA8YnI+DQo8aHI+DQo8Yj5Gcm9tOjwvYj4gRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT48YnI+ DQo8Yj5TZW50OjwvYj4gVGh1LCBBdWcgMjUsIDIwMTEgMTE6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+ ICZxdW90O0Jyem96b3dza2ksIEpvaG4mcXVvdDsgPEpvaG5fQnJ6b3pvd3NraUBDYWJsZS5Db21j YXN0LmNvbT48YnI+DQo8Yj5DQzo8L2I+VGVkIExlbW9uIDxUZWQuTGVtb25Abm9taW51bS5jb20+ LElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdjZvcHNdIFdoZW4gYW4gUkcgc2hvdWxkIGlzc3VlIGEgREhDUHY2IHNvbGljaXQ8YnI+DQo8 bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIi Pg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSB0ZXh0IC0tPjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsg bWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1sZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAw IDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5PbiAyNSBBdWd1c3QgMjAxMSAy Mjo1MywgQnJ6b3pvd3NraSwgSm9objxicj4NCiZsdDtKb2huX0Jyem96b3dza2lAY2FibGUuY29t Y2FzdC5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSSB1bmRlcnN0YW5kLCBob3dldmVyIGFzIGVu YWJsZW1lbnQgcHJvZ3Jlc3NlcyBtb3JlIGRldmljZXMgdGhhdCBhcmUgSVB2Njxicj4NCiZndDsg ZW5hYmxlZCBjb250aW51ZSB0byB0cmFuc21pdCByZXF1ZXN0cy4gJm5ic3A7VGhpcyBtdWx0aXBs aWVkIGJ5IHRoZSBmYWN0IHRoYXQ8YnI+DQomZ3Q7IHRoZXNlIGRldmljZXMgc3lzdGVtYXRpY2Fs bHkgYXR0ZW1wdCB0byByZWluaXRpYWxpemUgREhDUHY2IGV2ZXJ5ICZxdW90O24mcXVvdDs8YnI+ DQomZ3Q7IG1pbnV0ZXMgZ2VuZXJhdGVzIGEgbG90IG9mIHRyYWZmaWMuICZuYnNwO0V2ZW4gd2l0 aCB0aGUgZXhwb25lbnRpYWwgYmFjayBvZmY8YnI+DQomZ3Q7IGJldHdlZW4gU09MSUNJVHMuPGJy Pg0KJmd0Ozxicj4NCiZndDsgQ29uc2lkZXIgdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAqIGV2ZXJ5ICZxdW90O24mcXVvdDsgbWludXRlczxicj4NCiZndDsgKiBhIHNlcmllcyBv ZiBESENQdjYgU09MSUNJVHMgYXJlIHNlbnQgZXhwb25lbnRpYWxseSBiYWNraW5nIG9mZiBiZXR3 ZWVuPGJyPg0KJmd0OyBlYWNoPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG1vcmUgZGV2aWNlcyBk b2luZyB0aGlzIGdlbmVyYXRlcyBsb3RzIG9mIHRyYWZmaWMuICZuYnNwO0lmIE0gYW5kIE8gd2Vy ZSBpbjxicj4NCiZndDsgcGxhY2UgdG8gaW5mbHVlbmNlIHRoZSBiZWhhdmlvciB0aGUgc2FtZSBj b3VsZCBiZSBzZXQgdG8gaW5mbHVlbmNlIHRoZTxicj4NCiZndDsgYmVoYXZpb3Igb2YgdGhlIGNs aWVudHMuICZuYnNwO0Z1cnRoZXIsIGlmIHRoZSByYXRlIG9yIGZyZXF1ZW5jeSBvZiBSQXMgd2l0 aCBNPGJyPg0KJmd0OyBhbmQvb3IgTyBzZXQgdG8gMSBmdXJ0aGVyIGFsdGVyZWQgdGhlIHJhdGUg b2YgREhDUHY2IHJlcXVlc3RzIHRoZXJlIGNvdWxkPGJyPg0KJmd0OyBiZSBhZGRlZCBiZW5lZml0 Ljxicj4NCjxicj4NCiZsdDtzbmFya3kmZ3Q7PGJyPg0KQW5kIGhvdyBtdWNoIHRyYWZmaWMgaXMg Z2VuZXJhdGVkIGlmIHlvdSBqdXN0IGFuc3dlciB0aGVzZSByZXF1ZXN0cz8mbmJzcDsgOy0pPGJy Pg0KJmx0Oy9zbmFya3kmZ3Q7PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_hqhn17cxtakyphcdaisgdld71314291123577emailandroidcom_-- From lee@asgard.org Thu Aug 25 10:36:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B4621F8BEF for ; Thu, 25 Aug 2011 10:36:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHsWVwZvXK78 for ; Thu, 25 Aug 2011 10:36:30 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 5526D21F8BEC for ; Thu, 25 Aug 2011 10:36:30 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7PHbbuw004690 for ; Thu, 25 Aug 2011 13:37:39 -0400 Authentication-Results: cm-omr12 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.165] ([204.235.115.165:19471] helo=HDC00027112) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5D/A3-02902-068865E4; Thu, 25 Aug 2011 13:37:37 -0400 From: "Lee Howard" To: "'james woodyatt'" , "'IPv6 Operations'" References: <003101cc611d$cc0642d0$6412c870$@iname.com> <001f01cc612d$4dc88030$e9598090$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F1EB3EF83@crexc50p> <067E6CE33034954AAC05C9EC85E2577C05BBCADD@XMB-RCD-111.cisco.com> <79689D59-4F01-4599-B26D-26ED1B77BB94@apple.com> <0E9859AF-EF07-4D5A-9499-2A6A142904BC@apple.com> <4E55632C.1030806@raszuk.net> In-Reply-To: Date: Thu, 25 Aug 2011 13:37:35 -0400 Message-ID: <000001cc634d$ae4cc480$0ae64d80$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acxi1a+RhuQZnLFwQ9ujrdQwfa0T2QAdfbog Content-Language: en-us Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 17:36:31 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james > woodyatt > Sent: Wednesday, August 24, 2011 11:19 PM > To: IPv6 Operations > Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit > > On Aug 24, 2011, at 13:46 , Robert Raszuk wrote: > > > > ...which we like it or not will be randomly plugged in and what's worse .. expected to > work :) > > The best way to signal to said ordinary people that they shouldn't expect anything useful to > happen by inserting this plug into that jack is to assign the job to a mechanical engineer. > People seem to understand that delicate electronics gear shouldn't require a hammer and > pliers to close the network connection loops. If we built a smiley-face plug for Homenet use, somebody would invent a smiley-to-RJ45 dongle. Also out of scope is the sadness people will feel if they plug their Ethernet RJ45 into a T1 jack, or their MoCA interface into Arcnet. When I was an IT guy, I shut down unauthorized routers where I found them. If I still were one, I would: * not respond to IA_PD requests, * continue tracking/removing unauthorized routers as I found them * not worry about the volume of DHCPv6 SOLICITs on my LAN If IT administrators wants to use Homenet boxes to build their network, they're going to have limitations. Some of those may be remedied with a different software build, (designed for commercial use) in which case they might actually be happy to have RJ45s instead of smiley plugs. Can we move this to Homenet? Lee From joelja@bogus.com Thu Aug 25 20:54:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0B21F8AA9 for ; Thu, 25 Aug 2011 20:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6F6Bp-sfFS5 for ; Thu, 25 Aug 2011 20:54:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B617321F8A91 for ; Thu, 25 Aug 2011 20:54:56 -0700 (PDT) Received: from [192.168.43.44] (md20536d0.tmodns.net [208.54.5.210]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7Q3u69k090238 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 26 Aug 2011 03:56:08 GMT (envelope-from joelja@bogus.com) Message-ID: <4E571950.7050708@bogus.com> Date: Thu, 25 Aug 2011 20:56:00 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Thomas Narten References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 26 Aug 2011 03:56:09 +0000 (UTC) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 03:54:57 -0000 On 8/23/11 08:46 , Thomas Narten wrote: > IMO, the real elephant in the room is that there are too many drafts > covering marginal work topics. But rather than tell people "no", we > allow work to continue, even enable it (e.g., by saying "we'll discuss > further on the list", when in fact, little useful discussion happens > but the ID gets respun and gets presented again at the next > meeting). And given the that the WG (and in fact any WG) has a finite > amount of clue/cycles, if you stretch that too thin, you start > thrashing, and then you are really in a fix. While I largly agree with the sentiment, we've also engaged in some signficant backpressure on not presenting documents which have not been discussed. > The WG needs to focus on stuff that matters, and say "no" to > everything else. > > Absent a real willingness to do this, splitting the WG up is nothing > more then rearranging the deck chairs... > > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Aug 26 06:53:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5744521F86EE for ; Fri, 26 Aug 2011 06:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.932 X-Spam-Level: X-Spam-Status: No, score=-104.932 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keZqMlXZSGuz for ; Fri, 26 Aug 2011 06:53:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BB23C21F86AA for ; Fri, 26 Aug 2011 06:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=132; q=dns/txt; s=iport; t=1314366901; x=1315576501; h=date:from:message-id:to:subject:cc; bh=jtrQbZ3EU7cmB8+A5m6mFBP6Ls4mPzzVZo2UswvLIuw=; b=Hn+EoNpcCOnCMlBPdnxlXYfaIqZd/y6XnsIYJYwbIY0EKYAjsyzk9OlP i1T+YMyhrOTkL9oIKE6qtJR0xwbXqhS2rS2fsiTk5GBLHFHGL676vz13A 6WaOCA1IDRHqTHyY2xry5cGEykqZzR1koOSy7e/OjiPE3cvxq+NfI/3g6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsASACOlV06rRDoG/2dsb2JhbABCmH0BAYNgizl3gVkBZjwtgQqHVJsTAZ8chkwEh2KcWA X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16805129" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 26 Aug 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QDt0o9020822; Fri, 26 Aug 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p7QDt0r13136; Fri, 26 Aug 2011 06:55:00 -0700 (PDT) Date: Fri, 26 Aug 2011 06:55:00 -0700 (PDT) From: Message-Id: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-asati-v6ops-dad-loopback@tools.ietf.org Subject: [v6ops] new draft: draft-asati-v6ops-dad-loopback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:53:45 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-asati-v6ops-dad-loopback. Please take a look at it and comment. From wesley.george@twcable.com Fri Aug 26 06:55:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A79721F8B9D for ; Fri, 26 Aug 2011 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+fKvpex8jIS for ; Fri, 26 Aug 2011 06:55:32 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 265FB21F8B5C for ; Fri, 26 Aug 2011 06:55:29 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,432,1309752000"; d="scan'208";a="266574310" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 09:54:49 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 26 Aug 2011 09:56:45 -0400 From: "George, Wesley" To: "Rajiv Asati (rajiva)" , Thomas Narten , Scott Beuker Date: Fri, 26 Aug 2011 09:56:43 -0400 Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: Acxhsilucsrw0kpvTdawYS9qU1tK5wA5YWbwAFeK+2A= Message-ID: <34E4F50CAFA10349A41E0756550084FB0DBB3C55@PRVPEXVS04.corp.twcable.com> References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com><20110816141748.GF72014@Space.Net><067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com><4E4AEE2E.4030000@es.net><1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD> <201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> <067E6CE33034954AAC05C9EC85E2577C05BBCEA2@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCEA2@XMB-RCD-111.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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:55:33 -0000 Rajiv - I've reviewed your draft, and I have some comments on your solution algorit= hm. I agree that this is a potential problem, and I support this work. I think that there are some situations where this will still result in the = original brokenness - If the loop is placed, but the problem is intermitten= t, the following might occur: Loop up Step 1 Step 2 Loop drops (fault on the line) causing step 3 to fail step 4/5, leading to disabled IPv6. The above is a corner case example, but does happen. It may be necessary to= add some explicit recommendation that if the interface changes state, ever= ything resets and the duplicate is ignored, rather than simply relying on t= imers. An alternate way to do this is to recommend that the implementation uses an= y built-in loop detection mechanism of the underlying interface to signal N= D to temporarily disable DAD. For example, when a Cisco router sees a certain set of conditions on an int= erface using HDLC, the interface shows up/up (looped). It should be possibl= e to simply use that state change as a trigger to disable DAD temporarily, = and when the state changes back to down or up (but not looped) DAD is re-en= abled. Your proposed solution would still be a good recommended enhancement for im= plementations that do not have some lower-layer method to detect the presen= ce of a loop. Thanks, Wes George -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= ajiv Asati (rajiva) Sent: Wednesday, August 24, 2011 3:57 PM To: Thomas Narten; Scott Beuker Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments Thomas, Please see inline, > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. Well, the ND messages are likely handled by the CPU, which may not get involved for forwarding packets. So, whether or not the interface is being used (for forwarding packets) is irrelevant for ND messages handling. > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. Agreed. I have drafted the ID and would submit in a week or so. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Tuesday, August 23, 2011 11:30 AM > To: Scott Beuker > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments > > > > What is wrong with retrying periodically? The point is to do this > > > every few tens of seconds, or every minute or two, so as to avoid > > > spending a lot of CPU on DAD. However, the desire is that layer 3 > > > be self healing once layer 2 has been fixed. IPv4 is self-healing > > > in this way. IPv6 is currently not. > > > +1 > > I agree. The other thing to keep in mind is that if an interface is in > loopback mode, the interface is effectively not working (i.e,. not > forwarding traffic), and any "load" caused by such probes is > pretty much irrelevant. > > What I'd suggest as a next step is that someone write a short ID that > describes the problem, and sketches out a recommended algorithm for > handling this situation. > > E.g., use NS/ND probes to detect the condition, switch to periodic > probing mode when the interface is in loopback, and then describe > how/when to switch back to normal mode. > > This appears to be doable using existing packet/option formats, so no > new protocol extensions are needed. > > We can then publish it as a short BCP or informational document (we > can figure out later which once the actual content has been worked > out). > > Do we have a taker? > > Thomas > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From rajiva@cisco.com Fri Aug 26 08:06:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1F521F8B00 for ; Fri, 26 Aug 2011 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKfauD2+Feao for ; Fri, 26 Aug 2011 08:06:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDF321F8AFF for ; Fri, 26 Aug 2011 08:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6896; q=dns/txt; s=iport; t=1314371267; x=1315580867; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Jq+Y8+78FO32i4i/klu4O1AQfYHPA+kFsTkUAq5PGr0=; b=UY/hLlYQ0hA6vJj21ZmtiwqaC4HTrcaek13EhNhYqeaGtmKXtsZTHvzb c2ZTrT5+Jatd4eMzl681f14j0Jpure6VkpgMRkmELyfxSms+sdglsQbut rXAw7pVUvNFTDOUfAKiOFtrU4RDyWoE82TZwwMd6Da+e+kIJZJdrWBb1I U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAADu2V06tJXG8/2dsb2JhbABCmEWPXXeBQAEBAQECAQEBAQ8BHQo0BAcFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh1AEmmABnxuFbGAEh2KQTowI X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16822203" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2011 15:07:46 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QF7kBs006132; Fri, 26 Aug 2011 15:07:46 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 10:07:46 -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 Date: Fri, 26 Aug 2011 10:07:45 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05C85D43@XMB-RCD-111.cisco.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0DBB3C55@PRVPEXVS04.corp.twcable.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DAD issues in IPv6 backbone environments Thread-Index: Acxhsilucsrw0kpvTdawYS9qU1tK5wA5YWbwAFeK+2AAAKy0YA== References: <4E49D9DB.5060109@es.net><201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com><20110816.154827.78743604.sthaug@nethelp.no><20110816135546.GE72014@Space.Net><201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com><20110816141748.GF72014@Space.Net><067E6CE33034954AAC05C9EC85E2577C05B1A902@XMB-RCD-111.cisco.com><4E4AEE2E.4030000@es.net><1CB1702389DB184EBD9A463AD7A84B42013D38@PRDCG4MBXW03.OSS.PRD><201108231530.p7NFURkL008288@cichlid.raleigh.ibm.com> <067E6CE33034954AAC05C9EC85E2577C05BBCEA2@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0DBB3C55@PRVPEXVS04.corp.twcable.com> From: "Rajiv Asati (rajiva)" To: "George, Wesley" , "Thomas Narten" , "Scott Beuker" X-OriginalArrivalTime: 26 Aug 2011 15:07:46.0262 (UTC) FILETIME=[E9878760:01CC6401] Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:06:31 -0000 Hi George, Appreciate the feedback. > I agree that this is a potential problem, and I support this work. Thanks. > Loop up > Step 1 > Step 2 > Loop drops (fault on the line) causing step 3 to fail > step 4/5, leading to disabled IPv6. If the loop dropped, then=20 - If the interface stayed UP, then step 5 result in keeping IPv6 enabled on that interface, since the same NS message as the one transmitted should no longer be removed. - If the interface went DOWN, then IPv6 would stay enabled (since step 2 hadn't disabled it) and follow the normal course (this needs to be phrased better in the draft, as you suggest below). > The above is a corner case example, but does happen. It may be necessary to > add some explicit recommendation that if the interface changes state, > everything resets and the duplicate is ignored, rather than simply relying on > timers. Good suggestion. I agree to adding this text. > An alternate way to do this is to recommend that the implementation uses any > built-in loop detection mechanism of the underlying interface to signal ND to > temporarily disable DAD. Good suggestion. That's worth adding as the 3rd solution as well.=20 > Your proposed solution would still be a good recommended enhancement for > implementations that do not have some lower-layer method to detect the > presence of a loop. I agree. =20 Cheers, Rajiv > -----Original Message----- > From: George, Wesley [mailto:wesley.george@twcable.com] > Sent: Friday, August 26, 2011 9:57 AM > To: Rajiv Asati (rajiva); Thomas Narten; Scott Beuker > Cc: v6ops@ietf.org > Subject: RE: [v6ops] DAD issues in IPv6 backbone environments >=20 > Rajiv - >=20 > I've reviewed your draft, and I have some comments on your solution algorithm. > I agree that this is a potential problem, and I support this work. > I think that there are some situations where this will still result in the > original brokenness - If the loop is placed, but the problem is intermittent, > the following might occur: >=20 > Loop up > Step 1 > Step 2 > Loop drops (fault on the line) causing step 3 to fail > step 4/5, leading to disabled IPv6. > The above is a corner case example, but does happen. It may be necessary to > add some explicit recommendation that if the interface changes state, > everything resets and the duplicate is ignored, rather than simply relying on > timers. >=20 > An alternate way to do this is to recommend that the implementation uses any > built-in loop detection mechanism of the underlying interface to signal ND to > temporarily disable DAD. > For example, when a Cisco router sees a certain set of conditions on an > interface using HDLC, the interface shows up/up (looped). It should be > possible to simply use that state change as a trigger to disable DAD > temporarily, and when the state changes back to down or up (but not looped) > DAD is re-enabled. > Your proposed solution would still be a good recommended enhancement for > implementations that do not have some lower-layer method to detect the > presence of a loop. >=20 > Thanks, >=20 > Wes George >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Wednesday, August 24, 2011 3:57 PM > To: Thomas Narten; Scott Beuker > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments >=20 > Thomas, >=20 > Please see inline, >=20 > > I agree. The other thing to keep in mind is that if an interface is in > > loopback mode, the interface is effectively not working (i.e,. not > > forwarding traffic), and any "load" caused by such probes is > > pretty much irrelevant. >=20 > Well, the ND messages are likely handled by the CPU, which may not get > involved for forwarding packets. So, whether or not the interface is > being used (for forwarding packets) is irrelevant for ND messages > handling. >=20 > > This appears to be doable using existing packet/option formats, so no > > new protocol extensions are needed. >=20 > Agreed. I have drafted the ID and would submit in a week or so. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Thomas Narten > > Sent: Tuesday, August 23, 2011 11:30 AM > > To: Scott Beuker > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] DAD issues in IPv6 backbone environments > > > > > > What is wrong with retrying periodically? The point is to do this > > > > every few tens of seconds, or every minute or two, so as to avoid > > > > spending a lot of CPU on DAD. However, the desire is that layer 3 > > > > be self healing once layer 2 has been fixed. IPv4 is self-healing > > > > in this way. IPv6 is currently not. > > > > > +1 > > > > I agree. The other thing to keep in mind is that if an interface is in > > loopback mode, the interface is effectively not working (i.e,. not > > forwarding traffic), and any "load" caused by such probes is > > pretty much irrelevant. > > > > What I'd suggest as a next step is that someone write a short ID that > > describes the problem, and sketches out a recommended algorithm for > > handling this situation. > > > > E.g., use NS/ND probes to detect the condition, switch to periodic > > probing mode when the interface is in loopback, and then describe > > how/when to switch back to normal mode. > > > > This appears to be doable using existing packet/option formats, so no > > new protocol extensions are needed. > > > > We can then publish it as a short BCP or informational document (we > > can figure out later which once the actual content has been worked > > out). > > > > Do we have a taker? > > > > Thomas > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. From frnkblk@iname.com Fri Aug 26 09:08:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE9721F8C15 for ; Fri, 26 Aug 2011 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMe+eiUQdq4k for ; Fri, 26 Aug 2011 09:08:33 -0700 (PDT) Received: from premieronline.net (smtp2-3.premieronline.net [96.31.0.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA9F21F8C60 for ; Fri, 26 Aug 2011 09:08:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 3491841-1729245 for multiple; Fri, 26 Aug 2011 11:09:48 -0500 From: "Frank Bulk" To: "'Thomas Narten'" , References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> In-Reply-To: <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> Date: Fri, 26 Aug 2011 11:09:49 -0500 Message-ID: <005901cc640a$94b4a8e0$be1dfaa0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxcGaPNmeSEenjzThmnmKLdfZhEyQH713Pw Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=6 Friend=374 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 899, in=14087515, out=52991, spam=0 Known=true ip=199.120.69.26 Cc: IETF v6ops list Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:08:34 -0000 Except the person(s) testing the link may not be the same people that can disable/renable DAD for the test. If v4 normals without intervening on L3, v6 should, too. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Tuesday, August 16, 2011 8:24 AM To: dart@es.net Cc: IETF v6ops list Subject: Re: [v6ops] DAD issues in IPv6 backbone environments Having a configuration knob to turn of DAD to deal with these sorts of issues seems perfectly reasonable to me. Fine for a router, seems unnecessary for a host. Disabled by default. I don't think any spec needs to be changed. This is an example of the kind of thing an implementation should just be able to do if necessary. Thomas Eli Dart writes: > Hi all, > We have run across an operational issue with IPv6 in backbone > environments. The issue concerns Duplicate Address Detection (DAD). > It is common in backbone environments to troubleshoot some transport > system issues by installing soft loops in the middle of the problem > circuit facing the ends, and walking the loops out toward the routers at > the ends while checking for connectivity. This is a common > fault-isolation technique. In an IPv4 network, connectivity on the > circuit is restored when the loops are removed and the circuit is > normalized. In an IPv6 network, this is not always the case. > In an IPv6 network, when the loops are installed the routers at the ends > see themselves and therefore believe that another host in the same > broadcast domain has the same address. RFC 4862 section 5.4.5 states > that when DAD detects a duplicate address that appears to be derived > from a hardware address (e.g. duplicate link-local address), IPv6 > operation on the interface SHOULD be disabled. Since the circuit is > looped back on itself, the router sees itself and shuts down IPv6 > processing on that interface. > The result of this behavior is that transport-layer troubleshooting can > break IPv6, and IPv6 can stay broken even after the circuit is > normalized (soft loops can be installed and removed without causing the > interface to bounce, so DAD is never reset). IPv4 does not have DAD, so > IPv4 is self-healing under these circumstances. Therefore, you can get > into a situation where IPv4 has self-healed, and IPv6 stays broken until > somebody notices. > ESnet has asked one of our router vendors for an interface config knob > (off-by-default so as to avoid direct confrontation with standards) that > would cause a router with an interface disabled due to DAD to re-run the > DAD test on the interface periodically, subject to a timer. This would > cause IPv6 to be self-healing in the same way that IPv4 is self-healing > under troubleshooting conditions common in backbone environments. Note > that the semantics here are very similar to the err-disable state > timeout on Cisco routers. > Please understand that this behavior is almost certainly not unique to > one vendor - this is behavior that is specified by and conforms to > current IPv6 standards. The standard behavior appears reasonable in a > LAN environment. However, it appears suboptimal in a backbone/provider > networking context. > Many thanks, > --eli > -- > Eli Dart NOC: (510) 486-7600 > ESnet Network Engineering Group (AS293) (800) 333-7638 > Lawrence Berkeley National Laboratory > PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From frnkblk@iname.com Fri Aug 26 09:08:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6121F8C7D for ; Fri, 26 Aug 2011 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWI8u8Uy+8TK for ; Fri, 26 Aug 2011 09:08:37 -0700 (PDT) Received: from premieronline.net (mail.premieronline.net [96.31.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id B968B21F8C13 for ; Fri, 26 Aug 2011 09:08:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 30409559-1729245 for multiple; Fri, 26 Aug 2011 11:09:51 -0500 From: "Frank Bulk" To: "'Philip Homburg'" References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <20110816135546.GE72014@Space.Net> <201108161405.p7GE53q9015556@cichlid.raleigh.ibm.com> In-Reply-To: Date: Fri, 26 Aug 2011 11:09:52 -0500 Message-ID: <005a01cc640a$96619590$c324c0b0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxcIG7n/A/t7EYHScaGZgbTE4HOlgH6OlOQ Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=7 Friend=351 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 902, in=14084308, out=66060, spam=0 Known=true ip=199.120.69.26 Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:08:38 -0000 Let's not design a solution that is susceptible to race conditions. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg Sent: Tuesday, August 16, 2011 9:25 AM To: Thomas Narten Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments If, when adding systems to a link, you do it slowly enough that one node will have completed DAD before the next one starts, then you don't need to do anything special in case of duplicate MACs. For router networks, this is typically the case. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Fri Aug 26 10:23:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DFE21F86F6 for ; Fri, 26 Aug 2011 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.053 X-Spam-Level: X-Spam-Status: No, score=-104.053 tagged_above=-999 required=5 tests=[AWL=-1.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqrl89wVcsOM for ; Fri, 26 Aug 2011 10:23:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9D21F8515 for ; Fri, 26 Aug 2011 10:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=270; q=dns/txt; s=iport; t=1314379512; x=1315589112; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QFgks4WAbKagqur50KsThqf3uczsFsAWEzg5fiS63JE=; b=OMp+Az904zjjPYNzZ2ReuRx2XKYW2GVf3yoeD4luUlpFqUfpp66/1tYs TOD0Xrf/SHBHNV/jMXAov5803khds2r/UhtCFHSURIJ2Ysfsa3rUiDuXr 8n6A5v49ozJUWozPovEkJ/DeF6XXAJOyo3VH2uHa84A/+ns7EnVa5YbU9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANfVV06rRDoG/2dsb2JhbABDqCR3gUABAQEBAgESASc/BQsLRlcGNYdQmyMBnx2FbGAEh2KLOIUNjBM X-IronPort-AV: E=Sophos;i="4.68,286,1312156800"; d="scan'208";a="16877921" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2011 17:25:11 +0000 Received: from dhcp-128-107-114-18.cisco.com (dhcp-128-107-114-18.cisco.com [128.107.114.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QHPBhB023962; Fri, 26 Aug 2011 17:25:11 GMT Received: from [127.0.0.1] by dhcp-128-107-114-18.cisco.com (PGP Universal service); Fri, 26 Aug 2011 10:25:12 -0700 X-PGP-Universal: processed; by dhcp-128-107-114-18.cisco.com on Fri, 26 Aug 2011 10:25:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> Date: Fri, 26 Aug 2011 10:25:03 -0700 Message-Id: <16F42961-EEDB-451A-9BD0-7F468B037339@cisco.com> References: <4E49D9DB.5060109@es.net> <201108161324.p7GDOGXO015351@cichlid.raleigh.ibm.com> <20110816.154827.78743604.sthaug@nethelp.no> <201108161355.p7GDtcrW015509@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] DAD issues in IPv6 backbone environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:23:56 -0000 On Aug 16, 2011, at 6:55 AM, Thomas Narten wrote: > Isn't this a case where you'd want to "kick" the interface to try > again (once the loopback is disabled) Seems like a case where it might kick itself, in a network with any = degree of size or complexity.= From shemant@cisco.com Sun Aug 28 14:42:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D773D21F86EC for ; Sun, 28 Aug 2011 14:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCMwwhQKNnjO for ; Sun, 28 Aug 2011 14:42:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3909521F86EA for ; Sun, 28 Aug 2011 14:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1381; q=dns/txt; s=iport; t=1314567862; x=1315777462; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Tx83RnCl9nRlvw5qOqd4hSgSvvvaFAe3XtAKz/muMj0=; b=bAASOVhsQ4yOoAxWVCHDjL3FVM3h5o2s32txPG7N0ec2UBVzc0Xp3gJE IhP2OkZBu21HrKiCcI+AeIRcrPxEV7jnTmqvpoDLzfkLggz+VTCfWFMCi 3sXq6jHsAR5GyY/XaM8kOKvzW+LvUeJxdzAnDlhFhn/ovG8EP0tBb2M4d w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAMy1Wk6tJXG+/2dsb2JhbABCmBmPXneBQAEBAQEDEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEggaoScBnVeFbGAEh2SQUowL X-IronPort-AV: E=Sophos;i="4.68,294,1312156800"; d="scan'208";a="17250336" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2011 21:44:20 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7SLiKQO014923; Sun, 28 Aug 2011 21:44:20 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Aug 2011 16:44:20 -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 Date: Sun, 28 Aug 2011 16:44:18 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302A64767@XMB-RCD-109.cisco.com> In-Reply-To: <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] How to divide v6ops Thread-Index: Acxhq+tAhs/qwvpAQxu6P6tO/D/sawEH2sLw References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> From: "Hemant Singh (shemant)" To: "Thomas Narten" , "Fred Baker (fred)" X-OriginalArrivalTime: 28 Aug 2011 21:44:20.0509 (UTC) FILETIME=[A4D4FCD0:01CC65CB] Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 21:42:59 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Tuesday, August 23, 2011 11:47 AM To: Fred Baker (fred) Cc: IPv6 Operations; Ron Bonica Subject: Re: [v6ops] How to divide v6ops >IMO, the real elephant in the room is that there are too many drafts >covering marginal work topics. But rather than tell people "no", we >allow work to continue, even enable it (e.g., by saying "we'll discuss >further on the list", when in fact, little useful discussion happens >but the ID gets respun and gets presented again at the next >meeting). And given the that the WG (and in fact any WG) has a finite >amount of clue/cycles, if you stretch that too thin, you start >thrashing, and then you are really in a fix. >The WG needs to focus on stuff that matters, and say "no" to >everything else. >Absent a real willingness to do this, splitting the WG up is nothing >more then rearranging the deck chairs... During the past two years or so I have seen repeated allusions to the fact that v6ops is overloaded but I haven't seen any evidence. Granted a lot of drafts get submitted to v6ops but many do not get discussed in the mailer and thus such documents should not be even considered for presentation at an IETF. +1 to Thomas and others on marginal work to be punted out. =20 Hemant From fred@cisco.com Sun Aug 28 16:24:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377021F8620 for ; Sun, 28 Aug 2011 16:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4K9RVfkZsMp for ; Sun, 28 Aug 2011 16:24:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3321F861A for ; Sun, 28 Aug 2011 16:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=10191; q=dns/txt; s=iport; t=1314573927; x=1315783527; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=7pf+60vwSin8vhcTMecBiulmJQSYxQS9JDeUMQy6WZY=; b=cXkO2tHTaTEyAihfGDokZazG9YSqilWV8j/F0pToZeI/gRwnXhUvy2D3 5F1+ewAKZLg4WcJaQoXaFr/jkfW7x1Zf5kaXkUFNd0LiaZm+liJOkF/TY LhfCcy0Xjjkm3YK6ZKtLXLSdwjWkQr51RDxGfZdog5Up72MiOgwHAEgfD A=; X-IronPort-AV: E=Sophos;i="4.68,294,1312156800"; d="scan'208";a="17265267" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 28 Aug 2011 23:25:26 +0000 Received: from Freds-Computer.local (sjc-vpn2-696.cisco.com [10.21.114.184]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7SNPPER018196; Sun, 28 Aug 2011 23:25:26 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 28 Aug 2011 16:25:24 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 28 Aug 2011 16:25:24 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302A64767@XMB-RCD-109.cisco.com> Date: Sun, 28 Aug 2011 16:25:02 -0700 Message-Id: <2DA5A858-5F5F-46D6-8BA3-FF8F4CF00856@cisco.com> References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302A64767@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 23:24:05 -0000 On Aug 28, 2011, at 2:44 PM, Hemant Singh (shemant) wrote: > During the past two years or so I have seen repeated allusions to the = fact that v6ops is overloaded but I haven't seen any evidence.=20 Actually, we usually have at least one draft in discussion on the = mailer. That's how we run WGLCs, and to pick one sequence, we went = through ten drafts in two-week discussions in April and May. To give you = a measure of what folks currently wish v6ops was discussing (45 drafts, = several of which are seriously off-topic and a few are in the IESG or = RFC Editor lists), see the list at the end of this note. 45 drafts, or even 20, is a lot of work in a working group. There are = currently 2012 posted internet drafts; if they are all in discussion in = a working group (which they are not - many are not being discussed, and = some are in the IESG or the RFC Editor's lists), that's 16 per working = group on average. Think about it. As to the comment about the chairs not saying "no", the chairs have = repeatedly asked for working group input on what it wants to discuss, = and generally get negligible comment - 19 out of nearly 300 f2f = attendees in IETF-79, 14 of mailing list members in June. For IETF-81, = we scheduled 20 of the 42 then-posted drafts for discussion, and added a = couple more when we were able to arrange for a third meeting. Setting = aside half the drafts constitutes "saying 'no' to some" in my book. For = those that have asked for additional editorial control, I think it also = implies the application of the charter as editorial control. If folks want to make helpful comments, they can tell us how best to = divide or tighten up the charter so that they get happier with the = editorial control. They can also reply to questions sent to the working = group by the chairs. http://datatracker.ietf.org/doc/draft-andrews-v6ops-6to4-router-option "6to4 DHCP Relay Router Option", Mark Andrews, 10-May-11 http://datatracker.ietf.org/doc/draft-asati-v6ops-dad-loopback "IPv6 DAD Enhancements for handling Layer1 Loopbacks", Rajiv Asati, = Eli Dart, 24-Aug-11 = http://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-bearer-network-trial= s "IPv6 Practices on China Mobile IP Bearer Network", Gang Chen, Tianle Yang, Lianyuan Li, Hui Deng, 4-Jul-11 http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe "NAT64-CPE Mode Operation for Opening Residential Service", Gang Chen, Hui Deng, 10-Jul-11 http://datatracker.ietf.org/doc/draft-chown-v6ops-address-accountability "IPv6 Address Accountability Considerations", Tim Chown, 11-Jul-11 http://datatracker.ietf.org/doc/draft-chown-v6ops-call-to-arms "World IPv6 Day Call to Arms", Tim Chown, Mat Ford, Stig Venaas, 7-Jun-11 http://datatracker.ietf.org/doc/draft-dec-stateless-4v6 "Stateless 4Via6 Address Sharing", Wojciech Dec, Rajiv Asati, Congxiao Bao, Hui Deng, 11-Jul-11 = http://datatracker.ietf.org/doc/draft-deng-v6ops-aplusp-experiment-results= "Implementing AplusP in the provider's IPv6-only network", Xiaohong Deng, Tao Zheng, Mohammed Boucadair, France Telecom, Xiaohong Huang, = Qin Zhao, Yan Ma, 8-Jul-11 http://datatracker.ietf.org/doc/draft-denog-v6ops-addresspartnaming "Naming IPv6 address parts", Lutz Donnerhacke, Richard Hartmann, Kay Rechthien, Leon Weber, Ronny Boesger, Thorsten Dahm, Joerg Dorchain, Sascha Lenz, Michael Horn, Jan Walzer, Sebastian Wiesinger, 7-Apr-11 http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-diagnostic-header "IPv6 Diagnostic Header", Nalini Elkins, Lawrence Kratzke, Michael Ackermann, 4-Jul-11 http://datatracker.ietf.org/doc/draft-fling-v6ops-hybrid-bridged-routed "A Hybrid IPv6 Service model of Bridged and Routed Mode", Chih-Cheng Tsao, Fang-Yu Ling, 8-Apr-11 http://datatracker.ietf.org/doc/draft-gashinsky-v6nd-enhance "Operational Neighbor Discovery Problems and Enhancements.", Warren Kumari, 29-Jun-11 http://datatracker.ietf.org/doc/draft-gont-v6ops-ra-guard-evasion "IPv6 Router Advertisement Guard (RA-Guard) Evasion", Fernando Gont, = UK CPNI, 7-Jun-11 = http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-rese= rvations "Reserved IPv6 Interface Identifier for Proxy Mobile IPv6", Sri Gundavelli, 8-Aug-11 http://datatracker.ietf.org/doc/draft-hilliard-v6ops-ipv6-discard-prefix "A Discard Prefix for IPv6", Nick Hilliard, 4-Jul-11 http://datatracker.ietf.org/doc/draft-hu-v6ops-radius-issues-ipv6 "RADIUS issues in IPv6 deployments", Jie Hu, Yulong Ouyang, Qian Wang, 14-Mar-11 http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps "IPv6 in 3GPP Evolved Packet System", Jouni Korhonen, Jonne Soininen, Basavaraj Patil, Teemu Savolainen, Gabor Bajko, Kaisu Iisakkila, 20-Aug-11 http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Ole Troan, 24-Jun-11 http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs "Happy Eyeballs: Success with Dual-Stack Hosts", Dan Wing, Andrew Yourtchenko, 11-Jul-11 http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router-bis "Advanced Requirements for IPv6 Customer Edge Routers", Hemant Singh, Wes Beebee, Chris Donley, Barbara Stark, Ole Troan, 10-Jul-11 = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-= ipv6nat "IPv6 Multihoming without Network Address Translation", Ole Troan, = David Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 29-Mar-11 http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework "Framework for IP Version Transition Scenarios", Brian Carpenter, = Sheng Jiang, Victor Kuarsingh, 26-Jul-11 = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications "IPv6 AAAA DNS Whitelisting Implications", Jason Livingood, 8-Jun-11 = http://datatracker.ietf.org/doc/draft-jjmb-v6ops-comcast-ipv6-experiences "Comcast IPv6 Trial/Deployment Experiences", John Jason Brzozowski, Chris Griffiths, 8-Jul-11 = http://datatracker.ietf.org/doc/draft-kanizsai-v6ops-anycast-data-aggregat= ion "IPv6 anycast based feedback data aggregation", Zoltan Kanizsai, = Laszlo Bokor, Gabor Jeney, Gianmarco Panza, 7-Mar-11 http://datatracker.ietf.org/doc/draft-keranen-ipv6day-measurements "Some Measurements on World IPv6 Day from End-User Perspective", Ari Keranen, Jari Arkko, 11-Jul-11 = http://datatracker.ietf.org/doc/draft-kuarsingh-v6ops-6to4-provider-manage= d-tunnel "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier Vautrin, 13-Mar-11 = http://datatracker.ietf.org/doc/draft-kuarsingh-wireline-incremental-ipv6 "Wireline Incremental IPv6", Victor Kuarsingh, 4-Jul-11 = http://datatracker.ietf.org/doc/draft-li-v6ops-load-balancing-requirement "Analysis on Load Balancing Requirement in IPv4/IPv6 Transition", Zhenqiang Li, Qin Zhao, Xiaohong Huang, Yan Ma, KuiKe Building = http://datatracker.ietf.org/doc/draft-matsushima-v6ops-transition-experien= ce "Use case and consideration experiences of IPv4 to IPv6 transition", Satoru Matsushima, Yuji Yamazaki, Chunfa Sun, Masato Yamanishi, Jie Jiao, 29-Mar-11 http://datatracker.ietf.org/doc/draft-sarikaya-v6ops-prefix-delegation "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks", Behcet Sarikaya, Frank Xia, Ted Lemon, 16-Jun-11 http://datatracker.ietf.org/doc/draft-sun-v6ops-laft6 "LAFT6: Lightweight address family transition for IPv6", Qiong Sun, Chongfeng Xie, 14-Mar-11 http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, 11-Jul-11 http://datatracker.ietf.org/doc/draft-sunq-v6ops-ivi-sp "Considerations for Stateless Translation (IVI/dIVI) in Large SP Network", Qiong Sun, Chongfeng Xie, Xing Li, Congxiao Bao, Ming Feng, 6-Mar-11 http://datatracker.ietf.org/doc/draft-tan-v6ops-fast6-aaa "AAA for broadband access in IPv6 transition", Jinghua Tan, GuoLiang Yang, Cathy Zhou, 6-Jul-11 http://datatracker.ietf.org/doc/draft-tan-v6ops-nat64-experiences "Experience from NAT64 applications", Jinghua Tan, JinYan Lin, Weibo = Li, 7-Mar-11 http://datatracker.ietf.org/doc/draft-templin-v6ops-isops "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Fred Templin, 27-Jul-11 http://datatracker.ietf.org/doc/draft-troan-v6ops-6to4-update "Connection of IPv6 Domains via IPv4 Clouds (6to4) as Last Resort", = Ole Troan, Keith Moore, James Woodyatt, 10-Aug-11 = http://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6on= ly "Multicast Transition to IPv6 Only in Broadband Deployments", Tina = Tsou (Ting ZOU), Tom Taylor, 14-Mar-11 http://datatracker.ietf.org/doc/draft-v6ops-multihoming-without-ipv6nat "IPv6 Multihoming without Network Address Translation", Ole Troan, = David Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 29-Mar-11 http://datatracker.ietf.org/doc/draft-vanrein-v6ops-6bed4 "IPv6 Tunneling for Embedded Systems (6bed4)", Rick van Rein, = 25-Jul-11 http://datatracker.ietf.org/doc/draft-xli-v6ops-ivi-icmp-address "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 25-Jul-11 http://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-pppoe "Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6) -- PPPoE Broadband Access", GuoLiang Yang, JinYan Lin, Jinghua Tan, 11-Jul-11 http://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-tools-selection "The analysis of tools selection for broadband ISPs", GuoLiang Yang, Cancan Huang, Youming Wu, 11-Jul-11 http://datatracker.ietf.org/doc/draft-yang-v6ops-space6-icp "Service-Provider Application Cloud-based Engine for IPv6", GuoLiang Yang, ZhiLan Huang, Weibo Li, 9-Jun-11 From dougb@dougbarton.us Sun Aug 28 16:35:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02621F8562 for ; Sun, 28 Aug 2011 16:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqLMbbsgjzgF for ; Sun, 28 Aug 2011 16:35:53 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA8421F855A for ; Sun, 28 Aug 2011 16:35:53 -0700 (PDT) Received: (qmail 25406 invoked by uid 399); 28 Aug 2011 23:37:15 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 28 Aug 2011 23:37:15 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4E5AD12A.8060203@dougbarton.us> Date: Sun, 28 Aug 2011 16:37:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Fred Baker References: <482178F0-0A35-4D63-AE8B-48694324C3B7@cisco.com> <201108231546.p7NFkk41008416@cichlid.raleigh.ibm.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302A64767@XMB-RCD-109.cisco.com> <2DA5A858-5F5F-46D6-8BA3-FF8F4CF00856@cisco.com> In-Reply-To: <2DA5A858-5F5F-46D6-8BA3-FF8F4CF00856@cisco.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , IPv6 Operations , Ron Bonica Subject: Re: [v6ops] How to divide v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 23:35:54 -0000 On 8/28/2011 4:25 PM, Fred Baker wrote: > As to the comment about the chairs not saying "no", the chairs have repeatedly asked for working group input on what it wants to discuss, and generally get negligible comment Speaking for myself, my reactions to seemingly off-topic stuff tend to fall into 3 broad categories: 1. That's a really bad idea (in which case I usually say so). 2. That sounds wacky to me, but there may be something about it that I'm not seeing, so I'll wait and see if someone smarter than me comments. 3. Oy, again? Seriously? I hope the chairs do something about it. :) What might be helpful (and I'm sorry to even suggest this, since I know y'all are not really looking for more stuff to do) would be for the chairs to be a teensy bit more assertive in edging stuff closer to the cliff. I.e., if something seems like it's not getting enough support post a message to the effect of, "This item doesn't seem to have the support of the group. Unless $P people speak up within $D days we will assume the group is not interested." Derivation of reasonable values of P and D left as an exercise ... hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ek@google.com Mon Aug 29 02:53:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7821F8AAF for ; Mon, 29 Aug 2011 02:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.654 X-Spam-Level: X-Spam-Status: No, score=-105.654 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsp+RVH-blNL for ; Mon, 29 Aug 2011 02:53:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9721F8A96 for ; Mon, 29 Aug 2011 02:53:36 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p7T9t0gk020282 for ; Mon, 29 Aug 2011 02:55:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314611700; bh=Bxd4h589kR/Et7jsZJkJuuohi9s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BYNA1nVY2eVNBAp+8o3T+S251cB6mVGFLfnUx3d5+hdoL+jP8TlPvFoexSXk9+Myz mjKZUQ8le5vpmrC0x/ExQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=ReY0WpymM8SRm1nLu3Rph3PVkTZmoM7IeX50czK6nIWa6acyg1Cvx1DDhugRbQoR+ /rqPfTJ3sMheHyAAQC9Fw== Received: from qwh5 (qwh5.prod.google.com [10.241.194.197]) by wpaz17.hot.corp.google.com with ESMTP id p7T9s17U018058 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 29 Aug 2011 02:54:59 -0700 Received: by qwh5 with SMTP id 5so4051630qwh.34 for ; Mon, 29 Aug 2011 02:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NUfhxmy7+4RaSMp4NYKpWGyfUXtL/xy3EIVPyFC9yqU=; b=O9MV5Hg4jbKNIYbauBDkMCt7bC1QLniY0fTd8Z/u4BBG1IvRhJijtGY+H7nT4RpF6W iRLhI3sYyRASM7SIqeHg== Received: by 10.229.63.140 with SMTP id b12mr5518151qci.27.1314611699406; Mon, 29 Aug 2011 02:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.140 with SMTP id b12mr5518141qci.27.1314611699225; Mon, 29 Aug 2011 02:54:59 -0700 (PDT) Received: by 10.229.158.196 with HTTP; Mon, 29 Aug 2011 02:54:59 -0700 (PDT) In-Reply-To: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> Date: Mon, 29 Aug 2011 18:54:59 +0900 Message-ID: From: Erik Kline To: fred@cisco.com Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 09:53:37 -0000 +1 to section 3.2, generally. On 26 August 2011 22:55, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-asati-v6ops-dad-loopback. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Mon Aug 29 03:14:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5B21F8A6F for ; Mon, 29 Aug 2011 03:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.916 X-Spam-Level: X-Spam-Status: No, score=-105.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEJdcbxiFo0f for ; Mon, 29 Aug 2011 03:14:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 61AED21F86EE for ; Mon, 29 Aug 2011 03:14:27 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p7TAFi2S030526 for ; Mon, 29 Aug 2011 03:15:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314612946; bh=spS8OXwV/cMN5vSEd/p7r4nnnWM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n8k933M7UkiIHwGVYizBGmkLa2tcRxOB0S3bGEmxK5Iujjr1nm26Du/E8urUSJ+pY qNE2Pi8ajY8vi9nse8mMw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=k/ebnAQ9nIniYhZiTaKfSTwqkIpwi+T1u2uCP+Yu4BO6RtpKkDALc5UWJNSr0cC0N CwaweczFNqvLqXZZrzaaQ== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq7.eem.corp.google.com with ESMTP id p7TAFgiw026031 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 29 Aug 2011 03:15:43 -0700 Received: by gyf3 with SMTP id 3so4223349gyf.3 for ; Mon, 29 Aug 2011 03:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=huKZBzGgnYoRs2irrb/xD2+hfOE7eF9fNUyXeuF+Pdc=; b=qkHTb+lomlbg3pV9MWs5kMUW3vP2SRiwcfl8qIXxcNgkiItuXNWtsOoOO5WYYZbP92 0s4iJ4Hi/awiZWcrhbsQ== Received: by 10.150.134.20 with SMTP id h20mr58293ybd.285.1314612942294; Mon, 29 Aug 2011 03:15:42 -0700 (PDT) Received: by 10.150.134.20 with SMTP id h20mr58284ybd.285.1314612942095; Mon, 29 Aug 2011 03:15:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.144.19 with HTTP; Mon, 29 Aug 2011 03:15:22 -0700 (PDT) In-Reply-To: References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> From: Lorenzo Colitti Date: Mon, 29 Aug 2011 19:15:22 +0900 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=000e0cd4ce306e479904aba22d15 X-System-Of-Record: true Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 10:14:28 -0000 --000e0cd4ce306e479904aba22d15 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 29, 2011 at 18:54, Erik Kline wrote: > +1 to section 3.2, generally. This is definitely a useful problem to solve. I have personally had to work around this situation more than once, sometimes by disabling DAD completely on routers. A couple of points that the draft doesn't explain: - Why can't the node simply retry DAD without the nonce option? - How does the nonce option guarantee that the address is unique? Just probabilistically, because the nonce would have to collide? - Why only send the nonce on the second (and subsequent?) messages? Why not simply send out all NSes with nonces all the time? - What state is the address in while the timer is ticking? Also: in some cases this happens when buggy drivers (typically wifi drivers) loop back the node's own multicast packets. This is a violation of 802.11, but nobody notices since it doesn't affect IPv4. With your proposed scheme, DAD would succeed, but the node would be continuously receiving its own multicast packets. What happens in such situations? --000e0cd4ce306e479904aba22d15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 29, 2011 at 18:54, Erik Kline <ek@googl= e.com> wrote:
+1 to section 3.2, generally.

This is definitely= a useful problem to solve. I have personally had to work around this situa= tion more than once, sometimes by disabling DAD completely on routers.

A couple of= points that the draft doesn't explain:
- Why can't the node simply retry DAD without the nonce option?
<= div class=3D"gmail_quote"> - How does the nonce option guarantee that the address is unique? Just prob= abilistically, because the nonce would have to collide?
-=A0Why only send the nonce on the second (and subsequent?) me= ssages?=A0Why not simply send out all NSes with nonces all the time?
- What state is the address in while the timer i= s ticking?

Also: in some cases this happens when buggy drivers (typically wifi dr= ivers) loop back the node's own multicast packets. This is a violation = of 802.11, but nobody notices since it doesn't affect IPv4. With your p= roposed scheme, DAD would succeed, but the node would be continuously recei= ving its own multicast packets. What happens in such situations?
--000e0cd4ce306e479904aba22d15-- From internet-drafts@ietf.org Wed Aug 31 00:37:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB221F8C09; Wed, 31 Aug 2011 00:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5JQ8Ob7NvEk; Wed, 31 Aug 2011 00:37:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86E21F8BCD; Wed, 31 Aug 2011 00:37:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110831073754.10298.54002.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 00:37:54 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 07:37:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-05.txt Pages : 34 Date : 2011-08-31 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-05.txt From internet-drafts@ietf.org Wed Aug 31 23:23:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DAE21F8B23; Wed, 31 Aug 2011 23:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nveB6NuAeIn; Wed, 31 Aug 2011 23:23:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE23A21F8B12; Wed, 31 Aug 2011 23:23:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110901062337.13131.28709.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 23:23:37 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 06:23:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 Multihoming without Network Address Translation Author(s) : Ole Troan David Miles Satoru Matsushima Tadahisa Okimoto Dan Wing Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt Pages : 21 Date : 2011-08-31 Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. Nevertheless, we mention that the possible needs for IPv6 NAT in the transition phase to the fully deployment of the proposed solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-witho= ut-ipv6nat-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-withou= t-ipv6nat-01.txt