From sm@elandsys.com Tue Jul 2 15:03:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A3F11E8103 for ; Tue, 2 Jul 2013 15:03:48 -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=[AWL=0.000, 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 tHc6XmvQbo+w for ; Tue, 2 Jul 2013 15:03:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D389911E8100 for ; Tue, 2 Jul 2013 15:03:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.177]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r62M3ZRG002898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Jul 2013 15:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372802627; bh=PhB+urJQ31Z/zA93+35BjQiops44SBrmUAltLXSfs5A=; h=Date:To:From:Subject; b=IB/htEC0h0vrRO62lKyDpYRUzJndx+kQdJrNSqrfVslp5snQavbGEI6Xqk0Gqvlgs O9BWXQdhR7dcZLFaQFwjeYK/hcse4O0lxpOpF7grfLn/1YpQdS9DnpV2LnN/yRYjEQ ASCO8PUYmXd8ALKQhPCOGwZfQPdvsFHr5doIEnSY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372802627; i=@elandsys.com; bh=PhB+urJQ31Z/zA93+35BjQiops44SBrmUAltLXSfs5A=; h=Date:To:From:Subject; b=LA0fJjwoij2B4wYqy5aCxmxDndfxdnCVeAsD0zbSG3xLxr9klGU9uWUa+ZjkYgoeZ 96UiBhwjwqF/iQpNMYK+pSfk1lDZxFqUHJYbQRoSfwTACaPcQU8A/ZWEEZuyFBRMA0 YLQNhP4YY8DV0RMxOEV0lGGmnXJoGIOjx/C2zWVQ= Message-Id: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 Jul 2013 15:02:24 -0700 To: v6ops@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 22:03:48 -0000 Hello, An IPv6 Router Advertisements flooding attack can cause a node to consume all CPU resources available making the system unusable and unresponsive. draft-moonesamy-ra-flood-limit-00 ( http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) recommends some configurable variables as a mitigation against an IPv6 Router Advertisements flooding attack. I would appreciate if you read the draft and comment. Regards, S. Moonesamy From rpaulo@apple.com Tue Jul 2 15:48:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A721411E8116 for ; Tue, 2 Jul 2013 15:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RZXdsvccOuPW for ; Tue, 2 Jul 2013 15:48:52 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6011E80FA for ; Tue, 2 Jul 2013 15:48:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPB00GP4ZDFI4L0@mail-out.apple.com> for v6ops@ietf.org; Tue, 02 Jul 2013 15:48:51 -0700 (PDT) X-AuditID: 11807165-b7f496d000000613-47-51d358d34b39 Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 3A.7B.01555.3D853D15; Tue, 02 Jul 2013 15:48:51 -0700 (PDT) Received: from [17.153.106.204] by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MPB00KPPZDEJM90@chicory.apple.com> for v6ops@ietf.org; Tue, 02 Jul 2013 15:48:51 -0700 (PDT) From: Rui Paulo In-reply-to: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> Date: Tue, 02 Jul 2013 15:48:50 -0700 Message-id: <39A40291-B7DE-453F-A6BB-05D6392E3F20@apple.com> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1783) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCcrHs54nKgwZ1Zhhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtKdF9kK1rBVNO6+xNTAOJ21i5GTQ0LARKLj7ycoW0ziwr31 bF2MXBxCAv1MEg/WHGOEcJqYJH5Mu88EUsUsoCWxfudxMJtXQE9i0+N7QB0cHMIChRLHl4SD hNkElCSe9Z1gB7E5Bewk+vYuYAaxWQRUJf6u72aGGKMg0faunRHC1pZ48u4CK8RIG4mD2yaD 2UICthKN/z4zgYwXEVCT2DczHeJOWYlJbc/YJjAKzEJy0CwkB81CMnUBI/MqRoGi1JzESnO9 xIKCnFS95PzcTYzgsCtM3cHYuNzqEKMAB6MSD6/Ds0uBQqyJZcWVuYcYJTiYlUR4uYUvBwrx piRWVqUW5ccXleakFh9ilOZgURLnTZUGqhZITyxJzU5NLUgtgskycXBKNTDyfpf9m1PQM192 Ou9O0Qahi4+KHqqlre3oifr4Jztw619JVpX6gHQOz0XuzbH+Zvscbf86vVVcy2j/7mdHSVFh 4J4L/VHTJ3oFtU/Pjc/uePDzeYj1sQ38cZM0ut+XWz62EOpIND20QMZ5TfLH7mnFHbv9JoYt +Pm8QX/KNSPjnqwvwSJ7k5RYijMSDbWYi4oTAc+QSlM3AgAA Cc: IPv6 Ops WG Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 22:48:57 -0000 On Jul 2, 2013, at 15:02, S Moonesamy wrote: > Hello, > > An IPv6 Router Advertisements flooding attack can cause a node to consume all CPU resources available making the system unusable and unresponsive. draft-moonesamy-ra-flood-limit-00 ( http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) recommends some configurable variables as a mitigation against an IPv6 Router Advertisements flooding attack. > > I would appreciate if you read the draft and comment. I think it doesn't offer enough guidance to implementors. I also think that Appendix A makes an inaccurate statement about NetBSD and OpenBSD as they (along with FreeBSD) limit the number of ND options in the packets, not the number prefixes / routers. -- Rui Paulo From sm@elandsys.com Tue Jul 2 16:51:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500921F99D5 for ; Tue, 2 Jul 2013 16:51:12 -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=[AWL=0.000, 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 7kwanHtfNW-x for ; Tue, 2 Jul 2013 16:51:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2B921F99ED for ; Tue, 2 Jul 2013 16:51:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.177]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r62NoswK014665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 16:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372809065; bh=EPFbwxi/TrWumbUcFBjVv1qpyZL/79espIOm1zu9HrQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m3oVb0KkAHynpujVTgmteGJ7WSNnSAF7Gm3dX+UBjQi5T3oM8OEs00WXeS6jK4UV7 XYfu31FLO3A9A0VEj1qvQMuPh4vGStIQCyl8cxxXamQGoaT1uzW1o+u9f9S/eFC86T i99hS11u+0jpJSFkEKgQgvS38ckDsADikjvaCc38= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372809065; i=@elandsys.com; bh=EPFbwxi/TrWumbUcFBjVv1qpyZL/79espIOm1zu9HrQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RRZxIWhs6fX2jNdZDg+orIZm4rNkDig7N7E2geLnHKmjCNAy9VR/oS13lULtDN2vF ei6tz9xVOnmHqVdyprRPntqQgf71S2jQqU9GjLoPp2lFgxAXDcvRo0h6b/4hvVrGSY mx0LQyM4/gYMq/1LxcSEbCqK3qSpEONw7QYeep9A= Message-Id: <6.2.5.6.2.20130702161113.0af3a210@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 Jul 2013 16:46:22 -0700 To: Rui Paulo From: S Moonesamy In-Reply-To: <39A40291-B7DE-453F-A6BB-05D6392E3F20@apple.com> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <39A40291-B7DE-453F-A6BB-05D6392E3F20@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 23:51:12 -0000 Hi Rui, At 15:48 02-07-2013, Rui Paulo wrote: >I think it doesn't offer enough guidance to implementors. I also >think that Appendix A Thanks for the feedback. As an example this is part of what one implementation does: if (ip6_maxifdefrouters >= 0 && ext->ndefrouters >= ip6_maxifdefrouters) { splx(s); return (NULL); } The information provided in the Router Advertisement is discarded once maximum is reached. > makes an inaccurate statement about NetBSD and OpenBSD as they > (along with FreeBSD) limit the number of ND options in the packets, > not the number prefixes / routers. I understand the comment about ND options in the above. I read the NetBSD and OpenBSD source code and I saw that there is a limit on the number of prefixes and routers. I also performed several tests on NetBSD and OpenBSD to understand the impact of RA flooding on those systems. Appendix A does not mention FreeBSD as there is still work to be done to address the problem report about RA flooding. Regards, S. Moonesamy From farmer@umn.edu Tue Jul 2 21:43:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25E11E8166 for ; Tue, 2 Jul 2013 21:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGJzmRR4niyF for ; Tue, 2 Jul 2013 21:43:23 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id BB80F11E80A5 for ; Tue, 2 Jul 2013 21:43:23 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 2 Jul 2013 23:43:18 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-gh0-f182.google.com [209.85.160.182] #+LO+TR X-Umn-Classification: local Received: by mail-gh0-f182.google.com with SMTP id z15so2758798ghb.41 for ; Tue, 02 Jul 2013 21:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=88l/OGHozXdxk0OF96FNkawiUYNCzcCd+xUBipW7p7M=; b=NSWap0DSBTy9CDKi9UciNlKNJqfcMwyD3NAtDNGhKWigtOdd/kUMt2ImjWHqIWcrY7 RkmPIuJz4rr/CCJ1ynAxcgs9XIV0KqEQTnbyW+ja/IxRgEqzAJbGf7lzOwVAf6aU2GDR mwjc7dhA1MKZBcz4sAUaEXvEJ3y0zdr0SZRnESUHgbYOJUHkMFvLYUrEv3nXfRfKtpjm TjIGmxwOIJ0qwTougbCOGfUiZUTBKAwzPgv0SBUnUvj47c6SegZHvFQ/OpElhxjmo0/S H3uO3b7tObuchgrJ55eRn69gI5nxWJiJYS6YzW1g+G1Ps4BTSEPHkBOraTSMS8+Mk2Ek /lLg== X-Received: by 10.236.38.6 with SMTP id z6mr15919225yha.230.1372826598114; Tue, 02 Jul 2013 21:43:18 -0700 (PDT) X-Received: by 10.236.38.6 with SMTP id z6mr15919223yha.230.1372826598019; Tue, 02 Jul 2013 21:43:18 -0700 (PDT) Received: from oit201651646.local ([2001:470:1f11:821:5c3d:8fa0:6a59:107a]) by mx.google.com with ESMTPSA id b50sm44744569yhl.1.2013.07.02.21.43.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 21:43:17 -0700 (PDT) Message-ID: <51D3ABE4.9030901@umn.edu> Date: Tue, 02 Jul 2013 23:43:16 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> In-Reply-To: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmTDY5tzHIrNqWlH5N7tSnQsMhEC9LTJiwLrm7oVsotrbq+AwQMqIYUqWWnAXYJS3O0I/7Jfdjf3UespuikgbthylmkdELlhESWZhcJl/FNdHo3/B97DGQWEgtM6sBzpQHl5agE Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:43:28 -0000 First, I think it is necessary to make the point that the primary technique to mitigate a malicious RA flood attack is through deployment of RA Guard mechanisms as described in [RFC6105] or the other mitigation techniques discussed in section 3 of [RFC6104]. This describes a necessary, but secondary, mechanism that only mitigates exhaustion of CPU resources by a RA flood attack. While important, even with this technique properly implemented it still seems possible for a malicious attacker to disrupt access to a network or cause traffic to be maliciously diverted. In section 2 you say the following; A host will silently discard a Router Advertisement once the configurable limit is reached. Default values are specified to make it unnecessary to configure any of these variables. Does this mean all RAs are silently discarded at that point, or only those that would cause configuration of additional prefixes, default routers, or redirects per interface? If it is not all RAs, don't you still have to look at all the RAs and decide which ones refresh the current state of the allowed prefixes, default routers, or redirects per interface? How would this protect the CPU resources? Or, if you discard all RAs until something times out and drops you below the limits, doesn't that allow a malicious attacker to achieve their goal? Isn't it likely that the valid prefixes or routers will timeout first? I think you need to provide more details. On 7/2/13 17:02 , S Moonesamy wrote: > Hello, > > An IPv6 Router Advertisements flooding attack can cause a node to > consume all CPU resources available making the system unusable and > unresponsive. draft-moonesamy-ra-flood-limit-00 ( > http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) > recommends some configurable variables as a mitigation against an IPv6 > Router Advertisements flooding attack. > > I would appreciate if you read the draft and comment. > > Regards, > S. Moonesamy > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From sm@elandsys.com Wed Jul 3 00:39:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4595F11E817A for ; Wed, 3 Jul 2013 00:39:04 -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 MCY6J0ZfV8Ji for ; Wed, 3 Jul 2013 00:39:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33A11E8177 for ; Wed, 3 Jul 2013 00:39:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.177]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r637cjgh021281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 00:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372837139; bh=ehkUACSdds23WRon1W4CshmM4bqgqZP09lwuOtcvW0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=davH9W+TKAuJr3Q0GfqtVWeEMpkPcGyK/GjXiXaoq2HB/qYeIxtQx01s5PBE8DqMv UU9rQntXY/mKF6lHdN1xLtG8IIMPNNycDGDzm5sQZuKFLSGE9Wb6fM9sjn3T5Z7xtU fU5hv8SfqwkWCGlM+ksHxQbiOGa6OOinKHsAkFqU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372837139; i=@elandsys.com; bh=ehkUACSdds23WRon1W4CshmM4bqgqZP09lwuOtcvW0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vpvZrkvpbbfF22I6HZld4XG4yErsreYbSVwWPT1DxOC7q07nI2VfohtQdQZb0BH6N oLQHLklNAKMN6jGCftaryE++Y7+83GiS2UiqRjF6fKSR+rUtTt3JmG+3XANEkKSpRq FDDDNmAuMpDIMGMJb+p1ubtISRTje/uXvrZPzgzY= Message-Id: <6.2.5.6.2.20130702233628.0bc7c778@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Jul 2013 00:34:09 -0700 To: David Farmer From: S Moonesamy In-Reply-To: <51D3ABE4.9030901@umn.edu> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D3ABE4.9030901@umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:39:04 -0000 Hi David, Thanks for the feedback. At 21:43 02-07-2013, David Farmer wrote: >First, I think it is necessary to make the point that the primary >technique to mitigate a malicious RA flood attack is through >deployment of RA Guard mechanisms as described in [RFC6105] or the >other mitigation techniques discussed in section 3 of [RFC6104]. This The draft already mentions that the Router Advertisement problem is documented in RFC 6104. The following paragraph then mentions a mitigation against a Router Advertisements flooding attack. The proposal documents what some code (see Appendix A) does in practice instead of getting into a discussion of the various techniques available. As a side note, a friend and I deployed IPv6 in a school. My friend donated a router to make that possible. I doubt that the school would have deployed IPv6 if we told its management that the the school will have to purchase devices compliant with RFC 6105. > describes a necessary, but secondary, mechanism that only > mitigates exhaustion of CPU resources by a RA flood attack. While > important, even with this technique properly Yes, that's what the Introduction Section says. > implemented it still seems possible for a malicious attacker to > disrupt access to a network or cause traffic to be maliciously diverted. I agree that it is still possible for an attacker to disrupt access. The code tries to reduce the scope of the attack by preventing the system from being unusable or unresponsive. That seems better than disabling IPv6 altogether. >In section 2 you say the following; > > A host will silently discard a Router Advertisement once the > configurable limit is reached. Default values are specified to make > it unnecessary to configure any of these variables. > >Does this mean all RAs are silently discarded at that point, or only >those that would cause configuration of additional prefixes, default >routers, or redirects per interface? If it is not all RAs, don't >you still have to look at all the RAs and decide which ones refresh >the current state of the allowed prefixes, default routers, or >redirects per interface? How would this protect the CPU resources? No, what the code does is to short-circuit processing of Router Advertisements (RA) to disallow the addition of additional prefixes, or default routers, or redirects per interface. Looking at all the RAs is not a problem. The system internally processes the information beyond its limits and that causes a significant amount of CPU resources to be consumed. >Or, if you discard all RAs until something times out and drops you >below the limits, doesn't that allow a malicious attacker to achieve >their goal? Isn't it likely that the valid prefixes or routers will >timeout first? If the goal is to crash the system that won't happen if the system enforces the limits mentioned in the draft. Yes, the system will lose valid information first. >I think you need to provide more details. My preference is to focus on what is being implemented instead of the sensationalist angle. Regards, S. Moonesamy From farmer@umn.edu Wed Jul 3 10:26:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2804511E80E9 for ; Wed, 3 Jul 2013 10:26:39 -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 MnZHNRksgjmN for ; Wed, 3 Jul 2013 10:26:32 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4111E80D1 for ; Wed, 3 Jul 2013 10:26:32 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 3 Jul 2013 12:26:29 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f170.google.com [209.85.223.170] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f170.google.com with SMTP id e11so1082678iej.15 for ; Wed, 03 Jul 2013 10:26:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=168i6MyDUG7I3HX/3IpkLjsmvtk0eMWWD5GVptd1NEA=; b=oCXa3rtIfkpl8gc7ZaYxJVPLhwfDrCN7a+F9aP9lZrgFUkXNeBR+2XtmJxX5b+3SZs ZhV7DoEa+aEgTNXosWEP3XLnmUUzak0nc8CAl4GYPq/tRjpUuvo44cI5NkZQZ7Q8U6dZ 5K2li56bxO8SZkKeWVNiSJmEPXLhyu5/qsQ/X0f3WyaAU3vFm6l6nFkJwmmXjndvKnzE Kt8y1yL02Y7AVdTbtytCknz3c8+NASGnHGUsTCR4NfBz12P2nlz1GXJ9lj0SW3Gmd2rp maOA/jtiaMh1PdzDk81UR6Wwukgb2/hoDc7u4EOmjICC4z5HXifAcSOOk+WoTFgrBTjV 8XYg== X-Received: by 10.42.133.66 with SMTP id g2mr1147033ict.49.1372872389105; Wed, 03 Jul 2013 10:26:29 -0700 (PDT) X-Received: by 10.42.133.66 with SMTP id g2mr1147028ict.49.1372872389011; Wed, 03 Jul 2013 10:26:29 -0700 (PDT) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id p6sm24637206iga.10.2013.07.03.10.26.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 10:26:28 -0700 (PDT) Message-ID: <51D45EC2.6080807@umn.edu> Date: Wed, 03 Jul 2013 12:26:26 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D3ABE4.9030901@umn.edu> <6.2.5.6.2.20130702233628.0bc7c778@elandnews.com> In-Reply-To: <6.2.5.6.2.20130702233628.0bc7c778@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlKagsCtBm74YUDv/j6RGl1gktR3Gb2mm86C7nFiMtzYSlVG/SEKVh0VH9nfgjeGnZstich1nrudpMvd0kVssx73reXhBXFvLWbWcneZvwe/WawN5dEPAwiPd4MmfVGNLCnRgwT Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:26:39 -0000 On 7/3/13 02:34 , S Moonesamy wrote: > Hi David, > > Thanks for the feedback. > > At 21:43 02-07-2013, David Farmer wrote: ... > As a side note, a friend and I deployed IPv6 in a school. My friend > donated a router to make that possible. I doubt that the school would > have deployed IPv6 if we told its management that the the school will > have to purchase devices compliant with RFC 6105. I didn't say you had to deploy RFC6105 complaint devices, I said you need that, "or the other mitigation techniques discussed in section 3 of [RFC6104]." In the particular case you describe, I'd recommend the technique described in section 3.5 of RFC6104; Setting the valid RA to a Router Preference of "High", this has little or no cost and is relatively effective, especailly with the techniques described in this draft. ... > I agree that it is still possible for an attacker to disrupt access. > The code tries to reduce the scope of the attack by preventing the > system from being unusable or unresponsive. That seems better than > disabling IPv6 altogether. I agree, I'm just saying you should be more explicit about what this does and doesn't do. Maybe add the following as an additional paragraph to the security considerations section; However, without deployment of RA Guard mechanisms as described in [RFC6105] or the other mitigation techniques discussed in section 3 of [RFC6104] it is still possible for a malicious attacker to disrupt access to a network or cause traffic to be diverted. >> In section 2 you say the following; >> >> A host will silently discard a Router Advertisement once the >> configurable limit is reached. Default values are specified to make >> it unnecessary to configure any of these variables. >> >> Does this mean all RAs are silently discarded at that point, or only >> those that would cause configuration of additional prefixes, default >> routers, or redirects per interface? If it is not all RAs, don't you >> still have to look at all the RAs and decide which ones refresh the >> current state of the allowed prefixes, default routers, or redirects >> per interface? How would this protect the CPU resources? > > No, what the code does is to short-circuit processing of Router > Advertisements (RA) to disallow the addition of additional prefixes, or > default routers, or redirects per interface. Looking at all the RAs is > not a problem. The system internally processes the information beyond > its limits and that causes a significant amount of CPU resources to be > consumed. Thanks, I better understand the intended behaviour now. I suggest the following text for section 2, to more clearly describe the intended behaviour. A host will silently discard any Router Advertisement that cause one of the following configurable limits to be exceeded. However, Router Advertisements that only refresh previously learned configuration information are processed. Suggested default values are specified making it unnecessary to configure these variables for most typical situations. ... >> I think you need to provide more details. > > My preference is to focus on what is being implemented instead of the > sensationalist angle. My intent is not sensationalism, its fair warning. I don't want a naive users or enterprise network operator reading this and thinking that if their hosts implement this all their RA issues are solved. If you added the paragraph I suggest above to the security consideration section I think it would provide the explicit and necessary fair warning I'm looking for. > Regards, > S. Moonesamy -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From warren@kumari.net Wed Jul 3 16:58:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2175911E826F for ; Wed, 3 Jul 2013 16:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 wY-PataJOsze for ; Wed, 3 Jul 2013 16:58:38 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340C711E826B for ; Wed, 3 Jul 2013 16:58:38 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id ADAF51B407D8; Wed, 3 Jul 2013 19:58:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari Date: Wed, 3 Jul 2013 19:58:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1508) Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Wed, 03 Jul 2013 23:58:43 -0000 Begin forwarded message: > A new version of I-D, draft-wkumari-long-headers-01.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. >=20 > Filename: draft-wkumari-long-headers > Revision: 01 > Title: Operational Issues Associated With Long IPv6 = Extension Header Chains > Creation date: 2013-07-04 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt > Status: = http://datatracker.ietf.org/doc/draft-wkumari-long-headers > Htmlized: = http://tools.ietf.org/html/draft-wkumari-long-headers-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-long-headers-01 >=20 > Abstract: > This document explains why IPv6 header chain length affects the cost > of ASIC-based packet forwarding. It also explains why some network > service providers discard packets with exceptionally long header > chains. Finally, it identifies a reasonable header chain length. > While a network service provider can enforce any filtering policy > that supports its security model, a network service provider should > not discard IPv6 packets based solely upon header chain length if = the > header chain is not longer than the value specified herein. >=20 -- What our ancestors would really be thinking, if they were alive today, = is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From bill.jouris@insidethestack.com Wed Jul 3 17:25:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CB711E80EC for ; Wed, 3 Jul 2013 17:25:41 -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 R7XNTQEuvUpn for ; Wed, 3 Jul 2013 17:25:36 -0700 (PDT) Received: from nm2-vm9.access.bullet.mail.bf1.yahoo.com (nm2-vm9.access.bullet.mail.bf1.yahoo.com [216.109.114.82]) by ietfa.amsl.com (Postfix) with ESMTP id 391A511E80E4 for ; Wed, 3 Jul 2013 17:25:36 -0700 (PDT) Received: from [66.196.81.156] by nm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 00:25:35 -0000 Received: from [66.196.81.131] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 00:25:35 -0000 Received: from [127.0.0.1] by omp1007.access.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 00:25:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 445459.20563.bm@omp1007.access.mail.bf1.yahoo.com Received: (qmail 35490 invoked by uid 60001); 4 Jul 2013 00:25:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372897534; bh=/zCluj+fYOQpEz/78Vi/cVbLqr1y/sbw1sqUe45yEgY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=uUrAlspl3O7/NX1YYMyagUADFZvx4KJZQV36xtADRsCz0oUJiAN/T6N5nGLJARnoTPLltYnWJh4AeqpucO/r+UGGG8EseHouiQ1gPm0zEkUr3bPDvhx0YhY1FfspXDkqlJ0ICsJtTAjvBQ6NreXshkUlDKarrEZjrRi2U8VnyJ0= X-YMail-OSG: 3CW1IssVM1m9QxNAIy_4qzwj5MW0bXqP1.ucjZt.u1ZAY5c x9VQp7s4LinWlojqSc_xr7fMtRlKGukOS0YNyv0mEXvqRb56xF3QXQcgS4h_ anqeXF5h4eLU3TNtHxJZPz62ajA1YcijZa.FRG6s7Bi5qjme6MfrxdybnH3A NqPvNO92grPBNmh_Y_LQYtE3oRFwURVMVo.FI6sWwK3wPSp9gtbSZLvGSbKx hONcmvRRRAXms7vnSD4XcpjhP84Ov_BRb3KbNhoglDowM0lJwHGYbUcAuROk G2DUX.dXAofID4_iTnNa.sN5dN_4JfaEBuiCN8ikXvvEvuUuF4fF3M47ci6q i9XaSG2cn09TWqPMbSJxX9e1147ZkqU5_re8.do_XDlOHO97.TnNaQD3bjyc FJlU1wHMMNBI7.FvXQIBiW6.FDDAWw8sVWfS0D_p2H5DudqRSwkeJztBWENM idAbtgkcjJsFYQ6186cwRhPYMycUsrXhLjs60qi6dnoOpYkDEI9KUJZx0aX6 xF1LysF.HVp3C3uoppKRQpLK7e79djpmImgJC1LSpIxwF8RAxiet.BavMpvT 4PlPXCguFSqIIw.WI4qdgern90O2gKHsEyG7wE2_K.0d6YfhIStrqU5IZAIg Yez4D6qkXRlUX3JzOdfCMod8Yl87YulLZzX.6mCOBem0MnJ6J3xDWt6HfVzA - Received: from [50.143.174.186] by web2802.biz.mail.ne1.yahoo.com via HTTP; Wed, 03 Jul 2013 17:25:34 PDT X-Rocket-MIMEInfo: 002.001, U28gaW4gc3VtbWFyeSwgQVNJQy1iYXNlZCBmb3J3YXJkZXJzIChhbmQgSVNQcyB3aGljaCB1c2UgdGhlbSkgY2FuIGNhbGwgdGhlbXNlbHZlcyBJUHY2LWNvbXBsaWFudCwgZXZlbiB0aG91Z2ggdGhleSBhcmUgdW5hYmxlIHRvIChvciBjaG9vc2Ugbm90IHRvKSBwYXJzZSBJUHY2IGhlYWRlcnMuwqAgSnVzdCBhcyBsb25nIGFzIHRoZXkgZG9uJ3QgZGlzY2FyZCBwYWNrZXRzIHdpdGggSVB2NiBoZWFkZXJzIHdoaWNoIGFyZSBzaG9ydGVyIHRoYW4gMTI4IGJ5dGVzLiAKCgpXaGljaCB3b3VsZCBhcHBlYXIgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> Message-ID: <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Wed, 3 Jul 2013 17:25:34 -0700 (PDT) From: Bill Jouris To: "v6ops@ietf.org Operations" In-Reply-To: <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-277646772-1372897534=:35448" Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Jouris List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 00:25:41 -0000 ---153701192-277646772-1372897534=:35448 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So in summary, ASIC-based forwarders (and ISPs which use them) can call the= mselves IPv6-compliant, even though they are unable to (or choose not to) p= arse IPv6 headers.=A0 Just as long as they don't discard packets with IPv6 = headers which are shorter than 128 bytes. =0A=0A=0AWhich would appear to be= another way to say that, even though IPv6 has been around for over a decad= e, we won't (now or, presumably, ever) require that the Internet be able to= actually deal it.=A0 Or with IPv6 packets, even though they conform entire= ly to the long-standing IPv6 specifications.=A0 Is there a reason for this,= other than avoiding forcing vendors to actually get around to finally deal= ing with the specifications that we wrote?=A0 Pr, more to the point, being = able to claim that they are "IPv6 complaint" when they manifestly are not?= =0A=0AWhy not just tell them to admit that they are not compliant?=A0 If th= ey don't want to change, just indulge in a little truth in advertising. =0A= =0A=A0=0ABill Jouris=0AInside Products, Inc.=0Awww.insidethestack.com=0A831= -659-8360=0A925-855-9512 (direct)=0A=0A=0A=0A______________________________= __=0A From: Warren Kumari =0ATo: "v6ops@ietf.org Operati= ons" =0ASent: Wednesday, July 3, 2013 4:58 PM=0ASubject: [= v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt= =0A =0A=0A=0A=0ABegin forwarded message:=0A=0A> A new version of I-D, draft= -wkumari-long-headers-01.txt=0A> has been successfully submitted by Warren = Kumari and posted to the=0A> IETF repository.=0A> =0A> Filename:=A0=A0=A0 = draft-wkumari-long-headers=0A> Revision:=A0=A0=A0 01=0A> Title:=A0=A0=A0 = =A0=A0=A0 Operational Issues Associated With Long IPv6 Extension Header Ch= ains=0A> Creation date:=A0=A0=A0 2013-07-04=0A> Group:=A0=A0=A0 =A0=A0=A0 = Individual Submission=0A> Number of pages: 8=0A> URL:=A0 =A0 =A0 =A0 =A0 = =A0 http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt= =0A> Status:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-wkuma= ri-long-headers=0A> Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/dra= ft-wkumari-long-headers-01=0A> Diff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf= .org/rfcdiff?url2=3Ddraft-wkumari-long-headers-01=0A> =0A> Abstract:=0A>=A0= This document explains why IPv6 header chain length affects the cost=0A>= =A0 of ASIC-based packet forwarding.=A0 It also explains why some network= =0A>=A0 service providers discard packets with exceptionally long header= =0A>=A0 chains.=A0 Finally, it identifies a reasonable header chain length= .=0A>=A0 While a network service provider can enforce any filtering policy= =0A>=A0 that supports its security model, a network service provider shoul= d=0A>=A0 not discard IPv6 packets based solely upon header chain length if= the=0A>=A0 header chain is not longer than the value specified herein.=0A= > =0A=0A--=0AWhat our ancestors would really be thinking, if they were aliv= e today, is: "Why is it so dark in here?"=0A=0A=A0 =A0 -- (Terry Pratchett,= Pyramids)=0A=0A=0A_______________________________________________=0Av6ops = mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---153701192-277646772-1372897534=:35448 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So in summary, ASIC-b= ased forwarders (and ISPs which use them) can call themselves IPv6-complian= t, even though they are unable to (or choose not to) parse IPv6 headers.&nb= sp; Just as long as they don't discard packets with IPv6 headers which are shorter than 128 bytes.

Which would appear to be another w= ay to say that, even though IPv6 has been around for over a decade, we won'= t (now or, presumably, ever) require that the Internet be able to actually = deal it.  Or with IPv6 packets, even though they conform entirely to the long-standing IPv6 specifications.  Is there a reason for this, o= ther than avoiding forcing vendors to actually get around to finally dealin= g with the specifications that we wrote?  Pr, more to the point, being= able to claim that they are "IPv6 complaint" when they manifestly are not?=

Why not just tell them to admit that they are not compliant?  If= they don't want to change, just indulge in a little truth in advertising. =
 
Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-836= 0
925-855-9512 (direct)

From: Warren Kumari <warren@kumari.net> To: "v6ops@ietf.org Ope= rations" <v6ops@ietf.org>
= Sent: Wednesday, July 3, 2013 4:58 PM
Subject: [v6ops] Fwd: New Version Notification f= or draft-wkumari-long-headers-01.txt

=0A

Begin forwarded message:

> A new versi= on of I-D, draft-wkumari-long-headers-01.txt
> has been successfully = submitted by Warren Kumari and posted to the
> IETF repository.
&g= t;
> Filename:    draft-wkumari-long-headers
>= Revision:    01
> Title:     &nb= sp;  Operational Issues Associated With Long IPv6 Extension Header Ch= ains
> Creation date:    2013-07-04
> Group:&nb= sp;       Individual Submission
> Number of= pages: 8
> URL:            http://www= .ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt
> Status:=           http://datatracker.ietf.org/doc/draft-wk= umari-long-headers
> Htmlized:        http://tool= s.ietf.org/html/draft-wkumari-long-headers-01
> Diff:    &n= bsp;       http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-long-header= s-01
>
> Abstract:
>  This document explains why I= Pv6 header chain length affects the cost
>  of ASIC-based packe= t forwarding.  It also explains why some network
>  servic= e providers discard packets with exceptionally long header
>  c= hains.  Finally, it identifies a reasonable header chain length.
&g= t;  While a network service provider can enforce any filtering policy=
>  that supports its security model, a network service provide= r should
>  not discard IPv6 packets based solely upon header c= hain length if the
>  header chain is not longer than the value= specified herein.
>

--
What our ancestors would really be= thinking, if they were alive today, is: "Why is it so dark in here?"
    -- (Terry Pratchett, Pyramids)


_______________________________________________
v6= ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6o= ps


---153701192-277646772-1372897534=:35448-- From cb.list6@gmail.com Wed Jul 3 17:47:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9DE21F9AA0 for ; Wed, 3 Jul 2013 17:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 tdGzaNxxij4B for ; Wed, 3 Jul 2013 17:47:07 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1848121F9A88 for ; Wed, 3 Jul 2013 17:47:06 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so700011wib.2 for ; Wed, 03 Jul 2013 17:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=67xDIG7me4KFrJZOBwWMYKDOjyaNeJ+1UAv2FRI1fOg=; b=Cl3n6kyEbNm2GAzcx9VAIM1Sc4VhxldGG3SEDzKx08+nUmEeHFguA5oB0sraI9ZZ3w 6smSlDg82wAFwbGrR0m2cKfR4i068gYpipKiSbtNnCkHvajLKj/MxDpJrylQqlaoKPzp 7CfIK8Qww+hhdZSQ6g5Z/486JVvP+f/k+56uETt24GO1UIgNN7vuEaiaWcDkf07ZjLBU 4ebLHfyErfs3IYtd+EtJ/ym1AL477Y5iYkhKZX5a2dKQIuSUmc8bvjnkm/JMJncBD2b3 4u9qCm/wA0WF8fe7pirZCOqstp2etpzbRxSaZayzJaPoZdcRJEHCAP0zhinL0MNhK/PE 2juQ== MIME-Version: 1.0 X-Received: by 10.180.211.202 with SMTP id ne10mr1940028wic.39.1372898825986; Wed, 03 Jul 2013 17:47:05 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Wed, 3 Jul 2013 17:47:05 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Wed, 3 Jul 2013 17:47:05 -0700 (PDT) In-Reply-To: <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Wed, 3 Jul 2013 17:47:05 -0700 Message-ID: From: "cb.list6" To: Bill Jouris Content-Type: multipart/alternative; boundary=001a11c259eed5e87904e0a4ea79 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 00:47:08 -0000 --001a11c259eed5e87904e0a4ea79 Content-Type: text/plain; charset=ISO-8859-1 On Jul 3, 2013 5:25 PM, "Bill Jouris" wrote: > > So in summary, ASIC-based forwarders (and ISPs which use them) can call themselves IPv6-compliant, even though they are unable to (or choose not to) parse IPv6 headers. Just as long as they don't discard packets with IPv6 headers which are shorter than 128 bytes. > > Which would appear to be another way to say that, even though IPv6 has been around for over a decade, we won't (now or, presumably, ever) require that the Internet be able to actually deal it. Or with IPv6 packets, even though they conform entirely to the long-standing IPv6 specifications. Is there a reason for this, other than avoiding forcing vendors to actually get around to finally dealing with the specifications that we wrote? Pr, more to the point, being able to claim that they are "IPv6 complaint" when they manifestly are not? > > Why not just tell them to admit that they are not compliant? If they don't want to change, just indulge in a little truth in advertising. > The internet, including ipv4, does not work as originally specified. That does not matter. What matter is that the internet evolves and adapts according to various stressors CB > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > ________________________________ > From: Warren Kumari > To: "v6ops@ietf.org Operations" > Sent: Wednesday, July 3, 2013 4:58 PM > Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt > > > > Begin forwarded message: > > > A new version of I-D, draft-wkumari-long-headers-01.txt > > has been successfully submitted by Warren Kumari and posted to the > > IETF repository. > > > > Filename: draft-wkumari-long-headers > > Revision: 01 > > Title: Operational Issues Associated With Long IPv6 Extension Header Chains > > Creation date: 2013-07-04 > > Group: Individual Submission > > Number of pages: 8 > > URL: http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt > > Status: http://datatracker.ietf.org/doc/draft-wkumari-long-headers > > Htmlized: http://tools.ietf.org/html/draft-wkumari-long-headers-01 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01 > > > > Abstract: > > This document explains why IPv6 header chain length affects the cost > > of ASIC-based packet forwarding. It also explains why some network > > service providers discard packets with exceptionally long header > > chains. Finally, it identifies a reasonable header chain length. > > While a network service provider can enforce any filtering policy > > that supports its security model, a network service provider should > > not discard IPv6 packets based solely upon header chain length if the > > header chain is not longer than the value specified herein. > > > > -- > What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" > > -- (Terry Pratchett, Pyramids) > > > _______________________________________________ > 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 > --001a11c259eed5e87904e0a4ea79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 3, 2013 5:25 PM, "Bill Jouris" <bill.jouris@insidethestack.com> wrote: >
> So in summary, ASIC-based forwarders (and ISPs which use them) can cal= l themselves IPv6-compliant, even though they are unable to (or choose not = to) parse IPv6 headers.=A0 Just as long as they don't discard packets w= ith IPv6 headers which are shorter than 128 bytes.
>
> Which would appear to be another way to say that, even though IPv6 has= been around for over a decade, we won't (now or, presumably, ever) req= uire that the Internet be able to actually deal it.=A0 Or with IPv6 packets= , even though they conform entirely to the long-standing IPv6 specification= s.=A0 Is there a reason for this, other than avoiding forcing vendors to ac= tually get around to finally dealing with the specifications that we wrote?= =A0 Pr, more to the point, being able to claim that they are "IPv6 com= plaint" when they manifestly are not?
>
> Why not just tell them to admit that they are not compliant?=A0 If the= y don't want to change, just indulge in a little truth in advertising. =
> =A0

The internet, including ipv4, does not work as originally sp= ecified.

That does not matter.

What matter is that the internet evolves and adapts accordin= g to various stressors

CB

> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com > 831-659-8360
> 925-855-9512 (direct)
>
> ________________________________
> From: Warren Kumari <warren@ku= mari.net>
> To: "v6ops@ietf.org Operati= ons" <v6ops@ietf.org>
> Sent: Wednesday, July 3, 2013 4:58 PM
> Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-= headers-01.txt
>
>
>
> Begin forwarded message:
>
> > A new version of I-D, draft-wkumari-long-headers-01.txt
> > has been successfully submitted by Warren Kumari and posted to th= e
> > IETF repository.
> >
> > Filename:=A0=A0=A0 draft-wkumari-long-headers
> > Revision:=A0=A0=A0 01
> > Title:=A0=A0=A0 =A0=A0=A0 Operational Issues Associated With Long= IPv6 Extension Header Chains
> > Creation date:=A0=A0=A0 2013-07-04
> > Group:=A0=A0=A0 =A0=A0=A0 Individual Submission
> > Number of pages: 8
> > URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-d= rafts/draft-wkumari-long-headers-01.txt
> > Status:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-wkum= ari-long-headers
> > Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-wkumari-long-= headers-01
> > Diff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2= =3Ddraft-wkumari-long-headers-01
> >
> > Abstract:
> >=A0 This document explains why IPv6 header chain length affects th= e cost
> >=A0 of ASIC-based packet forwarding.=A0 It also explains why some = network
> >=A0 service providers discard packets with exceptionally long head= er
> >=A0 chains.=A0 Finally, it identifies a reasonable header chain le= ngth.
> >=A0 While a network service provider can enforce any filtering pol= icy
> >=A0 that supports its security model, a network service provider s= hould
> >=A0 not discard IPv6 packets based solely upon header chain length= if the
> >=A0 header chain is not longer than the value specified herein. > >
>
> --
> What our ancestors would really be thinking, if they were alive today,= is: "Why is it so dark in here?"
>
> =A0 =A0 -- (Terry Pratchett, Pyramids)
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a11c259eed5e87904e0a4ea79-- From cb.list6@gmail.com Wed Jul 3 17:52:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47A411E80E4 for ; Wed, 3 Jul 2013 17:52:44 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 KZjfIm3yDMc8 for ; Wed, 3 Jul 2013 17:52:43 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC3221F9B87 for ; Wed, 3 Jul 2013 17:52:38 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so702298wib.2 for ; Wed, 03 Jul 2013 17:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V4OLFrDYsb9QtmScu0/g+xsbPzBb6GYQLrDiAIvF4E0=; b=Zw5f4cbzQ3BhBw4Hfpd7OAiX2TvLhzNiuYHTEL+fV7pOFztfpFmR2jlzzT5nt71XHQ APKZk5e2HdEiOeQptGhRWO7VdgzZB8LknJeOWpJaXbIERSmMUQUMyQaN2O24JidZYjHX IWzMj6bECxgJ34I5SNDijq17IaySY2NOqvTh9WEjZhpRuMORAa0j+u+4cRDugnhy43Tl zfHdW71q96yGC9xCz6F7AtL9RSJdc1KxPSks+VZR5L5Vjn0MmbR5rwVQNMxi40MJ8pNt bAOIiapJfN38fzPRU3YJxB+3JfChW61lCVAb8A092bhaTBWSfptlaI+U3QnmbbeByVmT XsRQ== MIME-Version: 1.0 X-Received: by 10.180.108.50 with SMTP id hh18mr19237301wib.39.1372899148597; Wed, 03 Jul 2013 17:52:28 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Wed, 3 Jul 2013 17:52:28 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Wed, 3 Jul 2013 17:52:28 -0700 (PDT) In-Reply-To: References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Wed, 3 Jul 2013 17:52:28 -0700 Message-ID: From: "cb.list6" To: Bill Jouris Content-Type: multipart/alternative; boundary=e89a8f3b9fdd108fd404e0a4fef7 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 00:52:44 -0000 --e89a8f3b9fdd108fd404e0a4fef7 Content-Type: text/plain; charset=ISO-8859-1 On Jul 3, 2013 5:47 PM, "cb.list6" wrote: > > > On Jul 3, 2013 5:25 PM, "Bill Jouris" wrote: > > > > So in summary, ASIC-based forwarders (and ISPs which use them) can call themselves IPv6-compliant, even though they are unable to (or choose not to) parse IPv6 headers. Just as long as they don't discard packets with IPv6 headers which are shorter than 128 bytes. > > > > Which would appear to be another way to say that, even though IPv6 has been around for over a decade, we won't (now or, presumably, ever) require that the Internet be able to actually deal it. Or with IPv6 packets, even though they conform entirely to the long-standing IPv6 specifications. Is there a reason for this, other than avoiding forcing vendors to actually get around to finally dealing with the specifications that we wrote? Pr, more to the point, being able to claim that they are "IPv6 complaint" when they manifestly are not? > > > > Why not just tell them to admit that they are not compliant? If they don't want to change, just indulge in a little truth in advertising. > > > > The internet, including ipv4, does not work as originally specified. > > That does not matter. > > What matter is that the internet evolves and adapts according to various stressors > > CB > Or as a visual of what is going on http://blogs.cisco.com/wp-content/uploads/tyre_swing1.jpg CB > > Bill Jouris > > Inside Products, Inc. > > www.insidethestack.com > > 831-659-8360 > > 925-855-9512 (direct) > > > > ________________________________ > > From: Warren Kumari > > To: "v6ops@ietf.org Operations" > > Sent: Wednesday, July 3, 2013 4:58 PM > > Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt > > > > > > > > Begin forwarded message: > > > > > A new version of I-D, draft-wkumari-long-headers-01.txt > > > has been successfully submitted by Warren Kumari and posted to the > > > IETF repository. > > > > > > Filename: draft-wkumari-long-headers > > > Revision: 01 > > > Title: Operational Issues Associated With Long IPv6 Extension Header Chains > > > Creation date: 2013-07-04 > > > Group: Individual Submission > > > Number of pages: 8 > > > URL: http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt > > > Status: http://datatracker.ietf.org/doc/draft-wkumari-long-headers > > > Htmlized: http://tools.ietf.org/html/draft-wkumari-long-headers-01 > > > Diff: http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01 > > > > > > Abstract: > > > This document explains why IPv6 header chain length affects the cost > > > of ASIC-based packet forwarding. It also explains why some network > > > service providers discard packets with exceptionally long header > > > chains. Finally, it identifies a reasonable header chain length. > > > While a network service provider can enforce any filtering policy > > > that supports its security model, a network service provider should > > > not discard IPv6 packets based solely upon header chain length if the > > > header chain is not longer than the value specified herein. > > > > > > > -- > > What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" > > > > -- (Terry Pratchett, Pyramids) > > > > > > _______________________________________________ > > 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 > > --e89a8f3b9fdd108fd404e0a4fef7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 3, 2013 5:47 PM, "cb.list6" <cb.list6@gmail.com> wrote:
>
>
> On Jul 3, 2013 5:25 PM, "Bill Jouris" <bill.jouris@insidethestack.com> wrot= e:
> >
> > So in summary, ASIC-based forwarders (and ISPs which use them) ca= n call themselves IPv6-compliant, even though they are unable to (or choose= not to) parse IPv6 headers.=A0 Just as long as they don't discard pack= ets with IPv6 headers which are shorter than 128 bytes.
> >
> > Which would appear to be another way to say that, even though IPv= 6 has been around for over a decade, we won't (now or, presumably, ever= ) require that the Internet be able to actually deal it.=A0 Or with IPv6 pa= ckets, even though they conform entirely to the long-standing IPv6 specific= ations.=A0 Is there a reason for this, other than avoiding forcing vendors = to actually get around to finally dealing with the specifications that we w= rote?=A0 Pr, more to the point, being able to claim that they are "IPv= 6 complaint" when they manifestly are not?
> >
> > Why not just tell them to admit that they are not compliant?=A0 I= f they don't want to change, just indulge in a little truth in advertis= ing.
> > =A0
>
> The internet, including ipv4, does not work as originally specified. >
> That does not matter.
>
> What matter is that the internet evolves and adapts according to vario= us stressors
>
> CB
>

Or as a visual of what is going on http://blogs.cisco.com/wp-cont= ent/uploads/tyre_swing1.jpg

CB

> > Bill Jouris
> > Inside Products, Inc.
> > www.insidethestack.com<= /a>
> > 831-659-8360
> > 925-855-9512 (direct)
> >
> > ________________________________
> > From: Warren Kumari <warr= en@kumari.net>
> > To: "v6ops@ietf.org Op= erations" <v6ops@ietf.org>=
> > Sent: Wednesday, July 3, 2013 4:58 PM
> > Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-= long-headers-01.txt
> >
> >
> >
> > Begin forwarded message:
> >
> > > A new version of I-D, draft-wkumari-long-headers-01.txt
> > > has been successfully submitted by Warren Kumari and posted = to the
> > > IETF repository.
> > >
> > > Filename:=A0=A0=A0 draft-wkumari-long-headers
> > > Revision:=A0=A0=A0 01
> > > Title:=A0=A0=A0 =A0=A0=A0 Operational Issues Associated With= Long IPv6 Extension Header Chains
> > > Creation date:=A0=A0=A0 2013-07-04
> > > Group:=A0=A0=A0 =A0=A0=A0 Individual Submission
> > > Number of pages: 8
> > > URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/inter= net-drafts/draft-wkumari-long-headers-01.txt
> > > Status:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft= -wkumari-long-headers
> > > Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-wkumari-= long-headers-01
> > > Diff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-wkumari-long-headers-01
> > >
> > > Abstract:
> > >=A0 This document explains why IPv6 header chain length affec= ts the cost
> > >=A0 of ASIC-based packet forwarding.=A0 It also explains why = some network
> > >=A0 service providers discard packets with exceptionally long= header
> > >=A0 chains.=A0 Finally, it identifies a reasonable header cha= in length.
> > >=A0 While a network service provider can enforce any filterin= g policy
> > >=A0 that supports its security model, a network service provi= der should
> > >=A0 not discard IPv6 packets based solely upon header chain l= ength if the
> > >=A0 header chain is not longer than the value specified herei= n.
> > >
> >
> > --
> > What our ancestors would really be thinking, if they were alive t= oday, is: "Why is it so dark in here?"
> >
> > =A0 =A0 -- (Terry Pratchett, Pyramids)
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >

--e89a8f3b9fdd108fd404e0a4fef7-- From bill.jouris@insidethestack.com Wed Jul 3 17:54:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087C711E8114 for ; Wed, 3 Jul 2013 17:54:11 -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 8MTgH+4L9pw9 for ; Wed, 3 Jul 2013 17:54:03 -0700 (PDT) Received: from nm18-vm9.access.bullet.mail.gq1.yahoo.com (nm18-vm9.access.bullet.mail.gq1.yahoo.com [216.39.62.65]) by ietfa.amsl.com (Postfix) with ESMTP id A22BC21F9B9C for ; Wed, 3 Jul 2013 17:54:02 -0700 (PDT) Received: from [216.39.60.175] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 00:54:01 -0000 Received: from [216.39.60.231] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 00:54:01 -0000 Received: from [127.0.0.1] by omp1002.access.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 00:54:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 417503.4789.bm@omp1002.access.mail.gq1.yahoo.com Received: (qmail 87694 invoked by uid 60001); 4 Jul 2013 00:54:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372899240; bh=EOtu7OtRbJmpQTLblRnV12+3VuKbeAE6GyVV5PcQqLM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0FD99RjbCvxvJu5xS9LXjVIOT/SWdHCkhlUqyhOEFXetT9/Eto0AR53V3IcOKZkeY/v+Nbp0QlFp4z7Lu4/Z1KTvJqDX/ErQO51bTGNdc3r0cvy/GTnTwJkDrJPw6fyfEY0k0uj16DvIMRg4dK8NfJ5mTH2ougRaW4yYkPdguiw= X-YMail-OSG: JDfDVJsVM1me8m3oBWggTI5cPY52ssfKExLpQpl4LphPcEp uECsbxAsjZ47GU0aDqb4._Xwd7rzSxJx6AJvu6jHp2MbjXLEHelle5thYJhS E_mXr.Yn__l.uvYWQaSLmZnQFROhpUSi69oqSDdXo0yLA28neLaDzNwMmcMI SWM3COQhwroIgMXG..GqkUSePRyo.4LnTjczdpfO0nwVWy1X7VperrNWDB4p 9DmY0vKKVfmuchXyiDdJJ7GaEu7EU5rSCovO1KwQJUFqIIgg17qGbHZbaOQr BxPPokdNXW1Hb1T9voc0EZkGeVVQLVnp1vWPW5pJ3fPAWUNHdtlM6FLDJOj5 3atF2euHhXtCrw1.0UXAfY11KYCN_QBvEyeDoVuo.HPonTwMnDtvCr.kwFBS odilLsOfirYeoxm1T65W4gmnFNltebrgh_8LXFIn268qd14gEMey4KYo55et Wr59Cb.WljJEl2j1_7Sl33D_a4Yibt4FNaR.zz9kME.ThZy8bI.QTM43Ppri M5ezfU2BO_toK45XGzZZws6iCyaHefq.Ui2YycymQ8NSrukxIy04WnyDP6OG EGgddALURfzv1tBMHuXDvw4zWzcrW.EzM0guADXW272cvm9KWWCBbalCJmwQ Yzi.ENToGHGFdDurp1G5Mk3kvofNzyvu_0cvWIh6_H7b5y0QO4Dgtp6uDiXl 4z8KBxA-- Received: from [50.143.174.186] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 03 Jul 2013 17:54:00 PDT X-Rocket-MIMEInfo: 002.001, SSBoYXZlIG5vIHByb2JsZW0gYXQgYWxsIHdpdGggdGhlIHNwZWNpZmljYXRpb25zIGV2b2x2aW5nIHRvIG1ha2UgdGhlIEludGVybmV0IHdvcmsgYmV0dGVyLsKgIEJ1dCB0aGlzIGlzbid0IHdoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgaGVyZS7CoCBSYXRoZXIsIHdlIGFyZSB0YWxraW5nIGFib3V0IGNoYW5naW5nIHRoZSBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIGNvbnZlbmllbmNlLCBub3Qgb2YgdGhvc2UgdXNpbmcgdGhlIEludGVybmV0LCBidXQgb2YgdGhvc2UgYnVpbGRpbmcgdGhlIGluZnJhc3RydWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Message-ID: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 3 Jul 2013 17:54:00 -0700 (PDT) From: Bill Jouris To: IPv6 Ops WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1264173757-1372899240=:80312" Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Jouris List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 00:54:15 -0000 ---1551098171-1264173757-1372899240=:80312 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have no problem at all with the specifications evolving to make the Inter= net work better.=A0 But this isn't what we are talking about here.=A0 Rathe= r, we are talking about changing the specifications for the convenience, no= t of those using the Internet, but of those building the infrastructure.=0A= =0AOr are you (or the authors) suggesting that there are technical problems= with making a device which could handle longer headers in hardware?=A0 If = that is the contention, then I apologize for missing that in the discussion= .=A0 (And I suggest that the RFC ought to include at least some discussion = of what those techincal issues.)=0A=0A=A0=0ABill Jouris=0AInside Products, = Inc.=0Awww.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A=0A= =0A=0A=0A________________________________=0A From: cb.list6 =0ATo: Bill Jouris =0ACc: IPv6 Ops WG= =0ASent: Wednesday, July 3, 2013 5:47 PM=0ASubject: Re: [= v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt= =0A =0A=0A=0A=0AOn Jul 3, 2013 5:25 PM, "Bill Jouris" wrote:=0A>=0A> So in summary, ASIC-based forwarders (and ISPs w= hich use them) can call themselves IPv6-compliant, even though they are una= ble to (or choose not to) parse IPv6 headers.=A0 Just as long as they don't= discard packets with IPv6 headers which are shorter than 128 bytes. =0A>= =0A> Which would appear to be another way to say that, even though IPv6 has= been around for over a decade, we won't (now or, presumably, ever) require= that the Internet be able to actually deal it.=A0 Or with IPv6 packets, ev= en though they conform entirely to the long-standing IPv6 specifications.= =A0 Is there a reason for this, other than avoiding forcing vendors to actu= ally get around to finally dealing with the specifications that we wrote?= =A0 Pr, more to the point, being able to claim that they are "IPv6 complain= t" when they manifestly are not?=0A>=0A> Why not just tell them to admit th= at they are not compliant?=A0 If they don't want to change, just indulge in= a little truth in advertising. =0A> =A0=0A=0AThe internet, including ipv4,= does not work as originally specified. =0AThat does not matter.=0AWhat mat= ter is that the internet evolves and adapts according to various stressors= =0ACB=0A> Bill Jouris=0A> Inside Products, Inc.=0A> www.insidethestack.com= =0A> 831-659-8360=0A> 925-855-9512 (direct)=0A>=0A> _______________________= _________=0A> From: Warren Kumari =0A> To: "v6ops@ietf.o= rg Operations" =0A> Sent: Wednesday, July 3, 2013 4:58 PM= =0A> Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-= headers-01.txt=0A>=0A>=0A>=0A> Begin forwarded message:=0A>=0A> > A new ver= sion of I-D, draft-wkumari-long-headers-01.txt=0A> > has been successfully = submitted by Warren Kumari and posted to the=0A> > IETF repository.=0A> > = =0A> > Filename:=A0=A0=A0 draft-wkumari-long-headers=0A> > Revision:=A0=A0= =A0 01=0A> > Title:=A0=A0=A0 =A0=A0=A0 Operational Issues Associated With L= ong IPv6 Extension Header Chains=0A> > Creation date:=A0=A0=A0 2013-07-04= =0A> > Group:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A> > Number of page= s: 8=0A> > URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/= draft-wkumari-long-headers-01.txt=0A> > Status:=A0 =A0 =A0 =A0 =A0 http://d= atatracker.ietf.org/doc/draft-wkumari-long-headers=0A> > Htmlized:=A0 =A0 = =A0 =A0 http://tools.ietf.org/html/draft-wkumari-long-headers-01=0A> > Diff= :=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-l= ong-headers-01=0A> > =0A> > Abstract:=0A> >=A0 This document explains why I= Pv6 header chain length affects the cost=0A> >=A0 of ASIC-based packet forw= arding.=A0 It also explains why some network=0A> >=A0 service providers dis= card packets with exceptionally long header=0A> >=A0 chains.=A0 Finally, it= identifies a reasonable header chain length.=0A> >=A0 While a network serv= ice provider can enforce any filtering policy=0A> >=A0 that supports its se= curity model, a network service provider should=0A> >=A0 not discard IPv6 p= ackets based solely upon header chain length if the=0A> >=A0 header chain i= s not longer than the value specified herein.=0A> > =0A>=0A> --=0A> What ou= r ancestors would really be thinking, if they were alive today, is: "Why is= it so dark in here?"=0A>=0A> =A0 =A0 -- (Terry Pratchett, Pyramids)=0A>=0A= >=0A> _______________________________________________=0A> v6ops mailing lis= t=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A= >=0A>=0A> _______________________________________________=0A> v6ops mailing= list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A= > ---1551098171-1264173757-1372899240=:80312 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have no problem at = all with the specifications evolving to make the Internet work better. = ; But this isn't what we are talking about here.  Rather, we are talki= ng about changing the specifications for the convenience, not of those usin= g the Internet, but of those building the infrastructure.

=
Or are you (or the authors) suggesting that there are technic= al problems with making a device which could handle longer headers in hardw= are?  If that is the contention, then I apologize for missing that in the discussion.  (And I suggest that the RFC ought to include at leas= t some discussion of what those techincal issues.)
&nb= sp;
Bill Jouris
Insid= e Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 = (direct)


From: cb.list6 <cb.list6@gmail.com>
To: Bill Jouris <bill.jouris@insideth= estack.com>
Cc: IPv= 6 Ops WG <v6ops@ietf.org>
= Sent: Wednesday, July 3, 2013 5:47 PM
Subject: Re: [v6ops] Fwd: New Version Notification for d= raft-wkumari-long-headers-01.txt

=0A=

=0AOn Jul 3, 2013 5:25 PM, "= Bill Jouris" <bill.jouris@insidethestack.com> wrote:
=0A>
=0A> So in= summary, ASIC-based forwarders (and ISPs which use them) can call themselv= es IPv6-compliant, even though they are unable to (or choose not to) parse = IPv6 headers.  Just as long as they don't discard packets with IPv6 he= aders which are shorter than 128 bytes.
=0A=0A>
=0A> Which wou= ld appear to be another way to say that, even though IPv6 has been around f= or over a decade, we won't (now or, presumably, ever) require that the Inte= rnet be able to actually deal it.  Or with IPv6 packets, even though t= hey conform entirely to the long-standing IPv6 specifications.  Is the= re a reason for this, other than avoiding forcing vendors to actually get a= round to finally dealing with the specifications that we wrote?  Pr, m= ore to the point, being able to claim that they are "IPv6 complaint" when t= hey manifestly are not?
=0A=0A>
=0A> Why not just tell them to = admit that they are not compliant?  If they don't want to change, just= indulge in a little truth in advertising.
=0A>  
=0A<= div dir=3D"ltr">The internet, including ipv4, does not work as originally s= pecified.
=0A
That does not matter.
=0A
What matter is that the internet evolves and adapts according to v= arious stressors
=0A
CB
=0A
> = Bill Jouris
=0A> Inside Products, Inc.
=0A> www.insidethesta= ck.com
=0A> 831-659-8360
=0A> 925-855-9512 (direct)
=0A&= gt;
=0A> ________________________________
=0A> From: Warren Kum= ari <warren@kumari.net>
=0A&= gt; To: "v6ops@ietf.org Operations" <v6ops@ietf.org>
=0A> Sent: Wednesd= ay, July 3, 2013 4:58 PM
=0A> Subject: [v6ops] Fwd: New Version Notif= ication for draft-wkumari-long-headers-01.txt
=0A>
=0A>
=0A&= gt;
=0A> Begin forwarded message:
=0A>
=0A> > A new ve= rsion of I-D, draft-wkumari-long-headers-01.txt
=0A> > has been su= ccessfully submitted by Warren Kumari and posted to the
=0A> > IET= F repository.
=0A> >
=0A> > Filename:    = draft-wkumari-long-headers
=0A> > Revision:    01=0A> > Title:        Operational Issu= es Associated With Long IPv6 Extension Header Chains
=0A> > Creati= on date:    2013-07-04
=0A> > Group:  &nb= sp;     Individual Submission
=0A> > Number of page= s: 8
=0A> > URL:            http://w= ww.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt
=0A> &g= t; Status:          http://datatracker.ietf.org/do= c/draft-wkumari-long-headers
=0A> > Htmlized:      =   http://tools.ietf.org/html/draft-wkumari-long-headers-01
=0A> = > Diff:            http://www.ietf.org/rfc= diff?url2=3Ddraft-wkumari-long-headers-01
=0A> >
=0A> > = Abstract:
=0A> >  This document explains why IPv6 header chai= n length affects the cost
=0A> >  of ASIC-based packet forwar= ding.  It also explains why some network
=0A> >  service= providers discard packets with exceptionally long header
=0A> >&n= bsp; chains.  Finally, it identifies a reasonable header chain length.=
=0A> >  While a network service provider can enforce any fil= tering policy
=0A> >  that supports its security model, a net= work service provider should
=0A> >  not discard IPv6 packets= based solely upon header chain length if the
=0A> >  header = chain is not longer than the value specified herein.
=0A> >
= =0A>
=0A> --
=0A> What our ancestors would really be thinkin= g, if they were alive today, is: "Why is it so dark in here?"
=0A>=0A>     -- (Terry Pratchett, Pyramids)
=0A>
=0A>=
=0A> _______________________________________________
=0A> v6op= s mailing list
=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A>
=0A>
=0A>
=0A> _________________________________= ______________
=0A> v6ops mailing list
=0A> v6ops@ietf.org
=0A> https://www.ietf.org= /mailman/listinfo/v6ops
=0A>
=0A
=0A


<= /div> ---1551098171-1264173757-1372899240=:80312-- From Ted.Lemon@nominum.com Wed Jul 3 18:14:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F3D11E80EC for ; Wed, 3 Jul 2013 18:14:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N19B7P2IU7VZ for ; Wed, 3 Jul 2013 18:13:57 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4211E80E4 for ; Wed, 3 Jul 2013 18:13:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUdTMVcyiN6WZ3enQBN2h3IHIUc9CLvgh@postini.com; Wed, 03 Jul 2013 18:13:57 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 E1AD01B821E for ; Wed, 3 Jul 2013 18:13:56 -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 DB259190061; Wed, 3 Jul 2013 18:13:56 -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.02.0318.004; Wed, 3 Jul 2013 18:13:51 -0700 From: Ted Lemon To: Bill Jouris Thread-Topic: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt Thread-Index: AQHOeElrv3jck2otOEmduD6lCqxPE5lUHsQAgAAGA4CAAAHvAIAABYsA Date: Thu, 4 Jul 2013 01:13:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751FBDCB@mbx-01.win.nominum.com> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 01:14:04 -0000 On Jul 3, 2013, at 8:54 PM, Bill Jouris wr= ote: > Or are you (or the authors) suggesting that there are technical problems = with making a device which could handle longer headers in hardware? If tha= t is the contention, then I apologize for missing that in the discussion. = (And I suggest that the RFC ought to include at least some discussion of wh= at those techincal issues.) Yes, that's what's been said. See paragraphs 1 and 2 of the introduction,= as well as the second-to-last paragraph of section 3. From Ted.Lemon@nominum.com Wed Jul 3 18:15:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7221111E811F for ; Wed, 3 Jul 2013 18:15:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcWz6ZUnM8uL for ; Wed, 3 Jul 2013 18:15:16 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0B11E80E4 for ; Wed, 3 Jul 2013 18:15:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUdTMpBoy5ambw9OEsqd6EGohPBNmWokm@postini.com; Wed, 03 Jul 2013 18:15:16 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 36E9B1B821E for ; Wed, 3 Jul 2013 18:15:16 -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 3060B190061; Wed, 3 Jul 2013 18:15:16 -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.02.0318.004; Wed, 3 Jul 2013 18:15:16 -0700 From: Ted Lemon To: Bill Jouris Thread-Topic: [v6ops] New Version Notification for draft-wkumari-long-headers-01.txt Thread-Index: AQHOeFPws9LePXSk00C3NETQBt0daQ== Date: Thu, 4 Jul 2013 01:15:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751FBE0C@mbx-01.win.nominum.com> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <8D23D4052ABE7A4490E77B1A012B6307751FBDCB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751FBDCB@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 01:15:23 -0000 On Jul 3, 2013, at 9:13 PM, Ted Lemon wrote: > See paragraphs 1 and 2 of the introduction Sorry, paragraphs 2 and 3 if you count from 1. :) From arturo.servin@gmail.com Wed Jul 3 18:19:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE321F9104 for ; Wed, 3 Jul 2013 18:19:18 -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 k52u9SQJx5ke for ; Wed, 3 Jul 2013 18:19:17 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE521F9057 for ; Wed, 3 Jul 2013 18:19:17 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so492703qcx.21 for ; Wed, 03 Jul 2013 18:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=4k+0hWvShcXcnvjW/h0WbsWQQv285w+2GKtWTgsSE7Y=; b=wjemhVTz20rbFcx0EOqE9Ts+5Dhs3PdsEddo9O3Mx1EQYz0f36Gh/p7lg/adsnNFk4 zylUp9DGX2kMKwDgBVRBL+xzsiblhBoFQOLGgYC+BdZaftmyB0laBDGAdGNyyruPqAJc iCP8JRu+ZoLTjdVz9F6JutD2mvHT/loLLLfE8rC+kwxCGB6h2t84I5Awv8614fYOJ7Ea xXgG12YWRehTp59h0kTwyD/Rvy4tLrmCqIWCVIKyy61LrPlLuALZX9hf9Py0369oq55U toqcdk1D1GYFLfqnWWI/igFgglGzUtjtR1ThZ+CxIolYdbRoNdOnGzCSQvGfHv2WF3ta ee+Q== X-Received: by 10.229.126.197 with SMTP id d5mr958155qcs.91.1372900757251; Wed, 03 Jul 2013 18:19:17 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r186-48-205-176.dialup.adsl.anteldata.net.uy. [186.48.205.176]) by mx.google.com with ESMTPSA id pg6sm789054qeb.5.2013.07.03.18.19.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 18:19:16 -0700 (PDT) Message-ID: <51D4CD90.5070005@gmail.com> Date: Wed, 03 Jul 2013 22:19:12 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> In-Reply-To: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> Content-Type: multipart/alternative; boundary="------------090907070309000305010109" Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 01:19:18 -0000 This is a multi-part message in MIME format. --------------090907070309000305010109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit SM, Why IPv6 Router Advertisement Guard would be not enough? Or are these recommendations orthogonal to a network applying RA? I think that it would be important to address those questions in the draft. Also, related. Is it possible for a host to perform a RS attack? Regards, as On 7/2/13 7:02 PM, S Moonesamy wrote: > Hello, > > An IPv6 Router Advertisements flooding attack can cause a node to > consume all CPU resources available making the system unusable and > unresponsive. draft-moonesamy-ra-flood-limit-00 ( > http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) > recommends some configurable variables as a mitigation against an IPv6 > Router Advertisements flooding attack. > > I would appreciate if you read the draft and comment. > > Regards, > S. Moonesamy > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------090907070309000305010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit SM,

    Why IPv6 Router Advertisement Guard would be not enough?

    Or are these recommendations orthogonal to a network applying RA?

    I think that it would be important to address those questions in the draft.

    Also, related. Is it possible for a host to perform a RS attack?

Regards,
as
   
On 7/2/13 7:02 PM, S Moonesamy wrote:
Hello,

An IPv6 Router Advertisements flooding attack can cause a node to consume all CPU resources available making the system unusable and unresponsive. draft-moonesamy-ra-flood-limit-00 ( http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) recommends some configurable variables as a mitigation against an IPv6 Router Advertisements flooding attack.

I would appreciate if you read the draft and comment.

Regards,
S. Moonesamy

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

--------------090907070309000305010109-- From sm@elandsys.com Wed Jul 3 18:20:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83AB21F9A0A for ; Wed, 3 Jul 2013 18:20:57 -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 LM4UQedX6dXz for ; Wed, 3 Jul 2013 18:20:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D265821F9A05 for ; Wed, 3 Jul 2013 18:20:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r641Kghh012194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 18:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372900853; bh=v5m+HUDiJrgS7NcUCXLNk8sk0WnmeKpCLsOx0H97DK8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SlpVyocWRxRWErEagWtCVWOT83WLzsVV2jDqWoUePSSt4PsTbbxK2FqngKrj/aHOX UqHFYlpZYhhFCwrTasj3wLVKGXg4Z/lDA295OGw8bvoAY8efD6lhsSfpM0HYrWS8zs ZqO7cXLnKP+10u/QbeBZlXPNKp7IEafmz4cJG7Vs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372900853; i=@elandsys.com; bh=v5m+HUDiJrgS7NcUCXLNk8sk0WnmeKpCLsOx0H97DK8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QpHQVQYzClVxvhLH+luK/FHsPepIse4Nz8SNajZ5BJp7xRPvs+A88PmOm16syiF8y Jzj9x/yFwKRlb9DRfNorcFEL44TXzokI7lKpBwL1264xb+nfJY+HToAxEuWY9tN6nV bDfXHmPWF6ianEWyZcfCNtGa4wf4QWC4pzKr3gh4= Message-Id: <6.2.5.6.2.20130703130208.0dd80478@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Jul 2013 16:05:27 -0700 To: David Farmer From: S Moonesamy In-Reply-To: <51D45EC2.6080807@umn.edu> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D3ABE4.9030901@umn.edu> <6.2.5.6.2.20130702233628.0bc7c778@elandnews.com> <51D45EC2.6080807@umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 01:20:58 -0000 Hi David, At 10:26 03-07-2013, David Farmer wrote: >I didn't say you had to deploy RFC6105 complaint devices, I said you >need that, "or the other mitigation techniques discussed in section >3 of [RFC6104]." In the particular case you describe, I'd recommend >the technique described in section 3.5 of RFC6104; Setting the valid >RA to a Router Preference of "High", this has little or no cost and >is relatively effective, especailly with the techniques described in >this draft. The reference to RFC 6104 is there so that people can read that document and decide about which mitigation technique is better suited to their needs. Setting the valid RA to a Router Preference of "High" is an operational decision instead of an implementation decision. >I agree, I'm just saying you should be more explicit about what this >does and doesn't do. Maybe add the following as an additional >paragraph to the security considerations > section; > > However, without deployment of RA Guard mechanisms as described in > [RFC6105] or the other mitigation techniques discussed in section 3 > of [RFC6104] it is still possible for a malicious attacker to > disrupt access to a network or cause traffic to be diverted. The above sounds like an operational choice. It may be better to keep the different decisions separate. >Thanks, I better understand the intended behaviour now. I suggest >the following text for section 2, to more clearly describe the >intended behaviour. > > A host will silently discard any Router Advertisement that cause one > of the following configurable limits to be exceeded. However, Router > Advertisements that only refresh previously learned configuration > information are processed. Suggested default values are specified > making it unnecessary to configure these variables for most typical > situations. Thanks for suggesting text. I would like to read the off-list comments I received and then figure out how to add the suggested changes. >My intent is not sensationalism, its fair warning. I don't want a >naive users or I don't think that was your intent. I meant that I am looking at what the code does instead of other angles that might be misleading. > enterprise network operator reading this and thinking that if > their hosts implement this all their RA issues are solved. If you > added the paragraph I suggest above to the security consideration > section I think it would provide the explicit and necessary fair > warning I'm looking for. I agree that a fair warning would be appropriate. Someone else already suggested changes to the Security Considerations section. I will incorporate them in the next revision. Regards, S. Moonesamy From brian.e.carpenter@gmail.com Wed Jul 3 20:45:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58C11E8117 for ; Wed, 3 Jul 2013 20:45:42 -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 K0SxD68RBvjH for ; Wed, 3 Jul 2013 20:45:42 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EA34511E8120 for ; Wed, 3 Jul 2013 20:45:37 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so679045pdd.20 for ; Wed, 03 Jul 2013 20:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EdPeQMbZEEKa9OUSn+mY0ZCC/00I0GcJl5dMiin8f8I=; b=CYq2l0a8Rj7K/lFFjEGbqKQuXGqJsmOahioP2VQtdsUdMaPhZuN0l++BV6nPfEcUFa /ZZkCY/mPGagGL48vtHAJFc3cfcITVM53XySILUlDkJSKRr04TMN/SupRglu35dTTsTB sGWt7j5mUR6j3jpZ95UabUwzfN1cUGVtL3hK7H1Acfa4SIognDuSpPu+kbcYQFejMuc7 PeT5dNNsTb1eld9qeKvmo5p7+IdtFjscRl8b4cBRIUUkDz110QJBFm6V10pudTn644yL WVidDeJ0iVbVyj706IiriiTwMqSrLjter7Dkq2XcsRhwQzCd+MSt9kxP/3MXbcqdMWj6 a41g== X-Received: by 10.66.5.195 with SMTP id u3mr5147657pau.79.1372909532934; Wed, 03 Jul 2013 20:45:32 -0700 (PDT) Received: from [10.1.9.177] ([203.167.141.74]) by mx.google.com with ESMTPSA id vu5sm1451788pab.10.2013.07.03.20.45.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 20:45:32 -0700 (PDT) Message-ID: <51D4EFDD.1010508@gmail.com> Date: Thu, 04 Jul 2013 15:45:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "cb.list6" References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 03:45:42 -0000 On 04/07/2013 12:47, cb.list6 wrote: ... > What matter is that the internet evolves and adapts according to various > stressors Fair enough. But that's why we should not relax the requirements too readily - to keep tension between making things work as designed and designing to minimise cots. I'd go for SHOULD and 256 bytes, to set an ambitious goal. Brian From sm@elandsys.com Thu Jul 4 01:16:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8521F9ECB for ; Thu, 4 Jul 2013 01:16:49 -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=[AWL=0.000, 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 LlBjHOxehJoa for ; Thu, 4 Jul 2013 01:16:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A921F9D9B for ; Thu, 4 Jul 2013 01:16:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r648G2kJ006021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 01:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372925774; bh=ntm61AUKZv2J/lVuhjTp26s46NTAEnBv58ZUaH35kQg=; h=Date:To:From:Subject:In-Reply-To:References; b=UDGj3O6E3ghJ9mC2PedUmYtUOt6CjJyx1f7TembvNVGdUN48oSK7Ad28QXWD09Nbk cU8PdlhY5mbjsx77K08lPULc9bXMj5zjwXzUJp5jh6CWF8qR004tDMlbCJz5jgSzh4 5xRKD51u8wynE8SDAnEDRjwv0KbBE38zaK/wJAbg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372925774; i=@elandsys.com; bh=ntm61AUKZv2J/lVuhjTp26s46NTAEnBv58ZUaH35kQg=; h=Date:To:From:Subject:In-Reply-To:References; b=nRr6gY93RYir0rRQtoI0Xaz3UErd/XKcH7uPBgYL+WFfH7vOLe6q+YnWGj0kTUiKV 7tfuOj/0gGKKPdNLZPBSBzkbBIIVDU8w/ZVM5KSKmnEY4M0DUyXPvrTwm4sy8dCQA2 T7f+EqDp4+MXjsf1EZ/8ypxESYYmHGtnKHBefF38= Message-Id: <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Jul 2013 23:02:38 -0700 To: Arturo Servin , v6ops@ietf.org From: S Moonesamy In-Reply-To: <51D4CD90.5070005@gmail.com> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 08:16:49 -0000 Hi Arturo, At 18:19 03-07-2013, Arturo Servin wrote: > Why IPv6 Router Advertisement Guard would be not enough? The draft does not seek to criticize Router Advertisement Guard in any way. The draft looks at what can occur on the host and what has been done to ensure that there isn't a crash. > Or are these recommendations orthogonal to a network applying RA? Yes. > I think that it would be important to address those questions > in the draft. That would be an operational issue. > Also, related. Is it possible for a host to perform a RS attack? I don't have sufficient information to provide a good answer. I prefer not to give you a misleading answer. Regards, S. Moonesamy From gert@space.net Thu Jul 4 02:46:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC46921F9F12 for ; Thu, 4 Jul 2013 02:46:34 -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 hHuXwl7LpwkI for ; Thu, 4 Jul 2013 02:46:34 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE521F9E78 for ; Thu, 4 Jul 2013 02:46:33 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 12969603FB for ; Thu, 4 Jul 2013 11:46:32 +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 E4D6560183 for ; Thu, 4 Jul 2013 11:46:31 +0200 (CEST) Received: (qmail 73984 invoked by uid 1007); 4 Jul 2013 11:46:31 +0200 Date: Thu, 4 Jul 2013 11:46:31 +0200 From: Gert Doering To: Bill Jouris Message-ID: <20130704094631.GV2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 09:46:35 -0000 Hi, On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote: > Or are you (or the authors) suggesting that there are technical > problems with making a device which could handle longer headers in hardware? Just the small technicality that someone has to actually pay for that, and the cost of walking a header chain that could be up to 65k long at 100Gbit/s is higher than "if it's not in the first 128 byte, drop the packet and/or ignore what comes after it". 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 arturo.servin@gmail.com Thu Jul 4 04:31:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E021F9E79 for ; Thu, 4 Jul 2013 04:31:07 -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.301, 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 4WNp7fjC0eVx for ; Thu, 4 Jul 2013 04:31:07 -0700 (PDT) Received: from mail-gg0-x22a.google.com (mail-gg0-x22a.google.com [IPv6:2607:f8b0:4002:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6FA21F9E71 for ; Thu, 4 Jul 2013 04:31:07 -0700 (PDT) Received: by mail-gg0-f170.google.com with SMTP id s5so377678ggc.15 for ; Thu, 04 Jul 2013 04:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JjpVqnPS+zo2pN8qaGNEi+3xiI9EwDu8v2N451UGnHE=; b=PVGjYh44XBrfYynZwiT7vz0gOpN1g+z6iE5778eRTCYTXwtRw+MZP6hb8Mbe9UP9/9 Cj3wXbbeOdy4bI/Q0IlY5eTLQmtmpxWmZ9SBJOCkf6V5w7N0HGXfPHZVHpncTsNphTmn i03stxE4KAhtN61O4AKkDazfdqLdMQojKVja5uyNeypO4jdc2QCbySKd8lB4SQ1kQ5BE mmhHddwwFgrYPJVmDnsZBKQL2Hy30Ugqbfc8+9NNCSEm5mOMFIfC5v2naFPsEWu55QlM 8mf/urUhIie3iQ4JDtgtmxfAvpx8fdnPWz+/QV+RLZqF8yZz+qUATXmk4NP+irxfKdCB 84BA== X-Received: by 10.236.159.196 with SMTP id s44mr2719417yhk.105.1372937466393; Thu, 04 Jul 2013 04:31:06 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r186-48-202-5.dialup.adsl.anteldata.net.uy. [186.48.202.5]) by mx.google.com with ESMTPSA id s29sm4130223yhf.6.2013.07.04.04.31.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 04:31:05 -0700 (PDT) Message-ID: <51D55CF0.9010301@gmail.com> Date: Thu, 04 Jul 2013 08:30:56 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> In-Reply-To: <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:31:08 -0000 SM, Sorry, I should have said "Or are these recommendations orthogonal to a network applying RA Guard?" I think the ansewer is still yes. But for that reason I think that you should mention that this is an add-on to RA Guard (not instead of, not criticizing it) and it is intended to provide some security mechanisms to the host when the network administrator do not have this capability (RA-Guard) in its network. In the end, having RA-Guard could solve enteraly this problem, but when it is not provided by the network the host should have mechanisms to defend itself. Then is when your draft applies. Does it make sense my comment? Regards, as On 7/4/13 3:02 AM, S Moonesamy wrote: > Hi Arturo, > At 18:19 03-07-2013, Arturo Servin wrote: >> Why IPv6 Router Advertisement Guard would be not enough? > > The draft does not seek to criticize Router Advertisement Guard in any > way. The draft looks at what can occur on the host and what has been > done to ensure that there isn't a crash. > >> Or are these recommendations orthogonal to a network applying RA? > > Yes. > >> I think that it would be important to address those questions in >> the draft. > > That would be an operational issue. > >> Also, related. Is it possible for a host to perform a RS attack? > > I don't have sufficient information to provide a good answer. I > prefer not to give you a misleading answer. > > Regards, > S. Moonesamy From v.bajpai@jacobs-university.de Thu Jul 4 06:03:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C621F9FDC for ; Thu, 4 Jul 2013 06:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zNlHoNhm1Wo0 for ; Thu, 4 Jul 2013 06:02:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1BFC21F9FDA for ; Thu, 4 Jul 2013 06:02:58 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D88B20BE5 for ; Thu, 4 Jul 2013 15:02:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tn7WOJ8U-mqK for ; Thu, 4 Jul 2013 15:02:57 +0200 (CEST) Received: from exchange.jacobs-university.de (SHUBCAS05.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id E33B820BE1 for ; Thu, 4 Jul 2013 15:02:57 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Thu, 4 Jul 2013 15:02:54 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: Measuring the Effectiveness of Happy Eyeballs Thread-Index: AQHOeLbLQQ26/UHCGku1zbl+BMyWdA== Date: Thu, 4 Jul 2013 13:02:53 +0000 Message-ID: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.226.26] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Measuring the Effectiveness of 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: Thu, 04 Jul 2013 13:03:03 -0000 Hello, I would like to request a 10-minute presentation slot=20 at the upcoming IETF 87 to present my PhD work: Title: Measuring the Effectiveness of Happy Eyeballs Authors: Vaibhav Bajpai and J=FCrgen Sch=F6nw=E4lder URL: http://tools.ietf.org/html/draft-bajpai-happy-00 Abstract: The IETF has developed solutions that promote a healthy IPv4 and IPv6 co-existence. The happy eyeballs algorithm for instance, provides recommendations to application developers to help prevent bad user experience in situations where IPv6 connectivity is broken. This document describes a metric used to measure the effectiveness of the happy eyeballs algorithm. The insights uncovered by analysing the data from multiple locations is discussed. Thank you! Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From marka@isc.org Thu Jul 4 07:06:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564521F9FCA for ; Thu, 4 Jul 2013 07:06:58 -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 FhIM1E5vnl6z for ; Thu, 4 Jul 2013 07:06:53 -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 CBFDB21F9F86 for ; Thu, 4 Jul 2013 07:06:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 4820BC94D7; Thu, 4 Jul 2013 14:06:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372946813; bh=z7jgurMXAtSTg6MCrP6ilENIoGBMf0u+TCjMUCOiSA4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=cw05rE9pDHp1Q48xU6TwSXrFkJkGAaP9cV20V9h9/j/wdWr+UKi6Go68QgQAwz5sp XVXxaxofJMwyWGWV5oBMPg8YT91qHudZ8KeRGWPueSVQvjAYJrQotK3JAhqRaO/rLC T4mn94T8A/nN0MbqC6SjGZAMnmFwoqmczSb8eV5s= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 4 Jul 2013 14:06:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B2AB11600F4; Thu, 4 Jul 2013 14:08:33 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kIkFVzoPFgu1; Thu, 4 Jul 2013 14:08:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 022601600F3; Thu, 4 Jul 2013 14:08:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zvlVJnZI3Hy9; Thu, 4 Jul 2013 14:08:32 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id A7C27160058; Thu, 4 Jul 2013 14:08:32 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 95E4A36DF95C; Fri, 5 Jul 2013 00:06:41 +1000 (EST) To: Gert Doering From: Mark Andrews References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130704094631.GV2706@Space.Net> In-reply-to: Your message of "Thu, 04 Jul 2013 11:46:31 +0200." <20130704094631.GV2706@Space.Net> Date: Fri, 05 Jul 2013 00:06:41 +1000 Message-Id: <20130704140641.95E4A36DF95C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 14:06:58 -0000 In message <20130704094631.GV2706@Space.Net>, Gert Doering writes: > Hi, > > On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote: > > Or are you (or the authors) suggesting that there are technical > > problems with making a device which could handle longer headers in hardware? > > Just the small technicality that someone has to actually pay for that, > and the cost of walking a header chain that could be up to 65k long at > 100Gbit/s is higher than "if it's not in the first 128 byte, drop the > packet and/or ignore what comes after it". Nodes are only required to be able reassemble to 1500 bytes. Why are people putting additional requirements on routers? > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bill.jouris@insidethestack.com Thu Jul 4 08:10:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EEC11E8137 for ; Thu, 4 Jul 2013 08:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=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 hk1AbWq6GyJQ for ; Thu, 4 Jul 2013 08:10:41 -0700 (PDT) Received: from nm21-vm8.access.bullet.mail.gq1.yahoo.com (nm21-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.229]) by ietfa.amsl.com (Postfix) with ESMTP id B075311E8136 for ; Thu, 4 Jul 2013 08:10:41 -0700 (PDT) Received: from [216.39.60.169] by nm21.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 15:10:40 -0000 Received: from [216.39.60.160] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 15:10:40 -0000 Received: from [127.0.0.1] by omp1026.access.mail.gq1.yahoo.com with NNFMP; 04 Jul 2013 15:10:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 466546.79178.bm@omp1026.access.mail.gq1.yahoo.com Received: (qmail 22053 invoked by uid 60001); 4 Jul 2013 15:10:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372950639; bh=WPbn4wEdaV1T9ETuekgARjv1z/fV5zrv8+G5EqPGsLg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g2G1iq9Lz3FJhMVrABFU/sCErom8dKOnD7EhatScI9fMgs2N04oRTsRM1hWmwC8U95tYvC59Zs/7yBAQVM34R9o7VEIOv94Ys6W2tIn/NuVI9r8Tn+ygtA4xGJY5uKxw0h7OljbCJu05v6Vf6WNDOfG0rMVPFK3KRb8d1FGi1xk= X-YMail-OSG: jEm5D84VM1kYe9_A25TNzOdA3GuKsfxmapJHybjqURGen4Q GZvRWRqq12.Ty9DL2cu5hFI7dkyAcMrZF9M8HOKecDgNar5kl2SwoGUJUc_a TMVCoagDsO5QmQVqrzj3PUOoZqLGMvUje6zeN_zqWcAU4IZV3n.9J55T6XiY dTTOx_zS8rDbM0fbg_fMfTYkwey9LTkH2ASsbSQAIWm3VZEm9Gb9ZoxHFSe_ kOONG6U9bkUaTQJ55viiS16YhAtmnUXF9ajsaOFxi40MNlQOM0AOG3CLO4_Y zfnqRU6EVOM657hAOeKQYP5GhBiIBvbK5tjFX1HKlbovfSbgATrzLalTcsHv AMzygk.1tfRi9mB5iRGVkLV3U6lpJ6r24MxKpjjZs78TvZBo0LSUa.XrsYQ6 zkckaRHkp70AlINfLhlFR8GzZLtVVg2oAAB5vqKZ8SwGCFlAOCd.b1sgK9Gf rQVuTOQo9gF_y371SzZ9wM6DO6I21zAGuJhOhTwFtZVcbDDKHOvawPyBhuNc QZ_rIiOvq20kbhdvJe8deMAPzedMBzOyRuyMHEeWXw1KDdmHpKCj6EHhHuvE mcOT0P4Y6Rvy9429lN3SmjPmRMovN3YDI1me7T4t.XlOkjL0HIky7J_dcSix 4aRZCUf31uX.Bi01KcOqtxJ62bAYicw2nqRqqSEJq8tByn0CavZkdh8qhlMk - Received: from [50.143.174.186] by web2801.biz.mail.ne1.yahoo.com via HTTP; Thu, 04 Jul 2013 08:10:39 PDT X-Rocket-MIMEInfo: 002.001, Cj4gT24gV2VkLCBKdWwgMDMsIDIwMTMgYXQgMDU6NTQ6MDBQTSAtMDcwMCwgQmlsbCBKb3VyaXMgd3JvdGU6Cj4.IE9yIGFyZSB5b3UgKG9yIHRoZSBhdXRob3JzKSBzdWdnZXN0aW5nIHRoYXQgdGhlcmUgYXJlIHRlY2huaWNhbCAKPj4gcHJvYmxlbXMgd2l0aCBtYWtpbmcgYSBkZXZpY2Ugd2hpY2ggY291bGQgaGFuZGxlIGxvbmdlciBoZWFkZXJzIGluIGhhcmR3YXJlPwo.Cj4gSnVzdCB0aGUgc21hbGwgdGVjaG5pY2FsaXR5IHRoYXQgc29tZW9uZSBoYXMgdG8gYWN0dWFsbHkgcGF5IGZvciB0aGF0LAo.IGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130704094631.GV2706@Space.Net> Message-ID: <1372950639.19958.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Thu, 4 Jul 2013 08:10:39 -0700 (PDT) From: Bill Jouris To: IPv6 Ops WG In-Reply-To: <20130704094631.GV2706@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-1970667571-1372950639=:19958" Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Jouris List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:10:47 -0000 --36908767-1970667571-1372950639=:19958 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A> On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote:=0A>> Or a= re you (or the authors) suggesting that there are technical =0A>> problems = with making a device which could handle longer headers in hardware?=0A>=0A>= Just the small technicality that someone has to actually pay for that,=0A>= and the cost of walking a header chain that could be up to 65k long at=0A>= 100Gbit/s is higher than "if it's not in the first 128 byte, drop the =0A>= packet and/or ignore what comes after it".=0A>=0A> Gert Doering=0A>=A0 =A0= =A0 =A0 -- Operator=0A=A0=0AOf course.=A0 But then, every time any technol= ogy changes, someone has to pay for it.=A0 And frequently the straight out-= of-pocket cost to buy the new technology is higher (at least initially) tha= n just buying more of the old technology.=A0 =0A=0ABut that doesn't mean th= at any change should simply be ignored.=A0 At minimum, I would expect to se= e a cost/comparison analysis from those who object to meeting the long-stan= ding specifications.=A0 Showing what it would cost to meet them and, for co= mparison, what the cost of dropping all those packets is.=A0 (And note that= we aren't talking, necessarily, of doing an immediate and wholesale replac= ement of the existing infrastructure.=A0 Just of using the upgraded hardwar= e for new/replacement purchases.)=0A=0A=0ABill Jouris=0AInside Products, In= c.=0Awww.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A=0A=0A= =0A=0A________________________________=0A From: Gert Doering =0ATo: Bill Jouris =0ACc: IPv6 Ops WG =0ASent: Thursday, July 4, 2013 2:46 AM=0ASubject: Re: [v6op= s] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt=0A = =0A=0AHi,=0A=0AOn Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote:= =0A> Or are you (or the authors) suggesting that there are technical =0A> p= roblems with making a device which could handle longer headers in hardware?= =0A=0AJust the small technicality that someone has to actually pay for that= ,=0Aand the cost of walking a header chain that could be up to 65k long at= =0A100Gbit/s is higher than "if it's not in the first 128 byte, drop the = =0Apacket and/or ignore what comes after it".=0A=0AGert Doering=0A=A0 =A0 = =A0 =A0 -- Operator=0A-- =0Ahave you enabled IPv6 on something today...?=0A= =0ASpaceNet AG=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vorstand: Seb= astian v. Bomhard=0AJoseph-Dollinger-Bogen 14=A0 =A0 =A0 =A0 =A0 Aufsichtsr= atsvors.: A. Grundner-Culemann=0AD-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 HRB: 136055 (AG Muenchen)=0ATel: +49 (89) 32356-444=A0 =A0 =A0= =A0 =A0 =A0 USt-IdNr.: DE813185279 --36908767-1970667571-1372950639=:19958 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

> On Wed, Jul 03, 20= 13 at 05:54:00PM -0700, Bill Jouris wrote:
>> Or are you (or the a= uthors) suggesting that there are technical
>> problems with maki= ng a device which could handle longer headers in hardware?
>
> = Just the small technicality that someone has to actually pay for that,
&= gt; and the cost of walking a header chain that could be up to 65k long at<= br>> 100Gbit/s is higher than "if it's not in the first 128 byte, drop t= he
> packet and/or ignore what comes after it".
>
> Gert= Doering
>        -- Operator
 Of course.  But then, every time any technology changes, someone has = to pay for it.  And frequently the straight out-of-pocket cost to buy = the new technology is higher (at least initially) than just buying more of the old technology. 

But that doesn't mean that any c= hange should simply be ignored.  At minimum, I would expect to see a c= ost/comparison analysis from those who object to meeting the long-standing = specifications.  Showing what it would cost to meet them and, for comp= arison, what the cost of dropping all those packets is.  (And note tha= t we aren't talking, necessarily, of doing an immediate and wholesale repla= cement of the existing infrastructure.  Just of using the upgraded har= dware for new/replacement purchases.)

Bill Jouris<= /font>
Inside Products, Inc.
www.insidethestack.com<= br>831-659-8360
925-855-9512 (direct)


= From: Gert Doering <ger= t@space.net>
To: Bi= ll Jouris <bill.jouris@insidethestack.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Thursday, July 4, 2013 2= :46 AM
Subject: Re: [v= 6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

=0AHi,

On Wed, = Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote:
> Or are you (or= the authors) suggesting that there are technical
> problems with ma= king a device which could handle longer headers in hardware?

Just th= e small technicality that someone has to actually pay for that,
and the = cost of walking a header chain that could be up to 65k long at
100Gbit/s= is higher than "if it's not in the first 128 byte, drop the
packet and= /or ignore what comes after it".

Gert Doering
     = ;   -- Operator
--
have you enabled IPv6 on something today...?=

SpaceNet AG                =         Vorstand: Sebastian v. Bomhard
Joseph-Dollin= ger-Bogen 14          Aufsichtsratsvors.: A. Grund= ner-Culemann
D-80807 Muenchen            &= nbsp;     HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444          &nb= sp; USt-IdNr.: DE813185279


--36908767-1970667571-1372950639=:19958-- From joelja@bogus.com Thu Jul 4 09:31:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0521F9F52 for ; Thu, 4 Jul 2013 09:31:15 -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, 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 GRT9TduMLFwO for ; Thu, 4 Jul 2013 09:31:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCB621F99C6 for ; Thu, 4 Jul 2013 09:31:12 -0700 (PDT) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r64GVAlK085166 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 4 Jul 2013 16:31:10 GMT (envelope-from joelja@bogus.com) Message-ID: <51D5A34B.20509@bogus.com> Date: Thu, 04 Jul 2013 09:31:07 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Bill Jouris , IPv6 Ops WG References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130704094631.GV2706@Space.Net> <1372950639.19958.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1372950639.19958.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Thu, 04 Jul 2013 16:31:11 +0000 (UTC) Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 16:31:15 -0000 On 7/4/13 8:10 AM, Bill Jouris wrote: > > > On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote: > >> Or are you (or the authors) suggesting that there are technical > >> problems with making a device which could handle longer headers in > hardware? > Yeah, I think that's pretty explicit in the draft. the memory into which the fragment of a packet expected contain the header is copied into is a lot more expensive and faster than the packet buffer. in merchant silicon that powers L3 switches that expense is basically the bounding of the asic size/power envelope/cost since the forwarding logic associated with a group of ports is a discrete single chip potentially with offboard packet buffer (take a look at broadcom trident 2 or Dune Arad for 10/40/100Gb/s examples). > > Just the small technicality that someone has to actually pay for that, > > and the cost of walking a header chain that could be up to 65k long at > > 100Gbit/s is higher than "if it's not in the first 128 byte, drop the > > packet and/or ignore what comes after it". > > > > Gert Doering > > -- Operator > > Of course. But then, every time any technology changes, someone has > to pay for it. And frequently the straight out-of-pocket cost to buy > the new technology is higher (at least initially) than just buying > more of the old technology. > Oddly I expect the future version of my network to cost less and be faster than previous version. > But that doesn't mean that any change should simply be ignored. At > minimum, I would expect to see a cost/comparison analysis from those > who object to meeting the long-standing specifications. So the reason you see drafts today describing what network operators and content-provider/enterprise networks can actually do is because that's at odds with assumptions made before these things were widely deployed. Level-setting expectations to match reality is not an unreasonable thing, nor is asking for more in the future, being reaslistic about the prospects for many outcomes outcomes is helpful. > Showing what it would cost to meet them and, for comparison, what > the cost of dropping all those packets is. (And note that we aren't > talking, necessarily, of doing an immediate and wholesale replacement > of the existing infrastructure. Just of using the upgraded hardware > for new/replacement purchases.) > > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > > ------------------------------------------------------------------------ > *From:* Gert Doering > *To:* Bill Jouris > *Cc:* IPv6 Ops WG > *Sent:* Thursday, July 4, 2013 2:46 AM > *Subject:* Re: [v6ops] Fwd: New Version Notification for > draft-wkumari-long-headers-01.txt > > Hi, > > On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote: > > Or are you (or the authors) suggesting that there are technical > > problems with making a device which could handle longer headers in > hardware? > > Just the small technicality that someone has to actually pay for that, > and the cost of walking a header chain that could be up to 65k long at > 100Gbit/s is higher than "if it's not in the first 128 byte, drop the > packet and/or ignore what comes after it". > > 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 From joelja@bogus.com Thu Jul 4 12:32:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DFA11E81A0 for ; Thu, 4 Jul 2013 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 pk4+y39aR8dY for ; Thu, 4 Jul 2013 12:32:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2711E819D for ; Thu, 4 Jul 2013 12:32:38 -0700 (PDT) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r64JWc1x087055 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 4 Jul 2013 19:32:38 GMT (envelope-from joelja@bogus.com) Message-ID: <51D5CDD3.5010805@bogus.com> Date: Thu, 04 Jul 2013 12:32:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Bill Jouris , IPv6 Ops WG References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Thu, 04 Jul 2013 19:32:38 +0000 (UTC) Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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, 04 Jul 2013 19:32:39 -0000 On 7/3/13 5:54 PM, Bill Jouris wrote: > I have no problem at all with the specifications evolving to make the > Internet work better. But this isn't what we are talking about here. > Rather, we are talking about changing the specifications for the > convenience, not of those using the Internet, but of those building > the infrastructure. On the contrary, two of the three authors are users not vendors. Cameron and his customers are likewise consumers not developers. We've arrived at a pretty backwards place if you're telling me that's it ok from your vantage point that I can't find the L4 header, that's an enterprise requirement since along with the ip header it's the basis of firewall policy. > Or are you (or the authors) suggesting that there are technical > problems with making a device which could handle longer headers in > hardware? If that is the contention, then I apologize for missing > that in the discussion. (And I suggest that the RFC ought to include > at least some discussion of what those techincal issues.) > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > > ------------------------------------------------------------------------ > *From:* cb.list6 > *To:* Bill Jouris > *Cc:* IPv6 Ops WG > *Sent:* Wednesday, July 3, 2013 5:47 PM > *Subject:* Re: [v6ops] Fwd: New Version Notification for > draft-wkumari-long-headers-01.txt > > > On Jul 3, 2013 5:25 PM, "Bill Jouris" > wrote: > > > > So in summary, ASIC-based forwarders (and ISPs which use them) can > call themselves IPv6-compliant, even though they are unable to (or > choose not to) parse IPv6 headers. Just as long as they don't discard > packets with IPv6 headers which are shorter than 128 bytes. > > > > Which would appear to be another way to say that, even though IPv6 > has been around for over a decade, we won't (now or, presumably, ever) > require that the Internet be able to actually deal it. Or with IPv6 > packets, even though they conform entirely to the long-standing IPv6 > specifications. Is there a reason for this, other than avoiding > forcing vendors to actually get around to finally dealing with the > specifications that we wrote? Pr, more to the point, being able to > claim that they are "IPv6 complaint" when they manifestly are not? > > > > Why not just tell them to admit that they are not compliant? If > they don't want to change, just indulge in a little truth in advertising. > > > The internet, including ipv4, does not work as originally specified. > That does not matter. > What matter is that the internet evolves and adapts according to > various stressors > CB > > Bill Jouris > > Inside Products, Inc. > > www.insidethestack.com > > 831-659-8360 > > 925-855-9512 (direct) > > > > ________________________________ > > From: Warren Kumari > > > To: "v6ops@ietf.org Operations" > > > > Sent: Wednesday, July 3, 2013 4:58 PM > > Subject: [v6ops] Fwd: New Version Notification for > draft-wkumari-long-headers-01.txt > > > > > > > > Begin forwarded message: > > > > > A new version of I-D, draft-wkumari-long-headers-01.txt > > > has been successfully submitted by Warren Kumari and posted to the > > > IETF repository. > > > > > > Filename: draft-wkumari-long-headers > > > Revision: 01 > > > Title: Operational Issues Associated With Long IPv6 > Extension Header Chains > > > Creation date: 2013-07-04 > > > Group: Individual Submission > > > Number of pages: 8 > > > URL: > http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt > > > Status: http://datatracker.ietf.org/doc/draft-wkumari-long-headers > > > Htmlized: http://tools.ietf.org/html/draft-wkumari-long-headers-01 > > > Diff: http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01 > > > > > > Abstract: > > > This document explains why IPv6 header chain length affects the cost > > > of ASIC-based packet forwarding. It also explains why some network > > > service providers discard packets with exceptionally long header > > > chains. Finally, it identifies a reasonable header chain length. > > > While a network service provider can enforce any filtering policy > > > that supports its security model, a network service provider should > > > not discard IPv6 packets based solely upon header chain length if the > > > header chain is not longer than the value specified herein. > > > > > > > -- > > What our ancestors would really be thinking, if they were alive > today, is: "Why is it so dark in here?" > > > > -- (Terry Pratchett, Pyramids) > > > > > > _______________________________________________ > > 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 touch@isi.edu Thu Jul 4 17:36:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B773011E821B for ; Thu, 4 Jul 2013 17:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 jJzsmyGd4dGA for ; Thu, 4 Jul 2013 17:36:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E5A8411E80F9 for ; Thu, 4 Jul 2013 17:36:43 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r650a5ax016805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jul 2013 17:36:15 -0700 (PDT) Message-ID: <51D614F6.4030000@isi.edu> Date: Thu, 04 Jul 2013 17:36:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bill Jouris References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 00:36:49 -0000 On 7/3/2013 5:54 PM, Bill Jouris wrote: > I have no problem at all with the specifications evolving to make > the Internet work better. But this isn't what we are talking about > here. Rather, we are talking about changing the specifications for > the convenience, not of those using the Internet, but of those > building the infrastructure. That is correct. Claims that this is about a technical problem are false. E.g., it's incorrect to claim that this is a forwarding issue. It is a *firewall* (and possibly NAT) issue. The problem is that IPv6 was designed to make it easier to add and delete options and "shim" layers between IP and transport - which it does. *Everything* an IP *router* ***requires*** to forward a packet is visible in the main IP header or the HBH options. The sum of the two is already limited to 40 (main header) + 256 (HBH), so it's already the case that a compliant IP router never needs to look beyond the first 296 bytes to forward a packet. Endpoints - and things that act on their behalf - need to parse the chain to find useful information. That information depends on what the device does. Many want to look at the transport information - which may or may not be visible. Others may want to look at other parts of the chain. So let's please be very clear about what _this_ draft is saying - it is NOT about making routers do something that routers *need* to do. Joe From sm@elandsys.com Thu Jul 4 21:09:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265E821F8EEA for ; Thu, 4 Jul 2013 21:09:38 -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=[AWL=0.000, 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 GsJ5xnXdI7K5 for ; Thu, 4 Jul 2013 21:09:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 402C221F93E5 for ; Thu, 4 Jul 2013 21:09:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.75]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6549Gu9026477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 21:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372997368; bh=FjgwU0Nf74edDOTGIi8/l2urM1t2RD6Z98egrJDrwow=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JMU4yHp7voEJnLC0SQgHcWIGRfkxjgD/ejgJXzL9LXQqrit0jMXGUn1fmOG+HLvVj EfCCWgcGUhb/MfQN/L55ltkFN7p0dZ3Fns2QkNPdXnLvoVHyZPrye4OtlSANqsCsfv XiZXRHSkoVch92PY7UxjSdMB1dMvIEMsKeAEFcuc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372997368; i=@elandsys.com; bh=FjgwU0Nf74edDOTGIi8/l2urM1t2RD6Z98egrJDrwow=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YL5D9mK8hiWdyuXljJoRootSexLxKU+OvCKs08OkUt16hsLoGayQURueFQxhpcp0y L7cJlzTMYCdCKsVJUm9gPS1Us2WhSlHnPrWWXyRzD3hofFHqYXqrpx5NMfw2VtTJvJ t2xreKW5M6rLNAi8JuuVrKyjsVmeUuB9iEujppPs= Message-Id: <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 Jul 2013 20:27:19 -0700 To: Arturo Servin From: S Moonesamy In-Reply-To: <51D55CF0.9010301@gmail.com> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> <51D55CF0.9010301@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 04:09:38 -0000 Hi Arturo, At 04:30 04-07-2013, Arturo Servin wrote: > Sorry, I should have said "Or are these recommendations orthogonal >to a network applying RA Guard?" Yes. > I think the ansewer is still yes. But for that reason I think that >you should mention that this is an add-on to RA Guard (not instead of, >not criticizing it) and it is intended to provide some security >mechanisms to the host when the network administrator do not have this >capability (RA-Guard) in its network. I think that we are looking at this from two different angles. I can look at this in terms of: (a) how does the network protect the host (b) how is the host protected If there is a protection for (a), for example, Router Advertisement Guard, (b) might not be much of a problem. If the host is protected, the question being asked is whether (a) is needed or not. I am not trying to answer that question as there is existing code for doing (b) and that is what the draft is talking about. What the person writing the code for the host may wish to say is that their system provides for the limits mentioned in draft-moonesamy-ra-flood-limit-00. > In the end, having RA-Guard could solve enteraly this problem, but >when it is not provided by the network the host should have mechanisms >to defend itself. Then is when your draft applies. Does it make sense my >comment? Yes, I understood what you wrote. In my opinion it depends on your security posture. Some people may prefer to put security closer to the end whereas others might find it better to do it centrally. RFC 6104 discusses about scenarios and different methods to mitigate against rogue Router Advertisements. In my opinion that is where the above is more relevant. What the code does is to prevent the host it is running on from crashing. Regards, S. Moonesamy From sthaug@nethelp.no Fri Jul 5 03:16:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B543A11E8288 for ; Fri, 5 Jul 2013 03:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 XCGDPZmfviey for ; Fri, 5 Jul 2013 03:16:44 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 082EF11E8287 for ; Fri, 5 Jul 2013 03:16:36 -0700 (PDT) Received: (qmail 21307 invoked from network); 5 Jul 2013 10:16:34 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Jul 2013 10:16:34 -0000 Date: Fri, 05 Jul 2013 12:16:34 +0200 (CEST) Message-Id: <20130705.121634.74739259.sthaug@nethelp.no> To: touch@isi.edu From: sthaug@nethelp.no In-Reply-To: <51D614F6.4030000@isi.edu> References: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> 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] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 10:16:49 -0000 > > I have no problem at all with the specifications evolving to make > > the Internet work better. But this isn't what we are talking about > > here. Rather, we are talking about changing the specifications for > > the convenience, not of those using the Internet, but of those > > building the infrastructure. > > That is correct. Claims that this is about a technical problem are false. > > E.g., it's incorrect to claim that this is a forwarding issue. It is a > *firewall* (and possibly NAT) issue. > > The problem is that IPv6 was designed to make it easier to add and > delete options and "shim" layers between IP and transport - which it does. > > *Everything* an IP *router* ***requires*** to forward a packet is > visible in the main IP header or the HBH options. The sum of the two is > already limited to 40 (main header) + 256 (HBH), so it's already the > case that a compliant IP router never needs to look beyond the first 296 > bytes to forward a packet. Looks like we need to come up with a new term here. A pure IPv6 router, as you define it, is completely useless to me. My real, operation requirements include IPv4 / IPv6 forwarding for multiple 10 Gbit/s links *and* very basic, stateless access lists that must be able to look at address *and* L4 info (port numbers). I believe that when most operators talk about routers, they include this or similar capabilities - simply because that is a necessity in order to run a production network. > So let's please be very clear about what _this_ draft is saying - it is > NOT about making routers do something that routers *need* to do. It is about making what *operators* call routers useful in real life. Your definition of router is not the same as that of many operators. Let's make a note of this and move on. Steinar Haug, AS 2116 From nick@inex.ie Fri Jul 5 03:37:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32E11E82A0 for ; Fri, 5 Jul 2013 03:37: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 USHTVH2XVBxW for ; Fri, 5 Jul 2013 03:37:01 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 645C311E829F for ; Fri, 5 Jul 2013 03:37:00 -0700 (PDT) X-Envelope-To: Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65Aavtp037818 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 5 Jul 2013 11:36:57 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6A1C9.8030208@inex.ie> Date: Fri, 05 Jul 2013 11:36:57 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> In-Reply-To: <51D614F6.4030000@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 10:37:02 -0000 On 05/07/2013 01:36, Joe Touch wrote: > That is correct. Claims that this is about a technical problem are false. this statement is disturbingly disconnected from operational reality, imho. Nick From gert@space.net Fri Jul 5 05:46:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C861C11E82C5 for ; Fri, 5 Jul 2013 05:46:54 -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 cGXQpC5opT4v for ; Fri, 5 Jul 2013 05:46:54 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 465A811E82BD for ; Fri, 5 Jul 2013 05:46:53 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3529660A09 for ; Fri, 5 Jul 2013 14:46:51 +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 0DD5360A00 for ; Fri, 5 Jul 2013 14:46:51 +0200 (CEST) Received: (qmail 36322 invoked by uid 1007); 5 Jul 2013 14:46:51 +0200 Date: Fri, 5 Jul 2013 14:46:51 +0200 From: Gert Doering To: Joe Touch Message-ID: <20130705124651.GP2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D614F6.4030000@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 12:46:54 -0000 Hi, On Thu, Jul 04, 2013 at 05:36:06PM -0700, Joe Touch wrote: > So let's please be very clear about what _this_ draft is saying - it is > NOT about making routers do something that routers *need* to do. If you can build a router for me that has a control plane which is completely unreachable from the outside, that would be sufficient (but that would likely be a MPLS P router, who wouldn't need to look at *any* IPv6 bits). Today's routers *need* to be able to protect themselves, and that can only be done by L4-aware rate limiting and ACLs. So please stop repeating this "a router doesn't need any of this" - while this is fairly nice for a theoretical router, it doesn't work out there, and *this* is what should be interesting. Not "ivory tower beauty". 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 touch@isi.edu Fri Jul 5 05:51:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9FB21F98AD for ; Fri, 5 Jul 2013 05:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.974 X-Spam-Level: X-Spam-Status: No, score=-105.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 1KK+-7vOFmoy for ; Fri, 5 Jul 2013 05:50:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5645A21F9955 for ; Fri, 5 Jul 2013 05:50:54 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65CoH4g015099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 05:50:32 -0700 (PDT) Message-ID: <51D6C10A.2080802@isi.edu> Date: Fri, 05 Jul 2013 05:50:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sthaug@nethelp.no References: <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705.121634.74739259.sthaug@nethelp.no> In-Reply-To: <20130705.121634.74739259.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 12:51:00 -0000 On 7/5/2013 3:16 AM, sthaug@nethelp.no wrote: ... >> E.g., it's incorrect to claim that this is a forwarding issue. It is a >> *firewall* (and possibly NAT) issue. ... > Looks like we need to come up with a new term here. > > A pure IPv6 router, as you define it, is completely useless to me. Feel free to come up with a new term, document its requirements, and publish a standard on it. At that point we should consider its implications on existing standards. Until then, we have a situation where false marketing is driving a change to a standard. > My real, operation requirements include IPv4 / IPv6 forwarding for > multiple 10 Gbit/s links *and* very basic, stateless access lists > that must be able to look at address *and* L4 info (port numbers). The Internet doesn't need port examination to function correctly, and ports are increasingly meaningful only at the endpoints anyway. Port examination provides exactly two things: - a false sense of security (that services are truly being blocked) - a false view that the operator has control over traffic by type > Your definition of router is not the same as that of many operators. > Let's make a note of this and move on. Feel free. That 'note' would be a standards-track RFC. Until then, I don't think it's useful to use the IETF for (mis)marketing. Joe From touch@isi.edu Fri Jul 5 05:53:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53611E82CF for ; Fri, 5 Jul 2013 05:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 BX8f0KJNEmw1 for ; Fri, 5 Jul 2013 05:53:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD211E82CA for ; Fri, 5 Jul 2013 05:53:00 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65CqPIk015587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 05:52:35 -0700 (PDT) Message-ID: <51D6C189.9020300@isi.edu> Date: Fri, 05 Jul 2013 05:52:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> In-Reply-To: <20130705124651.GP2706@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 12:53:07 -0000 On 7/5/2013 5:46 AM, Gert Doering wrote: > Hi, > > On Thu, Jul 04, 2013 at 05:36:06PM -0700, Joe Touch wrote: >> So let's please be very clear about what _this_ draft is saying - it is >> NOT about making routers do something that routers *need* to do. > > If you can build a router for me that has a control plane which is > completely unreachable from the outside, that would be sufficient > (but that would likely be a MPLS P router, who wouldn't need to look > at *any* IPv6 bits). > > Today's routers *need* to be able to protect themselves, and that can > only be done by L4-aware rate limiting and ACLs. Are you referring to forwarded traffic? If so, how is that "protecting the router"? If you're talking about traffic addressed to the router itself, the entire chain has to be parsed anyway. > So please stop repeating this "a router doesn't need any of this" - while > this is fairly nice for a theoretical router, it doesn't work out there, > and *this* is what should be interesting. Not "ivory tower beauty". That "ivory tower" is all we have documented requirements for. If you want to propose other requirements for routers, please do. But until then I do not support changes to standards to support non-existent requirements. Joe From touch@isi.edu Fri Jul 5 06:00:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99121F9E76 for ; Fri, 5 Jul 2013 06:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 T-aLdzvCiqFT for ; Fri, 5 Jul 2013 06:00:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78021F8B04 for ; Fri, 5 Jul 2013 05:59:24 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65Cwcx9016430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 05:58:49 -0700 (PDT) Message-ID: <51D6C2FF.4090103@isi.edu> Date: Fri, 05 Jul 2013 05:58:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> In-Reply-To: <51D6A1C9.8030208@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:00:11 -0000 On 7/5/2013 3:36 AM, Nick Hilliard wrote: > On 05/07/2013 01:36, Joe Touch wrote: >> That is correct. Claims that this is about a technical problem are false. > > this statement is disturbingly disconnected from operational reality, imho. I'll repeat that any claim to the contrary is disturbingly disconnected from the documented standards. I don't object to changing IPv6 requirements to support a *requirement*, but not changing them to support false marketing (here's an IPv6 router, but oh, we can't actually support the existing IPv6 requirements, and we can port-filter, but not if the L4 header is too deep to be implemented cheaply). The reality is that there is no requirement that routers port-filter. Joe From nick@inex.ie Fri Jul 5 06:07:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4D921F9C40 for ; Fri, 5 Jul 2013 06:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7q91b9meW5u for ; Fri, 5 Jul 2013 06:07:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8639521F9975 for ; Fri, 5 Jul 2013 06:07:25 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65D7Lg4038678 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 14:07:21 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6C509.7040806@inex.ie> Date: Fri, 05 Jul 2013 14:07:21 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> In-Reply-To: <51D6C2FF.4090103@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:07:27 -0000 On 05/07/2013 13:58, Joe Touch wrote: > The reality is that there is no requirement that routers port-filter. To take a practical example, could you advise me then on how to set up a control plane policing policy on a C6500/sup720 or c7600/rsp720 which protects against ipv6 fragment attacks? Nick From gert@space.net Fri Jul 5 06:09:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943D821F9963 for ; Fri, 5 Jul 2013 06:09: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 ydDVkdmmTyKQ for ; Fri, 5 Jul 2013 06:09:36 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 0602921F9956 for ; Fri, 5 Jul 2013 06:09:36 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5F27B60A04 for ; Fri, 5 Jul 2013 15:09:35 +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 347D560A08 for ; Fri, 5 Jul 2013 15:09:35 +0200 (CEST) Received: (qmail 44004 invoked by uid 1007); 5 Jul 2013 15:09:35 +0200 Date: Fri, 5 Jul 2013 15:09:35 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20130705130935.GQ2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D6C509.7040806@inex.ie> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:09:36 -0000 hi, On Fri, Jul 05, 2013 at 02:07:21PM +0100, Nick Hilliard wrote: > On 05/07/2013 13:58, Joe Touch wrote: > > The reality is that there is no requirement that routers port-filter. > > To take a practical example, could you advise me then on how to set up a > control plane policing policy on a C6500/sup720 or c7600/rsp720 which > protects against ipv6 fragment attacks? Obviously this is no router feature, so the question is not relevant. 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 v6ops@globis.net Fri Jul 5 06:11:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D211E82C3 for ; Fri, 5 Jul 2013 06:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ImlTs5WcMmPO for ; Fri, 5 Jul 2013 06:11:57 -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 98C8211E82DB for ; Fri, 5 Jul 2013 06:11:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B928C87007F; Fri, 5 Jul 2013 15:11:36 +0200 (CEST) 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 eT8zS8nBrnoo; Fri, 5 Jul 2013 15:11:36 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1D351870002; Fri, 5 Jul 2013 15:11:36 +0200 (CEST) Message-ID: <51D6C601.70003@globis.net> Date: Fri, 05 Jul 2013 15:11:29 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> In-Reply-To: <20130705124651.GP2706@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:11:57 -0000 Gert Doering wrote: > Hi, > > On Thu, Jul 04, 2013 at 05:36:06PM -0700, Joe Touch wrote: >> So let's please be very clear about what _this_ draft is saying - it is >> NOT about making routers do something that routers *need* to do. > > If you can build a router for me that has a control plane which is > completely unreachable from the outside, that would be sufficient > (but that would likely be a MPLS P router, who wouldn't need to look > at *any* IPv6 bits). Right. > Today's routers *need* to be able to protect themselves, and that can > only be done by L4-aware rate limiting and ACLs. So could we specify different requirements and solutions for control traffic which terminates on the router, compared to end user traffic which only transits it? If so, couldn't this requirement be implemented as "being able to filter at wire speed any traffic headed for the control processor based on a IPV6 source prefix", rather than having to filter on a full L4 header? And then numbering end user LAN's from prefixes completely disjoint from your control network ranges and BGP peer addresses? If it's more than this I think it'd help to better specify the requirement. > So please stop repeating this "a router doesn't need any of this" - while > this is fairly nice for a theoretical router, it doesn't work out there, > and *this* is what should be interesting. Not "ivory tower beauty". > > Gert Doering > -- Operator From touch@isi.edu Fri Jul 5 06:14:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2421F99D9 for ; Fri, 5 Jul 2013 06:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.242 X-Spam-Level: X-Spam-Status: No, score=-106.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 xpNJNwhP0y95 for ; Fri, 5 Jul 2013 06:14:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 178F821F99D0 for ; Fri, 5 Jul 2013 06:14:19 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65DDIZZ019080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 06:13:29 -0700 (PDT) Message-ID: <51D6C66E.5060901@isi.edu> Date: Fri, 05 Jul 2013 06:13:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> In-Reply-To: <51D6C509.7040806@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:14:29 -0000 On 7/5/2013 6:07 AM, Nick Hilliard wrote: > On 05/07/2013 13:58, Joe Touch wrote: >> The reality is that there is no requirement that routers port-filter. > > To take a practical example, could you advise me then on how to set up a > control plane policing policy on a C6500/sup720 or c7600/rsp720 which > protects against ipv6 fragment attacks? I don't think that's possible unless you also protect "against" fragments altogether, and I don't think that is the job of a router. Joe From gert@space.net Fri Jul 5 06:17:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C311E82DF for ; Fri, 5 Jul 2013 06:17:33 -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 RzttAYwdxG3t for ; Fri, 5 Jul 2013 06:17:33 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id EC78011E82DE for ; Fri, 5 Jul 2013 06:17:32 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 15DB160A0D for ; Fri, 5 Jul 2013 15:17:29 +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 EF92260A00 for ; Fri, 5 Jul 2013 15:17:28 +0200 (CEST) Received: (qmail 47949 invoked by uid 1007); 5 Jul 2013 15:17:28 +0200 Date: Fri, 5 Jul 2013 15:17:28 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130705131728.GR2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wErsYZ8E6bdnXudW" Content-Disposition: inline In-Reply-To: <51D6C601.70003@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:17:33 -0000 --wErsYZ8E6bdnXudW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 05, 2013 at 03:11:29PM +0200, Ray Hunter wrote: > If so, couldn't this requirement be implemented as "being able to filter > at wire speed any traffic headed for the control processor based on a > IPV6 source prefix", rather than having to filter on a full L4 header? This is not actually sufficient. To make real life operation work, you need stuff like "permit mbit/s of BGP traffic, mbit/s of ICMP traffic, and nothing else". Being able to tell the box "oh, yeah, packets from that IXP are permitted!" just to get CPU-starved by 10Gbit/s of garbage because another participant there got hacked is not sufficient. Trade-off-time again, of course - you= =20 might not be able to avoid losing BGP-to-the-IXP if you get flooded by=20 TCP/179-packets from there, but everything else on that router should=20 better not die. 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 --wErsYZ8E6bdnXudW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUdbHaKkuBuNlUUl1AQJ8AAP+Nf76mhHBmyoxntOxYyqU0jxRJ3wIRojL KSciwzuceG/wGSqwpTXljJxoeX6bulsWhgpJAKKM4wlj+iLpOLccWw0oCxkOCoUD pO1GY3/ka+/V1tE+bZ4OJ8hxF9Pa+G1Bc99//AS8Dc1l3b4D407lNJjbrEhd8NbW sviIjYaU16w= =Wn9b -----END PGP SIGNATURE----- --wErsYZ8E6bdnXudW-- From gert@space.net Fri Jul 5 06:17:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A3F11E82E4 for ; Fri, 5 Jul 2013 06:17:59 -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 JaYmNRWNUnPS for ; Fri, 5 Jul 2013 06:17:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10111E82E3 for ; Fri, 5 Jul 2013 06:17:59 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C206E60A0C for ; Fri, 5 Jul 2013 15:17:58 +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 9A3BD60A00 for ; Fri, 5 Jul 2013 15:17:58 +0200 (CEST) Received: (qmail 47989 invoked by uid 1007); 5 Jul 2013 15:17:58 +0200 Date: Fri, 5 Jul 2013 15:17:58 +0200 From: Gert Doering To: Joe Touch Message-ID: <20130705131758.GS2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D6C66E.5060901@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:18:00 -0000 Hi, On Fri, Jul 05, 2013 at 06:13:18AM -0700, Joe Touch wrote: > I don't think that's possible unless you also protect "against" > fragments altogether, and I don't think that is the job of a router. So how do you operate your network? 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 cb.list6@gmail.com Fri Jul 5 06:18:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642FD21F9D18 for ; Fri, 5 Jul 2013 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 cL5Fpi3IEDzA for ; Fri, 5 Jul 2013 06:18:10 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08111E82E9 for ; Fri, 5 Jul 2013 06:18:09 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so1950486wgh.4 for ; Fri, 05 Jul 2013 06:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gu/Sc0ja8xRvDGZIC2B+FdUeKvtpgVpq0OpgwUtJMA0=; b=TQf5PoU9PX4YDGuiS70DDArL0WTJH3PWfDFpn5iVqBg5WbmFu7YVSFgAecoryTz20k LlH5uBBAAbAkXk7tOcMtzrPoKTSg16cvXaHimQfLuUJs9BldOf+FGpQJr2/Wdq/4y6ns FE22GpxdXSbNqgPEhtRJmrAFEPfe5NNLnRh4NRG/nJD46Lkn/Un/Ck6Ie9R3Z5QHrR79 G6PivN9FIb/JmzY/sCmVLzVgk1GilOX89H52qivZJvT3UgEqTcFpDGHasWpSewzAhnrS X9ZA319lOVwjaG+HB8e10scJNRwinj6SIFELIs3jhaMw7LXDuh/OIumnZjV97XSpbFhf UHiQ== MIME-Version: 1.0 X-Received: by 10.194.158.130 with SMTP id wu2mr6223928wjb.12.1373030288791; Fri, 05 Jul 2013 06:18:08 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Fri, 5 Jul 2013 06:18:08 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Fri, 5 Jul 2013 06:18:08 -0700 (PDT) In-Reply-To: <51D6A1C9.8030208@inex.ie> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> Date: Fri, 5 Jul 2013 06:18:08 -0700 Message-ID: From: "cb.list6" To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e013c6ab8a11cb204e0c386d5 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:18:10 -0000 --089e013c6ab8a11cb204e0c386d5 Content-Type: text/plain; charset=ISO-8859-1 On Jul 5, 2013 3:37 AM, "Nick Hilliard" wrote: > > On 05/07/2013 01:36, Joe Touch wrote: > > That is correct. Claims that this is about a technical problem are false. > > this statement is disturbingly disconnected from operational reality, imho. > +1 CB > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --089e013c6ab8a11cb204e0c386d5 Content-Type: text/html; charset=ISO-8859-1


On Jul 5, 2013 3:37 AM, "Nick Hilliard" <nick@inex.ie> wrote:
>
> On 05/07/2013 01:36, Joe Touch wrote:
> > That is correct. Claims that this is about a technical problem are false.
>
> this statement is disturbingly disconnected from operational reality, imho.
>

+1

CB

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

--089e013c6ab8a11cb204e0c386d5-- From nick@inex.ie Fri Jul 5 06:19:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82721F955A for ; Fri, 5 Jul 2013 06:19:18 -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 MJU0StbMuQPO for ; Fri, 5 Jul 2013 06:19:18 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DB59621F8E2A for ; Fri, 5 Jul 2013 06:19:17 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65DJEjj038770 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 14:19:15 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6C7D2.6020504@inex.ie> Date: Fri, 05 Jul 2013 14:19:14 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> In-Reply-To: <51D6C66E.5060901@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:19:19 -0000 On 05/07/2013 14:13, Joe Touch wrote: > I don't think that's possible unless you also protect "against" fragments > altogether, and I don't think that is the job of a router. so you're ok about the idea of having a router sitting on the Internet DFZ which you can take down with 20kpps of ipv6 fragments, and where there is no way of protecting against this because in your own words, you "don't think it's the job of the router". And also that "claims that this is about a technical problem are false". Nick From ipepelnjak@gmail.com Fri Jul 5 06:27:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD39111E82E5 for ; Fri, 5 Jul 2013 06:27: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVqYjG-EQJj2 for ; Fri, 5 Jul 2013 06:27:57 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1011E82C9 for ; Fri, 5 Jul 2013 06:27:57 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so1992280wev.0 for ; Fri, 05 Jul 2013 06:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=62t1CFeBHSpr/a5IGi6bvAvnCp6YJvcpwMUXfZOAMec=; b=sm0IPPgg1uuF6TlzXdGYQ/wix5u5RR+L8WsNuiix2orD7iJ6oiPBBG112rPPOiP8Zn bKmcUmJAWQhQDLk5n7u0cDx+BxruE68VdthBSUpFbzC33wTRrhumgSwWOMjn7l9Pdffx Zdsa8OM8zu6TIWJv9w1N6h5MQ5Akt+NdKfk3zET5y1UfyEfPrjTa2a4NtBZCLgcAmpvq A4BnJksNSumIoibUiDTpX9mJWEPI0Jb5azuRRAdczS2spkManQEunQNdlDdPJ2dr0vv7 m4plEQ39VOLNd7Ntp2wx5URQdrRuJGQmEbaT9E45t2CU9FQeXo3IQWXXo+VmQTuwWijh txYQ== X-Received: by 10.194.2.79 with SMTP id 15mr6213211wjs.42.1373030875146; Fri, 05 Jul 2013 06:27:55 -0700 (PDT) Received: from [192.168.200.196] (BSN-61-84-204.dial-up.dsl.siol.net. [86.61.84.204]) by mx.google.com with ESMTPSA id fd3sm40815887wic.10.2013.07.05.06.27.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 06:27:54 -0700 (PDT) Message-ID: <51D6C9D9.8070404@gmail.com> Date: Fri, 05 Jul 2013 15:27:53 +0200 From: Ivan Pepelnjak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> In-Reply-To: <51D6C7D2.6020504@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:27:58 -0000 Nick, you don't get it. A proper router has out-of-band management and control planes that we so loved and cherished with ATM switches and thus never has to touch anything beyond L3 header. Anything else is not a router. Ivan On 05.07.2013 15:19 , Nick Hilliard wrote: > On 05/07/2013 14:13, Joe Touch wrote: >> I don't think that's possible unless you also protect "against" >> fragments altogether, and I don't think that is the job of a >> router. > > so you're ok about the idea of having a router sitting on the > Internet DFZ which you can take down with 20kpps of ipv6 fragments, > and where there is no way of protecting against this because in your > own words, you "don't think it's the job of the router". And also > that "claims that this is about a technical problem are false". > > Nick > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Fri Jul 5 06:33:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBF11E82F0 for ; Fri, 5 Jul 2013 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.287 X-Spam-Level: X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 VWABvA5gTrN4 for ; Fri, 5 Jul 2013 06:32:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4A21F9943 for ; Fri, 5 Jul 2013 06:32:56 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65DWcPH022244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 06:32:48 -0700 (PDT) Message-ID: <51D6CAF6.6080007@isi.edu> Date: Fri, 05 Jul 2013 06:32:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> In-Reply-To: <51D6C2FF.4090103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:33:02 -0000 PS - here's what *I* think would be required to fix this doc, at a minimum. - make it clear that this is about either NATs, L4 filtering (firewalls), or L4 port-based forwarding, not IP forwarding (the latter is a well-defined term and does not include L4 ports) - make the requirement about a network *device*, not a network *provider* - explain the corner cases in more detail you mention a few cases here, but it seems like you need to specify a length for nearly every protocol payload because you're claiming that you have enough information to handle the IP header, the IP options, and the next *header* (at least the most interesting parts of it). There are a bunch of cases that are common enough that they ought to be covered: IPv6 (just the inner IPv6? and its HBH?) IPv4 (any options?) GRE MPLS What about the TCP header? why stop at just the ports? might a future operator want to block traffic on whether it used authentication? or SACK? What about ICMP - why not also its payload? How far in? - explain what to do if the chain is too long to see what you want MUST forward seems the only viable alternative to me, but if you disagree, propose an alternate and justify it if you don't forward, then you ought to be sending ICMP errors (subject to rate control) - correct some of the other errors IPv6 has HBH headers for exactly the reasons you cite - to limit how much of the chain needed to be examined. What really changed is the desire for port-filtering and port-forwarding devices. IPv4 makes this simpler because the 'jump' to the end of the chain is in the header in a fixed location. This has nothing to do with ASIC vs. multicore software processing (e.g., on a NPU). It has to do with a fixed jump vs. a chain of jumps. ASICs and multicore software can either one, but the space cost is higher and variable, and the time cost is higher and variable. Joe From nalini.elkins@insidethestack.com Fri Jul 5 06:36:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A911E82C4 for ; Fri, 5 Jul 2013 06:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 tH1f77q4nXJ6 for ; Fri, 5 Jul 2013 06:35:56 -0700 (PDT) Received: from nm19-vm1.access.bullet.mail.gq1.yahoo.com (nm19-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3601411E82E3 for ; Fri, 5 Jul 2013 06:35:52 -0700 (PDT) Received: from [216.39.60.171] by nm19.access.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jul 2013 13:35:51 -0000 Received: from [216.39.60.160] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jul 2013 13:35:51 -0000 Received: from [127.0.0.1] by omp1026.access.mail.gq1.yahoo.com with NNFMP; 05 Jul 2013 13:35:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503973.40705.bm@omp1026.access.mail.gq1.yahoo.com Received: (qmail 93151 invoked by uid 60001); 5 Jul 2013 13:35:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373031350; bh=PR5FoglEbMJW1sOrOhlns0hWuzIGwy/lEaWrKIfZu6k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QUHsEzl0hafy/EgzapxEcUhc5VdaDn8ha55salTqYhbebv/Hoy5S92cHT9hjmn8neWLkiQM+fJZ/3d0XD/L7Y5xDP7kmqp9LsCjHGTduZrcKliSkl9VIPZUHSnRyJV7FMNMVe+1DfGjrNjUKRZQuBIZBjG/29XYUNuKKK/yI5mI= X-YMail-OSG: z0uVohUVM1kwPhMt2o1iccpcoVbSLInpp4.iC2p8bz8cq1E GWzRsh0YuIZ1Jz5n75jnoMVutzEEjwzwdYTZmKq7KER46sjM8CpkNSfxwZDe 7fC15fdnAbuaNr27sRCkYUHcoQmRip3.NwKPfFnQcuCHycR0XfJr6htL93lC PCDZgYSxa337cdh2iyeMKntrcg6SCH9cRCOMlSG8t.T7ujdr_5UhJoxGIt6F jYUqreTZ2BNn7L4MR182WkO5z0wGCTlPE4QPpYO.G7...4jM_x4TE0N3kz.v j4QBB09gYERHGT5EdEkSKC4.EhMOwGaykQ8EZGK74Y9jiQ1dTcZDHdh0LHj1 9mHCZnYo2oBcccwS0xBcGGtaoTnzoXwmCG1OWIC7LM.VhYgBSl0LaaJQDvE3 Aq.qqz6ZBJzcxvyppaqPcX0wptr_sQX4wulAclJss9rDXr_lQ745ZX.vrFf1 cyLpdvssF1Xlk3jHVaTRvzO0biwCpwixTqmzTAPD8S2SUtDAphOwgqbbJ8.h UgmGmehIAZDNQJY0jvf4hjrmVDttNG0heQ9cyNmqXm6TMeFmtanpWYRJa4IU 0C5y3PWXWrt2ITWRumrkopQ_VKQjfb31C99WozsCHtO7NK.U7AFgA.H9fNgB gRPXJbP6qaRG4BdtWdB.LcY5ji1ssQhkVb27DcbPCMIbCBisZlZtIPYlH8Z6 Ss52gMg-- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Fri, 05 Jul 2013 06:35:50 PDT X-Rocket-MIMEInfo: 002.001, PlRvZGF5J3Mgcm91dGVycyAqbmVlZCogdG8gYmUgYWJsZSB0byBwcm90ZWN0IHRoZW1zZWx2ZXMsIGFuZCB0aGF0IGNhbiBvbmx5IGJlIGRvbmUgYnkgTDQtYXdhcmUgcmF0ZSBsaW1pdGluZyBhbmQgQUNMcy4KCgpPcGVyYXRvcnMgb2YgbmV0d29ya3MgbmVlZCB0byBwcm90ZWN0IHRoZWlyIG5ldHdvcmtzIGFuZCB1c2Vycy4gwqBPcGVyYXRvcnMgYWxzbyBuZWVkIGNhcGFiaWxpdGllcyB3aGljaCBhcmUgcHJvdmlkZWQgYnkgSVB2NiBleHRlbnNpb24gaGVhZGVycy4gwqAgSGF2aW5nIHNhaWQgdGhhdCwgbmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> Message-ID: <1373031350.93099.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Fri, 5 Jul 2013 06:35:50 -0700 (PDT) From: Nalini Elkins To: Gert Doering , Joe Touch In-Reply-To: <20130705124651.GP2706@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-699651999-1373031350=:93099" Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 13:36:02 -0000 --1619178251-699651999-1373031350=:93099 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >Today's routers *need* to be able to protect themselves, and that can only= be done by L4-aware rate limiting and ACLs.=0A=0A=0AOperators of networks = need to protect their networks and users. =A0Operators also need capabiliti= es which are provided by IPv6 extension headers. =A0 Having said that, netw= ork traffic has to be transmitted as quickly as possible. =A0 So, that mean= s reliance on hardware.=0A=0A=0AI would vote for=A0a compromise position of= encouraging 256 bytes for ASIC size. =A0=0A=A0=0AThanks,=0A=0A=0ANalini El= kins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com --1619178251-699651999-1373031350=:93099 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>Today's routers *need* to be able to protect them= selves, and that can only= be done by L4-aware rate limiting and ACLs.

=
Operators of networks need to protect their networks a= nd users.  Operators also need capabilities which are provided by IPv6= extension headers.   Having said that, network traffic has to be tran= smitted as quickly as possible.   So, that means reliance on hardware.=

I would vote= for a compromise posit= ion of encouraging 256 bytes for ASIC size.  
 
Thanks,

<= div>Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidet= hestack.com

 
--1619178251-699651999-1373031350=:93099-- From touch@isi.edu Fri Jul 5 06:36:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557C211E82F5 for ; Fri, 5 Jul 2013 06:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.321 X-Spam-Level: X-Spam-Status: No, score=-106.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 BD92sS+8PDxw for ; Fri, 5 Jul 2013 06:36:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1E011E82E9 for ; Fri, 5 Jul 2013 06:36:28 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65DZqsL022570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 06:36:03 -0700 (PDT) Message-ID: <51D6CBB9.2060200@isi.edu> Date: Fri, 05 Jul 2013 06:35:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> In-Reply-To: <51D6C7D2.6020504@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:36:34 -0000 On 7/5/2013 6:19 AM, Nick Hilliard wrote: > On 05/07/2013 14:13, Joe Touch wrote: >> I don't think that's possible unless you also protect "against" fragments >> altogether, and I don't think that is the job of a router. > > so you're ok about the idea of having a router sitting on the Internet DFZ > which you can take down with 20kpps of ipv6 fragments, The router ought to be able to forward at that rate. Unless these are addressed *to* the router they don't cause the router a problem. If they are, then limiting the forwarding chain won't help because these aren't forwarded by that router. Joe From touch@isi.edu Fri Jul 5 06:38:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5AD11E82E2 for ; Fri, 5 Jul 2013 06:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 3s4sJEI1wrrh for ; Fri, 5 Jul 2013 06:37:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18B11E82C4 for ; Fri, 5 Jul 2013 06:37:54 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65Db530023021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 06:37:15 -0700 (PDT) Message-ID: <51D6CC01.4070600@isi.edu> Date: Fri, 05 Jul 2013 06:37:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> In-Reply-To: <51D6C601.70003@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 13:38:00 -0000 On 7/5/2013 6:11 AM, Ray Hunter wrote: > So could we specify different requirements and solutions for control > traffic which terminates on the router, compared to end user traffic > which only transits it? Sure. But that's not at all what this doc does; this doc talks about forwarded traffic. That won't affect terminated traffic at all. Joe From nick@inex.ie Fri Jul 5 07:07:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C938711E80A5 for ; Fri, 5 Jul 2013 07:07: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=[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 kphkA6Vfind5 for ; Fri, 5 Jul 2013 07:07:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id BDB0021F9DEE for ; Fri, 5 Jul 2013 07:06:59 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65E6tid039092 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 15:06:56 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6D2FF.40305@inex.ie> Date: Fri, 05 Jul 2013 15:06:55 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> In-Reply-To: <51D6CBB9.2060200@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:07:10 -0000 On 05/07/2013 14:35, Joe Touch wrote: > ... then limiting the forwarding chain won't help because these aren't > forwarded by that router. then your understanding of modern routers is incorrect. Let's say you have an IPv6 address on a router interface - it doesn't matter if it's used for management or not. If it's pingable, then the ping packets will be directed to the router management or route processor engine for slow path processing. We use control plan policing or equivalent technologies to ensure that packets of this form do not overload the RE / RP. In order to implement CoPP/RE firewalling, we need hardware ACL support to be able to distinguish between the sorts of packets that we want to see and the ones we don't. In practice, this means implementing sophisticated ACL + QoS support in hardware. Consequently, this means that we need the ability to inspect reasonably deeply into ipv6 packet headers. On several well known router engines, this functionality is not there because the lookup engines cannot inspect far enough into the packet header to handle ipv6 headers properly. Consequently, large chunks of the internet run on equipment which cannot be protected against trivial pps based ipv6 attacks. On some of them, it turns out that it doesn't matter whether it's pingable or not, because you can craft IPv6 packets which can bypass the hardware classification mechanisms. All you need to know is the ipv6 address of any interface on the box, and you can trivially trash it remotely. On this basis, I would suggest that this is not just a technical problem, but a really serious technical problem with potentially devastating operational consequences. Nick From v6ops@globis.net Fri Jul 5 07:15:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23F811E8286 for ; Fri, 5 Jul 2013 07:15:06 -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 Wr7X50fPY5Gy for ; Fri, 5 Jul 2013 07:15: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 51ED111E80F3 for ; Fri, 5 Jul 2013 07:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8C15287007B; Fri, 5 Jul 2013 16:14:50 +0200 (CEST) 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 UAdxwOMWxfOV; Fri, 5 Jul 2013 16:14:50 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5E64E870070; Fri, 5 Jul 2013 16:14:50 +0200 (CEST) Message-ID: <51D6D4D4.5000704@globis.net> Date: Fri, 05 Jul 2013 16:14:44 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> In-Reply-To: <51D6CC01.4070600@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:15:07 -0000 > Joe Touch > 5 July 2013 15:37 > > > > > Sure. But that's not at all what this doc does; this doc talks about > forwarded traffic. That won't affect terminated traffic at all. > > Joe > Exactly. And the requirement from Geert and Steinar was for protecting control plane traffic AFAICS. So what is the requirement to process L4 headers offorwarded traffic at 10 gbps in backbone routers? And are there alternatives? RayH From gert@space.net Fri Jul 5 07:17:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AD411E82FD for ; Fri, 5 Jul 2013 07:17:41 -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 0DLXBvK4SUjH for ; Fri, 5 Jul 2013 07:17:40 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 4260811E82F6 for ; Fri, 5 Jul 2013 07:17:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id BFDDE60A12 for ; Fri, 5 Jul 2013 16:17:35 +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 984CC60A06 for ; Fri, 5 Jul 2013 16:17:35 +0200 (CEST) Received: (qmail 76996 invoked by uid 1007); 5 Jul 2013 16:17:35 +0200 Date: Fri, 5 Jul 2013 16:17:35 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130705141735.GT2706@Space.Net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hGNdHmcoeERwtJjO" Content-Disposition: inline In-Reply-To: <51D6D4D4.5000704@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:17:41 -0000 --hGNdHmcoeERwtJjO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: > Exactly. And the requirement from Geert and Steinar was for protecting > control plane traffic AFAICS. Well, actually we need both... > So what is the requirement to process L4 headers offorwarded traffic at > 10 gbps in backbone routers? =2E.. "drop this UDP/53 flood at the most external borders we can to stop it from overloading internal links". 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 --hGNdHmcoeERwtJjO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUdbVf6kuBuNlUUl1AQLeSQQAquzON4nO1gE2jAna9mEmqGxqWykeMIM5 rkdKILRQGvVi9Ezc4e1qEyNqhnxz/8EfKyOzHoOlGuH8ZtIbX3t1UOYe31ud/Q5Y b+hE/tc+MWomr7dMVrPY2mFijCcM/+4cIlhJ+6omT3Jj6zgIrfp127Fcl/FVi1zw lbH+14HNxzY= =Wnu1 -----END PGP SIGNATURE----- --hGNdHmcoeERwtJjO-- From touch@isi.edu Fri Jul 5 07:21:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934CC11E8104 for ; Fri, 5 Jul 2013 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 u9S2TSDYKhVL for ; Fri, 5 Jul 2013 07:21:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7721F9FE1 for ; Fri, 5 Jul 2013 07:21:25 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65EKrRV000373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 07:21:04 -0700 (PDT) Message-ID: <51D6D646.7080102@isi.edu> Date: Fri, 05 Jul 2013 07:20:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> In-Reply-To: <51D6D2FF.40305@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:21:31 -0000 On 7/5/2013 7:06 AM, Nick Hilliard wrote: > On 05/07/2013 14:35, Joe Touch wrote: >> ... then limiting the forwarding chain won't help because these aren't >> forwarded by that router. > > then your understanding of modern routers is incorrect. > > Let's say you have an IPv6 address on a router interface - it doesn't > matter if it's used for management or not Agreed. Packets addressed *to* the router need to be fully processed. That has nothing to do with packets not addressed to the router. Those packets pass through the forwarding plane. The draft talks about this being a forwarding plane issue. Your explanation has nothing to do with that. However, I can still shut down your router any number of ways, by sending lots of interesting things in those first 128 bytes that cause the router to overload - e.g., fragments to reassemble, source routes to process, etc. So limiting the chain for packets addressed *to* the router solves the problem of how much data to copy before you know you need to something else with the packet. But you can easily be asked to do a lot more than the router can handle once you copy that. So you've solved the copy problem, but not much else. > In order to implement CoPP/RE firewalling, we need hardware ACL support to > be able to distinguish between the sorts of packets that we want to see and > the ones we don't. In practice, this means implementing sophisticated ACL > + QoS support in hardware. Consequently, this means that we need the > ability to inspect reasonably deeply into ipv6 packet headers. Hardware does not imply short headers. Wanting to do fast copies of subsets of a packet does - independent of hardware vs. software. > ...All you need to know is the > ipv6 address of any interface on the box, and you can trivially trash it > remotely. Whether that's true does not seem to depend on the header chain length, though. Joe From v6ops@globis.net Fri Jul 5 07:24:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501021F9310 for ; Fri, 5 Jul 2013 07:24:17 -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 WicaqZ1Y31yg for ; Fri, 5 Jul 2013 07:24:17 -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 4F19021F8FAF for ; Fri, 5 Jul 2013 07:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 942A887007B; Fri, 5 Jul 2013 16:24:01 +0200 (CEST) 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 w7KUgMbgEC+M; Fri, 5 Jul 2013 16:24:01 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6C9AC870070; Fri, 5 Jul 2013 16:24:01 +0200 (CEST) Message-ID: <51D6D6FB.2090401@globis.net> Date: Fri, 05 Jul 2013 16:23:55 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> In-Reply-To: <20130705141735.GT2706@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:24:18 -0000 > Gert Doering > 5 July 2013 16:17 > Hi, > > On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >> Exactly. And the requirement from Geert and Steinar was for protecting >> control plane traffic AFAICS. > > Well, actually we need both... > >> So what is the requirement to process L4 headers offorwarded traffic at >> 10 gbps in backbone routers? > > ... "drop this UDP/53 flood at the most external borders we can to stop > it from overloading internal links". No disrespect, but by the time you've detected the attack and put in the appropriate L4 filtering config, haven't the attackers long gone? Doesn't this sort of DoS defence need to be auto-detecting, and auto-responding, like fair queueing? Or in the old days, simply reducing the link speed to untrusted peers? > Gert Doering > -- NetMaster > From touch@isi.edu Fri Jul 5 07:25:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75AB11E811B for ; Fri, 5 Jul 2013 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.391 X-Spam-Level: X-Spam-Status: No, score=-106.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 e0Ayit9hoD3c for ; Fri, 5 Jul 2013 07:25:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9A11E81DA for ; Fri, 5 Jul 2013 07:25:24 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65EO1c0001084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 07:24:12 -0700 (PDT) Message-ID: <51D6D701.3070700@isi.edu> Date: Fri, 05 Jul 2013 07:24:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> In-Reply-To: <20130705141735.GT2706@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ray Hunter , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:25:39 -0000 On 7/5/2013 7:17 AM, Gert Doering wrote: > Hi, > > On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >> Exactly. And the requirement from Geert and Steinar was for protecting >> control plane traffic AFAICS. > > Well, actually we need both... > >> So what is the requirement to process L4 headers offorwarded traffic at >> 10 gbps in backbone routers? > > ... "drop this UDP/53 flood at the most external borders we can to stop > it from overloading internal links". You don't need to know UDP/53 to do this; you need enough info to differentiate this flow from others. That means N bytes into the header; the more into the header you copy, the less false positives you drop (e.g., if you check only 40, you'd drop all traffic from a source). That's value added for vendors that want to support looking further into a packet, but has nothing to do with whether the source should limit its header chain. Joe From sthaug@nethelp.no Fri Jul 5 07:34:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DAB21F99E1 for ; Fri, 5 Jul 2013 07:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 KBaINFBcWY0i for ; Fri, 5 Jul 2013 07:34:28 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id F309121F9B25 for ; Fri, 5 Jul 2013 07:34:26 -0700 (PDT) Received: (qmail 35819 invoked from network); 5 Jul 2013 14:34:24 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Jul 2013 14:34:24 -0000 Date: Fri, 05 Jul 2013 16:34:24 +0200 (CEST) Message-Id: <20130705.163424.41642834.sthaug@nethelp.no> To: v6ops@globis.net From: sthaug@nethelp.no In-Reply-To: <51D6D6FB.2090401@globis.net> References: <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> <51D6D6FB.2090401@globis.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: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:34:33 -0000 > > ... "drop this UDP/53 flood at the most external borders we can to stop > > it from overloading internal links". > No disrespect, but by the time you've detected the attack and put in the > appropriate L4 filtering config, haven't the attackers long gone? Not necessarily. We see DNS-based spoofed source amplification attacks that last for *days*. Steinar Haug, AS 2116 From gert@space.net Fri Jul 5 07:43:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8362411E812B for ; Fri, 5 Jul 2013 07:43: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3k4JFDd3Tc7 for ; Fri, 5 Jul 2013 07:43:31 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id D990211E8104 for ; Fri, 5 Jul 2013 07:43:30 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 533C660A12 for ; Fri, 5 Jul 2013 16:43:28 +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 3FE05609FB for ; Fri, 5 Jul 2013 16:43:28 +0200 (CEST) Received: (qmail 86476 invoked by uid 1007); 5 Jul 2013 16:43:28 +0200 Date: Fri, 5 Jul 2013 16:43:28 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130705144328.GU2706@Space.Net> References: <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> <51D6D6FB.2090401@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V04wbe4pUYOisw7u" Content-Disposition: inline In-Reply-To: <51D6D6FB.2090401@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:43:31 -0000 --V04wbe4pUYOisw7u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 05, 2013 at 04:23:55PM +0200, Ray Hunter wrote: > > ... "drop this UDP/53 flood at the most external borders we can to stop > > it from overloading internal links". > No disrespect, but by the time you've detected the attack and put in the > appropriate L4 filtering config, haven't the attackers long gone? >=20 > Doesn't this sort of DoS defence need to be auto-detecting, and > auto-responding, like fair queueing? Well, these days people observe UDP/53 flooding that goes on for days. Who will know what's there tomorrow? > Or in the old days, simply reducing the link speed to untrusted peers? All peers are untrusted - and we're not interested in reducing speed for useful traffic. =20 Assume that our external links can handle the traffic, the "bad" traffic=20 is easily identified (like: UDP/53 reflective DoS to a web server who=20 doesn't need any external UDP in the first place), and that some internal= =20 link towards the web server would become overloaded. Being able to filter at the most external borders is a must. (But I'm not sure this discussion is going anywhere - I'd welcome if all people that argue that this is not a problem run an ISP network for a=20 few weeks, and then come back) 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 --V04wbe4pUYOisw7u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUdbbkKkuBuNlUUl1AQImMQP5Ad5rmzgmRlc+eO8sjgqvW3X6R56KfzP9 rP7JsYi+tsPfogQ+dUsc8vNInK1KPkuy2pbRXOsASD+yHgIozgvZTi9mn4DICPLP NG0wqvWeJ4w6KioVDbniH8iydhZ+CY4nWnPunMdRp+p7xdvd/8HRn0UaAEygyetK GdWyGfTjFn8= =h0Ir -----END PGP SIGNATURE----- --V04wbe4pUYOisw7u-- From touch@isi.edu Fri Jul 5 07:47:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9A11E82FC for ; Fri, 5 Jul 2013 07:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 lirW7GC2t3KB for ; Fri, 5 Jul 2013 07:47:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0348711E8286 for ; Fri, 5 Jul 2013 07:47:53 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65El0FD005709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 07:47:11 -0700 (PDT) Message-ID: <51D6DC65.8000009@isi.edu> Date: Fri, 05 Jul 2013 07:47:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> <51D6D701.3070700@isi.edu> In-Reply-To: <51D6D701.3070700@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ray Hunter , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:47:59 -0000 On 7/5/2013 7:24 AM, Joe Touch wrote: > > > On 7/5/2013 7:17 AM, Gert Doering wrote: >> Hi, >> >> On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >>> Exactly. And the requirement from Geert and Steinar was for protecting >>> control plane traffic AFAICS. >> >> Well, actually we need both... First, the doc doesn't discuss these as the separate issues they are. Second, the following are entirely different operational suggestions: - limit chains of all IPv6 packets - limit chains of IPv6 packets addressed to routers (and suggest that routers drop packets that aren't as simple as expected to protect their control plane) The latter is entirely reasonable; if you're running the router, you get to decide how long a chain you want to allow to your control plane. The former has widespread implications on the use of IPv6 options, and should be avoided unless absolutely necessary. I still haven't seen where this is the case. Note that other end-systems could similarly limit what they do - DNS servers, etc. That's always up to the end system to decide anyway. Joe From nick@inex.ie Fri Jul 5 07:55:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6C21F9E34 for ; Fri, 5 Jul 2013 07:55:04 -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 GoUCKZLczaYn for ; Fri, 5 Jul 2013 07:54:51 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6240721F9C56 for ; Fri, 5 Jul 2013 07:54:47 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65EsiUn039397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 15:54:44 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6DE34.2060800@inex.ie> Date: Fri, 05 Jul 2013 15:54:44 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu> In-Reply-To: <51D6D646.7080102@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 14:55:13 -0000 On 05/07/2013 15:20, Joe Touch wrote: > Your explanation has nothing to do with that. In fact it has because it's still the same silicon which is used in both circumstances. Alternatively let's talk about infrastructure ACLs. I also want to be able to filter ipv6 packets with arbitrary ipv6 headers on my network edge so that other people cannot reach my core network with known harmful traffic. Is that better? Remember, it's the same silicon which does both. > However, I can still shut > down your router any number of ways, by sending lots of interesting things > in those first 128 bytes that cause the router to overload - e.g., > fragments to reassemble, source routes to process, etc. Eh, no, you generally can't. Source routed packets have dropped for the last 15 years. Reassembly attacks can be protected by dropping packets from everything except known hosts, and by using infrastructure acls to stop spoofing. >> ...All you need to know is the >> ipv6 address of any interface on the box, and you can trivially trash it >> remotely. > > Whether that's true does not seem to depend on the header chain length, though. God almighty, Joe, of course it depends on the header chain length. It depends on plenty of other things too, but header chain length is one of them. This is a ridiculous argument: you clearly have no operational experience in this area, nor any clue of how modern routers operate and how their operational limitations affect production networks. Nick From touch@isi.edu Fri Jul 5 08:29:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5911E8132 for ; Fri, 5 Jul 2013 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.42 X-Spam-Level: X-Spam-Status: No, score=-106.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 Kmtnsr2D7iu3 for ; Fri, 5 Jul 2013 08:28:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id ED79011E813F for ; Fri, 5 Jul 2013 08:28:51 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r65FRjEK013760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 08:27:55 -0700 (PDT) Message-ID: <51D6E5F1.3020205@isi.edu> Date: Fri, 05 Jul 2013 08:27:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nick Hilliard References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu> <51D6DE34.2060800@inex.ie> In-Reply-To: <51D6DE34.2060800@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 15:29:00 -0000 On 7/5/2013 7:54 AM, Nick Hilliard wrote: > of course it depends on the header chain length. It > depends on plenty of other things too, but header chain length is one of them. It would be useful to start by explaining: a) what traffic you need to inspect? - to the router - through the router Which one determines whether you need to suggest limiting header chains for all traffic or just traffic to your router. b) what is the problem with inspecting traffic? - the length of the chain - how many 'links' in the chain the former is a memory capacity and bandwidth problem; the latter is a processing speed problem Neither one has anything to do with whether you use ASICs; they both have to do with whether you are space or time limited and in what resource. Which one is the problem determines whether you need to limit the length of the chain or the number of links in it, or both. Joe From lambert@psc.edu Fri Jul 5 08:32:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0738B11E82CD for ; Fri, 5 Jul 2013 08:32:05 -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 iyql7YxMZy0W for ; Fri, 5 Jul 2013 08:32:04 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5A111E8127 for ; Fri, 5 Jul 2013 08:32:04 -0700 (PDT) Received: from [192.168.1.69] (c-71-60-91-199.hsd1.pa.comcast.net [71.60.91.199]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id r65FW3iF030999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jul 2013 11:32:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael H Lambert In-Reply-To: <51D6E5F1.3020205@isi.edu> Date: Fri, 5 Jul 2013 11:32:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11BB590E-01FE-4BA0-9511-370B8C6F2F29@psc.edu> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu> <51D6DE34.2060800@inex.ie> <51D6E5F1.3020205@isi.edu> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [v6ops] New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 15:32:05 -0000 On 5 Jul 2013, at 11:27, Joe Touch wrote: > It would be useful to start by explaining: >=20 > a) what traffic you need to inspect? > - to the router > - through the router >=20 > Which one determines whether you need to suggest limiting header = chains for all traffic or just traffic to your router. Are hop-by-hop options TO the router, THROUGH the router, or both? Michael From farmer@umn.edu Fri Jul 5 08:53:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E7E11E8302 for ; Fri, 5 Jul 2013 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNvOwEizydIi for ; Fri, 5 Jul 2013 08:53:11 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 95F1B11E8127 for ; Fri, 5 Jul 2013 08:53:11 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 5 Jul 2013 10:53:01 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-oa0-f51.google.com [209.85.219.51] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f51.google.com with SMTP id i4so3573748oah.10 for ; Fri, 05 Jul 2013 08:53:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ICtzxFs5A4JxQyUsphOfJndZ772QULNA+yQA4sELBVk=; b=KOcFz8bdyiczh+UKlS2WyF/JuwPL9kaExdiXkqJqIVdGb2hK9zHxNKPpqVq/eLtgIT /+VD0PVURcdz1f5Y6FgsW4AHmmFk6zCvCC7mxErrqRi9+sQ9WzbAcTkkmsN6LxUoIace rceO6Avi6kwK7PF2aZqP1Ej+Z1IHroH/Z1lDSdWt4ds9PPb5Ni7MfpNWoL2oKo9nj7Ij 01D+Bj5cgpeaZz57WOzY6nf8QBUfEf1NOnMgGg727zJx0GdzQtAmxGzapTPeOnIMcXzY PKADRmMqUbSpKx9e2agnVHFyGwEnV7Mn7ouNFfRPejMi2C9kkOdeHvnIbyX4BskASFgf V2IQ== X-Received: by 10.60.57.164 with SMTP id j4mr11694071oeq.10.1373039581498; Fri, 05 Jul 2013 08:53:01 -0700 (PDT) X-Received: by 10.60.57.164 with SMTP id j4mr11694061oeq.10.1373039581406; Fri, 05 Jul 2013 08:53:01 -0700 (PDT) Received: from oit201651646.local ([2001:470:1f11:821:ccb8:28da:84a7:c9df]) by mx.google.com with ESMTPSA id tv3sm15234137obb.8.2013.07.05.08.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 08:53:00 -0700 (PDT) Message-ID: <51D6EBDB.3030309@umn.edu> Date: Fri, 05 Jul 2013 10:52:59 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy , Arturo Servin References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> <51D55CF0.9010301@gmail.com> <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkMrP5q9Q2lo8XThK+5yJ18wPpd2ECHXumCWKsX43u2//VgNHf+/CbzG/iOO6g1If/fx2bwzU5RhSFhibVoHRuZCbzstaVP4w78F6dqGcjCqXBwp4Pr52XO8CWlKK5a3+SMGlc5 Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:53:18 -0000 On 7/4/13 22:27 , S Moonesamy wrote: > Hi Arturo, > At 04:30 04-07-2013, Arturo Servin wrote: >> Sorry, I should have said "Or are these recommendations orthogonal >> to a network applying RA Guard?" > > Yes. > >> I think the ansewer is still yes. But for that reason I think that >> you should mention that this is an add-on to RA Guard (not instead of, >> not criticizing it) and it is intended to provide some security >> mechanisms to the host when the network administrator do not have this >> capability (RA-Guard) in its network. > > I think that we are looking at this from two different angles. I can > look at this in terms of: > > (a) how does the network protect the host > > (b) how is the host protected > > If there is a protection for (a), for example, Router Advertisement > Guard, (b) might not be much of a problem. If the host is protected, > the question being asked is whether (a) is needed or not. I am not > trying to answer that question as there is existing code for doing (b) > and that is what the draft is talking about. What the person writing > the code for the host may wish to say is that their system provides for > the limits mentioned in draft-moonesamy-ra-flood-limit-00. I think some kind of applicability statement would be a useful addition to the Draft. I'm less worried about a network operators deciding that they don't need to implement RA-Guard because their hosts implement RA-Flood-Limit. I'm more concerned about OS vendors or implementors deciding they don't need to implement RA-Flood-Limit because they view this as a network operator issue and if only the network operators would just implement RA-Guard then RA-Flood-Limit wouldn't be necessary. I think it needs to be made clear that both RA-Guard and RA-Flood-Limit are independently necessary to ensure both the security and stability of a network and its hosts. 1. RA-Guard or the other the techniques discussed in RFC6104 can effectively prevent RAs sourced from hosts either by malicious activity or simple miss-configuration. But, RA-Guard can do little to prevent RAs caused by software or hardware bugs within, or miss-configuration of the network itself. 2. RA-Flood-Limit prevents the consequences of many different RAs being seen by a host, regardless of the source of those RAs. But, can not distinguish between the source of the RAs, and may allow malicious configuration of the host. 3. Therefore, implementation of BOTH RA-Guard and RA-Flood-Limit are necessary to ensure BOTH the security and stability of a network and its hosts. >> In the end, having RA-Guard could solve enteraly this problem, but >> when it is not provided by the network the host should have mechanisms >> to defend itself. Then is when your draft applies. Does it make sense my >> comment? I disagree, RA-Guard can effectively deal with RA-Floods caused by hosts either through malicious activity or miss-configuration, but can not necessarily deal with RA-Floods caused by miss-configuration or bugs within the network itself. > Yes, I understood what you wrote. In my opinion it depends on your > security posture. Some people may prefer to put security closer to the > end whereas others might find it better to do it centrally. RFC 6104 > discusses about scenarios and different methods to mitigate against > rogue Router Advertisements. In my opinion that is where the above is > more relevant. What the code does is to prevent the host it is running > on from crashing. Security posture is only part of the issue, this is both a security and stability issue, that needs both host based and network based mitigation strategies. Neither, RA-Guard or RA-Flood-Limit can ensure both the stability and security of a network and it hosts independently, they are complementary strategies, and are both necessary for a complete solution. I think it is important for the Draft makes this point one way or another. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From arturo.servin@gmail.com Fri Jul 5 09:06:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF05511E82FE for ; Fri, 5 Jul 2013 09:06:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+ZEX5YFMVuy for ; Fri, 5 Jul 2013 09:06:31 -0700 (PDT) Received: from mail-gh0-x22c.google.com (mail-gh0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6514611E82F1 for ; Fri, 5 Jul 2013 09:06:31 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id r18so781508ghr.31 for ; Fri, 05 Jul 2013 09:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VNmu7ha89dZdbm5219cuHsttCMFAHiYzSLgYQt1cCmI=; b=ESeKT/5uMS92FBNGopgYAhO8D4mTjDg/FBD6lcLKaEFsAsBv49KIieGkfk4JRRPJXS AW7t72h+BatXQkzxDujBFU+IP+QKivt1wWFrtIaQiiFwrL0m1KhG6u9sYw9EnZAg8abq 3iEhqeurCBMRkjFGvROy24GJm5SEg5HYbpOZaxfJb+N9yZ/PyveTcph7GH/O+vjr8EWn ZB4YlCKC/7UkQHRaNhhIMX1MRpv2txZnwFY52vd/NcKedPHT6JLNum4RtaEJ+IXufsi0 EOuszb+HLWs17/nCQBElP4Xrc41jb+aZfgc0FP8aVUcAZM7ufN83MGbJ5lS9oQNCuUBc ++hQ== X-Received: by 10.236.145.199 with SMTP id p47mr6210912yhj.235.1373040389745; Fri, 05 Jul 2013 09:06:29 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2001:13c7:7001:7000:a82c:7621:165b:b631]) by mx.google.com with ESMTPSA id 66sm13542484yhe.20.2013.07.05.09.06.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 09:06:28 -0700 (PDT) Message-ID: <51D6EF03.8020909@gmail.com> Date: Fri, 05 Jul 2013 13:06:27 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Farmer References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> <51D55CF0.9010301@gmail.com> <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> <51D6EBDB.3030309@umn.edu> In-Reply-To: <51D6EBDB.3030309@umn.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, S Moonesamy Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 16:06:32 -0000 David On 7/5/13 12:52 PM, David Farmer wrote: > >>> In the end, having RA-Guard could solve enteraly this problem, but >>> when it is not provided by the network the host should have mechanisms >>> to defend itself. Then is when your draft applies. Does it make >>> sense my >>> comment? > > I disagree, RA-Guard can effectively deal with RA-Floods caused by > hosts either through malicious activity or miss-configuration, but can > not necessarily deal with RA-Floods caused by miss-configuration or > bugs within the network itself. Agreed. I was just considering the malicious activity but I oversight miss-configuration or bugs. I also agree with you that both RA-Guard and RA-Flood-Limit are necessary. I think those statements should be added to the draft. Regards, as From touch@isi.edu Fri Jul 5 09:14:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E8811E8311 for ; Fri, 5 Jul 2013 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 O+IWCBpdXaw4 for ; Fri, 5 Jul 2013 09:14:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DFF5F11E813D for ; Fri, 5 Jul 2013 09:14:00 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r65GDVZB020546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 09:13:41 -0700 (PDT) Message-ID: <51D6F0AA.6050800@isi.edu> Date: Fri, 05 Jul 2013 09:13:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael H Lambert References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu> <51D6DE34.2060800@inex.ie> <51D6E5F1.3020205@isi.edu> <11BB590E-01FE-4BA0-9511-370B8C6F2F29@psc.edu> In-Reply-To: <11BB590E-01FE-4BA0-9511-370B8C6F2F29@psc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 16:14:06 -0000 On 7/5/2013 8:32 AM, Michael H Lambert wrote: > On 5 Jul 2013, at 11:27, Joe Touch wrote: > >> It would be useful to start by explaining: >> >> a) what traffic you need to inspect? >> - to the router >> - through the router >> >> Which one determines whether you need to suggest limiting header chains for all traffic or just traffic to your router. > > Are hop-by-hop options TO the router, THROUGH the router, or both? Both, as per RFC2460 they are examined at every hop, including the source and destination. Joe From nick@inex.ie Fri Jul 5 09:33:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EC711E8129 for ; Fri, 5 Jul 2013 09:33:53 -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 LP1eluSP2wcv for ; Fri, 5 Jul 2013 09:33:52 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA6E11E8142 for ; Fri, 5 Jul 2013 09:33:51 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65GXmsh039940 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 17:33:48 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <51D6F56C.6000002@inex.ie> Date: Fri, 05 Jul 2013 17:33:48 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu> <51D6DE34.2060800@inex.ie> <51D6E5F1.3020205@isi.edu> In-Reply-To: <51D6E5F1.3020205@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 16:33:53 -0000 On 05/07/2013 16:27, Joe Touch wrote: > It would be useful to start by explaining: I already have, multiple times over the past couple of months, and most recently in my previous email. > a) what traffic you need to inspect? > - to the router > - through the router Both: to: control plane policing / RE firewalling through: infrastructure ACLs Both are equally important to running functional networks and incidentally both are handled by the same hardware ACL/queueing mechanisms. > b) what is the problem with inspecting traffic? > > - the length of the chain > - how many 'links' in the chain On current generation forwarding engines, mostly the length of the chain. > Neither one has anything to do with whether you use ASICs; they both have > to do with whether you are space or time limited and in what resource. I made no claim in this regard. What I said was that your statement "claims that this is about a technical problem are false" was absurd. Nick From joelja@bogus.com Fri Jul 5 12:04:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C021F9130 for ; Fri, 5 Jul 2013 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.045 X-Spam-Level: X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 2IrD2S+dWoW2 for ; Fri, 5 Jul 2013 12:04:30 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A5ACC21F90CC for ; Fri, 5 Jul 2013 12:04:30 -0700 (PDT) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r65J40ae001414 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 19:04:00 GMT (envelope-from joelja@bogus.com) Message-ID: <51D7189A.60307@bogus.com> Date: Fri, 05 Jul 2013 12:03:54 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Gert Doering , Ray Hunter References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> In-Reply-To: <20130705141735.GT2706@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 05 Jul 2013 19:04:01 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 19:04:31 -0000 On 7/5/13 7:17 AM, Gert Doering wrote: > Hi, > > On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >> Exactly. And the requirement from Geert and Steinar was for protecting >> control plane traffic AFAICS. > Well, actually we need both... > >> So what is the requirement to process L4 headers offorwarded traffic at >> 10 gbps in backbone routers? > ... "drop this UDP/53 flood at the most external borders we can to stop > it from overloading internal links". closer to the edge of my network, in addition to stateless acls, it's hash l4 flows into one of many stateful middle-boxes or endpoints. > > Gert Doering > -- NetMaster > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Fri Jul 5 12:16:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09D21F9CF7 for ; Fri, 5 Jul 2013 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 bT2HCbX6TOlZ for ; Fri, 5 Jul 2013 12:16:46 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEA721F9CAD for ; Fri, 5 Jul 2013 12:16:46 -0700 (PDT) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r65JGHLG001538 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 19:16:18 GMT (envelope-from joelja@bogus.com) Message-ID: <51D71B7C.7090501@bogus.com> Date: Fri, 05 Jul 2013 12:16:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Ray Hunter , Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> <51D6D6FB.2090401@globis.net> In-Reply-To: <51D6D6FB.2090401@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 05 Jul 2013 19:16:18 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 19:16:47 -0000 On 7/5/13 7:23 AM, Ray Hunter wrote: >> Gert Doering >> 5 July 2013 16:17 >> Hi, >> >> On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >>> Exactly. And the requirement from Geert and Steinar was for protecting >>> control plane traffic AFAICS. >> Well, actually we need both... >> >>> So what is the requirement to process L4 headers offorwarded traffic at >>> 10 gbps in backbone routers? >> ... "drop this UDP/53 flood at the most external borders we can to stop >> it from overloading internal links". > No disrespect, but by the time you've detected the attack and put in the > appropriate L4 filtering config, haven't the attackers long gone? The attempt at disruption lasts until the party achieves their goal, or gives up. > Doesn't this sort of DoS defence need to be auto-detecting, and > auto-responding, like fair queueing? Given a detection and mitigation platform you can identify and then install and remove acls accordingly http://tools.ietf.org/html/rfc5575 http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-03 of course that requires that you be able to find the header you're trying to match on. actual deployment of flowspec in the field isn't for everyone, and it has a lot of warts in implementations. but it's there. > Or in the old days, simply reducing the link speed to untrusted peers? >> Gert Doering >> -- NetMaster >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Fri Jul 5 15:34:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AD21F9F96 for ; Fri, 5 Jul 2013 15:34:11 -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, 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 HT8EqHPs+PbX for ; Fri, 5 Jul 2013 15:34:11 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE5C21F9F93 for ; Fri, 5 Jul 2013 15:34:10 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x11so2354686pdj.15 for ; Fri, 05 Jul 2013 15:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wpoY6QLCSwgYiFfSwXFiXojrt26iwgDEu320dwjA7TI=; b=DRGOl+IPBmLq9hiXw8HgB1x8UyT8U/9qTY826HuHBTz+WzfA4Ewpvst/aX8NNSuKcm BB8DSX4xpthBGIXhoD/V/rG4oTTQX+TYZw/QlkU2U5/yKxu5ORZTOJFAgkQXWbL+Ctcj p+ic/1UuSfOjoYNAyJgGB53PsIEIf0fKpmB276J+zfqezNRJgdxx6nfbDjAQM66OMBEh lOpNaWMRpljUJ3xvOVP1McbLXd7bmyvvC3iFV6cyHqn9G+oTq5rc2tsasvDvB9QG6gVh Ovc0k6GxHAlOQUGqFlayLw4CZiVYLMQGsSen3F+VRcouD0mYY5KbwOUJHgfhUHJPwRWG gDpw== X-Received: by 10.68.211.70 with SMTP id na6mr11548167pbc.22.1373063650789; Fri, 05 Jul 2013 15:34:10 -0700 (PDT) Received: from [10.1.9.177] ([203.167.141.74]) by mx.google.com with ESMTPSA id iq6sm9216632pbc.1.2013.07.05.15.34.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 15:34:07 -0700 (PDT) Message-ID: <51D749E5.3080301@gmail.com> Date: Sat, 06 Jul 2013 10:34:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> In-Reply-To: <20130705141735.GT2706@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-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: Fri, 05 Jul 2013 22:34:11 -0000 On 06/07/2013 02:17, Gert Doering wrote: > Hi, > > On Fri, Jul 05, 2013 at 04:14:44PM +0200, Ray Hunter wrote: >> Exactly. And the requirement from Geert and Steinar was for protecting >> control plane traffic AFAICS. > > Well, actually we need both... > >> So what is the requirement to process L4 headers offorwarded traffic at >> 10 gbps in backbone routers? In any case, we need to process L4 headers at line speed in full-function firewalls and in load balancers. So even if the argument about core routers was completely bogus (which it isn't), exactly the same problem would arise somewhere else on most paths. I don't think there's any way out of the need to keep the header chain reasonably short, and at least make fragmentation a rare exception case. Both of these could have been written into RFC 2460 from the start. Brian > > ... "drop this UDP/53 flood at the most external borders we can to stop > it from overloading internal links". > > Gert Doering > -- NetMaster > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sm@elandsys.com Fri Jul 5 17:47:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A11E80F3 for ; Fri, 5 Jul 2013 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 7jKaziNX6NOZ for ; Fri, 5 Jul 2013 17:47:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031221F9FF9 for ; Fri, 5 Jul 2013 17:47:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.24]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r660l9N7025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 17:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373071642; bh=VLViFhGQ2sSnPaZ2Svqqhw9d3YMLbYuTfRRX9Cqhpxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sTwBX9mOq1r3u40/8OO0ytsJG0l8yr23zW0t0/poPnsoThoBmzu9ryLjIsiCus1d0 81JpxpuVoQeuXE6ZOrrAS5RQWtcIXp0/u0uLyStJJtGuda3TnfEbo3Gl5u30SgAx+G ej8UJacmtD7P+8+AcMjpo8pH+gM4ukpR6/ju99mM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373071642; i=@elandsys.com; bh=VLViFhGQ2sSnPaZ2Svqqhw9d3YMLbYuTfRRX9Cqhpxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PuQw2o8rzOva36SEvdA82miMvg+6ridtIb5FbvND9D69NEvyq/H7/HyT2wXlCN/DS C8FU92vsTJ+N6pxZs8mDa3OH+fJmPJ0vaL4zcyN5x/OtQWQShVVvui9ImCHvKXOpL/ yAnmekKK5QwjSFUTRHyLax3paB1qL+NKscPy3z8Q= Message-Id: <6.2.5.6.2.20130705123350.0c715628@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Jul 2013 13:03:17 -0700 To: David Farmer , Arturo Servin From: S Moonesamy In-Reply-To: <51D6EBDB.3030309@umn.edu> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> <51D55CF0.9010301@gmail.com> <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> <51D6EBDB.3030309@umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:47:32 -0000 Hi Arturo, David, At 08:52 05-07-2013, David Farmer wrote: >I think some kind of applicability statement would be a useful >addition to the Draft. From an IETF Stream perspective it's difficult to assess how to write an applicability statement in this context. > I'm less worried about a network operators deciding that they > don't need to implement RA-Guard because their hosts implement > RA-Flood-Limit. I'm more concerned about OS vendors or > implementors deciding they don't need to implement RA-Flood-Limit > because they view this as a network operator issue and if only the > network operators would just implement RA-Guard then RA-Flood-Limit > wouldn't be necessary. I see. >I think it needs to be made clear that both RA-Guard and >RA-Flood-Limit are independently necessary to ensure both the >security and stability of a network and its hosts. Let me see if I can write some text to discuss the network versus host angle. >1. RA-Guard or the other the techniques discussed in RFC6104 can >effectively prevent RAs sourced from hosts either by malicious >activity or simple miss-configuration. But, RA-Guard can do little >to prevent RAs caused by software or hardware bugs within, or >miss-configuration of the network itself. I prefer not to comment about this. :-) >2. RA-Flood-Limit prevents the consequences of many different RAs >being seen by a host, regardless of the source of those RAs. But, >can not distinguish between the source of the RAs, and may allow >malicious configuration of the host. Yes. >3. Therefore, implementation of BOTH RA-Guard and RA-Flood-Limit are >necessary to ensure BOTH the security and stability of a network and its hosts. I think that the above looks at the proposal as a solution to the RA flooding problem whereas the scope of the proposal is a mitigation to a problem which a host may encounter. At 09:06 05-07-2013, Arturo Servin wrote: > I also agree with you that both RA-Guard and RA-Flood-Limit are >necessary. I think those statements should be added to the draft. Please see the comment above about the scope. Regards, S. Moonesamy From dwing@cisco.com Mon Jul 8 09:06:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BE121F9CB9 for ; Mon, 8 Jul 2013 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 qZATz3cKjq96 for ; Mon, 8 Jul 2013 09:06:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1621F9C3A for ; Mon, 8 Jul 2013 09:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3238; q=dns/txt; s=iport; t=1373299561; x=1374509161; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nIYOWrTcPGccOqNJzvE03E+nqd4ROeBh/slyDwUqkBA=; b=eSdHELBJ6d9WXvMESvZpZ4BUlDQ4sdGEqL3gxIzTwQVipNm3PXbhuOA9 itouCawiU2I9zWQMH0PMtL+wEjdGPXdnudr6sNGxJ3QsV8dcmYLNF/wLa HFEEjwOWkW+HMCNiOHwAtoK0ux75Ws/00rkjgZ7xRfNK/hPNzGivhJVrh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAB/i2lGrRDoG/2dsb2JhbABagwkywTGBEhZ0giMBAQECAQEBAQFGJQsFCwsQNicBLwYTG4duBQ24b484MweDB2kDiSWLaYJFgSmQH4MxHA X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208";a="85462246" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Jul 2013 16:05:58 +0000 Received: from sjc-vpn4-190.cisco.com (sjc-vpn4-190.cisco.com [10.21.80.190]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r68G5vrQ015996; Mon, 8 Jul 2013 16:05:57 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> Date: Mon, 8 Jul 2013 09:05:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> To: "Bajpai, Vaibhav" X-Mailer: Apple Mail (2.1508) Cc: v6ops@ietf.org Subject: Re: [v6ops] Measuring the Effectiveness of 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, 08 Jul 2013 16:06:05 -0000 On Jul 4, 2013, at 6:02 AM, "Bajpai, Vaibhav" = wrote: > Hello, >=20 > I would like to request a 10-minute presentation slot=20 > at the upcoming IETF 87 to present my PhD work: >=20 > Title: Measuring the Effectiveness of Happy Eyeballs > Authors: Vaibhav Bajpai and J=FCrgen Sch=F6nw=E4lder > URL: http://tools.ietf.org/html/draft-bajpai-happy-00 >=20 > Abstract: >=20 > The IETF has developed solutions that promote a healthy IPv4 and IPv6 > co-existence. The happy eyeballs algorithm for instance, provides > recommendations to application developers to help prevent bad user > experience in situations where IPv6 connectivity is broken. This > document describes a metric used to measure the effectiveness of the > happy eyeballs algorithm. The insights uncovered by analysing the > data from multiple locations is discussed. I noticed when this was published and presented earlier at = https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf. It's = nice to see it published as an Internet Draft, but disappointing that = the underlying Effective Measurement is testing something other than = Happy Eyeballs. Happy Eyeballs is doing what it was designed to do -- provide a good = user experience when the IPv6 (or IPv4) path is down. However, = draft-bajpai-happy did not evaluable how well Happy Eyeballs handles a = broken IPv6 or broken IPv4 path. Instead, what draft-bajpai-happy = measured was how well the selected path functioned. Happy Eyeballs = biases its path selection towards IPv6 by design (150-250ms timeout is = suggested in http://tools.ietf.org/html/rfc6555#section-5.5). The = justification for this delay is explained in "Delay IPv4", = http://tools.ietf.org/html/rfc6555#section-4.1, and was consensus of the = working group primarily because it (a) mimics the long-standing IETF = view that IPv6 should be preferred over IPv4 (b) reduces connection = attempts on servers and (c) minimizes the harm to IPv4-only devices = sharing an IPv4 address with the dual-stack client (as those IPv4-only = devices cannot use IPv6). Happy Eyeballs' algorithm differs from = Apple's algorithm (introduced in OS X 10.7) which uses whichever path = connects first (for details see = http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html), which = I expect would result in better results if tested using the test = methodology of draft-bajpai-happy. However, even with Apple's algorithm = if a path connects quickly but the path performs poorly (e.g., low = bandwidth) the user experience will suffer. Happy Eyeballs can perform = similarly to Apple's algorithm (but not identically) by setting its = connection delay to 0ms. -d > Thank you! >=20 > Best, Vaibhav >=20 > ----------------------------------------------------- > Vaibhav Bajpai >=20 > Research I, Room 86 > Computer Networks and Distributed Systems (CNDS) Lab > School of Engineering and Sciences > Jacobs University Bremen, Germany >=20 > www.vaibhavbajpai.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alh-ietf@tndh.net Mon Jul 8 12:09:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328621F9CB2 for ; Mon, 8 Jul 2013 12:09:24 -0700 (PDT) X-Quarantine-ID: <7teVJDhprY2B> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7teVJDhprY2B for ; Mon, 8 Jul 2013 12:09:23 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) by ietfa.amsl.com (Postfix) with ESMTP id 437DD21F9C83 for ; Mon, 8 Jul 2013 12:09:22 -0700 (PDT) Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1UwGo7-000Hze-Tc; Mon, 08 Jul 2013 12:09:18 -0700 From: "Tony Hain" To: "'Dan Wing'" , "'Bajpai, Vaibhav'" References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> In-Reply-To: Date: Mon, 8 Jul 2013 12:09:08 -0700 Message-ID: <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIXCU6jT4cMGJNJtxQq2Q1ZGNZftwD9dmt6mMIX4gA= X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: v6ops@ietf.org Subject: Re: [v6ops] Measuring the Effectiveness of 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, 08 Jul 2013 19:09:24 -0000 Dan Wing wrote: > On Jul 4, 2013, at 6:02 AM, "Bajpai, Vaibhav" > wrote: >=20 > > Hello, > > > > I would like to request a 10-minute presentation slot at the = upcoming > > IETF 87 to present my PhD work: > > > > Title: Measuring the Effectiveness of Happy Eyeballs > > Authors: Vaibhav Bajpai and J=FCrgen Sch=F6nw=E4lder > > URL: http://tools.ietf.org/html/draft-bajpai-happy-00 > > > > Abstract: > > > > The IETF has developed solutions that promote a healthy IPv4 and = IPv6 > > co-existence. The happy eyeballs algorithm for instance, provides > > recommendations to application developers to help prevent bad user > > experience in situations where IPv6 connectivity is broken. This > > document describes a metric used to measure the effectiveness of the > > happy eyeballs algorithm. The insights uncovered by analysing the > > data from multiple locations is discussed. >=20 > I noticed when this was published and presented earlier at > https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf. = It's nice > to see it published as an Internet Draft, but disappointing that the underlying > Effective Measurement is testing something other than Happy Eyeballs. It doesn't even acknowledge that the target nodes differ. DNS resolution = of a name does not tell you anything about deployed topology. >=20 > Happy Eyeballs is doing what it was designed to do -- provide a good = user > experience when the IPv6 (or IPv4) path is down. However, = draft-bajpai- > happy did not evaluable how well Happy Eyeballs handles a broken IPv6 = or > broken IPv4 path. Instead, what draft-bajpai-happy measured was how = well > the selected path functioned. =20 Well, it offer an ROFL moment with=20 "will never use Teredo IPv6 unless IPv4 connectivity is broken" clearly lacking the understanding that IPv4 is required to work for = Teredo to function... > Happy Eyeballs biases its path selection > towards IPv6 by design (150-250ms timeout is suggested in > http://tools.ietf.org/html/rfc6555#section-5.5). The justification = for this > delay is explained in "Delay IPv4", http://tools.ietf.org/html/rfc6555#section- > 4.1, and was consensus of the working group primarily because it (a) mimics > the long-standing IETF view that IPv6 should be preferred over IPv4 = (b) > reduces connection attempts on servers and (c) minimizes the harm to = IPv4- > only devices sharing an IPv4 address with the dual-stack client (as = those IPv4- > only devices cannot use IPv6). =20 If the IPv6 path is not given an automated preference the traffic will = never move. Even with emerging deployment on 'services', the cache topologies = are not identical in every instance, and getting them there requires demonstrated traffic. People continue to complain that IPv6 traffic = levels are low, but they will continue that way until ISP's and content = providers make everything identical between the protocol versions. Given that many = use lack of traffic at other sites as an excuse for not doing their own deployment, breaking the stalemate requires a bias. > Happy Eyeballs' algorithm differs from Apple's > algorithm (introduced in OS X 10.7) which uses whichever path connects first > (for details see http://lists.apple.com/archives/ipv6- > dev/2011/Jul/msg00009.html), which I expect would result in better = results if > tested using the test methodology of draft-bajpai-happy. However, = even > with Apple's algorithm if a path connects quickly but the path = performs > poorly (e.g., low bandwidth) the user experience will suffer. Happy Eyeballs > can perform similarly to Apple's algorithm (but not identically) by setting its > connection delay to 0ms. Apple's implementation is "not helpful". They start by refusing to allow modifications to the 3484 policy table to meet local policies, then = follow that with a refusal to ack that the IPv4 cache nodes are generally = closer to the request than the IPv6 ones, so traffic stays on IPv4 when it could & should have moved. Anything less than a 100ms delay for the IPv4 request = is essentially guaranteeing that the traffic stays on IPv4, until the cache topology catches up, which will never happen if the traffic loads can't justify it.=20 Tony From internet-drafts@ietf.org Mon Jul 8 23:03:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA321F9F62; Mon, 8 Jul 2013 23:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 l4pp44SxMc6r; Mon, 8 Jul 2013 23:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E944621F9F6F; Mon, 8 Jul 2013 23:03:31 -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: 4.51.p2 Message-ID: <20130709060331.32476.56863.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 23:03:31 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-02.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: Tue, 09 Jul 2013 06:03:50 -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 : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-02.txt Pages : 19 Date : 2013-07-08 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) and NAT64-FE (NAT64 server Front End) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Mon Jul 8 23:41:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57C521F9F76 for ; Mon, 8 Jul 2013 23:41:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvfoBlWVqLHK for ; Mon, 8 Jul 2013 23:41:31 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8821F9F6F for ; Mon, 8 Jul 2013 23:41:30 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so2844171qeb.18 for ; Mon, 08 Jul 2013 23:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=L9Qs68EqR/LRRqUFVRF3q0zxhUyW77E59mjHh39KHH0=; b=oH7TEujy/u6Ygcg8QBLpVUOclyeQYcInqx2W+eYs4V4PdZSrtz4kwy768flREwhcNp HyP+A3KsNbCRcMpEOMw1JO1kwdr9arbYPjEHtci3w6qKejbDxO87Dg2RY3RVhGfNjb3J 6USZVB5LCN8lNPeeSHtGHpduy4WJesq4DLA09DT2TxZmur6JAE9wiqrxwU9eCvMSTJZe Df1ekH0PpI8VzE6/awgSylf1HbDyCypxPbIDWGaMWVFbgfM7llAycOqtdZnEmMOgYBB1 jpatO8XQ7KCqVrdlrpnynznGjJq0Y/+l21Rde4JeyFBO+9VlOuTrc86hxY/0dgr3j602 7Gmw== MIME-Version: 1.0 X-Received: by 10.229.184.1 with SMTP id ci1mr4571910qcb.88.1373352090352; Mon, 08 Jul 2013 23:41:30 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Mon, 8 Jul 2013 23:41:30 -0700 (PDT) Date: Tue, 9 Jul 2013 14:41:30 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] New updates are available for draft-ietf-v6ops-nat64-experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 06:41:31 -0000 Wg, We just finished the updates on draft-ietf-v6ops-nat64-experience. The latest draft incorporates all the comments during the WGLC. You may find the following changes to echo reviews on the mailing list, including 1) Restructure the document for better readability 2) Share several testing results to better convey the experiences. 3) Improve the discussions on several aspects of NAT64-CGN & NAT64-FE deployment, including networking location, redundancy, Geo-location, Quality of Experience and MTU considerations. It would be great if the draft could receive your further reviews/comments Many thanks for your kind helps Best Regards Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 08 Jul 2013 23:03:31 -0700 Subject: I-D Action: draft-ietf-v6ops-nat64-experience-02.txt To: i-d-announce@ietf.org Cc: v6ops@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-02.txt Pages : 19 Date : 2013-07-08 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) and NAT64-FE (NAT64 server Front End) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From fred@cisco.com Tue Jul 9 05:45:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4621F9B4C for ; Tue, 9 Jul 2013 05:45:13 -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 RFNSPfhvMUWZ for ; Tue, 9 Jul 2013 05:45:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A794F11E8111 for ; Tue, 9 Jul 2013 05:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1373373908; x=1374583508; h=date:from:message-id:to:subject:cc; bh=MEOQzjmE1qNylBbHFR/arkEQqCl+SgGn74r7hnTIEuo=; b=Ep0ySdxq5VToog3Y6Kqf7JXpeu1py22rTtYMfXZjN5h9B+jzO6vCLMh3 I6wR6WK/42X8h3ecSAQ4g+1dXfDtraT2BpklkQgQK9uwcn5ZmzZNX44yP 5LMsxxSHBb6WEfZwUi3b7VyYkygjbFhNKfmsYw/MsIdDYSMtHLFMP1idD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqknALIE3FGrRDoI/2dsb2JhbABagwkygw6sUAGLG4ZSAwEDAYEXFnSDIzwtB4hvDboLjlmBEh2DXAOJJY9XkB+DMQ X-IronPort-AV: E=Sophos;i="4.87,1028,1363132800"; d="scan'208";a="83023204" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 09 Jul 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r69Cj0dh020198; Tue, 9 Jul 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r69Cj0Q08784; Tue, 9 Jul 2013 05:45:00 -0700 (PDT) Date: Tue, 9 Jul 2013 05:45:00 -0700 (PDT) From: Message-Id: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:45:13 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please take a look at it and comment. From amunoz0481@gmail.com Tue Jul 9 08:22:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A3E11E812A for ; Tue, 9 Jul 2013 08:22:16 -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 6lhxZR10FHsE for ; Tue, 9 Jul 2013 08:22:15 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDD621F9DAD for ; Tue, 9 Jul 2013 08:22:15 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so6399408qab.18 for ; Tue, 09 Jul 2013 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Sw2/BNjSTmUFlKLOoDRYhcrfpRtgj5Jufr8siO6Cjpc=; b=VbAjolXu8GVBegj1r3sm4fOiMK9U5p71oYcQ3BtG39VYMz7T5Nko8LIbwuKP3Q65Qd fT9z1Nc+cCk9IM1Bj+PakyOLIqa4KhTap19JoWASLyuzuR5IbvzPCAWgMKBkNy55/bCU Uqx/xjW1eBa4+CQadBb+qE/Im3FcgikyWQwyhA3xILCRJFN7DJkz1gFUyH9Fd5U2xVAO ZHf1/8TazpgCG9T+ujfq+GQWjMjyb7ysQjklL8uqlctHtAZe1ROxNHx1TBGnBYYHaE9z wt2y+24Kt6Ax10uhMlvKzYbTITqEGVHnX/76bCUizTR6UoMNLGd+wFfhFQwaYRt0J8vN XI7A== X-Received: by 10.49.74.227 with SMTP id x3mr21128173qev.29.1373383328567; Tue, 09 Jul 2013 08:22:08 -0700 (PDT) Received: from AMUNOZPC ([190.248.91.138]) by mx.google.com with ESMTPSA id ng3sm18729830qeb.0.2013.07.09.08.22.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 08:22:07 -0700 (PDT) From: "Alexis Munoz \(Gmail\)" To: , References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> In-Reply-To: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Tue, 9 Jul 2013 10:22:05 -0500 Message-ID: <0bb001ce7cb8$131ff050$395fd0f0$@gmail.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: AQHwgwRG32rBIwZ6GllqIvRvPxrLhpkYaboA Content-Language: en-us Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:22:16 -0000 It looks so interesting. I will check it and I will give you my comments very soon. Thanks, Alexis Mu=F1oz -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of fred@cisco.com Sent: Tuesday, July 09, 2013 7:45 AM To: v6ops@ietf.org Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. = Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From dwing@cisco.com Tue Jul 9 10:04:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52421F9E96 for ; Tue, 9 Jul 2013 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.182 X-Spam-Level: X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 S3VJzbafVQ2S for ; Tue, 9 Jul 2013 10:04:53 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF7C221F9EB6 for ; Tue, 9 Jul 2013 10:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1373389493; x=1374599093; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kn0+bm0DkpTe/OhAPl8QNjFjvaF1Fg9ycT5mq503gGQ=; b=Dg+DjAkmSCAvS5S674+lOVemZmW0aGeGIvqfRJC0H/0Ed5Erfrd174ZM fqiriOhlWp4ue5t3/bhmC7aR5Pl1HlFSwSQJ/gposN7KGDuyu6q9s8wNo pRQDIv7oH/unjaYxZGjohaQ5PffAUmsmS142qYgJQoZk5n2hyjYvrJLBv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAKdB3FGrRDoJ/2dsb2JhbABagwkyR8EYgRkWdIIjAQEBAwEBAQE3LQcLBQsLEQMBAi8hBigIBhMJEodiAwkFCAWxXA2IUY0AgjgzBwaDA2kDiSWMR4FngSmKegOFIoMxHA X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="85614570" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Jul 2013 17:04:48 +0000 Received: from sjc-vpn3-1420.cisco.com (sjc-vpn3-1420.cisco.com [10.21.69.140]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r69H4lra010693; Tue, 9 Jul 2013 17:04:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Tue, 9 Jul 2013 10:04:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GangChen X-Mailer: Apple Mail (2.1508) Cc: v6ops Subject: Re: [v6ops] New updates are available for draft-ietf-v6ops-nat64-experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 17:04:58 -0000 On Jul 8, 2013, at 11:41 PM, GangChen wrote: > Wg, >=20 > We just finished the updates on draft-ietf-v6ops-nat64-experience. The > latest draft incorporates all the comments during the WGLC. > You may find the following changes to echo reviews on the > mailing list, including >=20 > 1) Restructure the document for better readability > 2) Share several testing results to better convey the experiences. > 3) Improve the discussions on several aspects of NAT64-CGN & NAT64-FE > deployment, including networking location, redundancy, Geo-location, > Quality of Experience and MTU considerations. On geolocation of a shared IPv4 address, I would prefer a citation to = rfc6967 (which analyzes several solutions) rather than the individual = document draft-chen-behave-nat64-radius-extension (which details one = specific solution). -d > It would be great if the draft could receive your further = reviews/comments >=20 > Many thanks for your kind helps >=20 > Best Regards >=20 > Gang >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 23:03:31 -0700 > Subject: I-D Action: draft-ietf-v6ops-nat64-experience-02.txt > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-02.txt > Pages : 19 > Date : 2013-07-08 >=20 > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) > and NAT64-FE (NAT64 server Front End) are considered in this > document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rja.lists@gmail.com Tue Jul 9 11:11:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B6321F9B8D for ; Tue, 9 Jul 2013 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 I+F0QA-drluR for ; Tue, 9 Jul 2013 11:11:58 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4383521F9B38 for ; Tue, 9 Jul 2013 11:11:58 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so6545268qab.15 for ; Tue, 09 Jul 2013 11:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date :content-transfer-encoding:resent-date:resent-to:message-id:to :x-mailer; bh=4O7fenVCcBoWeCIn0oF+fA7CGWTYztOQ9QqSw+hGSLk=; b=MzOynu5p1M7vgLe8lxCughg48LQIhs31KhQbOuhaAHUOinags5FumiYHKTtzvT5FVr /6db1b1FUpeQ7GTH6FSxiv484rLjf2gUGqRttbDBdlLr+syURnnwCGx9dx6iwAlezGxx C0dnNRslPIfuHeHM9ctkIV++QgwIDIIG07K7aWtOdYQkZ4c4Ar86m3wixIEcfFCwdK7A tMPRjb9hZ2tDWvXqPwZmcPB3dV780J8Xnt1/0mSjtHSKASJU76geGhv41WNcr++1T7Tq wwbDAGScd5EYh48+NsgROOnScEvaSW62Z6cmRSpZth71MtQL7cGy5M/S49+7bk3tlUbv pCjg== X-Received: by 10.224.115.79 with SMTP id h15mr24203356qaq.41.1373393517668; Tue, 09 Jul 2013 11:11:57 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id a8sm20708194qae.11.2013.07.09.11.11.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:11:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson Resent-From: RJ Atkinson Date: Tue, 9 Jul 2013 14:03:07 -0400 Content-Transfer-Encoding: 7bit Resent-Date: Tue, 9 Jul 2013 14:11:56 -0400 Resent-To: v6ops@ietf.org Message-Id: <1C0DCB6D-18F4-4A16-843C-3822921E5CF7@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) Resent-Message-Id: <20130709181158.4383521F9B38@ietfa.amsl.com> Subject: Re: [v6ops] [6MAN] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 18:11:58 -0000 All, I support the ideas expressed in this draft. In the early part of this century, while working for an equipment supplier that designed their own packet processing chips, I was involved with the design of a packet processing chipset that could handle (even small IP packets) at line rate on 10 Gbps Ethernet interfaces, including parsing the IPv6 header chain and applying L4 filtering ACLs. Adding that ability to parse IPv6 header chains & perform L4 filtering at line-rate on a 10 GigE interface did NOT increase the ASIC gate count enough to change the die size. So there was no recurring manufacturing cost for that feature. As I recall, this implementation could at least parse 128 bytes into the IPv6 header chain. I'm pretty confident that the implementation did not parse any deeper than 255 bytes, and I am certain that it could not parse more than 255 bytes into the header chain. I have heard from several ISPs that a different manufacturer has for some years now (at least 6 years) deployed backbone routers that can at least parse past 1 IPv6 extension header to apply L4 ACLs/filtering -- also at line rate on interfaces operating at 10 Gbps (possibly higher speed by now). One person at that firm has confirmed this ability to me verbally. I'm not certain precisely what the depth of their parsing ability might be. So there are at least two implementations of ASIC/FPGA-based packet processors that can parse IPv6 header chains at 10 Gbps line-rate (possibly higher). I think long term, this capability will be highly desired (and in at least some operational environments, needed). This capability will tend to help encourage IPv6 deployment, because it will help IPv6 L4 ACL implementations perform at a level comparable to IPv4 L4 ACL implementations. This draft provides a significant help both to implementers and operators by providing a specification for a minimum parse depth (i.e. 128 bytes as per Section 4 of this I-D). I hope that this draft is able to move forward as a BCP. Yours, Ran Atkinson From fred@cisco.com Tue Jul 9 17:19:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD2811E8117 for ; Tue, 9 Jul 2013 17:19:17 -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 TCx13KnpzKo6 for ; Tue, 9 Jul 2013 17:19:12 -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 C3D1211E8144 for ; Tue, 9 Jul 2013 17:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2618; q=dns/txt; s=iport; t=1373415553; x=1374625153; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zbeq/snXb3SCvQl3ja1L7XyCm6Ety9fBuUquEhwcgRQ=; b=fx2IopqdeiKFxnYrTfYTsOOWfFjoFa7gPsZofTA3MSemnUge2RI24Zb6 etiOBme1dP0524bzPoYYFCR55yf3SMT68vsp2GK8h3lMni+jcVIX0ROWU /30eW8ESbSHNOy4XxSg2m2ThiUN0lyFfLA2Z8iTsm17b29HDaG8SAvJnw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFin3FGtJV2d/2dsb2JhbABbgwkyTcETgRYWdIIlAQQ6KyYBKhRCJwQbDId7mXygGo86g0FrA5h9kCCDEYIo X-IronPort-AV: E=Sophos;i="4.87,1031,1363132800"; d="scan'208";a="232862942" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2013 00:19:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6A0JClC021532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Jul 2013 00:19:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 19:19:11 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Preliminary thoughts on the agenda for IETF 87 Thread-Index: AQHOfQMZgjmxJ8c34EyU5yoBIng9AQ== Date: Wed, 10 Jul 2013 00:19:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B936455@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <99ACB4776B4F57408C3A599A9760C696@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Preliminary thoughts on the agenda for IETF 87 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:19:18 -0000 As things stand right now, we are scheduled on Tuesday and Friday. Draft status for agenda: The author of draft-ietf-v6ops-design-choices would like to know what peopl= e think about this. If someone wants to help, he's willing to continue, but= is considering letting it die. Opinions? Drafts that are not updated by Monday won't make it to the agenda. There ar= e some I expected we might well discuss; I'd encourage the authors to get o= n the stick. RFC Ed Queue: Mar 18 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat Oct 30 draft-ietf-v6ops-6204bis Nov 14 draft-ietf-v6ops-ra-guard-implementation Exiting WGLC; on its way to IESG: May 17 draft-ietf-v6ops-64share May 26 draft-ietf-v6ops-rfc3316bis Jun 11 draft-ietf-v6ops-mobile-device-profile Agenda: Working Group Document updated since IETF: May 17 draft-ietf-v6ops-ula-usage-recommendations Liubing plans to hold off until Novermber on this. George Michaelson wants to give a talk on measurements ULA visi= bility across the global internet Jul 8 draft-ietf-v6ops-nat64-experience Up for second WGLC in August, due to changes from first WGLC =20 Individual Submission to v6ops updated since IETF: Apr 14 draft-elkins-v6ops-ipv6-ipid-needed May 27 draft-jiang-v6ops-semantic-prefix May 30 draft-elkins-v6ops-ipv6-end-to-end-rt-needed May 30 draft-elkins-v6ops-ipv6-packet-sequence-needed May 30 draft-elkins-v6ops-ipv6-pdm-recommended-usage Jun 4 draft-taylor-v6ops-fragdrop Jul 8 draft-chen-v6ops-ipv6-roaming-analysis Homenet draft that John would like v6ops to look at: Feb 25 draft-grundemann-homenet-hipnet =20 ???? Working Group Document NOT updated since IETF: Feb 14 draft-ietf-v6ops-design-choices Feb 25 draft-ietf-v6ops-enterprise-incremental-ipv6 =20 Individual Submission to v6ops NOT updated since IETF: Jan 24 draft-mlevy-v6ops-auto-v6-allocation-per-asn Jan 25 draft-v6ops-vyncke-balanced-ipv6-security Feb 5 draft-lopez-v6ops-dc-ipv6 Feb 18 draft-ma-v6ops-ipv6-address-assignment Feb 20 draft-smith-v6ops-larger-ipv6-loopback-prefix Feb 25 draft-sun-v6ops-semantic-usecase Feb 25 draft-shishio-v6ops-dpvt Not expected to be on agenda: Mar 27 draft-generic-v6ops-tunmtu Apr 1 draft-yang-v6ops-fast6 Apr 23 draft-gundavelli-v6ops-community-wifi-svcs ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies From phdgang@gmail.com Wed Jul 10 00:38:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB321F9F70 for ; Wed, 10 Jul 2013 00:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 gUPP-pdxbmmX for ; Wed, 10 Jul 2013 00:38:30 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A390521F9DF8 for ; Wed, 10 Jul 2013 00:38:26 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so3576514qeb.18 for ; Wed, 10 Jul 2013 00:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iokwO41sE4bWIzNCfvslrFHPwHxZytUa217PX7abA6E=; b=Vh3dn5Sr/Lw8sGsQULkaf1e7KU7IrBfiIuAmZfLmPN3d7BlON+y02Jqg7JGPD1z881 zY/q969eLpcKUOwomTg/oyCBEXRkmHhlWiEN2crf0txBGWP693e7GgqxfkiiEyzL0I6a Okj6k7t/pOSv7D2O4ry+CYxHEBih+YIqlxeYNTlfhh6hMYANBrGdjHHPHXzR6xUe0ied hguc8VXdiep0UfIZm+j9T/T44YexMY9YZjAhDrMFxM/bSrc9dffaMboc1IWqANwyDesr qYw0j/It9QZlJ7Eu9BuhOVrzSi0yZTlC2vsxofE7Vd5vXG1zM2mPJkeuAg6PetWLPPi4 NBtA== MIME-Version: 1.0 X-Received: by 10.224.212.199 with SMTP id gt7mr27048146qab.80.1373441904481; Wed, 10 Jul 2013 00:38:24 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Wed, 10 Jul 2013 00:38:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jul 2013 15:38:24 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] New updates are available for draft-ietf-v6ops-nat64-experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:38:31 -0000 2013/7/10, Dan Wing : > > On Jul 8, 2013, at 11:41 PM, GangChen wrote: > >> Wg, >> >> We just finished the updates on draft-ietf-v6ops-nat64-experience. The >> latest draft incorporates all the comments during the WGLC. >> You may find the following changes to echo reviews on the >> mailing list, including >> >> 1) Restructure the document for better readability >> 2) Share several testing results to better convey the experiences. >> 3) Improve the discussions on several aspects of NAT64-CGN & NAT64-FE >> deployment, including networking location, redundancy, Geo-location, >> Quality of Experience and MTU considerations. > > On geolocation of a shared IPv4 address, I would prefer a citation to > rfc6967 (which analyzes several solutions) rather than the individual > document draft-chen-behave-nat64-radius-extension (which details one > specific solution). rfc6967 has already cited at the beginning of the section 5.2. rfc6967 didn't include the radius-based method, so the draft-chen-behave-nat64-radius-extension is mentioned to provide a link for the further descriptions of "We have investigated to deliver NAT64 BIBs ...". (BTW, the solution may be useful if geo-location systems are already built on a Radius database). Since that is an individual document, the draft is listed as a Informative Reference. Your suggestion may intend to provide various possibilities for operator's deployment. So I propose following changes. Please kindly check. OLD o The NAT64-CGN equipments may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. It's desirable to offer geo-location system more information, for example port number to retrieve the internal IPv6 address, which has meaning in global scale. We have investigated to deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius server[I-D.chen-behave-nat64-radius-extension], since current geo- location systems rely on a Radius database to inspect location information, for example the information provided in [RFC5580]. Those methods could convey original source address through same message bus. Another approach is to ask NAT64-CGN providing application aware gateway to insert IPv6 source addresses. However, that may introduce complexity and performance degradation. New o The NAT64-CGN equipments may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. [RFC6967] analyzed several options to reveal the host identifier. Each one may have their-own specific usage. With regards to NAT64 deployment, it's desirable to offer geo-location system the internal IPv6 address, which has the meaning in global scale. For the geo-location systems relying on a Radius database[RFC5580], we have investigated to deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius server[I-D.chen-behave-nat64-radius-extension]. This method could get along with [RFC5580] to convey original source address through same message bus. BRs Gang > -d > > > >> It would be great if the draft could receive your further >> reviews/comments >> >> Many thanks for your kind helps >> >> Best Regards >> >> Gang >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 08 Jul 2013 23:03:31 -0700 >> Subject: I-D Action: draft-ietf-v6ops-nat64-experience-02.txt >> To: i-d-announce@ietf.org >> Cc: v6ops@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >> >> Title : NAT64 Operational Experiences >> Author(s) : Gang Chen >> Zhen Cao >> Chongfeng Xie >> David Binet >> Filename : draft-ietf-v6ops-nat64-experience-02.txt >> Pages : 19 >> Date : 2013-07-08 >> >> Abstract: >> This document summarizes NAT64 function deployment scenarios and >> operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) >> and NAT64-FE (NAT64 server Front End) are considered in this >> document. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From swmike@swm.pp.se Wed Jul 10 01:01:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902CE21F9F5E for ; Wed, 10 Jul 2013 01:01:15 -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 EvumPXVGwuJn for ; Wed, 10 Jul 2013 01:01:14 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A399A21F9C00 for ; Wed, 10 Jul 2013 01:01:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A07AE9C; Wed, 10 Jul 2013 10:01:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 93F4F9A for ; Wed, 10 Jul 2013 10:01:12 +0200 (CEST) Date: Wed, 10 Jul 2013 10:01:12 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: 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 Subject: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 08:01:15 -0000 2013/7/10, Mikael Abrahamsson : > On Tue, 9 Jul 2013, GangChen wrote: > >> Hi Mikael, >> >> Thanks for the message. We are also doing the NAT64 testing recently. >> Some experiences have been documented in >> http://www.ietf.org/id/draft-ietf-v6ops-nat64-experience-02.txt >> Not sure if you have interests to read and comment > > 1. "Single stack IPv6 network deployment can simplify the network > provisioning. ". I would remove "the" frmo this sentence. > > I think it's good that you stress the benefit of having access being > single stack instead of dual stack. > > 3.1 > > I think it might be beneficial to say a little bit more here why 464xlat > is important, perhaps just one sentence "464XLAT enables access of IPv4 > only applications or applications that call IPv4 literal addresses" (or > similar). > > About geo-location, perhaps it can be adviced to chop up the outside IPv4 > address pool so that IPv6 addresses are NAT64:ed depending on their > geographical location (we're doing this on a per country basis). > > 5.1 > > I would like some text on "port block allocation", where a customer gets > 512 or 1024 ports, this is logged, which means as long as the same > customer still has this 512 port block, no further logging is needed. > > > > Apart from that the document looks good, and nothing more came to mind > when I read it. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From lorenzo@google.com Wed Jul 10 02:24:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204D211E80D5 for ; Wed, 10 Jul 2013 02:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 7HafKJG-prDD for ; Wed, 10 Jul 2013 02:24:17 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 71CAB11E80F6 for ; Wed, 10 Jul 2013 02:24:17 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so5442066veb.22 for ; Wed, 10 Jul 2013 02:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BH/4iyVJMd05N56OlpnaioG89Jq7rz3K0NKzTc5JUlg=; b=WRvGTnaZmsP3soRs39gJmcyg3kI+/gR9DQHOtzfQC6bX5YrJU39yvph1QFd6JPyb8d YMnEicb491SzHd/HXXut3Uj+tYKNkdtOIPB69ZZoluSvD/kZVS9IR6L8jzOlO03PG1a0 AxpcL/MmaJEkDmgK3GqUordEyAAX3LH8aKNYiD8PKVDOcIBrz+6m9SoLPJS/W/xpKDjF byNriwQbC0NcKk5uMUESgK3fIH9Jy1GtbuLbJZTR0liDZz/aL5jdFXALQlkPPI8pVEFO 6zG54me8qxSPG4ThBP32x+7Ncklhdq/e3QQ7dl7/5TRxL3GVHqNwrDZZ79HXOjiSvjkH AbeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=BH/4iyVJMd05N56OlpnaioG89Jq7rz3K0NKzTc5JUlg=; b=LpEfyCAX4nF0mmKj9CpmZ68J/5DAMiFmZcgv+do63KZL1fUpcNKggCmaox53BD/gJ0 y38GtJlvAvT5W7T4oV6ETCtF/75Z55YnhP/84pC2iSq3JQKLP12g+D4wgA/WKTJWTYGr uOlVOzAIpq+8TxPQJLi+knlb2iLKW2iiRg9QE8e9xON0mruZoKi6XBvFvNOHw1PsGxPx 38jcgukxTzBXp+Rur5vdNif+74WhtjSZrc+JCcTvAThTYzLJOO6oY+sdxb+xKgYcTSbl CaC8Lxlmi/RPTRrtE3UWjpHDcHROMq1v2DAsWxAv7yKoND993/rlk+hPViHiQAP0UyBs 7SOw== X-Received: by 10.220.143.140 with SMTP id v12mr18463128vcu.95.1373448256782; Wed, 10 Jul 2013 02:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Wed, 10 Jul 2013 02:23:56 -0700 (PDT) In-Reply-To: <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> From: Lorenzo Colitti Date: Wed, 10 Jul 2013 18:23:56 +0900 Message-ID: To: Tony Hain Content-Type: multipart/alternative; boundary=047d7b342f4476d79304e124d7fa X-Gm-Message-State: ALoCoQm4Dk7xXwgrml/0Ig3WOQU5Jw64slWsZwwRK85q+xXg+QVrCmHsMnkB5BfVlsCHF4cgpopOtvBYCJ4oF11QmAQpRrkKzuco7oily7+7aOPqohJE+rxLqLtiEqsaDyUptH87WK3Nvvl/8syPrDMgw4I6MFGdQwKwrnJrVyheZIluxsmW319lZtnHBxSoRWXnD0PSI/8n Cc: "Bajpai, Vaibhav" , "v6ops@ietf.org WG" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 09:24:18 -0000 --047d7b342f4476d79304e124d7fa Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 4:09 AM, Tony Hain wrote: > If the IPv6 path is not given an automated preference the traffic will > never > move. Even with emerging deployment on 'services', the cache topologies > are not identical in every instance, and getting them there requires > demonstrated traffic. Actually it's worse than that. Even when topology is congruent and IPv4 and IPv6 have exactly the same latency, a "use the first connection that completes" implementation with no preference will use IPv4 50% of the time, just due to statistical noise (introduced, if nothing else, by hashing along the path). > Apple's implementation is "not helpful". They start by refusing to allow > modifications to the 3484 policy table to meet local policies, then follow > that with a refusal to ack that the IPv4 cache nodes are generally closer > to > the request than the IPv6 ones, so traffic stays on IPv4 when it could & > should have moved. They also bias in favour of IPv4 because they send the A query before the AAAA query (or at least they used to). --047d7b342f4476d79304e124d7fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 4:09 AM, Tony Hain <alh-ietf@tndh.= net> wrote:
If the IPv6 path is n= ot given an automated preference the traffic will never
move. Even with emerging deployment on 'services', the cache topolo= gies are=A0not identical in every instance, and getting them there requires=
demonstrated traffic.

Actually it's wor= se than that. Even when topology is congruent and IPv4 and IPv6 have exactl= y the same latency, a "use the first connection that completes" i= mplementation with no preference will use IPv4 50% of the time, just due to= statistical noise (introduced, if nothing else, by hashing along the path)= .
=A0
Apple's implementation is = "not helpful". They start by refusing to allow
modifications to the 3484 policy table to meet local policies, then follow<= br> that with a refusal to ack that the IPv4 cache nodes are generally closer t= o
the request than the IPv6 ones, so traffic stays on IPv4 when it could &= ;
should have moved.

They also bias in favour= of IPv4 because they send the A query before the AAAA query (or at least t= hey used to).
--047d7b342f4476d79304e124d7fa-- From ek@google.com Wed Jul 10 02:49:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708021F9FFE for ; Wed, 10 Jul 2013 02:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bBRDBhRD9icF for ; Wed, 10 Jul 2013 02:49:12 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D871F21F9F90 for ; Wed, 10 Jul 2013 02:49:10 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ep20so1176130lab.9 for ; Wed, 10 Jul 2013 02:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bx858DKYxdmKfAv1xf2sao5SSs4sY7/BqoS01Qx/PBY=; b=S//vJ7Lwr2z+3zRqP6oBuTeOczPX65AUzGNz+CBEIqzlu9siyrhjVW0cbUMMtcHQrH 05CL3MSgX2LwckKTV+YSOufV5q4WgIq5V2OhflwqVGxWsOvLmXmsGfEQe7VEiA+XmT/U NeLeM9jPGPIJSRSEqa54tW9lc7Cn8mENGSsgR0ewi+LHFCc7aCCkTwpINm0t82vEhp1d w+KfmNuj6bkFNUemIcYrr7UGKszAxwK3hz7j3TRP0eC8OiJGqT0x4R8bzu3WKrQNSjji Dkq8QsCpyEvXqLtjkGItI+BXPbqhP7/XFoM/0ZhZlAnC6f8TaCKRBNCftVL3gdEK1QmA 3fFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Bx858DKYxdmKfAv1xf2sao5SSs4sY7/BqoS01Qx/PBY=; b=P3xzRDnkQLd8Ola7tVRhWoUxbwxKB2GqZv8plxIYKJUJbtwUO2vUjOLS3i/2XOLRsX xVthxHwwMKg9qVEtVFMJ1nQx/9M8i4UtzqhCZuYjjBimqONqGWbnpD3mqziEaCaSu9dQ w7EKzNCt7Cn2zIA9NjOqgEv+st86ccsyWhkDXKgn/sxcV4KRYrNd7tV/jAvoORwNwLg8 D1UqwZ+jWbEP+BQM8r1Z+15bZZyuHu+FNo0kABVV2V0FsqfymslYx5AxUt/Rw4C6xaEw R+87T9M8l2b49kfZy1DmhlXR32qA9OlhfItGRbPa16aFB32QWMmy+KNkl+1QPMnqg9Q/ 585Q== X-Received: by 10.152.27.40 with SMTP id q8mr14471796lag.75.1373449747679; Wed, 10 Jul 2013 02:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.30.195 with HTTP; Wed, 10 Jul 2013 02:48:47 -0700 (PDT) In-Reply-To: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> From: Erik Kline Date: Wed, 10 Jul 2013 18:48:47 +0900 Message-ID: To: Lorenzo Colitti Content-Type: multipart/mixed; boundary=089e0158c5aa53ecbb04e125303c X-Gm-Message-State: ALoCoQkL23IMXh50DmaCdFjYmUKyhXw7Co92AOytBrC+/MdJ3hchkflUnWk2ks76LOO+lArQpkp+ffQ8lJ83XenOSkfAkqRp2yR7b4DAal0JPXBNjpgkuozfIUo7RvGKM+fHYr7lJXjQQtVw+D0jHNiUpYUizXdLX6I3dwqaUxplb4kIC5W7sJYmJPbhYO7NDF6kLpZufP5G Cc: "Bajpai, Vaibhav" , "v6ops@ietf.org WG" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 09:49:12 -0000 --089e0158c5aa53ecbb04e125303c Content-Type: text/plain; charset=UTF-8 On 10 July 2013 18:23, Lorenzo Colitti wrote: > On Tue, Jul 9, 2013 at 4:09 AM, Tony Hain wrote: >> >> If the IPv6 path is not given an automated preference the traffic will >> never >> move. Even with emerging deployment on 'services', the cache topologies >> are not identical in every instance, and getting them there requires >> demonstrated traffic. > > > Actually it's worse than that. Even when topology is congruent and IPv4 and > IPv6 have exactly the same latency, a "use the first connection that > completes" implementation with no preference will use IPv4 50% of the time, > just due to statistical noise (introduced, if nothing else, by hashing along > the path). > >> >> Apple's implementation is "not helpful". They start by refusing to allow >> modifications to the 3484 policy table to meet local policies, then follow >> that with a refusal to ack that the IPv4 cache nodes are generally closer >> to >> the request than the IPv6 ones, so traffic stays on IPv4 when it could & >> should have moved. > > > They also bias in favour of IPv4 because they send the A query before the > AAAA query (or at least they used to). Some data. Here's a slide from my presentation at the IPv6 congress in Paris this past March. The pink is % of connections that arrived over IPv6. The client population is a set of gigabit FTTH native IPv6 users, where IPv4 is provided encap'd within IPv6. The mapping between clients and HE implementation is basically: Nexus 7: basically a special subset of Chrome (below) MSIE on NT6+: the well-known IPv6 probe on network attach Chrome: still the 300ms head start from just before W6D in 2011 Safari on OS X 10.[78]: connection racing Even when IPv4 is provided as an encap'd service in a native IPv6 network you can see that connection racing does not help the provider obtain much of the return on investment in IPv6 that might have come from migrating traffic away from IPv4 (e.g. in a CON environment). --089e0158c5aa53ecbb04e125303c Content-Type: image/png; name="IPv6 Measurement (World IPv6 Congress 2013).png" Content-Disposition: attachment; filename="IPv6 Measurement (World IPv6 Congress 2013).png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hiyc2m0u0 iVBORw0KGgoAAAANSUhEUgAAA8AAAALQCAIAAADQFY7jAACAAElEQVR42uzdaXQc533ne5+5b+67 OdcnTnLvmcw5yc3EuXaSk0wcJ7LjeHfGdpxkrFiJJ3Ei27EndiTLlmxZsq1YlmVZEimJG0gQCwkS ILjvK7gBIEAQAEEAxEISG7HvawO9o7vq/quexsNib2iAQAMgv79TBwdodHdtTz/1qaefeupd04QQ QgghhJCU8y42ASGEEEIIIQCaEEIIIYQQAE0IIYQQQgiAJoQQQgghBEATQgghhBACoAkhhBBCCAHQ bAJCCCGEEEIANCGEEEIIIQCaEEIIIYQQAE0IIYQQQgiAJoQQQgghBEATQgghhBACoNkEqzDl3ddf vLpOT7+o3jo4McxmIYQQQggB0AtOa7frWNnEpsPjL2wf/mGmNf1058j2E+NnKyc7eqcegv1RP9D8 9aIXfy33z/5T1nvftf2/ySS/5J4rHB8fp7ASQgghhADoVDMwMr3t2OgX/6P/j7819NhT/Z/7Qdtf //C2TJ//QcuHnuqVB9X0uRf6XysYvdm6hiU9MjLS2NQs03uy/0QB+rdzPjnlclFSCSGEEEIAdEqZ nJrecmT0Q08Pio+/9KOG9TlXKipr7rS0dnTclamlta3qel1Gfvk/vlT3gW8Pakn/77cG1zSjJe/J /qAC9O/nfY5iSgghhBACoFNKa7frSy8PCIg/8p3ud3Ze6erqTvTMgcHBrL1ln36uXRv6T58abG4f A9CEEEIIIeRRAXRT+9THn7X6bHzq2btFxTdS6cZQWdP4xRea5SV/9lT/hryyiclJAE0IIYQQQh4J QHf1uz7zgz6h8Iee6j15sS71FxacbhU9Z+2rnFzLegbQhBBCCCEAemH56i8jlwa+mlWzoBe+mdeQ f7jyIbjqDkATQgghhADoVHPw8rDS8ye/d7e3f3BBr13rDc8AmhBCCCEEQC84n3sh0vz8H9salm8u U339o5euDBUcGj50YuzaddfEAuU93ODqPuNq3WH9HG1ZKUC7RkbHyqtGjp4ZKbo80dJGgSaEEEII eeQAfb56VI+kcb586UUoUB7atf/2R/+2+d3vrX/fn9e/90PN//m/WdOv/377v35voqF5npePdUzU vjh6+ndGT/6XvhN/MHziv06c+L9kGjn3B5NNb7umRpO8dmzcdb568rWC0W+sG/jKa3Gm57b0194a ThHQ49dr2574RtN73tfwmx+Un2otbj/2uZGTReoJXd3dpVfKGhoaW1pbW1pa29rgNSGEEELIwwjo H269q/T8wX8fWPLb74mPhZiN73nfhSefunL+srplSenRUyWf/XsFUJFo35bcRC+fvJMzeuo3uo++ v/TEG9drauW1tXX1pSfX9xz93TlG/6FrKP4lj4UXxj7+7MD//FH7d9+48p3XrzpH3PviC03/9mrF 99eXVdfU697byQHd9dLrcgJw5VN/V7z3UP3Nhmul5ReeebHhV9+v1qJ73Rb1tPqbN8XNzbduAWhC CCGEkIcW0H/1Qpdi5Se+17207zxe29D0m3/S9O73XtywLYrmvX19JV99OtIU7QCoM2M31wmR7x79 w5t1VVH/qrtR2Xnk9yOGPvlbUYaenJp+ZrM1mvVz66va2zvkEVFyY/Odf3m5Vq3ph54eKL8Z3YEk CaDbn/6RLOSVv/4nWex7c5mcLNmwTdZOrcLA0dPWMzs6+vr6urq7B4eG+hxPJoQQQgghDw+gH3uq fzkAPdXX3/g7j4ksy/7u63EvNOzvH6j6wGcihn73e4cvlNyH79ZC5eO6ikNx37+24ujYiV9Rzxk8 8yfTrgn9r3WFA/YFkZ1DQ8P3Ofhu118+1xZZ2Wf7BkZSAnRfwUFZwoZf//2OW3eilkHWq+rPPqtW oeEDn6ZwE0IIIYQ8EoDWHRuWFtB3vvV8pJPGsTOJnnNjzyHdCN3w3z917x8TfSMnf1Nk3HnsjxKN 8jHlct089iUFaJmGb76lHu/onfrgU9Y9xr/1Rpze1TsON+r13Xyod15AuyYmG373w7J4VZ/6uzjL 0NVT/3sfU7wu/ZuvTI5PUL4JIYQQQh4hQH/46SXrcmA1P89dZjdyfzOwMxOTk9d//6Pa0MNXI101 BmvXKRa3nvrrJHO5XXNUA7r/1B+rB9fv6Var85PMOCN1jIyMfPSZyBOe/EXHvIDuPXZGLdv1bz7n fPLYtevt//q9pve8T5a/6NvPV5VVDA0PU7gJIYQQQh4tQMvU1r00bagduXs0i5M/s+p/P6ef2fTi q+rB7rOfVCxuP/t3SV4r/u479tva0FNjnfLgv74euVjwW+va477qa6/eUk94/Cft8wK68bs/UctW +9QL03aD9PChE3f+8u+bfu33ij//5QsZObdu33kIbiJDCCGEEAKgF5BPPXdXA3r36aVphG6Y678x L6Ab8/frZ9Y+/jX1oB6rLjmgJS0nv3CvEfrWEXnkn3/eqtblcz+M3yPlx9vuqCd8+eXWeQEti6SW re5//H3fuozmj/xN7R9+ouibz127eHloiCZnQgghhJBHEtD//MotDeiv/bIzxVdNTk23drtip65+ qzm29otf1SwevZ3spic9jc36mTf+55PqQW3irtOfSL4Yty/+QD+5p/GAPPKDTbf16jS0xmlQf2l7 RNi/yG2cF9CySJFle+zz9Tcbautu3mlpfWhuvkgIIYQQAqAXkw0FzVqcf/LtwY7eqXlfcrZy8nMv 9Dv7fqjpY9/rO158V55w/V/uDVHXWXAwyVtNuVz6mdf//hvqweHj/0/k0sAT/zX5krRXrNOA7m46 JY+cunxHL88zG+M0Qv/7+g7518e/29XW3j0voPWKNP7K/+eiyZkQQgghBEBL7rT3/NlT9zT8/Lae 5M8/fLH7F1nXf7Kp7PXtJZt3l//Lzxr0a1/aWqc6BNe+9o5mceO3f5j8De+1QL/8pnqk49hjmsUT AzeSvLbj2nr1tLHj7xnqt5rPJyYnv/rKTb1IJ8ruG3+6qd0ao+Mj3+k+fKYm6q3iArru9Y168drf 2EzxJYQQQggB0Fa+9fpNZyN0RcMCLiXUPSJk2nYocllee1WNvsPIzd/+M9dEwj4PrpHRyBWE735v W0VkFI7Gc9/RgO6teDHJ3O9WvKaedufovc4e7Xe7vvxSg16ddftGb7ZOCZ3zzo3/xXcHPvXs3eNF 12PfKi6g269V6xVp/K0P0ghNCCGEEAKgrdQ2tn/4O73awZ/+QZ/qyrxoQE+5XBWf+KJuu+3bezjR y/uKLqvnXP3sl/VwFm23KseOv2fuRoO/6ZoaTfTyzgtfUU9rLL/vfuDdPT1v7Sj9h5/c/MT37n78 e11//p1IE/uHnuotqWiI+1ZxAS2LdO2jf6NXpOVfn6UEE0IIIYQAaCsbd1c5ezN//sX+FA0dF9CS m0WXGn71/ZG229/7C9dIfAQ32Z2M63/jj5qu3ne/7uvH/103Qg/V/Cz+vCf6Rk78F3lCw5EvRN0q XKW3r6+xqbnmRt0/v9KilvAf/iPhFY2J7kR44+hp3QgtU9fL6yjEhBBCCCEAeloA+sMNlU5Df/aH fbV35r+gMBGgJcW/eFvTs+Ur/x772pGLpc3vfq84u2xrbqx9mw9/QgF6/MSvTPUUxb58qOyr1lB3 Rz7Q0dqUfCEff6ld3ywm0VWSGtDvy/tL5+NTLtflZ36kAW2ty19/Zfx6rfM5ronJkaNnRuoaKN+E EEIIIY8KoKftu/S9tLniA98edPaHfi1/aGBkkYCemJy8+Mt36n/jjyLu/Pw/jtdGiOkaGu59c0vT r/3ejd95rCRnd9x7kXR2ttccelwbeqLhl9OTQ3Mvrxsptf5Vf+jzt5vr5l215965d6Xjx5/tv9oQ bejO0Z7/M+v9CtD/R9Z7v1/2y5zG/UUdVyamJtWWufj0C852aJlu/fdPtz/5TPtXn2n5639ueu+H KrN3TTC8HSGEEELIIwXoabsdeufBq3/1/B1nU/SfPjX4/a2DB4snmtrvuXNs3FV7Zyrj2Pinvx/p PP0Xz3QXnmmLekORcdXl0vP/+G83fvtPI/T8rQ82/e6Hm9/93po/+NjZZ350M2mr7dDQcMnZrJuH PjNy4tcVo0fOvm/s9P87dvL/bj708cunM/v7B+ZdqeGx6eLKTudII3JiUHhhzPmcdWXbP5z9JT19 JOeJT+36pwNXT+onjI6NXcrdXfbRv4lidMOvvr/0M18qP3SM+xESQgghhDyKgFZpaW1bn1P2Dz+5 6URn7CQM/R/fb//nn9a8vKX0wIny2rqbIyMjiVx+s6Gp9OipC29vvbB+84Ut2eVFF2UuKd6RpLev r7q6qqRo95XTb8skv9TUXJcHk7yktdsluP/qGwMf/d6AdVnk93s/8b0u54WSMmWduDekhiy5YP2+ aTjOgBtdXd1XL5Vc2JB57tmfnHvhlQsZOZVXrqaCeEIIIYQQ8jADWqWnp7eisiZrb9lPNpb926sV enrxnSvrc67kHy4rr6huvnU7LjRXML2Dru9vHRTcf+ipvm/8vHpbQVnJlcr6mw2NTc3VNfXffPW6 09BX6icokYQQQgghAHpZMmlnlS/k7U7Xp75vNTl/6tm7J4quxbaIDw0Nr8su0y3r/+vnXZRIQggh hBAA/ejm8f/oExZ/4NuD54pvJjkTyNhTqa6V/OC/0/uCEEIIIQRAP6o5WzGi2pW/8MO25Jf0TUxO /tPLTerJbDdCCCGEEAD9iOblnMhgz4//pH3eJ7+ac1ue+dFnutluhBBCCCEA+hHNz7Ijtxv8yDN9 Y+PzDCr34lZL20+/eZPtRgghhBACoB/R7Dl9Ww+vsX7vYJJnCq8/8Wzfh7/Te72+je1GCCGEEAKg H9GMjIz83Y+btaET3UOxd9D1zfX9jz3Vn32gio1GCCGEEAKgH+nUNrR86ceN2tAfenrwexlDO89O HCy2pl3nxn+4fVge/MLzdw6cvMa9AwkhhBBCADSxbhb41o7SL/2o4UNP9UbdOvEvnun5Xy/Vrc8p a2vvYEMRQgghhABoci89Pb01N+oOnyrP3FO6eXd57v6yMxeu1dbd5LbbhBBCCCEAmhBCCCGEEABN CCGEEEIIAdCEEEIIIYQAaEIIIYQQQpYT0FNTU5OEEEIIIYSQ1PKuvr6+JkIIIYQQQkhqeVcwGHQT QgghhBBCUsu7TEIIIYQQQkjKAdCEEEIIIYQAaEIIIYQQQgA0IYQQQgghAJoQQgghhBAATQghhBBC CIAmhBBCCCGEAGhCCCGEEEIANCGEEEIIIQCaEEIIIYQQAE0IIYQQQgiAJoQQQgghBEATQgghhBBC ADQhhBBCCCEAmhBCCCGEEABNCCGEEEIIgCaEEEIIIQRAE0IIIYQQAqAJIYQQQgghAJoQQgghhBAA TQghhBBCCIAmhBBCCCEEQBNCCCGEEAKgCSGEEEIIAdCEEEIIIYSQ1Qjo/v6B7duz1aQe0X9OT0/r p508eUo/Pu8kT9YvLCkpjX23xUUvw4O81RIuz0LT0tKS+jZUk+ydNC9k2raPvH9sadHFr7Bw36Lf uabmhvOdY0v4khTCqF0z787Nzd1RVHS+s7NzybdkKBQqKyvfvDnj5ZdfkSkvb5cszFqsH/WekkLI 0SLJ7t6//+CTT37tC1/4G5kef/yJ/PwCNgshBECnO6KNP/7jD6pJPaL/dBLhm9/8N/34vJM8Wb9Q juix77a46GV4kLdawuVZhL1S34Zqkr2T5oVM2/aR948tLbr4iQwW/c4iMOc7x5bwJSmEUbsm9Z37 5S//0xLuVrHmZz/7V7Fz+e53nx0bG1u1VeHk5ORLL/00qozpPSWFkKNFosh2i9rXcsrEZiGEAGgA DaAB9MMMaDUdO3b8wRemsHCffsO//dsvPv/8C08++bUPfvAx9cjjjz+R/q9ZUsmlS5c/9rFPxpYx AD1vGhoanWdisqHkTCn9tQQhhADoBQM6P79AHk8+OZu+8vJ2yWtlevD2sLfeevvB32o1AFqUM+82 VFMgEADQawvQotjY/djZ2SnPF+/q1uLHHvvznp7eJfnkfuQjHy0qOq8fl7f9ylf+Rf3rjTfWrcI6 J1EZa2lpUR9wmlQTRapftelee+11tgYhBECvZNrb21WN/LGPfVI9Iod29cjw8HCsG6J6rK65rAZA R5Hx0dw+ywfow4eP6G4M8mdz8y3152c+89k0ADp566mc+2lDP6CBHn/8CfU+VVXVUf+ST676FMtP j8fLZ/ChiT45LCsrZ2sQQgD0Ckcda5988mvqT9V89ZGPfDSuGwA0gF7lgNZi3rBho/wpglR/Pv30 MysOaMmxY8cfHPSC5uSz0z1lV6G0APSDA5puG4QQAL3y+fKX/8l5JFaHN2H0kgBafXktk7M3ghw4 1YPqz8nJycOHj7zxxjqZtRwhEh0bWlpaYt8q6gn5+QWvvfa6GosgtmUu+cFbFkO9v0zyu8BL/S4g S7KCDQ2N8py6uvplBbResFAotKBNrTI8PCxb+K233pbV37w5o6jofKKGyajt097eLltSHpTXyvLP 26dW3rakpDQ3d8fPf/4LeZUQdv/+g3H7KiwC0PLmsuRquAkpLbKv4252LWbdz1g11ipPx26uBTHu wQGtV1ymgB21GFKQ5i1mugDI5lXvkGhYD5mLbBz5mWILtPpw6eE75IWFhfvkoyQzku0sxSD5y+Xz cunSZfnwqpFAZB/Jxnd+heWci5zJqIWXvemsB6R0qT/1SslHL/lH3rS7rOjPbJICIwVYPgKxi5TK mZ5zGeRP2SCyWWTjyCZKVHjUmqp9KuslL5FlUP3fop4pbysnOVu3ZqpSLe8Z9/OilkF/POVpiUrv 2NiYlEYp7eoDKL/HbpnYelgWQ7aPvEQ+vLGjuEipk+pUVQWqSCSqFXV51gsmL1QFQ3aBlIpEC+Ms S87lP3PmbPJqJ+r5SdaXEAKgl6VBSI+FpK5Mivp+edGAjgtW3Y5i2p2kdacRPQnfY2WQ5CJCOVCp 04CoSeQU5ZJEgJajjv5O/PnnX5ADhhwJ1KVOsnhJjkDqJc8994NlBfS3vvWUem1FxbVEz1F9Az7z mc86kS1LLqusLyzTk6xa3NGv9PaR7a+VpifZFHJ8jYt4OcjJ82N3ZaJBIRYKaJlv3Df/27/9Yuw2 UbtS73rZO7FFV6/pgoa3e3BAy4bSC690K6sQ22kqighqD0ohV4+olzxIO33c9ZKfUuzls5/6sB6y zPJ5iS1gMsmDL730U6fgE12LrI0YtQ0FlPNWO+obM5mXc+tJEZWKRX1+oxZJSumCrq3UlZWUWGFu 1JqqN4w9S1FrKjvIWbGo5zvPRmS95AMbu0GkxEYVhkRXozpLryyGbLHYfSEfHDmLiP3Y6lWTnf71 r3/D+RLnFxfyuy6izunJJ78WS239uZY3lzpEd8ePqkMSfTRkY8Zd/rjd4mWxRcyx1YJa3/RfQEII eeQALfWjHLF0i4LUifJn1De/ywRoqeb0hVBysPnkJz+jK0E5rkSxNRGgL126rOtceR85Esgz9VvJ v5zWibs8cuDRFb3Ss3pcS+Lw4SNx106OBOoJqYxc+yCAPnPmrHqtiCRRE7Wz30LsWYFsB1lHmfUT T3xZb2TnykZtHzk66pMQeZXzCBq7DHLkc85InKeuBnMKRh50zmtBgNblJO6bR+1i077WSlZEO0lK iPwZdUq2UoCuq6vXZVU9IjjQV+jGfYkebWP//oPOJnbZfVEN/zLJyi6i37NaL/ns6OZh+QTJXpCF dIIpqrTITtT+E7WoAiZv4nyV6om+OEDr3jhyApnoW5fYuchCypZxnkXLfGXhtbTkkdQvRNaVlX5P WU01/IV+Q1nlKK5pQMvTnGvqLNhvvfW2flzOfqM2nWxYZ4mdF9BSWzo/2upj4mxWkD+jdp9eNeeS RHWdd470IkUi6qMnSxv1LZD+XEstocuGrJ2suFPGsSCOOtNQy+9cI7F11NcLTvSr58uu0XOR/67C CwAIIQ8VoBfkhqUFtDpOyCFf1+ziAF3tRskmLqB7enr1YWzr1kx9GJNf5E9dfevHY5fHWRFHgVIf v+UJcddOsVKOK0l6ViwJoHVzuByx4h4V9Hrp9i1ZJH34lKO4c6PJeuljVVRrkH4ftWuc3WDknEof 3aOKgT7TEH5F0aSo6Lx+lfM0I3VAyzPVQVGW2fnttmwT3UIZ1eNoQSUzzYDWDtPfWgwPD0c1MMdt ZNXfhOgLf+VkSfay7MGoplZ5pqxUKmUyar30Yuj9Lm8iZ48aJVEnilrbztMVc+5mH/pVUe2Uib4F ijuMnSrDUQ3MOvozLnVILEzl4+ncTVIy9cZP/TPorKykJEeVYf05kpkm2p5S/whD5YVyHqjvECTb x1kBOs9Fncsf5fIkfaD1l1RyquD8mMjv+mQ4alQW/W6ynFKEpCDJZ1x+ylZVT6iouKZXXIqBLlGy VCJgtXbyQueucfZQUozW/5Xtr7vmy6uiVi3R8ktR1EcEZ7OO+lpJffadBUxeqz+kjIdICIBeRYBW zTlJpig/JQe0HOlju2rI4UTXpPMC+sUXf6z1nAQrZ86cjbs8Tj1L5R5rDt0EErffSNxj57yAlrVW dxFLPjkPq06k6nVxUlIh1elIPRiFKCd2vfRwELIwzl2mt488Hvv9rCaOvFa/p2xDdQ4jB8W4X47r dnoBxCIArVckbjO/PklYRPfWB/kgLALQwl9nrxjnyYmWaGxvY81l3d6s94KUeWdTa9QU+/VCKusl Wz72DE071SkwkYp2XtwZ6ZWN+gJnQYDWLaBxm+dVGZYzWK0xWSoFO3kwtplZllNv6hTvd+gEdOxL ZBbqyy6ZqXN2envKhyJ2MeRjoruHxe1frg0d1VKbCNCyYFqTsbtPHlHQl4V01rdOQMe9e6X+3ilu zzF9DuBsG3YCOvazINtf16jO8q+lLssZu/zi5qgvInRRift8eURXC2v0rpyEkIcQ0PNOUQfF5ICO qw05Fsb9Hj8W0JpuziOoM3V19fIEqbLVd99Ry+PUcyIE64FXY/vtadGmWEcv9F4bUa282uuxX2fr Dh56NZ2yTHSdmV41532z9fZJtEH0V9L6+CdylSOo7J245zCJYJQ6oPVyOtfOuVnk+CrruKAG1+UD tJhDXUjnnJ577geyO5xfYUd1g9EnjbHbUHdf0c1v+smKbnLuJHtQKU32hbOzeNR1k6msV9ybqEsJ jx3JROQnayGfoEQdnPQ2iWrjXxCg5axDrU5s87x+vpP1sspJViTRuqQC6ESN1vr80DlHvT3jfo70 SCyJBuoWYau1luKUCqB1823cK6edVYSzSOh3c3aAcTb9Jvmv0rA6gZESqKtfJ6DjntPq8uys33TL dFSrgZPyMi+9JPq8MdFZkD6jYMBsQgD0wwnoRIde8VMqgNZVfKKewbFxdnWYV8+qhUm5J+pIJgcM xZdEX7sveQu0OXdtXFRbl26/dF7sKL/oFppEy6ObNp0HSL19Eg0KodfC2ZycPLp5aXGA1ntZVlB8 meh8IM0fhAe5E6Fshyju6+IkSojbyOq8NtQ5L7FL7AaRZVOFNlHPhyTrFXd0hUQ7K3n0VwcPAmin lqIaa3ULt3OZU/lGQnUJiBqpc15AJ+q9pkUet7d3XOHp7geJvCvRtZNzReICWgqG/goo0bvpS1ed 9ZV+t7it+1q6Se6aqXeB7gmti0qiK1x1qXBuT1XIpbimeOWfbr9PdNqsW2GeeOLLyIMQAL0qAL20 faATHT9SBLT+DjH1W5fp5XFesJK8F6xuc3Uep3ULR6KGriT0XPQ40HHbjHUPWv0Vv9Misg1l7eJO +nt557mB3j6JjmS6X3iigUfkhQKdsrJyWUg5vjovY1ocoCW6E6f+r7zz4q6WWylAC9dkU8ipWqLx v3R/buc765MH5+mKbk1MUvy0bFL8aCQZ4iZFQMu+EErK50JKqZzQJvl8LRTQ+ht8Z/O87rYUdQar m/kTFXuZVPWS4kDUurJK9EWTGC72c6S3Z9weGs6e04kWUn9wnOUhLqD1lZRyDpZkrdWWcZ426HeL q3xd76nRReNOejV1U8i8RUV/UvShRF8Um+Rs3xmp8XT3mCTrqy8MQB6EAOiHENCJhnxOEdDzNg4l WR7d+S9JF8AoKzsbqlUbkrww9TFHHxzQujnc2ddZq9p5hY3TWPNOctyN3T6JliHRAVKWTXzjvGo+ bsvr4gAtb667rkZdLSc7IsXOrOkB9KKvW9JnJs4epc5RBWOhKVOiEdm0vFMZYPFBAN3T0yufi7jD nC0VoHVXAWfzfFHR+dhTCP3FS4pT8rG3oyqZJNpWVnN+jpJvT+dwQwvqyhW35nSWh1SmFOvh1L91 dO7iRQB6od9v6E9KilPqI64QQgA0gE4J0Bs2bNSXKEUNshZ1/FYHPP01uh6XN0WdLBWgnc1CWlSq pSpq+Gc9LzU8VvIpbheOBQG6rq4+dsxdmbVsH/G97vG5aECrCHcSWe3FF3+8SvpAP8iF/2pX6gEK dCNr1NW0us9AknsZLhQliwP0pUuXY0fhlR30/PMvHD58RHcOfkBAm47uBLqrgPogRJ3B6uWUpZq3 2MuUytULqQBa7abUAa03WioL6byALzmgpTyk8oYLBbQUv3nfM3UNPzig9frKJyWV9QXQhABoAB19 TNKNr4kG0E2yPOoloi7dPSDJFVf6onh1MNNdRxbU9rkkgI662kxbKmrh43Y7XtD2mbf5R8yqHhke HtYD1cnGFDnJc5ydKx7wIsK4npO5yAI4xxuOe4nh2gK0Pp1T5Up/jRB1qYD+ytsptvQDWvay7i/x 9NPPyBaQ0ujs+bMkFxGq6F4Kqnk+yRmsPnlbqj2uK6u4Nwg0HV04nD0Qkm9P3YdkoTf7iFtz6o/k Qm9WnyKg570P5YIKXiyg9fcGKfZX1rNINLooIQRAA+h5AK07V0SNse/Ma6+9ru4Hm2h55NisO3Ik +kpXX2+nrlZU1/ckGvpjWQGtrzZTHS51P+aotjS9wKlf4xi1fRJdq6fXQndI1a2Dopm4zcB6Ny0V oJ2U1Auc6F4bawjQesQJ5UJ9bWhsPw3diTZR61rsec6SA1qPIJloKAl9PvDggDbn+sGrMdf1O0fd 78mcuxxNpqW6n3PyjsLOk1in5pNvTz1oRip9SOYlr75AMMk3EosAtB5lqKjo/LIC2kzhokCpwGV5 8vMLpMBLHaiHoE7P906EEAD9sAFaKtPk3tKXm+i2iuTLIy5JZGJ1Mwt114DkblhWQJuO5nA5cqv+ DHGVrO8+kKjlTN2hQFzi9I3ePokGSIkdxk7vl0S3Gdcjiy0O0LKdZQWj+qjE6mEJ72u9UoA250ac EEnoa0PjjjCjy8C898hMsWF+EYDWzaiJzrX06BlLAmjdEUgKnjqDjVsk9IBoibaMnHTJkkuJkpKc ygmwrhwSnaXHHVMo+fbU571Jxv+RCkeqIzmJmncUDtMx9kiiy7JlH8m5h7yns9ZKXg/rL0CSdFST f0kVJOcD+gR+cYDWVzgkOiLoUw5Vm+khShLVOeoembK+qQ/QRAgB0I8QoJ01b9wF0wcq3ccj7vI4 h/dP1JFDd9vQ75BoOIXlBrRu8dIjLcQdikGzNe6NVJx9V5wDNei1i3tDDX0baue9M/R+iW0OVOcw unv04gCtHRZ3jFjd1v4QtECbjhEn9FrHJZFe689+9q9i26cnJyfV1xTOkQ2XD9Bxv+KXUuocECNu nRD1tUlyQOtB3/UpXNyPqu68JFsmbvO8/sJkoeNAy9xjz0VlFrr11Lmpk29PfbeXRDdScQ4rHndh ooqfbpIXMsY9z9TFKe440HHrYdng+pMbtxA6b0qv64rFAVpfEhr3VfpLQt3HQ4+FJ2cOcYfi0V+P MA40IQAaQMc/JjU0NOrhmaKAdezYcX0rXY2MRK1f+n0SdeTQX6+rn4sYXlQfOR5//An5PZUpUfuK vr9xkpFAtKJUG5KTWXLI0Q11UQJzXmT59a9/w/nOcrzUrdrOTa1FEnsXNDnHcF7z5yRL6oB2XiMV tWtk8fRpwEJLpkhCjbed+kCEaQC0HnFi3r68+vRJtoCzMMsZi94mqY/V/SBdOES0UWiTcquLSixi dPO5/CIFRjM3OaDNmCF0EvXN1a2V8kGLah3XNxhP0l8rEaBj39B5K++ok4Tk29N0dJCQDaWvjFQp KSnVnfujbjuaqOYMBAL6fEY+Zc4zB+cd76NuizhvPawvMpHlierIIVtP72LnTaYWB2gpP7oRXQq2 sxqRDa43sq525Pn6QammnI308i/dbiKLncpIhYQQAP0oAtrZ+qJcq+79pqtXOVI6m08SAdp5XE/U kcN52+TUL1uMPXKkPiU6COnm8ORfsMqBWR+J5Rd5pqy+rIVuWJIHow7eevuoJnl5gjxfHnSOaRX1 vbNsST0XOaaqoW2FbvprVjmix95MbkF9oDX3lRf17f30fOVNFtobUq9p8lHA0wxo5wlJohvU67Mg vYWlkItixUmys/QID/Lf1PvoLwLQ+pxTNZTKCYlsSfmpJaRvFxJVRHVnjKiBxuYFtHO8NudIjrGt ws6PvyyzvKEUIee5XOpnTbqyUoVNbWp5Q/mpN7WQPar4zQto5+5Tq6NKtXPc9NjW0yQ1Z0tLi/5c y4KphZSTHM1cWfKobtzz1sNRlZ5sVbWQziWP+ugtDtAKynpR5cxfVTtSdegyFlUqnM+X9ZVnqvXV 55/ywkT3NSSEAGgAHcmZM2fjDq0q75AIiLFvojpHpvLtcOy9ANMMaN0cPu9IIHJYVb23Yyc5HMb2 QtHbR1bQeSzXB6q48pCNHHf7yxFd9cGNva3aggAtR2jRofNW2M6RvMUZi7ijyqoFtB5xYt47fcha y7rH3SyyGAvaJosexs45EIqeRDbKLrG3elZtok6B6R4C8wLadPQbSdTFWX9AdAN5bJmMatZNEdBS knXvEWfxk5IZe/I2L6DV7ktUquWDFvcOOMlrzp6e3kSDN8vJQ2w3jFQALavmvDn8vOu+aECr5Y8q GHpGsgyxG1nmpb9tiB1DM9HXd4QQAJ3WSGWkOhUkuiItSSOoeqHzcC6qUw8mYqgcfeW/Ue0Hehni ykAelH+JJ9TYn/JLUdH52Ba4uMuj097erv4rh9jY+loPH+YcODn1yKZLsefGvF04zLleHGpQgnln LcfOzZsznnvuB2rU57feelseiftCvX3UsVO2w0sv/VRe9fzzL8gRPclpw/T09LFjx1VbtRzVZPvL a/X2F6mrt9XfgKv9FbuO6sG4TUdyvBS+q1nIJELKzy9Y9Fe0ek1TGQw4thBGbQq9c6NO2BYXKbqJ NkLcciW80DtXdvSCxh1L/cMVt0DKdhBZyr6QuT/99DMiKjmj00VLZKZeGHVjbXmCrKOcpv7857+Q hVe1irzVvNuwoaFRPSfRHWSiTkWk0Kpl02VyoedaUYPNl5WVyzLLG8oGlyVPVPySb09nZMvIBlSf MpnkzeXcIFHP9XlrTrWJtm7NlA+s2iPyYXfukYW+mz4hkU+3WnGZZGnlkxh33ZMUlahPSqJDiZQZ KcNSknW1k/x29FK3yD7S66tK4ELHBySEAGiyjNGXpa/4N4N6JJAkV/ETQh48i7hbEyGEEABN7kV9 XZhoPLV0Rl8ls4i2RkIIgCaEEABN0hE90NKCuswuRzo7O9XVQukZuI0QAA2gCSEEQJNUo652co5B IXJNpfPlckSNJPDccz/QF/QkufSHEAKgCSEEQJOVSdTgEgu6q+3SRg8Ktrj7IBJCADQhhABoko7o Ox0+/vgTK3vtoBzI1YhXYvq8vF0r3g+bkEch4mY19ATDohFCCIAmC8j09HSK90Ne7gQCgeQjOhFC CCGEAGhCCCGEEEIANCGEEEIIIQRAE0IIIYQQAqAJIYQQQggB0IQQQgghhABoQgghhBBCADQhhBBC CCEAmhBCCCGEEAKgCSGEEEIIAdCEEEIIIYQAaEIIIYQQQgA0IYQQQgghAJoQQgghhBAATQghhBBC CAHQhBBCCCGEAGhCCCGEEEIANCGEEEIIIQCaEEIIIYQQAE0IIYQQQgiAJoQQQgghhABoQgghhBBC ADQhhBBCCCEAmhBCCCGEEABNCCGEEEIIgCaEEEIIIQRAE0IIIYQQQgA0IYQQQgghAJoQQgghhBAA TQghhBBCCIAmhBBCCCEEQBNCCCGEEAKgCSGEEEIIIQCaEEIIIYQQAE0IIYQQQgiAJoQQQgghBEAT QgghhBACoAkhhBBCCAHQhBBCCCGEEABNCCGEEEIIgCaEEEIIIQRAE0IIIYQQAqAJIYQQQggB0IQQ QgghhABoQgghhBBCCIAmhBBCCCEEQBNCCCGEEAKgCSGEEEIIAdCEEEIIIYQAaEIIIYQQQh5hQL9s Z8OGDaOjo2wOQghZ2RiGwUYghJBVXlFHAP3ma2/WHKsaqOwdaOgbaOsb6O0fWM709vb29fUNpDcy R5lvmmbW2T9Q3ztwuaf/SGf3iY6Bkp7+22ld3+7u7oG059atW2meY39/f2yxlh198uTJ9K9+V1dX +me6Iju6p6dHtnyaZ7oilYasaXt7+2oo1SUlJbdv336Y60zH6stmf0Q+SitSabS0tKT/8xtbpAcH B/ft20edCbSWpNKQUp3+mUYA/fYrb3VuuO3JHPNk21PWqHf3uOfwpKd4ynPD5W2b8Q57vB7vUmVi YmJ6etqb3rhcrsnJyWWcwajb2zztvTjlKRj3bJdtOObJGHNvGRnN6fVsHfPKnwXj3msu75A7DSs7 NDTkTXtaW1vTP9PYellK144dO9K/JHI8SP9Mh4eH0z/TsbExt9ud5plO2Un/TOV4kOaZejye2FJ9 /Pjxjo6Oh63OjBcpWlLAHpGP0opU1J2dnen//MYWaSld69ate0S2+YrUmfLhlY2c5pkK7eQQnP46 U0p1+mcaAfS+Xxb4t04aW93WlDFjbLanDLeR6TZy3MZuj5FvT4e9RpHfqAoYd4JGf8h0G2Z4MU3f Mu9gMJjm9naZY9yP8QNlxjA7Zs3ygHnYZ+x2G3kea4ttdltbz96Yoe3T07tG7K1qP57ltjbjWZ/R OmsGlvGLWvnkpP8bDTmzX6pvRuTcTq1CKBTq6uqqrKxUzXKyE9va2q5duzYyMpLo5VJP5eXlpX/1 pdZI/0xFeOmfqWxh2S9pnqnfTvpnulR928Lh8M2bN2dnZ61qY2bmhh052ChJXL9+Xf6r6By3C8fp 06eF8mle/UAg4PP50jxTKVpSwB6Rj9KKVBoDAwNSGpfkrcSF4lHDjlTRVVVVUl3L77IT5XAg9XaS QisfrvXr16d/9Vfk4Cgf+aXa5qlHPrzyEU7zTKWKW3popWCGuN9yLO6tmpqaVEUtK9LQ0CDeUGVG 6qXa2lqpq1W9bXXh2PTaxuL1F4Yzuozt7vsmgeA2d0R+8nOLhcKwTBkz4cyZ8A53hNR7PMYRn3ne b9wICAqNoZDpnd+FaxrQxnTYaJs1rgSMQ15rCwiat9nnG1siaLY23dxmDGXNTO8eubdJ1cmJbMOd bqPAaxT7zd6QGXpI6oglAbT6JJSUlKiaV6BcXFws9fLFixflYNPT0yP/qq6uPn/+vLAjbmED0AB6 tQFaZHz79u2TJ0/KG0pFJFVweXm58EKqY6mLy8rKrl69WlFR0dzcLBU3gAbQawLQUjlLub1z5468 mwDx8uXLUqTlpzwusHbW2wAaQK8JQEuZbGtrk4paVkEqIpH0lStXpLqWylm8cePGDam3pVTLL/JM C9A71+VObh2I1nOiKaLqOSkKGTfZcMyw21Z32KQu8BiFHvO4z7zsN2uDZvusORIyfYZprGVAuwzr 9KA0YBy00bzTY20H1U6/1d4gmfG32H2A1pPahuq14m95z8qAORpe63XEkgBaPvNS8x49elSsLH/e vHlTIUMKrvxSU1MjyFCV9e2K5uB+F4AG0Ksc0FLPtra2njlz5siRI+oNpfSOj48PDw9LqZY6Ws4G ZT/29vZKNS1lG0AD6NUPaNlNYotjx47dunVL3k3ODwXTUlGLLaSWbmhokJ/ypxTp+vp6AA2gVz+g 5U2kEi4qKjp48KDqwCb1s9S6UoxLS0ulSItMRu2UlZXJTwvQu9bv9GdOpAroZKq226ozbFVvnI7o UP6701K1Kare6zFO+MySgHkz6G2ZCQ76rf4Ps+m73nzBgJ40zJZZo8RvAbfAgeZ4Lc2JpviA1pPu 2pFp95M55jMbguZMeI3WEUsCaKmX5ZMg5VUBWurf9vZ2+aWxsVHYIX9KEZc/pZru2tHSvvs2gAbQ qx/QUgV3dHQoQEsBlvpXNqBUR9euXZM6WiCidqUQRD65ABpAr35ASykdGhqqqqpSgJaSLMKQx9va 2qSilj/lpFH+bG5uVsUbQAPoVQ5o0/6qsKur6+jRo6rbulTOqkVDyrkUY6m3hZFSbqV49/f3LxGg k5Nad6q22qrtx7M9nsLxQKHL6v4h0z6vecxrnPUbpX6zLmjemTW6Z82RsMXrJT1GpwToCcO8PWte 9hsHxP3uCJo3uReE5gUAWm+uuU4yRo7H6kt91me2zVrN9o8eoNVhu7KyUgH60qVLd+/elV+kmj57 9qycAqrO0PX19ePv9F49VwagAfQqB7TK+Pi4ArScEEpFLEdTqY5EzEVFRVJNq10pdbSUIgANoFc/ oNWeamxsVIC+cOGCWFkelBPFc+fOSb2tGj7u3Lkj/wLQAHpNANq0r0g5fvy4GhWgtLRUAbq6ulpK tdTPsnZSbisqKsQnywbo5Kre6vbkjgUypyI9QGTabPNx61w/kN0eq39wQYTXxnGfWeS3LtSrDxot Nq9Hw4u4fjEhoMfD5i0bzfvtmcoCyJJsmlk0mhcM6Pu6drhVJ2mxu7nPY5TYnaTDa6OOWCpASwHV gJZTPamR5ZempqaSkhIpuH1dfeZAuLaoZurtAfE0gAbQawvQvb294mbVAi3lvNyO2pVSvOUngAbQ awXQDQ0NugVaqmh5UNwsFbX82dbWpho+5HQRQAPotQJoqQcUoMfGxqSi1oBWV6qoFmg1qkF6Ae2Y PHljgZype7CO6gQS6digeT03Hki2x8i1+1irixdl2u8xT9i8vhowbF6bPSFzLGxYvDaSAVoI3hQ0 L/oNQWqBqN1uJt+4NGhePKCdks6YG8pjt9s44DWrA4Yss7Gq64jlAHSdHXnk8qXL9RdvVJ+svHOo 0bdn8syB0xNv91WfugagAfQaArQc0kZGRi5evKgGaxNqNDY2nj17Vh4XH0sdLY8DaAC95gAtepbz QPm8VFVV1dbW1tfXqwutpISrrh0AGkCvLUC7XK7S0tLh4WHZjFJjSzG+dOmSGtmzuLhYau/VAeiF 9rFWFy8qXqvO1hFeu8O5brvd2msUWhcyGgcivDZsXgcbPd4ql3nBb/XGLrAtLi/cOHcR5NKheQkA 7ezakWGvaZbdlfy41+ok7QqvzjpiCbtwSC1sAdpvDNX3Xzp9UWrh8/vOubYPdeW0Xsq/ULL7UtHe s/6NE8NbugA0gF4TgJbioVqgpXhXV1cX2xFnyJFV3Cwl3Lou9vZt2bAAGkCvFUDrLhwCC0GGFOML Fy7ISslZomjDqrfPn1djfgFoAL0mAK27cMiKSPGWWlp9oyJ7sKamRtXbcooYDAbXCKDntfU9Xs/c 60x8f+t1ONsd2D3lzR+3nrDMaF4yQEd3krb7umS7rROAIp/Rlmwk6TUMaMMMDwYnioe9hyfMQm9w 13T/9rvtO5qHc7pl/0pZ7dvR0ZZ3azS319g2E9wwBaAB9JoAtFS4g4OD6iAqdfTdu3c7OzulUlaf VvlTPj7qwAOgAfSaALS6OlZ9x62uKezo6JBCrsaBll/a29uHh4eTfLgANIBebYCW5Zeiqw5wUhFJ tSzFWFUOUtql0pa6WtXbax/Q87rzXuv1TCBr0rNj3PozjWu6NIB2rlHG3JjTeXYre2nA6iQ9u8YB LWCYDptts0ax39hvfz+Q44l0kc9wh7fOBLdPhe9t0ulgVqTwhLfNrBZAz5oTIxOxOwJAL1EFafqn fYFpv2mkdbZLCOhYJjq3ofNPAA2g1wSgYxHjHMU86k8ADaDXBKBjqyN1U5XYPx92QN8/BXInPTvH 0zzTJQZ0VCfpjTPyi5nvMY94jar7RpJeG4D2G5b+q4PGcZ91MrDTYw2PvXE68uVAaqc6cXg3487P y0+ztMywOTE2Yaa5hjTMqfEp00jzqq4QoD2+gHcNt0Cnmruh8F43gAbQaw7Qi/hwAWgAvcoBnXym AHptAjpqJOlN9p1c9niMk16zMWhOh1cvoMOmMRY2m2etu1ce8Ir+rbXQt45feKea2DmcO3du4zsb W+60pLnCWpkuHJNT6T5VoAvH8mUkHNjvatpXD6ABNIAG0AAaQAPokXR0VsmY6/yd6zELPRPnh607 QVZat60x7gTNzpA5ELIG7HMv481rkgHabRgds2ZZwDzsDe+5r4dG6o3NKQL6jTfeeOWVV7Zt26Zu ubIcraHWCOVBw+qD7jNMj2GNWe4yJsYnzGnD2sJew2pcD9pPW2bdPpxdOMKGtXl99sZ0GVa5HQ77 ezz+Lo81zE53yOycNaU4tc+arbPW2Du3Z81bQaMpaF1iKwW+LmjdA7UmaFwPGNcCZmnAKAmYxX7z kjUZF/xGkd885zfP+o3TPlOmU37jhM846jWOeI1DHuOgPR3wGPs8/sLJkfxeq1vRAfvBw/Zzjvus 55/yGWd8xlmfcc5nXPCZF/3WUJgyoysyU7/M2rxhLYlxM2id096aNW4HTVnUtlnz7qy1/LIifSGz P2QOho3hkPX10XjYKPHfLbxTfKkYQANoAA2gATSABtAj6Zvj3Ph3E3kDkTtB5ngit1gv9Bh7vda4 2koDR73mGRsTglrRRvOsdVVib0ikYk6Fjftvvb5IQMs7iNprAqZQY7/XGt57m/vevd+XqDN67GK8 PJeS48XhOwHr1jy3gmZT0GiwNSOmuRE0rweNqoBxJWDdGlPcY7vKlKnIb93T54zfWuaTPlOoJGAS Nh3yWjekPGBvvX0ea3X2e+5Ne61tO3ZsUH6a++b+tW9uUhv8kINfJ33GaWsuxjm/cd7eC7IAxX7r tpdXA8Z1awnv2as5aAGxdc5eXaGIvWTbDoWmuiaMUfvUSKaJsHX7zCnDGqdl2r4Vkdv2vdfGqN8W f9CeZm3chxfp+ziADhlGwJ6RzFSWYSwsyyY6NHpCxl1bundmrRWRXVAbNKoDZnnAkBM8Qed5G7Kn /KaQVLbPQbXp1Da0i+veyKA6vgOT/v1TRqHX+qalwGtdA7DTYw1AucMePD7XbU9ybmZfaJvtsX5m OYZXz3BcaqxK4Bb71k5b7FuB6suON943+TaOj2zojvy5yTFuvZq2zESmjLlTQTVtV8vgthYmx16q XPtjKIu6023ssofgtFbK65jsRzbN1B2tuXz5MoAG0AAaQANoAA2gR9I8U5km8gfuuWGL45fNc0pQ N4bMmLHvDWkd48NydFfI3usJKwIe9ppCvXN+szhgVPrNm9Z9Ii3A3WvMjgG0Yd8CXcx6ae7GNNkP 1EPjQQB9/K0js7kuGy42sJRmFK2UrrY6poy5TRRR0RySNk1Hoep+S92bxvL6nX/GamzutXNi0zPS 4zOq7ZOl+WU31efOMTHWXnu9k0eG7V3mVYiPM4ndD8ydNe2f07z1iD4HsH8/YJ8hqOmQfc6gpqP2 dNxrod+ezNP+mZPjoZNu45j9hIP33so84DH3zc1X0zDfa0tX7YI512Y6t7lN0ii/OretLVRf9oQ/ e+Le/tri2FmKxUqxGc7tOXPfLt4Wb8qc++mc5kqXL3NiZFtP9HXJmY7xf7Y5BgKKnZzL41zaOP+1 /hV+c7rpQD2ABtAAGkADaAANoFcI0HsGFzgC4NztyjPc9+Fv84zyd3j7jKXPnTbgFNe0uuzGbPOi v3t/m3HMZ/13p2OM7a3uZR35JAmgr64vDm2ZnhOqA1ix0InrqgSoSjSN7xmYf0yYFPmVEUdX99lr 7jmTeYMOSqpzFfd9jo8y/aZ4Ta0bEvzuPFvYrN/cPZMzMpvhin6TCHnnaOu8KZKzmTYjHmpT2M6+ HRMypflzFA3oZZ7Cm2dcGwarT1wD0AAaQANoAA2gAfSKtEAPLk3X6ns3YJ+5vzF7JqYx2921+Y7d vDrnvLSsaWyx/tnLPxM9Z/0ic2DL3XRu83kAvTzTZMHQ0ven3x7v/MFB/5ldo7NZ0ymeVyyZZR8B QFsj1r8zM7axB0ADaAANoAE0gAbQKwHogsF0HvVVO2LX1jvpFFUiQN/Iqcx4dXP35pZg5hSAXo7J AnT2dLot+ygA2u6xHdroAtAAGkADaAANoAH0quzCsQyTBejtKw/omQNjea/lpn9JHiFA59kt0AB6 mTpyZM4AaAANoAE0gAbQAPpRAXT31pbVAehxAE0LNIAG0AAaQANoAA2gAfSaaIEG0AAaQANoAA2g ATSABtAAGkCvvS4cABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAL0ygDbM ybEJ+QmgATSABtAAGkADaAANoAH0WgO0YU6l31WGOTEOoAE0gAbQABpAA2gADaAB9BptgV4JV9GF A0ADaAANoAE0gAbQABpAP2jCwZDb5U5/u+zSdOEQI83KhjNMv2F6DNNtmNOGOWUY42FjNGyMhI2h sDEQMvpCRk/I6JqduD1m3J01784aHbNmh/2zPWZqc0ytc1NLZDLUL3cikyE/b88at+2ft2QKmvpn 86zZHJRpoK0/fDcoy2MtJIAG0AAaQANoAA2gATSAXkpA+1cC0LMh9/RytkCHbN3OhM3JsCmIHAyZ PSEh7FTTmGXQW7Nm06zZGDRvBs0bQbMyYFwNGOUB40rAKPUbxX7jst+46Dcu+I0iv3HGZ5z2Gqe8 xkmvccJrHLtvMo/5jCNeazrsNQ7Z00F7OmBP+7xGgWfi0KCx22Pkz03y+263/dMx7XIbuzzWtNsT +UWmPLc9eRzT/Y/slMltTx7HZD0yUNgZ2uOW5TFlOU/7jBK/URcUvpsjYdOXPlIDaAANoAE0gAbQ ABpAA+i0d+GYNS3wTRvGRNjC30DI7A5Z7bgtFoKNuoDF3zK/WRIwhbznfJZ0NXO1a0W0+yy8Tu4f ukfPHR4j12Nku41Mt7HNbWy1pwyZZowtM8ZmmdzGJrexccbYYE/vOCb5Ux7f5JjU87fYU4Y9qXfb PDO+q9/+70zkv+p35/O3zDimJA/GPifhg/2bOkJbpq3fN9qLKisla1rgsTbFMfuUQEgtJw/tIXM4 ZHqXi9QAGkADaAANoAE0gAbQywvos6fO9Pf2PzxdOMJGpKuD1+7n4Aqbk4Y5bnVyCA0E3XddZlfI 6r1wRyhstwRfC5hlgQiFz/qsdtMTPuO4PR31GYd9EQoXzjXTCoJzbP6KDi2qKuxO3wdcxVYl2i3u ybzB+4yb4cCunrbdP2U6prVTafRv6whtn4n8mTmnebXu6pRgyz1SR1qpixWpZ83hsNU1xQDQABpA A2gADaABNIBe9YDO35VfUlyS1mNw2Ay4/b4pr9XbwWVYHR7GrIZeYyhk9ofN3pBl3LuzRpvdB/e2 Ld2GoFEXNCoDRkXALA8YZQGrLfOy37jkN8/b8D3jM075Ih0e7Mk87jWOei0EH/FZTcKHvbOH3TNH xow9cxTeYbcEb3M4T5D3zhyFrSZed6S9NsMdaR7WDnbCdz7mThYMPiKVxsC2u6HMxJ/fKFJvcpBa 9sghu/3eJrV5PWh1yx6ySZ00cUUFoAE0gAbQABpAA2gAvbyAfv311zds2HD27NmFdIYwI5eyTVuN u1Ynh0Ebvp2zxlzjrlFvede86mjfPWe371rG9flPuXynpqyv9Y/O9XmIdOf1Gfu9lnHz7T67uxw9 H3Lu7/ag+g9snnNYpLfD/S3BG+cQbNt3dptrOnfkvo4NGTEOzlyOj9KjAuj+5IBOQurN97dSZ7mN fKvh3zxunReZxQGzxiK1MRiyTrrC90R15swZAA2gATSABtAAGkAD6HQD+mU7r7766kjzkCXgtkij r1E7J+ArAUswTgGf9FnTccVfX8S+9rVr9/o55Hrua3HcNNfP4W3rp3/rhDdz3NLtppl7os2Y6w28 2fGg6msb1e0hUYeHpKsvRWtm18hKfJQeHUA7unAsblLnSM5W6nfsfttZVrkKH7RbqYXUl/1mdaCn qvO1114D0AAaQANoAA2gATSAXhlA/+zlnzXn1EUErBp9s90JBayaeCP9fXUnB9XWG3NN29b7mWsv iX/HpDft2xxArwFAx522Ra6MvNfxY7P1ePmWEim6ABpAA2gADaABNIAG0CsG6J6NbfcEnBHT03fb UvZwANAA+sFJXftWJYAG0AAaQANoAA2gAfSKAXrv6wX+zMm0LQmABtAPPo1t7dv08w0AGkADaAAN oAE0gAbQ6QZ07pvZ59ad7N/Skc4lAdAAegkOgtunGzbUAGgADaABNIAG0AAaQKcb0Cc3HevZ3Jrm JQHQAHpp9mmmC0ADaAANoAE0gAbQADrdgD61+XjvlnYADaDXIqDjVtQAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAa QANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAAN oAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAa QANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAAN oAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAa QANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAAN oAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAa QANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAAN oAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAes0DesfbOUP53eKtdE6D+7tH9valeaYje3uH9qd7TaV+7D/QmeaZytRzqD39M23a UZvumRbE+cwMnejJeSMr/avffXgFtnnvoY70z3TgQNdYYX+aZzq0r2d4X0+6Z5rf3ZF3O92VRrxS fXTbodu5N9O8JMP7eofSvs2laK1QndnxiFQad3Y2jhf0r3hFPTY29uabb06mPX19femfqfBuYmIi zTMdHh4eHR1N80xltw4NDaV5prJtW1tb0z9TqwXau30slDWdzmlm16hvx0SaZypzdOeNpnmmwRzX VP5QmmcqkxyE0j/Tu9tup3+msfXy9MHRnb/MTf+SjBb2pX+mcoaW/pm6dg8HcqbSPFNP3ph353i6 Z5o1NpzZneaZzm53xZbqk5uP9WS0pnlJZIPLZk97nTklBewR+SitSEXdl9kezHKteEXt9XrXr18f TnvEPemfqcvlmp2dTfNMPR6Pz+dL80wDgYDb7U7zTEOhkJwXpX+mdOGgC8eq7sLhzR6vz79eXVBR WVA+ntPvz5po3F17obCob8ddunDQhWONduHo2tkiRbqqoOLWrnpf1sR47kDJnkvXCsqns0fowkEX jrXYhUPesGH3DVVRD+d2z2a5Wnc1XSw8fzfvDl046MKxRrtwDA4O1tTUVFdX19fXy9mInAWVl5eX lpaqIkQfaAC92gE9mtt7bu+ZawVlFQVXRnP6OvJuXyq8ULu76vj+Y+JpAA2g1xygQ9unywpKyvaU VOaXN+2qm8oZurC3SNhRUVBWm18dyJoE0AB6zQFazgNP7z1VYVfUQ7ndQzu6z+89V5NfeWbfqeHc HgANoNccoGV/iZtLSkoqKyvr6uqk2Fy1I6SuqKiQdQTQAHq1A3pgR+eN/Cpf9oRU0DJVFVxty2v2 Z01eKSxu2l0HoAH0mgO0ELl0z+WZnBEpz/J7z862C4VF8vvQjq6re664coYBNIBec4B2ZQ9JqfZl j0tJnt0+XZtfVb+7Rirq6oJr1/OvAWgAveYALSty48aNoaEhKaiyGYeHh4uLi2U/qnZo+RNAA+jV DuiOvNtH9x85ve9kSeElsYUIo29Hhzxet7s6Ub0MoAH0aga0O3v0YuH5U/tOnt175vauhju7GsoL SqxdmTN4taB0ImcAQAPoNQfowR1dh/cflor6cuHFmeyRij1XWvOa5PFbu26W7LkMoAH0mgO0lM+K ioqTJ0+ePn26rq6uq6tL3BwMBuXxysrKvr4+AA2gVzuge3e239xdM5rbe37vuar8q5cKz/fbgK7f ff1qwRUADaDXHKA92WPV+RXDuT3dO1ulPJfsuaQAPZUzeGVP8XhuP4AG0GsO0FJFS6mWn2V7Sqrz r14oLGrPa5bH5RRRqm4ADaDXHKBl0zU0NPT29o6OjhYVFZWVlV25ckXWTsG6u7sbQAPo1Q5oT9a4 P2syvH2maVfdub1nK/PLVQv0jd2VdburATSAXnOADmZNiaFFMO7s0asFpWUFxeUFpaoF+lp+mfwE 0AB6zQHam2V13pCKun3nrXN7z1TlX1Ut0M276hK1dABoAL2aAR0KhWRF5KfsuKqqqpKSkqtXr6oW aPlTZgegAfRqB7RUxC15jbNZruI9l4QXVfkVzbvqpbI+vu9Ye94tAA2g1xyg+3d0XNlTLIwezxm4 VHi+fnfNqb0n3dlj3Tta5fGZ7FEADaDXHKCv51+r2109u91VnV8hJ4RSqqWu9mSNXSw835zgYhUA DaBXM6DHx8fLy8tdLpdsw/Pnz9fW1l64cEEKjzx+6dIl+QmgAfRqB3TXzpbj+46f2Xfq9L5Trpzh /h13i/aePb3v5MXCokDWJIAG0GuxC0fxnouqSN/Ir/Jkj1cUlNldok+35TWLbAA0gF5zgB7J7Tm2 /5gq1eO5/ZM5g+cLz0lFfX7vOX/WBIAG0GuxC0dVVdWpU6fOnDkjkvZ4PPX19adPn5Y/GxoaQqEQ gAbQqx3QwSzXRO7A0I7u6Zzh8PaZWfvPgdxOUYh6AoAG0GsL0FKMpfQO7+ge2dHjs23hzR4f2tE1 ktsbzLJqRQANoNccoEPbpwXNUlFP5QxZJ4HbZ6ZyBgd3dE5nDyeqqAE0gF7NgJb3lA04Ojo6PDws v8ifsjFHRkbkT7VVATSAXu2AVuCQ2jnRnwAaQK8tQM+Bw0KG0x/6TwANoNccoHUxTr2iBtAAejUD Wr+zc8epexDqfwFoAL3aAZ18AtAAei0COtkZI4AG0GsT0AuqqAE0gF79gE4+UwANoAE0gAbQABpA A2gADaABdMoz7ZoF0AAaQANoAA2gATSABtAAGkCnkLBplPpcWUMAGkADaAANoAE0gAbQABpAA+iU 2p7H8vuvn6gE0AAaQANoAA2gATSABtAAGkCnMLubwfY9t4ovFQNoAA2gATSABtAAGkADaAANoFNI baBlT+Ply5cBNIAG0AAaQANoAA2gATSABtBJMxo2z/vDG6aHtnaVFV0B0AAaQANoAA2gATSABtAA GkDHnYFpDoeMMz4j221sdhtbZoJvT4xu6AHQABpAA2gADaABNIAG0AAaQMdkIGSe9hmZ4ma3sdVt bLOL9LaZ2Q0uAA2gATSABtAAGkADaAANoAH0XGR39YWME14zy251zpijs66ot80AaAANoAE0gAbQ ABpAA2gADaDt9ISMY16r1XnzzL1W55iKGkADaAANoAE0gAbQABpAA+hHG9Ah0+gMGYd9VqEVOmfE pzOABtAAGkADaAANoAH0ylTUd+/efeONN8bGxtJLLXNyYtK6JgxAA+iotIeMQ/O0OgNoAA2gATSA BtAAGkCvZEW9adOmV155JTc3t729nRZoAL1igJ41jbZZY7/XkA9FvL7OABpAA2gADaABNIAG0KsF 0C/bEUOfP38+nc4D0AD63mWCd2aNfR67w4bb2DpjNT8vpKIG0AAaQANoAA2gATSAXgFASwrX5U9l Dxk73MYOj7HTbeS5w3keY5fHKPCYhV5jr9fc67UaCA94jYNe87DPPGJN1jVex33mCZ9x0mec8hmn /eZZv3HWb170G6V+syxglgeMqwHjWsCsDJhVAaM6YNQEzNrA5PUxYyhkhgH0IwzooGHcCpp7bTpv mjEyFkZnAA2gATSABtAAGkAD6BUG9NHXD3k2jVodT7fMWD8329+kb47cscIafHez/dP6fSZs/7T/ dM896L7vEfUV/NYZ6+c29fO+aSJ/yMi1gX7Jb7bPmn4DQD9CgA4aZmPQKPQYWTadt7oXQWcADaAB NIAG0AAaQAPolQT066+8fuOditB2R32SOfdz3mlbCtPWuZ9z08TuQesXdaFYjseU6ZjPrAuY4+Hl u7gQQK88oAOG0WDTefvc3s980IoaQANoAA2gATSABtAAOq0Vdfn20l/+7LXGDTWebaNpPTiqHZ05 B2vVbi2P5HqMQq/V/aM7JNhaw4D2GtYqVAe81dOBUrdZEjBvBs2ukDkZTkPHldUIaJ9hnSDl263O m90PTmcADaABNIAG0AAaQAPolamop/YPr3vlzUDmZLoPjrE7OtNGVUbkXs1mrsfc7THO+qxusi5j DQBalnHCMO4ERf/Gfq+502P1Jt/m9uaNB3ImrVXbbvcvlynXbez1Gqd9ZkXAvD1rDoRNj/EwA9pn GDcCRoHn3uB0mUtZUQNoAA2gATSABtAAGkCntaL2HZxa/8q6FTg4JtnRmXM9Pex+1eEst7HTYx7y mtVBczC8qgBt+A2zL2TWBkXDVn/uHe5wtr3kmyOnATJ5c8f92ZP3erBkuCNdzLfYXcOzrVfZV21a 62hc8Ik1zY6QORY2g2sf0G7DunI0b8k6bABoAA2gATSABtAAGkAD6Pkm3cFjs/2nQHO327zkN9pm Td8KAdplmO2zRrnfPOi1aLjT7pOgLrLMmLv3h4OJ3p3j/tzJOCcJzk7hgulNtqq3zkQaqmVNd7jN Aq9xwmdeCRiNQaMnZEyl2v1j5QHtMQyhc77VBr9MdAbQABpAA2gADaABNIAG0EknLU413lmO2+oI cdxn1AetxtrwcgJ61jSGQkZD0DzvN/dEaBvVzJzkrh/xAR13BZ2qzrBVrYZAkT/tZngjz26o3u81 z/is9viWWXMwZHW2NlYToKcMoyJgbaLty0tnAA2gATSABtAAGkADaACdsqQVMVVHCLu91tznNcsC RnfI9C8RoN2G2Rmyxq4+5jN2283M2TZqN81ERJuyC1MFdPLThoiqZyKDCcqSZM5YF1xaw3W7w7vd xhGveSlgyunEXav7x6wnGA1oQXbIMGcNq2dIwDB8hnVVn8cwZ8LmdNh0hc2psDERNmUaCxujYXM4 bA6FLKD3h61uKr0hsydkdoWMzlmjY9bsmLVuHNg6ayH+dtDqp94cNBoD/We6rc2lWp23LS+dATSA BtAAGkADaAANoAH0wqdtulex/ftOj1ngMc74zObZuNcdJgO0PCxwvBU0LvkN4fguG82Z7sio2Bnu 2L4ZKU4PBOhUVK26f0RUbTdU73QHd7s8hWPhXRavrSZzewrvtLVtNWO7rR7bu+Z+5nkik9XI7bGf 4Ik7Re6toybrpMLuvqImqTO3z/Rv7oi0yqexogbQABpAA2gADaABNIAG0A/QLL3Fxm6OPYLHIa9Z GTAGQgkB7TOshtUbQfOUz8i31Zgz17a9wGbmtAI6+RawzyiC26Y82aORRvpN+s44cxcv6inDnvS9 b6KmrfEm59je9z8/nDHTv6UjDa3OABpAA2gADaABNIAG0AB6Sadtjt4OmTaLd9v3O2wLzYxMh8dD ZtusUea3eL3bbljN1JcALr6ZeeUBff8UzJkS4KW7ztw+I6U6/RU1gAbQABpAA2gADaABNIBe0kbZ jHvXHU4XjoZ2z6jhme9rZt62jIsBoAE0gAbQABpAA2gADaAB9BoBdFSn4YyZ6dzh0NbppeqbAaAB NIAG0AAaQANoAA2gAfRDCui5SRgQykp3nQmgATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAa QANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAAN oAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG 0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkAD aAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaAB NIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAA GkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gA DaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSA BtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpA A2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2g ATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQ ABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANo AA2gATSABtAAGkADaAANoAE0gAbQABpAA2gADaABNIAG0AAaQANoAA2gATSABtAAGkADaAANoAE0 gAbQABpAA2gA/f+3dybwWVV3/kZbHe2orVOnZartVGurbelUrf/RWq1SY0ctto51WlRsraUVlSpW tKDYsoTVQFaSsMi+hD2QsIQEEgjIJgQIJJCwCAhhTwhbK6j/b/KT4+19F94AJnnD83zOJ5+bu5y7 nfu7zz333PMi0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1A I9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj 0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQ CDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AI NAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0 Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQC jUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKN QCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1A I9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj 0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQ CDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AI NAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0 Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQC jUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKN QCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1A I9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj 0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQ CDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AI NAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0 Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQC jUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKN QCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1A I9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj 0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQ CDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AINAKNQCPQCDQCjUAj0Ag0Ao1AI9AI NAKNQCPQDS/Q76dX7R+4Y+/A7QFpGwKNQEepQB9L2x+sSG/fk7INgUago1GgT6QfOpi6M2ipRqAR 6CgVaBlyqECNQCPQjV2gT6ZXlycVD4xNTo5N8qceiQg0Ah2NAv339Mr8uLkJPeIDS3VSsFKNQCPQ jVyglef25LLhvYYmxyYGlOpEBBqBjkaB/kd61bIBhfE9BgQN1Ag0At3YBXr3wHdH9x6xLmElTTgQ 6CYj0CvjlwztOXjfwO004UCgm4ZAV6XuntJ3wpIBC04OqqYJBwLdNAR6fWKR7HlXyhaacCDQUSnQ SwcUzoub8376xwXmSNo+N4xAI9BRKtA9u/XckfyJEB9I3YlAI9BRLdCbk9ZP7TvxaNq+U9fOgeMe tUCgEehoFOjBPdO3JJWGCtQINAIdBQK9NmGF+zfnzeztyWUINAId7QLt/bdf934INAId7QI9Py7H +45lVfxSBBqBjnaB/udA3ReBRqARaAQagUagEWgEGoFGoBFoBBqBbuoCfSB1p9L0flPWJ65yb1IQ aAQ6egVa+Vup7tu9j/4eSzuAQCPQ0S7QB2uLdGH/eYX954cJ1Ag0Ah0tAv1+epU3UB9J24tAI9BR JtAJPeKVenfr3b9HXGKPeAQagY52gV6TsMJKdbeu3fR3RfxiBBqBjnaBTosdqMLcr3tfpYTQgRqB RqCjRaB3pJR7A3XOmzMRaASaJhwINAJNEw4EGoGmCQcCjUDThAOBbuoCvaB/3s6UzQg0At2UBDq9 ZyoCjUA3JYEuTnhnXeJKBBqBbkoC7QvUCDQCHQUCXZSw7IMQER+BRqCjVKDfTz8U/GaAQCPQ0SnQ uXGzIw/UCDQCHRUC7e021xeoEWgEurEL9Mr4JbP6zThyqntRBBqBbgICHd9jQEli0Yn0agQagW4a Ar01ecOkPhnejnIRaAQ62gV6VO/hRfHLTgSr7ECgEegoEOiq1Irxvce83b9AA4EJgUago1GgtySV pMambEpaH1ikKwfuQqAR6KgT6KNp+7P7Zea+Oetg6s5IAjUCjUA3foHekVz+Zvd+pYmrgwZqBBqB buwCrbQ75d30nqkDevT3pf7d4xBoBDoaBVppVfzSwCIdqlQj0Ah0IxfoD2t7Gh3Te2SERRqBRqAb v0ArlSUVhwrUCDQCHQUCfSK9ujptz6HU3b5EDTQCHb0C/ff0ysAiXVOqB1Yg0Ah0NAr0yUHVh9P2 RhioEWgEOioE+v30quCBOrUCgUagG7tAKyhvSSpN6pHQv0ecLyn+ItAIdDQK9Pvphxb2n/dm934R lmoEGoFu5AJdIzEpm9/qNaR/d3+R7h+sSCPQCHTjF+gT6YdWxi/p171v0ECNQCPQjV2g9w7cPrLX 8DWenuzCf5uCQCPQjV+gVZ7Te6buHbgt6LcpCDQCHXUCXZ26Z0rfCYv6558cVB1JoEagEejGL9Ab E9e+2b3fe8FiLx8RItBRINBLBxTmxs1+P73qcNrek6d6LXBdgCHQCHQ0CnTPbj23J5f9I71Kq/jg 1D3AzAOBRqCjUaA3J62XQB9J26dA7XotOBE6UCPQCHTjF+jBPdM3Ja1XMT6WdsC6aPyg9q04Ao1A R41A2w+pxPcYsCWpVKH/RHr16oTl1gUYAo1AR6lAf1j7HeGsftOP1nbReCB1Z0XKVsVoBBqBjlKB th9SUaAuTVwtyVDSgDk0Ao1AR6lA6++25I0T+4w/WNtFox4R303eYIEagUago0agixPeGd7rrYqU LRsT1/bp3ntHcjkCjUBHtUBXpVaM6z367QELjqbtn/vmzOx+mcfS9iPQCHRUC/TmpJKU2CRJhlJy bNKWpBIEGoGOaoF2XTRq4O3+BeP7jFHoRqAR6GgS6PfTD+XHzR3Va3hij/jypHU04UCgo12gP6zt ojGxR8LMvpkqtFbDgUAj0FEt0B/W/vrVoNg0JQ3QhAOBjnaBrik2qTuH9xo6s+/0pB4JCto04UCg o0yga0J/yuahPQdP7TPxBG2gEegmIdAnB1UvjJvXt3sfqcbHbewQaAQ6ygW6KrVibO9RSlWpuxFo BLoJCLRWsXLAEgXqwrj5tIFGoKNPoGUzOW9mZ/QemxKbpDFWiBFoBDp6BVpBeVvyxsQeCfPfzBnW a8julHdpA41AR7tAn0ivXty/YFjPocN6DtFAqI9VEGgEOloEWvlXpGx9q9cQBeqkHgkK2rSBRqCj TKCXD1g0qvfwg6k7dySX9+7WizbQCHS0C/T+gTtUpIvil51IP7Sgf25Wv2m0gUago12g1yWsSolN 0tOgkgY20wYagY5ygT6ctndq34kL+ucpUK+KXzqu92jaQCPQUSPQqxOWayCxR/yulC02sjypmCYc CHRUC/TJQdWrEpbmxc35R3qlxWjaQCPQUS3QKsxSmfgeA95N3vjxTeHUwHkv0HsQ6CgV6JPp1duS N07rO0khusYk0ys/aQM9Im74sbT9CDQC3WgFekX84tlvZh1LCzx3hz9I34tAI9DRKNBvdu9XllT8 QTCPCS7QSZk7UsoRaAS60Qr0luTSSX0yqlKDH8bzW6CrD4/afnLwQQQ66gR6WK+hxQkrg/42UI1A p/UZuDbhnX+kVyHQCHTjFOjK1F2je49YNqDwePoBb3o/fcOJ9N8g0Ah0NAr0pqR1ybFJ25LLfKVa 6VjafmqgEeioE+gjafum950yL27O0bR9AUX6AE04qIGORoFWiO7drZfCddBA3axrLdP6TvrgU7ii EGgE+pykipStiT0SVI69Kb//ve9O+HVQgR7TZxQCjUA3ZoGuebUyYLGvSFvq1bVnYKmenZK9M2Uz Ao1AN1qBrm3T/97wXkODluqgAp0Ym4BAI9CNWaCVNiSuCR6ou/Vq1quW1L4D9w3e8eGwo/WTjo45 8P7IQ/W2Okv/GFV1bMzBel7pB8MPV4/fV88rVaqcsLv+V7ptaFk9ru7IoTE/ejs/O0hcnlZ1aPze +t/9gxMr6n+lVRl76n+lh8ftPzGiup5Xenx05d9HV9bzSmWQ+956r76DxltB3ndXT9n3/sj6PuZ/ H111vN6P+ckRhw+Pa4CYWdUQMbNBgsauoVs/GHa4flcarAnHtEMNcp9qkJWqSJ8cXs/H/KiER9pT zyuV2h0de6C+Y+awIyrV9R+om5384CMSKWrTh4FxmcNCiup04iSlmkSgJpEad6D+4MNmizcdJ5Gi NwXGZY4JKarTovJjlGoSgZpEauSBGoEmnbtUfmT+uoMLy459XLzKDs9fX+n+PU1ZLDta+MmCRwpK qhZsOEJcJjV0OrZww6H80upFH5fwYwtKqwoiK5k1y5YeXvTJ8KH89VULy44i0KSGDtRHFagXbDwa NG6frnAeLTy1oIYXlFQVqJCXE6hJDZwKN1bnlxxS8AwSt08f5I+4QF24obomUG88ikCT6jXlz5t0 yee//KdRJfZv9uSkf/vGLT2yt0dgz5XDx89JHr96QbmGq0ePGPXAPa1+1XHInAhMhbhM+hTrGNbv euH533znV12z1hzSvwUrSx/5xb23vzgyAkc5Vrhxc4c/pGSW1ATl+StKOv/x2RY/uP+NkcsLyo8h 0KQGTAULcy699JLWKavs35xZoy++7MoXx2+KxJ6n5hb2ScmfV1ZTqqdNz/rlT3/x0B/6TFyxj0BN atjKu7i+nb7e8qlhhXtqZHp9RYfnn/he667TVx86rT0Xbtz+t87DJ62rCcsFRVt6/eW1m265t0PK gvkRBGoEmnQuBbpZsyvvejAjr7ZcDmjT7AvfuKVr9vZFZUf0SJdfUlv9Vq6nvcMLN1R5Kjwqx0+c 3Crmzt/HTs8vP567aP5PbvjhS4Oz7r/55gcHryUukxpcoC9o9svB+RU1z4RZ41p+p9mttQJdW1FR WbChpo65piqutHrBBlcVdzR3eVn/Xm0vveTH4yTQGys6Pfro7c+mjpg48ZabW/advxuBJjW0QF96 7Q0pOTXF9Vj6i9dfdNmVz4/fpGJcUFKlUl1b/XZs4cYjC0urFmx0gbpq2syFv/v1nQ8+nZxTdnzR utUxX/zqbxOz2jz00H3dpxOoSQ0u0Bc0u/uvQ9cpIOctWfnYD5t9u3XXzNWHamqmFahLq2sqpz8O 1NWFHwfqY/NXbxuY+NpXv3LX8OJji8sOxr3a8Uf/13nI1KzvNf/PV7J3INCkehXoiy+8/aGWj4x7 5/Di9SX3XPjZf7v+lq5Zm8eMSP7CFz5/xb9/9YX0wtwVK1v/5vXHf3HFE0PLP16wpOx3D9z29auv fyY2p6D8+PCE3932h9nzSqtmz387PmsrcZnUwALdvtN1n2necUTR4vLDgxPi/vPCC2/tMHJx+f6O 7f7voosv/v7PX5q0pnLq9IwHH3zwvj+9nrG8smbBssrBAxPvu+3Ln/3MzyeVHM9dmBfTJnZI3o78 dQcmzCqcuHQ/Ak1qYIH+15iW139vyNuHFpdufvTr115yhQR646QpGTd88z9Vqp/oPXNu0Yb2L/Vq 3erfYgas/3jB0q3P/aLlt7/x5YeeHp5bdnzqW8/9R6uJeaVVOYVFA7M3EKhJDS3Qff7jM9e16zFx QdmxadMnf/vCC7/zWNfMot1xb/zhoov/5Zt3tR5UsH3+gqyfPvjEz9o+npi3x5bKmDThobuuvexz LccWH8tfuf63z7/WZeT6/JKqabPmjVywG4Em1adAj7nykaSnu3d+ceqWuVPjPvtQ36cev+XlEdl3 3flieuGerOzZT8W0HpGz4Lprv/7wgHlZaz3vVkp3v/rya8/ETpdAD+75v5+//Lqrm1/0tQc6TSw5 TFwmNahA73yh3+CnOr7wxVcyC0v2dund+cet7r779ZHz56Z8+wfdsoorOsXc99L4DeNGDbj65pjY GRsLvC3nluZecXmMBDonP6flD+/67jcvu/hzl7fqNnsuTThIDSzQWZf+YnDnXs8+/Nb6vDmjvvpY n+cevvLJ9PlPPNbpryPXFBaXPPGtm1NyVrW8+4f3vj522uoq7/vutOR+Dz2dLIGekPb7f7n429d9 7aLmd/w2pXAngZrUwAI9dPD9z3X+bucRc9YfHpTySotWv3rgpa4ZM4ZdcWW7qcX7+/3xmfZ9p+fm jL3i6hs6jl+dV+ppHbpy2fdaPCqBnr+iuM3D9173tS9eeulF//3ChFllNOEg1a9Af+lHY1+LHfSH LjMGtL71ubEr//zbW16dtnlK3oqU4ROfe67tf8W0Hp0z77prB8/3FcSS3X9+0Qn0Iy1+1HHiih29 n7rtMy/NJS6TGligu7z1l/gZX/nKM5NXbO7yeMxrf/lNTJeRi8sPDJ80p0984rdv/NaLNQI9+N6H chf6NKUw93In0Hf8z+sj185dufLRB25rm7EJgSY1sEB/f1TamAkPPDZo4Mtt/pSa1fVXV/521Mas wuLUUVO7vPHK1d+6OT1necu7B2cs9L0tOZY4wAn001dd03r00orkzo9/qd1QAjWpgQU6eejjr069 7Y5Xx63c3+3+b7zSs+sjHbtOWbV71JTcuJTBd915e5u+0/Ny3rr+O5MX/POyC5Yta/HdUwL9vw/+ vtvMucXlz9zzHzFpxQg0qX4F+iuTRicN+9NjT9x17S/HFe/7889u+VPqmNtu/ebv/paaOGhM25oa 6NMJdJ877kgq0shZ47tf9L1BxGVSAwv082+9Hr+u89e+/se41F//tNPAvz4f8+rIGWP+3PzaG/42 NLPDHT/+82kFet6kn7zea8zyg4s2HOza6U9tey5HoEkNLNCXjsqcueiFlj/5nx/9fuDskq4/vvKx xKxf/vy2h599Y9CMgqdqaqBDCnQrE+jElld3e1sjc7KGXHd3PIGa1NBNOIY++fzSXi1/2j4pNeb6 NoPTkx95tutbI7r9y+cu/0vq5Nd+9eQLNTXQYQV6+Yo2f3uxR857Gjm079P3tctFoEn1LNBj5yws /NndN17wUP9FG/c9/7Nbfter5w86pWWtqZo6bXSrmF+PmpN33XXBBdo+Ipw0vPst96Rkl1QN7Hjn jd1XEJdJDS3Qg1+PL5k2+KULLr2yZd+3R3R7/od/GTmux/db9FtdWLzpd/f++OWxJTUC/fPgAj2u 5HjB8ncevO+VvtM256/d+txTd/4l8z0EmtTQAj04d1X5H3912wV3dZiwfFfnH1/Zqvewn7/2t5QF ewrfKbjnhlvS5iy7J4RA20eEOZnxzb/212nrDw3v+/Ttr00kUJMaWqAHP9l+yfRx/f710ouvfSVv 0tDk+5/tmhj7wGWdlxWW7Oz0+yef6ZMZRqCHFx9buGbLM091fqH/kvyNB15rffWTo7Yg0KT6FOix ze8eV1C6/fnHH/ntgDmLyva9/OStb4zJvfOOH1xw4YVX3PTw7f/vrqee/+vX7h3iF+jSPS93jG3X c25B+fEF67e3a91C81/43WdHraEbO1IDC/SLbwzpMqx00eoFLb7Y/M2CvSP6t3+k26j5OaNVQi+4 6oYf/fTOz33ukbhRQ2KeDRDopXmf//wTk2q6sTsyflTsV7502QUXXXpT2wmzNh5HoEkNKdCF2Z+7 eUh+2f7Y11/85UtJOSUHuzzyxefeWvh464dqAu93Hr3vJ7f99Bcv3/bYkIwlfoFOSkl86Pcjcmu6 sav62/P/rfkvuO6XvefsIFCTGlag+6cM+U23pYVrV3z/isvfyNk9aUxym1e7TsqaWBOoL//Kf939 ky9/udWQKenfahUg0CuXfe+/nhlbfGzxpqPTpo+45TtfUqn+95+lTy89jkCTGkEqPZRTVNM7QU2/ SBtP78SFZdW5a/ZF0pM5cZnUUGlhceX8dTUfueaXVEX0eFmy166C01s7Ak1qkLThcO7qysXWLeOG 6ggK6tG8tXsLSvjFK1JjrgSpzKvtsaCg9FAk8xeU7s8pOhhhoEagSdGdiMukphbxEWgSgZpEavSB GoEmEZdJJASaRCJQk0gINIm4TCIh0CQSgZpEQqBJJOIyCYEmkQjUJFLDC/SHH35EIkVt+jAwLnNY SFGdPviAUk1qaokiTWpqgfrDD5t9BAAAAAAAEYNAAwAAAAAg0AAAAAAACDQAAAAAAAINAAAAAIBA AwAAAAAg0AAAAAAAgEADAAAAACDQAAAAAAAINMD5w759+7bWcuLEicCpGmlTDx8+7B1fWVmZnZ09 YsSIMWPGFBUV+ZY6fvy4FtE89q+W3RoaN1sk2+nbDO+kE7VsDYvmDL+K/Pz88vJySgUAACDQABCS p556qlktUuHAqXl5eTZVruyUukOHDpdcckkzDzfeeOOSJUvcUtJQjezatav9q2WbhcbNFsl2tmrV KtQkU+RmYdGcQTOvqKi4//773Wy33npraWkpZaMJo8e2UA9vGq/yYMM7aonk6S4zM1PlPCMjI/AB 7LRPbtAkUQxJSEjo0qWLQpzKhitUkaNC1bWW4uLiui5bVFR0BitVQdVSnTp1ateuXVxcXGDliLsL ZGdnx8bGau/0d86cOUHrX9xFpDy1L0HzGVNLmMUN3V8KCwuDZq6LTvmHP0Q6DiNOoSvULv+geOto tNTkyZO1iPfu5s0q1PFBoM8l99xzj+7KKo6hJjWeTVVB+XoIOnbsSExswgL98MMPB05t27atT6AV W/VvTEyMAqLCh1xZMfSyWpw6BBVo5T8iGBHGILedbksCBVqxz5vznXfeadedGxM0BGspPQBo+4cO Hapd0F8Nq8AfP36c4tFUUWlU2bj99tuD3KuaNVNYtmELfeFvzCp+n/3sZ73PaXrM84pLmCc3aJJI B128clxyySV9+vSJPBPN7JaVodZ1GxR+taBCceTbLBX21YxYqPc9Q+rB4Prrr/fNpjGhFFY560LT PJLRoBt52sOiNX7hC18IvIhSUlK8l16bNm1CibjdktwdxNYbFHd/Uebeo3HrrbfaRe3NKsLaHwT6 HAi0TkZgtVZjE2jZzD0BNG/ePJJSDtEr0HJNlU9fAwkFo6uuuspipYUVjZFctmjRwhenMjIyNE/7 9u3DCPRZxhrbToVLRVJfQHcCHUqsw+es24bvFpWQkKAx2infnK1bt+7QoQNlJtrRjVAFyQp24F0/ coHW45Zio7Jq165dXl6eSpqe0DRs72RcrTMCfb5hfvboo4knDoIAABfeSURBVI+qdClUKq4qvKhI BJXIUNx0002BsS5yMjMzVeoif5Mm+zRN1KZa3YGWtcKsQu42Q5N0RegukJ6ebiVck+Li4nQVXHPN NaHa4+nS0CK+3dElo6Xuv//+8BumY2gG4ruI7O2oDrI2Q1tlx7xLly5hBNrJsf7t+s907NhRG6MV 2f3C5tdtURusM6gFNVX/+jJEoOtPoK3Cw2cejU2ggyq1ir5K+WlfskD0CrQpo68Vh0KwhSQXemQe FrMC6xhiYmI6der0aQu0InVgQ46zFGjd2Hw1kboNaBcC337qzuHUCqIXK0USBf2VIpyxQIevV3M5 I9DnG9fU4rtj6nHLJ2HhUcGLfOazRJFfpTToXd4uFqe5pq2BwdxuE0OHDg2/CndlSUyvuuoqHaUw rZukxX369LHXm4EXkbLSeK+yayPl6EHfHPoEOuj9RWdHe2f/2pOD9+nadzdBoOtboJ0BhBdoFQgV NZ0YlUXvLXzFihU6Z97iYt882TmW5nqb6dgzn3d+a7Sk4qgNUCmJ0IZVFlu0aKGCThu+pi3QpaWl Cka+Vhxt2rS56aabTH9d6FFYV6DRv2FaOHx6Aq1SLX33hcKzEWhdIJrHmidZq0E9NoTaNQS6aaBH Jt25NSBBUbH3vXiJUKDNJII2fFJ0VdjU5eMVaAXz2NhYDXTo0MHbbKmwsFAKrgCrQti+fXsXxjWP nkhtfndfdxeUpqpgy1o0g64si8+6FygTjVGQ9+2UN7egDZngHKJCpTIWOF6nwCsAdgZjYmLsTa+m 2nnUCdKZUibNmzfXgHv3q9DUunVrm1kFz/uKrE8tKjz316ICU6caaMV5RfVQodLawplpqKwGbY+q xwOV3vAtRrTxtqwuEOWpNYYviq7tn/bLJ9Aq3lrcd/WlpKSEau4SXqCtqsjbSNXaLnrryzXVq9QI dH0LtG7Vitq+hhw+gVbp1COUxmhOlQ/NrDJhk9LT072VfyqCWlbzWMDVsC/Qe5tAKXYroOtfqbDl rwsmEie2t9thHiuhaQi0Qqfu995WHJJIRfCEhASfQCs8WX2ACbdmCGzEXKc20HXdTpVbK8Yuup2N QGvjrXlSq1atXMs23beCRnYEuglgN2N71avIpmGF1jMQaJlohG/k7c24CpXKrQas1aZ726NSqlVY Zba7auxLAxVybYnuBRqWfLhaD3sJowtQk6whinKQTlm7FK3FuwsuN413ufFBy6eKPeTrzIb5wMNe 7eoU68xqTisA9umFYqzOlKKxFQBrNmYCp9k0s2K1tWpwIqvZdE/XSOWpYqDCEHkbaEVUa64QagZz D/N4uYQ2zJpwRNiBkre2QjuoxU1PT2ufVmloTxo+gdakwAYbdt8J+rFZGIG2Rik6dN5nTntOcC+R 5GzWmtFdgwh0fQu0BrKzs30NObwCrciuoq+p9jGWSptdh+6Jyj58sZBtXxi4Z9PwAq1yoFKrMmeT 7LZx2hhql4ouSwLi+SDQVqPm7uv2UG4fUPtCj8qnSpRFcENlz/uUVadeOOq6nS66uYYcZyPQtqm6 UclsJM2aWfceu7HZ+59IPjeBKMJu3hZjdctUiGvRosUZCLR12xJJp4dWWmJjYy3sFxcXa6WuhtJK qcK+jEohWqXOXnYr2tsd3fq9sRy8Gbq6FfNj5WkV1Zrf7hQW8O2mo1uJvVdxuQXtdQfOCa7GymKj FFnh0deaWeXHV5vWvn17r/J6H9dVzOwhyrsK+xzFKxIqSzq/MgfXJjgSgbYYGKaVkQKjdwaFX/u6 TrqisKni5JpNnxZlZQ+QMTExkTcKDRRo22Z3CTjNDSW1YQTami/qb+B4+5rcPhDSFeo9WQh0Awj0 R56mnIGTdHn4XqOoUOpG7h4N9aQoa7nmmmus9b23CIYXaE1VPt4HLJU832vBQOyRN2jvM9D0BNo+ GXQvxTRgBS9QoL2VKOnp6RJZi4kumgQVaK0oPxhnINCujse26uwFWoHS+0LGvom07fd+bqKLSFeZ +7fe+jCCc4VioM61t7LNvp3ytn+LUKAtdJ+2hb1leP3113vHmOB6S6k3GtsN21u9p2vTqpZdhl7p t9o4r13ZFWev+AObiio3720FPg3syzNZsr2vM93UuXZ3YQUW3701sLGcK4fSZZ1NX3sMnUFXOK00 eh/n6irQoT6/C+qv1vjkpptu8r61i6RCQTti78Dr9FVAKIH2rdFmc5/iRCLQOk3Na/E9AGg77Q2/ 7m72jkib7X1VhUA3jED7GnJ4J1mbep9eqIxqZpeVVSfovGpmbwvp8AJtLTGsK7oIHxbN3cN34QRN SaCtcs5acVjNnFUq+8K6/V6JL5Pi4mIVSHfX/1TbQLuHSa1RNyeNORuBNvnwfZWo3Q/avJUmHNGO FUXFQ9ftq41x7ZU/qmMNdIQCHfSzV++w9/lN11Gg3Vr1pBmST5fNG7zXl/eaVW7yA1+fA/YmnfJQ PyatxzMVOWts4w0gNklhVs6naGNmGVSgXdCTcyckJKgwWFsgn0CHEoBIBFrBP/wMQZVXAV+bZDeO SF5rxMTEWB81deqQJJRA+xpfnUENtL3MDFzEHmJdQz73Vsc1B0CgG0agP/rnhhzeSWFec3vrD6xF v68BRniB1op0iVrbOKtvU/wNH/rtDb57aQjng0C7VhxC0dlu6t6bsd3FXVsgL/Ye2SJOPQi0i30q +Wf/EWGgKyPQTRLX1Diwj15vr3ORt4EO1UGv7uUuaAfKR6BAhxduF8/t+gqsDgwj0Bbwg3btT3n4 NNB5LyoqCmwffPz4cbvd2+sOnUrXm7KEsnUtYQRa5c1e9Olsyp4lAFrqnAi0tYEO2ie6YR/n2Wvz HTt2BI3/2uXA1lA+rN2pbiK6OqyFd4Sd9IVqA+27p9h9J2h/u6EE2t5k+hpiBa7uo1M9ULkHVwS6 wQT6I09DDu8ka1EU9NdxfNKgS0jlz/sGObxAu6coXbQab29egn4m7LA3m/ys8Xkl0NaKQzFF7uj6 LfLejK11ZmDPX8I+wvN2Nf9pC7QLf1Zzc8bd2Oly0F57X8vYd2aBG4xARzVWQaWC7XvLZ11WuWZ1 EQq01YO4vs+Dmrr5QV0FOmgNtG2kFeY6CXSduk6Ds8d0M2hdrH19ZF0YNW/eXIFLpchFnjBNOFyz eG80ky2cE4F2tXKhbvcmDDZVw9KPoC+xrWONUKuw1s8ybFvWjpI2O5KW0IFGaxUf3hdH7vAGbXQa VKDdzxr4ZvZ+Z+x7snVnBIFuSIF2DTl0AbhJuh4Ci2ZCQoJ7T2FdJ0p8rdMxFWU3s/3cSWCMtutH hdVXdE77/lGbRxXF+SbQdp+2xzN3A/CGdevW0GKZ69BHy1rNtOsiJqhAd+jQIejDoauEsB+IClUm g9qwNeSwWpwzFmjbvLZt21oo17Up+9ERCLydKLDS7jl6CfVRh0qgt5lyhAJt7ZKD/jyWubXLpK4C HdgGWmhdujCDZhheoK0w+3JTaQ/aVBTOHgVGa6Tu60nQPfBrBqtA9ZUKe0YKKtCus1GvQpg/nBOB tj7RVVQCt9mqjV3Nq11Ega+m7aNGOUzQ/BWoTXi88dPqXCL5gbagVcK6THxtl/WAEfhzYGEE2rpg CvxtLB3bwMdOe/x2lUcIdEMKtAuy3o4I7JnMW71n7Sjcq2RZr+u3zmZ2DTnsynSfwugStW8X7Pqx 3zRybabtpzVDFbWPTr3TCfy9DGjyAm0fXHvLhq9eRLahKBn4EjwmJsb7fUzkvXD47gGhIn4oG7Z3 Mmcj0O6uoBCvbZCRW0fXlI2mhH0tpJMbtMbLKhSsPUbkP6Ri2qFsMzIy7Eauv/ZT8F5XqKtAW3Wj t98Max/lon2dBNrXp8dHpz6JoSe7Tw/r6eXGG29UYZB42W8yWAsNa5yjO6xVx9qDjU6x5rQWGkEF 2n6mxGmrbuVWZ+yeqU4r0NZB+GljoLZZBUb5q7ToXmDb7P1ZTU2y/pc0SeVfu6Yd1CLWHCVUs2a7 vnydZigrC7ZB24ScVqDtU2+NtMvE+trzvhHSJFfIgwp0mO/jXUd7lnl5ebl1lU0/0I1FoF3odJN0 FZkH61SpHCjk2c9jmgH4jNknHNYvh6K2irU9h1nRt6kq6PYzlVqjcrY3MmGe/Oq5cEADoiipCOJ9 lNK/erpz/yp2aIy3OlYFVeXNIrIFKZ/1KjLabz14cwiFi7n2a7e+3wMKs51ehw46KcwiQfPXpWG7 QzVz08MqI4K2PnI3Y6syiFygTU+tBZFVB9qnVNICb9vougq0sxnrudneUiqqe/uBjlygfbm5T9ki vC7gzJ7WFExMiL3opuwOuwmuNU9XEdKN3hTQ3eK9Ai1/tQ/vdBO3n7JSWbVmlvYG77QC7X3XHQpJ vBVmh/Uc4vvJCBlzYB2KFgz1exHWT1xgs353VapMhi+NQQXaFWwdQ9f3uTcfb+1MUIEOU0mvfKyC 3E6Q7aD38QCBrj+kqqG+YNWDjneSLjxFZJ05PZuqNOi508quHoPa1eJ9YWH9D7iWOjIAXVSSYy0u AVIp9/4QkbxE/+qxVTPoMvYaUiB6IrROxwiFUG+obCsO1rVzfoBIUADU7TPU6wiVPU21ZksacPo7 uZbwOStES30UnBUzFc+lEb4yrAx9v8tjj3aBw74gbL8dKBXzfaroy1A3e+/zatCHXu2+5abt1NNC 5F3wwhmjgqHCExsbK81SCQlsEqZTHBcXpxncr5/qtLrqWF+DMc2g3JSV++2qiooK3aPtxbLG+O7X vp8itna9kQRh+8VirUiXQ5iP/IqLi7VTms22P4wBa6d8P6LsuzA1NfzPummrNE/QX1XUjtsxDPyc V4u46phQ3d5pfJhOybS4MrdD4dt+BBoAGhEdO3YM0xcpAACcGbLYUA2UzwfC/5T3GWeIQANAo4Ba MQCAT4NHH300VOu480eg27Zt63szcwZYA0X7LAGBBgAAAICmLNDGWdZDe7NCoAEAAAAAGiMINAAA AAAAAg0AAAAAgEADAAAAACDQAAAAAAAINAAAAAAAAg0AAAAAAAg0AAAAAAACDQAAAACAQAMAAAAA INAAAAAAAAg0AAAAAAACDQAAAAAACDQAAAAAQF0E+uTJk+8DAAAAAEBkNNuzZ886AAAAAACIjGaV lZV7AQAAAAAgMppVAwAAAABAxCDQAAAAAAAINAAAAAAAAg0AAAAAgEADAAAAACDQAAAAAAAINAAA AAAAINAAAAAAAAg0AAAAAAACDQAAAACAQAMAAAAAINAAAAAAAAg0AAAAAAAg0AAAAAAACDQAAAAA AAINAAAAAIBAAwAAAAAg0AAAAAAACDQAAAAAACDQAAAAAAAINAAAAAAAAg0AAAAAgEADAABAU6N4 3fqZs3IyJk6Zmpm1ZOnyg5WVZ5nh3r17s2bOiWTOqkOHVhWtmZE1S2vXNmzatLmu6ypc9LaWXb1m beAayzdtXvHOqjrltmXruzYQZvu1xvK6b+dpt2379h1aqUv5BYU73nvvnJxf5aYzEnRSZWWl22UE GgAAACAiFi1eMmlK5say8t2792zbvn32nNyZs+eeZZ7KatiIMZHMmTevIHPGTDmcFllfUjpq9Hht SR1WtGePFpFoSvqXLlsR+GAwP39BnTZbLm7Dgbl5fVQ5n/1Di2/bNm/eMi5jsv4q6UFCmj567IR9 +/ef/SnWvhw4cCDopGXL36nTIUKgAQAA4HxH6jly9HhpqBsjE52WmW0VlpWVlevWl0q/vBWumrSq aPWKd1bt3LnLjZT12mxS4V0VFV6BlgLa/IH1qZpZjuh1u9Vr1koc3VTpncbYDNqwktINylxZrSpa o3+V3llZNHbcRMmohp3U2jxr1q5Tcna4ffsOW9CtTrlpO70jLTeNN8F1Vq3t1945sw8q0LJeba1y 04pC5W+5aS3aMO1XoEA7fTcyJkzRQ4V2R4dCa9RSp47nGq3LrciOuUYqZ+XvBF2PQ1q7Tq4dH43U Zmi9blmdyjlz583ImmWV0G5PteVVhw65nJXJho1lKgneTdV4BBoAAADOR+RGs+fkBp0khZJazc2d L2/LnDEzb16Baei4jMlyLLma9M6cUv9OzczSbMpKU6VrTqBr6nQnTNEM0jsN+Fo+LFm6XPkHXbs8 b+KkaebTWlAWqKxGjR4vedXImbNylKSDVk1rNay2Rmm6tkH7pcxlwyapkr9JUzK1oEZKUq1aVwtq B7VhykoD1bVtMzRSEqlhl5sy0c7a9liji0CB1gboEOkIaEAPJPZo8Un+s+dqqpm9ba2SBsILtPZI 82ik1qVtUCYLFi624/n2kmU1x3PiFFNq5aNhabGS5jS11fbrQSh3Xr6dC/3VXusgaFnbFx0TjdS+ 6NzJj+242Z5qNh0oy3nK1Bk69VqRcjbtVsHQnM7UEWgAAAA4v5AhOY2TEpnbKUmVJFWSJ5t0sLLS WkrIpVzbBs0g06qsnWQ6JbWSmXkFWs4nY7P5ZdtSulBr97n7qFMaWl3bzEM+97EI1laWyxE/EfRT 0mlj8gsK3RZq7Za/pPPdd7edGrnIZjCtrK6tiA2V25at7zrpl7NaboECLb90QqmpVlmrHKzS3cn9 osVLlGw2HZZAgdZe2zHRLmtL7NlG69JRtXm0uHbKhrVtklo7jOa7lq2tQmvctn272xdtnuZxa9Qk 21MdChupMTqhNtXaxFvOboPdxuuARNjAHYEGAACAJoj8ydUBO4GWWkmhnFp5vXBqZpY8z81vZjYu Y7KbTebnFWgtJclThjVpwpSRo8d71y7by52X71NnGbmvCbXVbXtH/lMN9z8rr9durZ3xvv37NUlr t81wVb/eVYTKTdtjlfR6llAOoQRaC0ouJZ0yXUmwTQ3M37ugbDVQoK05iiWnvxp2wqpVeFdtTxTK x1m+c19NsmYYTqB1arTv7lzYJrmzbF9zzpk7z/bU1qhJbnV6GNB4zWanGIEGAACA85TAVsjO81YV rfa2r5A6y9IkZ9ZEWOzcuUuyKD0dMXJs5amOO2xZJ7gzZ89dvWatTdI8vhVt2rRZ8l3p6fTD2lqY 8rrxUlhJW4QCLdl1a7R2xnI+TXLdUGgbLOdIBFqKr114991tBysrXavlQIGWNy9ZutyqzGdkzQol 0NJTSarb09O2gQ4UaG8OVrGtDVM+roGyplpjG9/atWv5BYWu3w8dE2vH4gR62fJ3MmfMtD3VE0ug QItpmdnyfln+2ffTgkADAABAFJM7L19iJJOWVNkHgtJiufKuigprtlFd2/pCnm0f7UmtNKCZFyxc ZPXHUkzpY2XtR36Saa9ASzqVuXlzjYzWVo76ZF1SaA0ztA3WhFrDkjkpXXXtN3NS6vUlpREKtORP a7RPDDVgdmgNiKtPfSLpbeXsE2htwEGPXkvHbTO0C1rQnigCBVp7bRXG27fvGBm6BlqaO2XqDDN4 HYozEGiXg/d4Kh8N2POJptoTTqBAa7zyt0Mtk9YTkXmzjr/OpvTaPt88WLttQQVaZ1M5RGOvHQg0 AAAAnEuslYLES5olY5Zruo6BN2wsmzhpWsaEKXJHa0OsmaVZskyNlD2ba0q7NSy1koRpzpreJ/Z8 4rXyvJrmExNqunkO7I1YOWgp2XlNK4tTX8VV1/ZPV9M1dW27C6s39ebphjVg3/8JN3XR4iVaUFvu mvBqvfaBo5K239o2eG3VhuWgyk3zaAYbo72uOQITp9R+DrjahFU766rhDW2hlpLoy7D1XGGCHph/ dW2Nr+ZUnnnzClzzYkPrcvviRevyNnSpaWMzYYoykfja8dRualh52vedvjXasPNmDWs2+bHVl8v4 bWP0AKDt11Q9uugxybZEW+jdUwm6Hg9cGx4EGgAAAOAMWbJ0ubUHsI8IXeNdqB989cSfHrsqKoLW kSPQAAAAAHUWuBlZs5YuW5E1c06oTvEg2gVa59c6FkSgAQAAAM4B1l3xprP+gWs4A3bu3BXql7rP 7Skuj9rzi0ADAAAAACDQAAAAAAAINAAAAAAAAg0AAAAAgEADAAAAACDQAAAAAACAQAMAAAAAINAA AAAAAAg0AAAAAAACDQAAAACAQAMAAAAAINAAAAAAAIBAAwAAAAAg0AAAAAAACDQAAAAAAAINAAAA AIBAAwAAAAAg0AAAAAAAgEADAAAAACDQAAAAAAAINAAAAAAAAg0AAAAAgEADAAAAADRR/j/NMOen SEVrTwAAAABJRU5ErkJggg== --089e0158c5aa53ecbb04e125303c-- From phdgang@gmail.com Wed Jul 10 03:16:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5F21F8DDD for ; Wed, 10 Jul 2013 03:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 byyw2aiHnXHF for ; Wed, 10 Jul 2013 03:16:52 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8621F8D8C for ; Wed, 10 Jul 2013 03:16:52 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so3593533qeb.4 for ; Wed, 10 Jul 2013 03:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oswNdjpe0c68icnVRUp2cQOQLSZKu+c2m7lg0VTGsDg=; b=vryGXasV2bPJ9PWPN5V2jj1m5LrUbDT+bv48XeCc/N+DcKPWSWaNmb5NMd9XSUu7FI 1t+edACFPe5/0Xsq8+z8E+iNplm+fcP14Zgr13Wor7u9In0wpK7Kkb4koReHS7sUNYhG WUeD6h+hBwCOMdimZJqM7pik/xjtearP4MjvcIVL6Gk0tlAiAWj97n+lAc9YrRVwHwkb 66xW5si4cCjnp5D2AWxgk3rpUCVu/sYXeAdVvOEeREuQUrGH9WrvLQkMcqrzMgObrTs8 kuNTWoy/D/gOT4dwIHE2ahfGR0pf3YJdfu8vImKmb3G+Sev60qRqgVAOkaVWHqS+1QlS qUog== MIME-Version: 1.0 X-Received: by 10.224.212.199 with SMTP id gt7mr27525471qab.80.1373451411893; Wed, 10 Jul 2013 03:16:51 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Wed, 10 Jul 2013 03:16:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jul 2013 18:16:51 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 10:16:53 -0000 Hi Mikael, >> >> 1. "Single stack IPv6 network deployment can simplify the network >> provisioning. ". I would remove "the" frmo this sentence. >> >> I think it's good that you stress the benefit of having access being >> single stack instead of dual stack. >> >> 3.1 >> >> I think it might be beneficial to say a little bit more here why 464xlat >> is important, perhaps just one sentence "464XLAT enables access of IPv4 >> only applications or applications that call IPv4 literal addresses" (or >> similar). Will add the texts to describe the benefits of 464xlat >> About geo-location, perhaps it can be adviced to chop up the outside IPv4 >> address pool so that IPv6 addresses are NAT64:ed depending on their >> geographical location (we're doing this on a per country basis). That is an interesting use. How do you implement those IPv4 pool allocations? I heard some NAT64 implementations could allocate different IPv4 pools to each inbound interface. Are you doing in the similar way? >> 5.1 >> >> I would like some text on "port block allocation", where a customer gets >> 512 or 1024 ports, this is logged, which means as long as the same >> customer still has this 512 port block, no further logging is needed. If I understand correctly, that is a static port block allocation. A port block would be reserved to a particular customer. No logging information needed. will clarify at the next update. >> >> Apart from that the document looks good, and nothing more came to mind >> when I read it. Many thanks for the review. Best Regards Gang >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Wed Jul 10 03:35:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679A621F9C37 for ; Wed, 10 Jul 2013 03:35:48 -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 dqVZVPa1iHrc for ; Wed, 10 Jul 2013 03:35:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74921F9C13 for ; Wed, 10 Jul 2013 03:35:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A3E5C9F; Wed, 10 Jul 2013 12:35:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DC2139C; Wed, 10 Jul 2013 12:35:40 +0200 (CEST) Date: Wed, 10 Jul 2013 12:35:40 +0200 (CEST) From: Mikael Abrahamsson To: GangChen In-Reply-To: Message-ID: References: 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] draft-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 10:35:48 -0000 On Wed, 10 Jul 2013, GangChen wrote: > That is an interesting use. How do you implement those IPv4 pool > allocations? I heard some NAT64 implementations could allocate > different IPv4 pools to each inbound interface. Are you doing in the > similar way? Some vendors allow certain IPv6 source addresses to go to certain outside IPv4 pool of addresses. > If I understand correctly, that is a static port block allocation. A > port block would be reserved to a particular customer. No logging > information needed. will clarify at the next update. Well, actually the block would be allocated upon first traffic seen from a certain source IPv6 address. Perhaps there are references to this in other RFCs that could be useful. For instance (I'm sure there are a lot more): http://www.ietf.org/proceedings/86/slides/slides-86-behave-2 http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/cg_nat/configuration/guide/cgnat43cgn.html#wp1015343 Bulk Port Allocation The creation and deletion of NAT sessions need to be logged and these create huge amount of data. These are stored on Syslog collector which is supported over UDP. In order to reduce the volume of data generated by the NAT device, bulk port allocation can be enabled. When bulk port allocation is enabled and when a subscriber creates the first session, a number of contiguous outside ports are pre-allocated. A bulk allocation message is logged indicating this allocation. Subsequent session creations will use one of the pre-allocated port and hence does not require logging. -- Mikael Abrahamsson email: swmike@swm.pp.se From phdgang@gmail.com Wed Jul 10 03:50:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52C21F8EEA for ; Wed, 10 Jul 2013 03:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 dMklOcs1A90G for ; Wed, 10 Jul 2013 03:50:54 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BC21F9ABB for ; Wed, 10 Jul 2013 03:50:53 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so6867189qae.6 for ; Wed, 10 Jul 2013 03:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b/74FYsZO1Kxcdn6g4G6zu0YLmLtczblW4PFrhOIx9U=; b=piU6YAOJwPpuxbl2C/Ysxbb+dz/9PsTir4AEDFwjNOKnWHhFdL1DySm8moBVo25lPW auwE+gEnYxWBq6+Ga2JPpXjQ+wfPEhWyyBEisMvwE2hisESDzNHRnU74FEpir8y4Dhf1 7kmEGhutTgQ9gdrcwPLH+xym7KkxAHSMVN+vGQOQ6aQLV4vJ3lEs6M48KMYrRcNUCApA lGWWfw1S0nqGIcQjqGCpDvVbh/VRb0CwpUiURNW5aKFn2WufEgzOD56HHZ9tdGg6/NPd wDCsg7ocISrK0tXlyT5eLiX8ZBmsqJGOPNfOcLxA2QoaiZP+0/RHyGIwY/26hdXTutXq NFiA== MIME-Version: 1.0 X-Received: by 10.224.212.199 with SMTP id gt7mr27630443qab.80.1373453451140; Wed, 10 Jul 2013 03:50:51 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Wed, 10 Jul 2013 03:50:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jul 2013 18:50:51 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 10:50:55 -0000 Many thanks for the information. The next update would catch those two points. BRs Gang 2013/7/10, Mikael Abrahamsson : > On Wed, 10 Jul 2013, GangChen wrote: > >> That is an interesting use. How do you implement those IPv4 pool >> allocations? I heard some NAT64 implementations could allocate >> different IPv4 pools to each inbound interface. Are you doing in the >> similar way? > > Some vendors allow certain IPv6 source addresses to go to certain outside > IPv4 pool of addresses. > >> If I understand correctly, that is a static port block allocation. A >> port block would be reserved to a particular customer. No logging >> information needed. will clarify at the next update. > > Well, actually the block would be allocated upon first traffic seen from a > certain source IPv6 address. Perhaps there are references to this in other > RFCs that could be useful. > > For instance (I'm sure there are a lot more): > > http://www.ietf.org/proceedings/86/slides/slides-86-behave-2 > > http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/cg_nat/configuration/guide/cgnat43cgn.html#wp1015343 > > Bulk Port Allocation > > The creation and deletion of NAT sessions need to be logged and these > create huge amount of data. These are stored on Syslog collector which is > supported over UDP. In order to reduce the volume of data generated by the > NAT device, bulk port allocation can be enabled. When bulk port allocation > is enabled and when a subscriber creates the first session, a number of > contiguous outside ports are pre-allocated. A bulk allocation message is > logged indicating this allocation. Subsequent session creations will use > one of the pre-allocated port and hence does not require logging. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From fred@cisco.com Wed Jul 10 05:45:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6821F9F00 for ; Wed, 10 Jul 2013 05:45:07 -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 hRHWexOsbR3k for ; Wed, 10 Jul 2013 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F521F9FE7 for ; Wed, 10 Jul 2013 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1373460302; x=1374669902; h=date:from:message-id:to:subject:cc; bh=s5Fa6LmdQ4J2FNx7RD6/1X4KdT0SgIjw9Wxzn20Y6a4=; b=lChJtjsOqhNFfadkrWOB5WXAbfaODGRxVmPGDyfwn4OPRxwfrvdc0vwj HDxi9ZX8Smpssll+raEwh8zxSyY1DN07RC9jdTajRCb9PrUNJGSdD0J0h QVw/4jjvMf5j0rfr1O/Z37pajKA1Ov5zmplEcPfs5MI6kpjZlNRDnlZ2u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcnAO5W3VGrRDoG/2dsb2JhbABagwkygw+sXgGLHIZLAwEDAYEPFnSDIzwtB4hvDblkjlGBEh2Cc2wDiSWPW5AhgzE X-IronPort-AV: E=Sophos;i="4.87,1036,1363132800"; d="scan'208";a="85620465" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 Jul 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6ACj09K016270; Wed, 10 Jul 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r6ACj0B14006; Wed, 10 Jul 2013 05:45:00 -0700 (PDT) Date: Wed, 10 Jul 2013 05:45:00 -0700 (PDT) From: Message-Id: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:45:07 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please take a look at it and comment. From arturo.servin@gmail.com Wed Jul 10 05:58:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76921F9F1B for ; Wed, 10 Jul 2013 05:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 T5gCQ03hTdkg for ; Wed, 10 Jul 2013 05:58:08 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DC3C221F9F17 for ; Wed, 10 Jul 2013 05:58:06 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b20so2758031yha.18 for ; Wed, 10 Jul 2013 05:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=+o1cMcgsmcrRV3Z+WOaj6toUy5ZrpzrGIjFmqsR5MQc=; b=u8+DLiEFyNK+J286nOLWGwDeufwVYZlHTXOI8x8qiUGZKLhRYDSjtjwDb+3IV3fUtd KaVSnP/9rB+58qCK4XhASvFy0TsuVLHC/AI0WXRr2loNOW5aN9L6/gol8T8R707Y+b9r EaGRqjRF2PIMX8U/IHOcnnAK5JX38Wu59wgyuJrH4Ydb3a1eqb22o7UpSFuuykq3umMt 7S1qydhwxQZ3Kxh0nuUd69fLV7pOdOB7EsuMjwawa0pnZP2nEWnjMZwgpTvSXbBYCXz6 VmMOQY6BCrKaluyTrhXNidE3Icdc6Izr0N0n4Z2FGQzXnrmQ+CKrlAxz+RQPxDVD6XNp T9og== X-Received: by 10.236.132.170 with SMTP id o30mr17746892yhi.136.1373461084524; Wed, 10 Jul 2013 05:58:04 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([200.7.87.33]) by mx.google.com with ESMTPSA id i4sm15216441yhg.16.2013.07.10.05.58.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 05:58:03 -0700 (PDT) Message-ID: <51DD5A5A.3090506@gmail.com> Date: Wed, 10 Jul 2013 09:58:02 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Erik Kline References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030109050101040700030505" Cc: "Bajpai, Vaibhav" , "v6ops@ietf.org WG" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 12:58:09 -0000 This is a multi-part message in MIME format. --------------030109050101040700030505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Is the destination the same in all the samples? (I assume it is and that is why it is so weird but better ask). Regards as On 7/10/13 6:48 AM, Erik Kline wrote: > On 10 July 2013 18:23, Lorenzo Colitti wrote: >> On Tue, Jul 9, 2013 at 4:09 AM, Tony Hain wrote: >>> If the IPv6 path is not given an automated preference the traffic will >>> never >>> move. Even with emerging deployment on 'services', the cache topologies >>> are not identical in every instance, and getting them there requires >>> demonstrated traffic. >> >> Actually it's worse than that. Even when topology is congruent and IPv4 and >> IPv6 have exactly the same latency, a "use the first connection that >> completes" implementation with no preference will use IPv4 50% of the time, >> just due to statistical noise (introduced, if nothing else, by hashing along >> the path). >> >>> Apple's implementation is "not helpful". They start by refusing to allow >>> modifications to the 3484 policy table to meet local policies, then follow >>> that with a refusal to ack that the IPv4 cache nodes are generally closer >>> to >>> the request than the IPv6 ones, so traffic stays on IPv4 when it could & >>> should have moved. >> >> They also bias in favour of IPv4 because they send the A query before the >> AAAA query (or at least they used to). > Some data. > > Here's a slide from my presentation at the IPv6 congress in Paris this > past March. > > The pink is % of connections that arrived over IPv6. The client > population is a set of gigabit FTTH native IPv6 users, where IPv4 is > provided encap'd within IPv6. > > The mapping between clients and HE implementation is basically: > > Nexus 7: basically a special subset of Chrome (below) > MSIE on NT6+: the well-known IPv6 probe on network attach > Chrome: still the 300ms head start from just before W6D in 2011 > Safari on OS X 10.[78]: connection racing > > Even when IPv4 is provided as an encap'd service in a native IPv6 > network you can see that connection racing does not help the provider > obtain much of the return on investment in IPv6 that might have come > from migrating traffic away from IPv4 (e.g. in a CON environment). > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------030109050101040700030505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Is the destination the same in all the samples?

    (I assume it is and that is why it is so weird but better ask).

Regards
as
On 7/10/13 6:48 AM, Erik Kline wrote:
On 10 July 2013 18:23, Lorenzo Colitti <lorenzo@google.com> wrote:

On Tue, Jul 9, 2013 at 4:09 AM, Tony Hain <alh-ietf@tndh.net> wrote:

If the IPv6 path is not given an automated preference the traffic will
never
move. Even with emerging deployment on 'services', the cache topologies
are not identical in every instance, and getting them there requires
demonstrated traffic.


Actually it's worse than that. Even when topology is congruent and IPv4 and
IPv6 have exactly the same latency, a "use the first connection that
completes" implementation with no preference will use IPv4 50% of the time,
just due to statistical noise (introduced, if nothing else, by hashing along
the path).


Apple's implementation is "not helpful". They start by refusing to allow
modifications to the 3484 policy table to meet local policies, then follow
that with a refusal to ack that the IPv4 cache nodes are generally closer
to
the request than the IPv6 ones, so traffic stays on IPv4 when it could &
should have moved.


They also bias in favour of IPv4 because they send the A query before the
AAAA query (or at least they used to).

Some data.

Here's a slide from my presentation at the IPv6 congress in Paris this
past March.

The pink is % of connections that arrived over IPv6.  The client
population is a set of gigabit FTTH native IPv6 users, where IPv4 is
provided encap'd within IPv6.

The mapping between clients and HE implementation is basically:

    Nexus 7:  basically a special subset of Chrome (below)
    MSIE on NT6+:  the well-known IPv6 probe on network attach
    Chrome:  still the 300ms head start from just before W6D in 2011
    Safari on OS X 10.[78]:  connection racing

Even when IPv4 is provided as an encap'd service in a native IPv6
network you can see that connection racing does not help the provider
obtain much of the return on investment in IPv6 that might have come
from migrating traffic away from IPv4 (e.g. in a CON environment).



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

--------------030109050101040700030505-- From v.bajpai@jacobs-university.de Wed Jul 10 06:16:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9888A21F9EF1 for ; Wed, 10 Jul 2013 06:16:25 -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.322, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5jWpCTM+R7HX for ; Wed, 10 Jul 2013 06:16:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3F21F9E7E for ; Wed, 10 Jul 2013 06:16:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDF8720BE8; Wed, 10 Jul 2013 15:16:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vTtTDnGB2ZTB; Wed, 10 Jul 2013 15:16:19 +0200 (CEST) Received: from exchange.jacobs-university.de (unknown [10.70.0.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id A6E5B20BE1; Wed, 10 Jul 2013 15:16:19 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 15:16:16 +0200 From: "Bajpai, Vaibhav" To: Andrew Yourtchenko Thread-Topic: Some comments on http://www.ietf.org/id/draft-bajpai-happy-00.txt Thread-Index: AQHOeY4AKuF20t30cUWskXYfpPbiBZldyrAA Date: Wed, 10 Jul 2013 13:16:16 +0000 Message-ID: <26BEA367-1EFF-4A69-A828-BFDA6E737893@jacobs-university.de> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.226.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B1E73D438C1D247ABC02559B05AD302@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Some comments on http://www.ietf.org/id/draft-bajpai-happy-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 Jul 2013 13:16:25 -0000 On Jul 5, 2013, at 4:30 PM, Andrew Yourtchenko wrote: > a couple of comments re. the draft... Thank you so much for the review! > First, the overall goal. The RFC6555 was not designed to get the best pos= sible > user experience. It was designed to (somewhat) minimize the degradation o= f the > user experience in case of nonworking IPv6. I think I did not catch it du= ring > the live presentation in Dublin, but reading the draft I think this is a > misunderstanding that I need to correct - please take a second look at th= e > abstract of RFC6555 as well. We understand it's a policy discussion to facilitate IPv6 adoption. We will add a section in the draft to clarify the motivation of RFC6555. > Now a couple of nits to the text: >=20 > " It appears that an application never uses IPv6 using Teredo except > when IPv4 connectivity is broken. >=20 > This is expected, it was deprecated because Teredo IPv6 connectivity is b= ad. Yep! a reprise to confirm that happy eyeballs is doing the right thing here= . > " We noticed, that a 300ms advantage > leaves a dual-stacked host only 1% chance to prefer a IPv4 route even > though it may be significantly faster than IPv6." >=20 > This 1% is in aggregate is a *good* thing, and why the 300ms delay is in > place. We are not arguing that happy eyeballs is _not_ doing its job. It's=20 definitely improving the user experience by orders of magnitude when the=20 user has broken IPv6 connectivity.=20 We argue that since applications on top of TCP will not be happy eyeballed only in scenarios where IPv6 connectivity is broken, but also in scenarios where the dual-stack host enjoys perfect IPv6 connectivity, we want to=20 measure how much imposition does such a user experience in reality by=20 measuring the effect of the 300ms timer value.=20 > We, as a community, want IPv6 to be deployed. If the HE was easily swayed= back > to the IPv4, this would result in a huge stress to have IPv6 systems func= tion > *faster* than IPv4. This is pretty hard if not impossible in many > circumstances. >=20 > Why is this important ? Because an operator who *has* to deploy a CGN to = still > deliver IPv4 will be able to use the IPv6 to offload the traffic to duals= tack > sites. >=20 > If the HE is too sensitive, or selects the best path, chances are high th= at > the IPv4 path will be selected, therefore nullifying the investment into = IPv6. >=20 > On aggregate, thus, being *too* attentive to the user experience will pai= nt a > bleak picture in the future by inhibiting IPv6 progress. > Please add this variable into your research model when you are doing the = next > iteration! We understand. We will add a section describing this policy decision. Thanks! Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From v.bajpai@jacobs-university.de Wed Jul 10 06:53:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F4D11E8119 for ; Wed, 10 Jul 2013 06:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 J0HXih1r8PUl for ; Wed, 10 Jul 2013 06:53:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6721F9FE9 for ; Wed, 10 Jul 2013 06:53:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF0B20BE5; Wed, 10 Jul 2013 15:53:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eyNlEaybBDZe; Wed, 10 Jul 2013 15:53:18 +0200 (CEST) Received: from exchange.jacobs-university.de (unknown [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id C450520BDC; Wed, 10 Jul 2013 15:53:18 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 15:53:15 +0200 From: "Bajpai, Vaibhav" To: Dan Wing Thread-Topic: [v6ops] Measuring the Effectiveness of Happy Eyeballs Thread-Index: AQHOeLbLQQ26/UHCGku1zbl+BMyWdJla1xkAgAL/mQA= Date: Wed, 10 Jul 2013 13:53:14 +0000 Message-ID: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.226.26] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3327E52A66D6A147AE1000D0DBE34418@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 13:53:58 -0000 On Jul 8, 2013, at 6:05 PM, Dan Wing wrote: > On Jul 4, 2013, at 6:02 AM, "Bajpai, Vaibhav" wrote: >=20 >> Hello, >>=20 >> I would like to request a 10-minute presentation slot=20 >> at the upcoming IETF 87 to present my PhD work: >>=20 >> Title: Measuring the Effectiveness of Happy Eyeballs >> Authors: Vaibhav Bajpai and J=FCrgen Sch=F6nw=E4lder >> URL: http://tools.ietf.org/html/draft-bajpai-happy-00 >>=20 >> Abstract: >>=20 >> [...] >=20 > I noticed when this was published and presented earlier at > https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf. =20 Thank you for noticing it :-) > It's nice to see it published as an Internet Draft, but disappointing > that the underlying Effective Measurement is testing something other > than Happy Eyeballs. >=20 > Happy Eyeballs is doing what it was designed to do -- provide a good user > experience when the IPv6 (or IPv4) path is down. However, draft-bajpai-h= appy > did not evaluable how well Happy Eyeballs handles a broken IPv6 or broken= IPv4 > path. Instead, what draft-bajpai-happy measured was how well the selecte= d > path functioned. =20 Yes! this is true. This is because we _wanted_ to measure in a real=20 uncontrolled environment. We wanted to know: if all the applications today get happy eyeballed, how would the dual-stack user experience be? This why we made significant effort to find and deploy probes and measure from=20 behind a residential gateway of a real dual-stack host. We don't change the network conditions, we only measure what the end-host might experience from a happy eyeballed application. Therefore, we think we do measure happy eyeballs on how it would perform in the wild today. > Happy Eyeballs biases its path selection towards IPv6 by > design (150-250ms timeout is suggested in > http://tools.ietf.org/html/rfc6555#section-5.5). =20 The draft mentions that 300ms is used in Chrome and Firefox. Since, the implementations are using their own timer value than what is recommended, it would be nice to know what would be a better timer value, by directly measuring from deployed dual-stacked hosts, no? > The justification for this delay is explained in "Delay IPv4", > http://tools.ietf.org/html/rfc6555#section-4.1, and was consensus of the > working group primarily because it (a) mimics the long-standing IETF view= that > IPv6 should be preferred over IPv4 (b) reduces connection attempts on ser= vers > and (c) minimizes the harm to IPv4-only devices sharing an IPv4 address w= ith > the dual-stack client (as those IPv4-only devices cannot use IPv6). We understand it's a policy discussion to facilitate IPv6 adoption. We will add a section describing this policy decision. We will also add a section i= n the draft to clarify the motivation of RFC6555. Best, Vaibhav > Happy Eyeballs' algorithm differs from Apple's algorithm (introduced in O= S X > 10.7) which uses whichever path connects first (for details see > http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html), which I > expect would result in better results if tested using the test methodolog= y of > draft-bajpai-happy. However, even with Apple's algorithm if a path conne= cts > quickly but the path performs poorly (e.g., low bandwidth) the user exper= ience > will suffer. Happy Eyeballs can perform similarly to Apple's algorithm (= but > not identically) by setting its connection delay to 0ms. ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From v.bajpai@jacobs-university.de Wed Jul 10 07:01:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4321F9F9A for ; Wed, 10 Jul 2013 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 snCmc+9NJRn3 for ; Wed, 10 Jul 2013 07:01:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89E21F8E79 for ; Wed, 10 Jul 2013 07:01:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A506F20BEF; Wed, 10 Jul 2013 16:01:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IoanDVeiW22x; Wed, 10 Jul 2013 16:01:25 +0200 (CEST) Received: from exchange.jacobs-university.de (SHUBCAS05.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8104920BE8; Wed, 10 Jul 2013 16:01:25 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 16:01:22 +0200 From: "Bajpai, Vaibhav" To: Tony Hain Thread-Topic: [v6ops] Measuring the Effectiveness of Happy Eyeballs Thread-Index: AQHOeLbLQQ26/UHCGku1zbl+BMyWdJla1xkAgAAzMACAAs6vAA== Date: Wed, 10 Jul 2013 14:01:21 +0000 Message-ID: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> In-Reply-To: <01b001ce7c0e$9f1baae0$dd5300a0$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.226.26] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 14:01:36 -0000 Hello, Thank you for the review! On Jul 8, 2013, at 9:09 PM, Tony Hain wrote: > It doesn't even acknowledge that the target nodes differ. DNS resolution = of > a name does not tell you anything about deployed topology. We understand that the target nodes differ. We will update the text to explicitly mention it. > Well, it offer an ROFL moment with "will never use Teredo IPv6 unless > IPv4 connectivity is broken" clearly lacking the understanding that > IPv4 is required to work for Teredo to function=85 We meant when the IPv4 reachability of the destination service is broken (not of the end-host). We will amend the text. Thank you for noticing this. Best, Vaibhav > If the IPv6 path is not given an automated preference the traffic will ne= ver > move. Even with emerging deployment on 'services', the cache topologies a= re > not identical in every instance, and getting them there requires > demonstrated traffic. People continue to complain that IPv6 traffic level= s > are low, but they will continue that way until ISP's and content provider= s > make everything identical between the protocol versions. Given that many = use > lack of traffic at other sites as an excuse for not doing their own > deployment, breaking the stalemate requires a bias. >=20 > [...] > Apple's implementation is "not helpful". They start by refusing to allow > modifications to the 3484 policy table to meet local policies, then follo= w > that with a refusal to ack that the IPv4 cache nodes are generally closer= to > the request than the IPv6 ones, so traffic stays on IPv4 when it could & > should have moved. Anything less than a 100ms delay for the IPv4 request = is > essentially guaranteeing that the traffic stays on IPv4, until the cache > topology catches up, which will never happen if the traffic loads can't > justify it.=20 ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com From lorenzo@google.com Wed Jul 10 07:14:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B321F9D98 for ; Wed, 10 Jul 2013 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GXI2HftGCl+a for ; Wed, 10 Jul 2013 07:14:57 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91021F9D8C for ; Wed, 10 Jul 2013 07:14:57 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so5975905veb.33 for ; Wed, 10 Jul 2013 07:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GvB7xlHIcac4nenDeahET8ebB8AyEQ/rJnzDW4srf6I=; b=UouRM8ruZ5r5E8Yz4DZftKVQXn3JJDVu6HnBIe0k/HslD+hFjBOOS006Kmd0M3C+fe i7S6b2B7vqgtb4HEm0YKzT+D1RYOEHvfS6Z8Jpu0aT+zO8OXyALyVINjkIz1Qy1s9Lwd di0/rWP2mZ2/KAFSco+QjerISk5Wml5YEM+QnUxG8rgP98erEaWlkEtppYN9G+Gw9MpD M4emxt0PGaS0unZ13tjJ3qWIq6DR/Kqnm1D8mcxBkOX0xA0bSfnGVOTeS2fMixovzkOW v7jy8dkUw5e+L0fU2WHpNShuRvxugpnqEZH8tMUtcKhP/XHQV41Uh9mb+mlgoVBnY3oS cEtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=GvB7xlHIcac4nenDeahET8ebB8AyEQ/rJnzDW4srf6I=; b=GI/L4s4IzVpnWFjFyScU2gXXPGsfkqmUskrPAjs0XK3hyI65OJT54cToFSinxyHpfr nBlF/YwX3MdEZyM7C6bpMGzWQH0BJbl7zg6d1UELgBFqE/9PTe7cz96Xif8aEzIBrsnN mNtVmokz/JhSlQ88PFMmaM0SRlK3Fd4UYqevgAhN8qvo8LAXKEwJeceK/EpXXYwxeJtX wVSdHJOQUeokOQ1qP4WFvngg6spqvnMedgJDvurhkGZOs1A+dD/TeVOZoeJECjB9dsov BJj/o1g9zWBpurJ6XDils4AsfERNo5ZsUYayqTAgjIoDsCZqC2X8lfubPQjU4IUudrVv aqjQ== X-Received: by 10.58.46.196 with SMTP id x4mr18938120vem.73.1373465696890; Wed, 10 Jul 2013 07:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Wed, 10 Jul 2013 07:14:36 -0700 (PDT) In-Reply-To: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> From: Lorenzo Colitti Date: Wed, 10 Jul 2013 23:14:36 +0900 Message-ID: To: "Bajpai, Vaibhav" Content-Type: multipart/alternative; boundary=089e0102f81cf9d0b604e128e6ef X-Gm-Message-State: ALoCoQl9wsg3INk+81UPRFbZQv/tJ51NJHsC/jGI9o53CrEM/QJufwtKRNUCBniqgut+TfqThpDIwiVpbuNnOP+SjSkXvpyszYVVnHU8h9c3nLGFa7hSi5VcR4NWaPQaR4RNMkMSx4bCRDQmr9xJG00I3HMsC3CoP4wF4veqibgL2+O3Lslc52Z8cunRpNU+S2hgTXWcwKJJ Cc: "" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 14:14:58 -0000 --089e0102f81cf9d0b604e128e6ef Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 10:53 PM, Bajpai, Vaibhav < v.bajpai@jacobs-university.de> wrote: > The draft mentions that 300ms is used in Chrome and Firefox. > Does Firefox use 300ms too? I thought Firefox did something more similar to Apple than to Chrome. --089e0102f81cf9d0b604e128e6ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 10:53 PM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
The draft mentions that 300ms is used = in Chrome and Firefox.

Does Firefox use 300ms too? I thought Fire= fox did something more similar to Apple than to Chrome.=A0
--089e0102f81cf9d0b604e128e6ef-- From lorenzo@google.com Wed Jul 10 07:29:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B33D11E80E1 for ; Wed, 10 Jul 2013 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 FQ0hz-NXgzuK for ; Wed, 10 Jul 2013 07:29:55 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28021F9FDF for ; Wed, 10 Jul 2013 07:29:53 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hz11so5512261vcb.24 for ; Wed, 10 Jul 2013 07:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OgeXmMVrr0yCL9v+vwpNsqvdrCtkxJWDq8wd+a3NxYc=; b=LtxMlz0dQ7xpecA/I1jnWl1Iul48wPqZvfahtQ+PwA5HMpw+XkHMfL9s1iKkl/mYSJ nFOdM/tkWKXvUj54rNi44NFT36y982gpkckbhuNF+e1Zm+2E4Z8gXGVHRUXa/lE+OO5w Fj0UNRS0EU9YP/IyVZHCg16TEM0C92MsJdnlWyE6Sj3G4HHjPAxZFLizZbkw6+w2EcTW W+60bSGrKbu5dkTKDUnfOcTGCndxYOAykf6lQ0UQhYY+BoQasvP6Gg4Bb2itu8ieU8KL paO9BPRsHlzZR2jHklOKuumlroYitbaemMubZqAsKE6qVCfd5bURRI6PnOIcSJmaOAET I/Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OgeXmMVrr0yCL9v+vwpNsqvdrCtkxJWDq8wd+a3NxYc=; b=T0g+9/1UmI0Cv96p9nZso/l0+nchaZMbiNQ5nn0KxTJM+eq68lWvQ1hc+d6/loVv7Y lBo04HyVMsbLfW1vp+AtSjqOiXCtSXSMtGTVhyUTpUKZ7yYhOkbK8y2i1jmf6upSHf3t TcqJCn+a5GbSR5NSt9gYcG8TObRZuKYV6iPQF7Xg9bGsefTtya2OqK9u6jcjTDT7ldYd 89jnEWagPCEu9oy+gBomlP3o3G/hImQJah9q2Vh6N9xixzcByVGYDFhsLtunIPKSIObn 38jmQALGIlGCd1IRvzVIrqyJAgYpBbd0YgbVLzCHEIh2nGq+k5Rg/TLwsLgVRRgHCWHl yvzg== X-Received: by 10.220.144.13 with SMTP id x13mr19543832vcu.21.1373466592395; Wed, 10 Jul 2013 07:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Wed, 10 Jul 2013 07:29:32 -0700 (PDT) In-Reply-To: <26BEA367-1EFF-4A69-A828-BFDA6E737893@jacobs-university.de> References: <26BEA367-1EFF-4A69-A828-BFDA6E737893@jacobs-university.de> From: Lorenzo Colitti Date: Wed, 10 Jul 2013 23:29:32 +0900 Message-ID: To: "Bajpai, Vaibhav" Content-Type: multipart/alternative; boundary=047d7b3442925a128904e1291cc3 X-Gm-Message-State: ALoCoQnLUk84UnbRyN0EWBON2WZ5zErkIHYif61cT6DZxbTxASelvIR0aETU6I98ilZdyQL6X87NUjDcjW9xzYjx3O3gnWSUKJlpJb7wU6/mVIraa5C5ZPUiE+9pxERgnKT6tJ9wMgtn/7X6imEgtFNcJFtbvMg47AmhmIie+gl2OYK8miCw8pNDEyQVU14vvc4v3WMvSPan Cc: "" Subject: Re: [v6ops] Some comments on http://www.ietf.org/id/draft-bajpai-happy-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 Jul 2013 14:29:57 -0000 --047d7b3442925a128904e1291cc3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 10:16 PM, Bajpai, Vaibhav < v.bajpai@jacobs-university.de> wrote: > We understand it's a policy discussion to facilitate IPv6 adoption. We will > add a section in the draft to clarify the motivation of RFC6555. > Actually, I think that's not enough, because I suspect the disagreement is deeper than you think. "Effectiveness" implies performance compared to a goal, but what Andrew is saying here is that latency minimization was (within reason) not a goal at all. The goal was to avoid impact so we could get on with enabling IPv6. If you do want to measure this, I think you might have to call it something other than "effectiveness". And to be pedantic, even with your definition of "effectiveness", it's not the "effectiveness" of happy eyeballs that you're measuring, you're comparing the "effectiveness" of IPv6 and IPv4. > We argue that since applications on top of TCP will not be happy eyeballed > only in scenarios where IPv6 connectivity is broken, but also in scenarios > where the dual-stack host enjoys perfect IPv6 connectivity, we want to > measure how much imposition does such a user experience in reality by > measuring the effect of the 300ms timer value. > Actually, that's not a good definition either. If the dual-stack host enjoys perfect IPv6 connectivity, then by definition IPv4 can never be better (since IPv6 is perfect), the 300ms timer will never fire. So by "perfect" I think what you really mean is "perfectly reliable". > > > On aggregate, thus, being *too* attentive to the user experience will > paint a > > bleak picture in the future by inhibiting IPv6 progress. > > Please add this variable into your research model when you are doing the > next > > iteration! > > We understand. We will add a section describing this policy decision. > Please also change the wording as well. Cheers, Lorenzo --047d7b3442925a128904e1291cc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 10:16 PM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
We understand it's a policy= discussion to facilitate IPv6 adoption. We will
add a section in the draft to clarify the motivation of RFC6555.

Actually, I think that's not enough, because = I suspect the disagreement is deeper than you think. "Effectiveness&qu= ot; implies performance compared to a goal, but what Andrew is saying here = is that latency minimization was (within reason) not a goal at all. The goa= l was to avoid impact so we could get on with enabling IPv6.

If you do want to measure this, I think you might have = to call it something other than "effectiveness". And to be pedant= ic, even with your definition of "effectiveness", it's not th= e "effectiveness" of happy eyeballs that you're measuring, yo= u're comparing the "effectiveness" of IPv6 and IPv4.
=A0
We argue that since applications on top of T= CP will not be happy eyeballed
only in scenarios where IPv6 connectivity is broken, but also in scenarios<= br> where the dual-stack host enjoys perfect IPv6 connectivity, we want to
measure how much imposition does such a user experience in reality by
measuring the effect of the 300ms timer value.

Actually, that's not a good definition either. If the dual-stac= k host enjoys perfect IPv6 connectivity, then by definition IPv4 can never = be better (since IPv6 is perfect), the 300ms timer will never fire. So by &= quot;perfect" I think what you really mean is "perfectly reliable= ".

> On aggregate, thus, being *too* attentive to the user experience w= ill paint a
> bleak picture in the future by inhibiting IPv6 progress.
> Please add this variable into your research model when you are doing t= he next
> iteration!

We understand. We will add a section describing this policy decision.

Please also change the wording as well.

Cheers,
Lorenzo
--047d7b3442925a128904e1291cc3-- From tom.taylor.stds@gmail.com Wed Jul 10 08:07:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD921F8BE6 for ; Wed, 10 Jul 2013 08:07: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=[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 t9qNkPn0Vax4 for ; Wed, 10 Jul 2013 08:07:11 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3D75121F9F75 for ; Wed, 10 Jul 2013 08:07:10 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so16024182iej.29 for ; Wed, 10 Jul 2013 08:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QDCvvm8Y2bEPFfcR1KvEuEtamwQZi2INuf+/S32Ln0A=; b=KYidDJzmpRenaXXtkzBCQlCg4f3yi7Z0va/CVLH8tiXK1QzvfNljNJTrkGGrm0pfTl +jm7MXGACJQKAt0hQxokuHyYhRY/lpM70KpnUS0+3PFkQlaR+kO0rLpSjcrjTbd+KECO UkS8EqqjIm/CKORFdQvFHvnKv4rPOjQ/vfavGPwDREHypXQ40OAqpAbjhtBysKW6+b1h PsKoAsWiEMULUVOhdSjvWSoeKreJMebHGInTXv4OWXM2NkE3bQBp88wBpMWAmVb3cWIf 8jM3TuBY7YHL79qZ8xeCVBFwbnPEBLqVqrK21mUz9jWLiTN4oa7+Yqx3U4iDqVreZ3aF NakQ== X-Received: by 10.50.1.78 with SMTP id 14mr9700590igk.60.1373468829853; Wed, 10 Jul 2013 08:07:09 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id nr4sm11997688igb.0.2013.07.10.08.07.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 08:07:09 -0700 (PDT) Message-ID: <51DD789E.8090306@gmail.com> Date: Wed, 10 Jul 2013 11:07:10 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: GangChen References: 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-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:07:12 -0000 We are working on logging drafts in Behave. Bulk port allocation can work as Mikael states. On the other hand, if the provider is using MAP or Lightweight 4over6, port allocation happens at provisioning time and may if desired be logged by network infrastructure (DHCP, AAA). Tom Taylor On 10/07/2013 6:35 AM, Mikael Abrahamsson wrote: > On Wed, 10 Jul 2013, GangChen wrote: > >> That is an interesting use. How do you implement those IPv4 pool >> allocations? I heard some NAT64 implementations could allocate >> different IPv4 pools to each inbound interface. Are you doing in the >> similar way? > > Some vendors allow certain IPv6 source addresses to go to certain > outside IPv4 pool of addresses. > >> If I understand correctly, that is a static port block allocation. A >> port block would be reserved to a particular customer. No logging >> information needed. will clarify at the next update. > > Well, actually the block would be allocated upon first traffic seen from > a certain source IPv6 address. Perhaps there are references to this in > other RFCs that could be useful. > > For instance (I'm sure there are a lot more): > > http://www.ietf.org/proceedings/86/slides/slides-86-behave-2 > > http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/cg_nat/configuration/guide/cgnat43cgn.html#wp1015343 > > > Bulk Port Allocation > > The creation and deletion of NAT sessions need to be logged and these > create huge amount of data. These are stored on Syslog collector which > is supported over UDP. In order to reduce the volume of data generated > by the NAT device, bulk port allocation can be enabled. When bulk port > allocation is enabled and when a subscriber creates the first session, a > number of contiguous outside ports are pre-allocated. A bulk allocation > message is logged indicating this allocation. Subsequent session > creations will use one of the pre-allocated port and hence does not > require logging. > From v.bajpai@jacobs-university.de Wed Jul 10 08:42:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9CC11E8124 for ; Wed, 10 Jul 2013 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bs9Pk0wXQkLr for ; Wed, 10 Jul 2013 08:42:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44821F9DF0 for ; Wed, 10 Jul 2013 08:42:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4220620BE2; Wed, 10 Jul 2013 17:42:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uRHW3a0fIo3J; Wed, 10 Jul 2013 17:42:16 +0200 (CEST) Received: from exchange.jacobs-university.de (unknown [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 15C8020BDA; Wed, 10 Jul 2013 17:42:16 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 17:42:13 +0200 From: "Bajpai, Vaibhav" To: Lorenzo Colitti Thread-Topic: [v6ops] Measuring the Effectiveness of Happy Eyeballs Thread-Index: AQHOeLbLQQ26/UHCGku1zbl+BMyWdJla1xkAgAL/mQCAAAX2AIAAGHwA Date: Wed, 10 Jul 2013 15:42:12 +0000 Message-ID: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.226.26] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <796B753D0AA9504A975520AA43F2C281@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 15:42:25 -0000 On Jul 10, 2013, at 4:14 PM, Lorenzo Colitti wrote: > On Wed, Jul 10, 2013 at 10:53 PM, Bajpai, Vaibhav wrote: > The draft mentions that 300ms is used in Chrome and Firefox. >=20 > Does Firefox use 300ms too? I thought Firefox did something more > similar to Apple than to Chrome.=20 The more aggressive approach needs to be enabled by setting=20 network.http.fast-fallback-to-IPv4 parameter to true. Firefox=20 then starts parallel TCP connections to the first endpoint of each address family [1]. [1] http://www.potaroo.net/ispcol/2012-05/notquite.html Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From lorenzo@google.com Wed Jul 10 08:52:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C95B21F9F75 for ; Wed, 10 Jul 2013 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 yN-mSLKu4K4u for ; Wed, 10 Jul 2013 08:52:19 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DB24A21F8C11 for ; Wed, 10 Jul 2013 08:52:10 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so5723548vcb.13 for ; Wed, 10 Jul 2013 08:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9O1oI6qm3P97yGV0BNbiSQu9INiNnh7BcU9fZOHR3JE=; b=YDMsZPnBCxIFeSRGEAGM5sEeCQ19AsFkZpaT6IvwXX4ny4y/bwPkhfbT1cecrttE6b KQ75h1EQY2RT7BvH6Ztr1jbaeX8wSwRs2sUOAADTYO6TO+C4ipOGv5VWVTaRcN3LThqU AoIQg2cwB4eFUHmKZxLQGKDJGerOr5j/w0QV5qzRRz6jCM+9w25JNouMpDzPuKMSmovF 3YSdSp8md3Bn+HnWYKxADgDh7ZEhyQP9Hibqk3y5EVdZjqaRgcN6aO8xYvelnVGFZmQz TxfY3NtedQ3QZO3+RZMYHtb9ZIiqG+rv/RrEms60XDX3khDhR51NsGKqiDsxdtEkHsSK DLWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9O1oI6qm3P97yGV0BNbiSQu9INiNnh7BcU9fZOHR3JE=; b=ZnvpRAhP4iGxbgqRy3o4n6YOZifWqlXf0FZr8iXve9r/VMRNAsl9UM1JejE0Yb4N/p Yj61rFFwxGi/fslIPlepHtBF4HdVfj8FTo//jdU5EcaFatxGe7ZShzKeIStToYM3HQyF 3HCVV55nDLPHqSjudDwD9I4yrZRcJbzVJXDybk32PrcDecOfQP5I5e1DV8aWj27Ea13W F3BoQdAwAUcuoAXcGHdhrKRRkYKIFbONOYsgNXspz/QDPJFEQWM+kYc+WuvmTDE5vIKt PP7t0+3dmIScNZfKg5sHITzFgbiIcH+L+xKpllrF1oxCDCX6ImtUC8UiWOg9D+rUEdEJ TZ2Q== X-Received: by 10.220.68.144 with SMTP id v16mr19486281vci.76.1373471530174; Wed, 10 Jul 2013 08:52:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Wed, 10 Jul 2013 08:51:50 -0700 (PDT) In-Reply-To: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> From: Lorenzo Colitti Date: Thu, 11 Jul 2013 00:51:50 +0900 Message-ID: To: "Bajpai, Vaibhav" Content-Type: multipart/alternative; boundary=047d7b3a9386aaa63c04e12a42c0 X-Gm-Message-State: ALoCoQkb08+wpmDpgjtznKbtawF+ZOh+1EJpwWDNRrXAIOzrnNfAgMzDxbzzAeywU7InqNqc/M0IOsxipq5QBR8c5KNy80/zrFaoydQmLfC3mCrmz9Uh/V3ZPbjPEbq9NgGLzBS4lv/GySfzklATACKOrEtJfKBMDcHQPeZNDVYlHKuIBLW0hEir/gtHVk/T3e0k7yoP9P52 Cc: "" Subject: Re: [v6ops] Measuring the Effectiveness of 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: Wed, 10 Jul 2013 15:52:21 -0000 --047d7b3a9386aaa63c04e12a42c0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 12:42 AM, Bajpai, Vaibhav < v.bajpai@jacobs-university.de> wrote: > The more aggressive approach needs to be enabled by setting > network.http.fast-fallback-to-IPv4 parameter to true. Firefox > then starts parallel TCP connections to the first endpoint of > each address family [1]. > Actually, as far as I can see, Firefox (at least the version I have, v22 on Ubuntu) has that parameter set to true by default (if you go to about:config, you can tell if it's been modified). If you set it to false it doesn't do HE at all. It appears to fall back to IPv6 after ~250ms, at least in this case where I connect to a port that doesn't respond: 00:46:51.836461 IP6 2400:2410:20c0:100:656d:e13c:6236:d37a.45342 > 2404:6800:4004:803::1012.81: Flags [S], seq 2062516864, win 14400, options [mss 1440,sackOK,TS val 179759058 ecr 0,nop,wscale 7], length 0 00:46:52.087045 IP 192.168.3.5.55797 > 74.125.235.115.81: Flags [S], seq 4216986802, win 14600, options [mss 1460,sackOK,TS val 179759120 ecr 0,nop,wscale 7], length 0 > [1] http://www.potaroo.net/ispcol/2012-05/notquite.html I wouldn't take that as the gospel truth. It also says that in Chrome "The choice of which protocol is preferred for the initial connection attempt is based on the DNS response time", which as far as I know is not true. Whether it prefers IPv6 or not depends only on what getaddrinfo returns first. --047d7b3a9386aaa63c04e12a42c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 11, 2013 at 12:42 AM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
The more aggressive approach needs t= o be enabled by setting
network.http.fast-fallback-to-IPv4 parameter to true. Firefox
then starts parallel TCP connections to the first endpoint of
each address family [1].

Actually, as f= ar as I can see, Firefox (at least the version I have, v22 on Ubuntu) has t= hat parameter set to true by default (if you go to about:config, you can te= ll if it's been modified). If you set it to false it doesn't do HE = at all.

It appears to fall back to IPv6 after ~250ms, at least = in this case where I connect to a port that doesn't respond:
=
00:46:51.836461 IP6 2400:2410:20c0:100:656d:e13c:6236:d= 37a.45342 > 2404:6800:4004:803::1012.81: Flags [S], seq 2062516864, win = 14400, options [mss 1440,sackOK,TS val 179759058 ecr 0,nop,wscale 7], lengt= h 0
00:46:52.087045 IP 192.168.3.5.55797 > 74.125.235.115.81: Fla= gs [S], seq 4216986802, win 14600, options [mss 1460,sackOK,TS val 17975912= 0 ecr 0,nop,wscale 7], length 0
=A0
[1] http://www.potaroo.net/ispcol/2012-05/notquite.html

I wouldn't take that as the gospel truth. It a= lso says that in Chrome "The choice of which protocol is preferred for= the initial connection attempt is based on the DNS response time", wh= ich as far as I know is not true. Whether it prefers IPv6 or not depends on= ly on what getaddrinfo returns first.

--047d7b3a9386aaa63c04e12a42c0-- From phdgang@gmail.com Wed Jul 10 20:19:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90CB11E80F1 for ; Wed, 10 Jul 2013 20:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 d5izemWTDPu4 for ; Wed, 10 Jul 2013 20:19:34 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0427A11E80EF for ; Wed, 10 Jul 2013 20:19:33 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so4167950qec.20 for ; Wed, 10 Jul 2013 20:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VeE83b8BhvpucFMi8goTrcRXERQ2lbNAxCTIURz1E/8=; b=p1vDXa+vRs4I9/d8NYWwgHT695u1TzPUG1ghk905S4V/U6Zdq7SmaXRZDJvTpFxUAj bgEXwFlbwfKJqYpGWSxGop7ystRE8MMQObfK9/DH4C762YyVu+6+141w9gKbEg32uY5/ 9IH9PVo1/95nfqcBpMgxxA3eRKd85j0p4QVMNtUtP8RGRqacOCQ3pzwIuXNMStJCrnPX 19/NLzrJCrGDSvfWeZj9V2om1LhINqfxYGl8HjnVBs6jxMU1aaJSkJtR84UzSK7Ufwgd slOmTgI8H1lgQFfUYwEw37DWNp0vZpjcs2RacBfU2FiPHps41mPgSqCstGKrUBDUznxs /u4g== MIME-Version: 1.0 X-Received: by 10.49.29.106 with SMTP id j10mr28649101qeh.37.1373512769346; Wed, 10 Jul 2013 20:19:29 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Wed, 10 Jul 2013 20:19:29 -0700 (PDT) In-Reply-To: <51DD789E.8090306@gmail.com> References: <51DD789E.8090306@gmail.com> Date: Thu, 11 Jul 2013 11:19:29 +0800 Message-ID: From: GangChen To: Tom Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 03:19:35 -0000 2013/7/10, Tom Taylor : > We are working on logging drafts in Behave. Bulk port allocation can > work as Mikael states. On the other hand, if the provider is using MAP > or Lightweight 4over6, port allocation happens at provisioning time and > may if desired be logged by network infrastructure (DHCP, AAA). I guess the bulk port allocation is a natural part of MAP or Lightweight4ovr6 or A+P. If the system is aware of the mapping rules, the log information may not be necessary > Tom Taylor > > On 10/07/2013 6:35 AM, Mikael Abrahamsson wrote: >> On Wed, 10 Jul 2013, GangChen wrote: >> >>> That is an interesting use. How do you implement those IPv4 pool >>> allocations? I heard some NAT64 implementations could allocate >>> different IPv4 pools to each inbound interface. Are you doing in the >>> similar way? >> >> Some vendors allow certain IPv6 source addresses to go to certain >> outside IPv4 pool of addresses. >> >>> If I understand correctly, that is a static port block allocation. A >>> port block would be reserved to a particular customer. No logging >>> information needed. will clarify at the next update. >> >> Well, actually the block would be allocated upon first traffic seen from >> a certain source IPv6 address. Perhaps there are references to this in >> other RFCs that could be useful. >> >> For instance (I'm sure there are a lot more): >> >> http://www.ietf.org/proceedings/86/slides/slides-86-behave-2 >> >> http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/cg_nat/configuration/guide/cgnat43cgn.html#wp1015343 >> >> >> Bulk Port Allocation >> >> The creation and deletion of NAT sessions need to be logged and these >> create huge amount of data. These are stored on Syslog collector which >> is supported over UDP. In order to reduce the volume of data generated >> by the NAT device, bulk port allocation can be enabled. When bulk port >> allocation is enabled and when a subscriber creates the first session, a >> number of contiguous outside ports are pre-allocated. A bulk allocation >> message is logged indicating this allocation. Subsequent session >> creations will use one of the pre-allocated port and hence does not >> require logging. >> > From satoru.matsushima@gmail.com Thu Jul 11 12:14:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0285B21F9DF1 for ; Thu, 11 Jul 2013 12:14:10 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 JjXDFacCnG0E for ; Thu, 11 Jul 2013 12:14:09 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DA84A21F9D95 for ; Thu, 11 Jul 2013 12:14:08 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ep20so2681858lab.37 for ; Thu, 11 Jul 2013 12:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kAo+3pdL5nZOemdrtFvaRs1SrOJ733kweeCIp7jjdGo=; b=uzDRTomI42PM4Ig13S/5YLriX763tvqcv7ucTSKfV3FTPc7tPnNZgCeCQOzoY5jcwB oN1wjolyDd0XU4AhnRUdX3i+o5gmqkdZFxYJiAK3xK6lIZ4qoLYZDu7Q+dAk1pGQTroW bXjyKgWE5iBAxeA+sMk32GOzfz5EWoHKiKbAdtNIcrnwCXaORTllTrtqJh9wo55XkvvZ xkddaa2kt+gtLwH6DWKRC8IH+ct/rNWA8EgFExyEpLkwsPf+M/4nHV7Ah4boQEX7zvWn 2Tt9+xYgPmXH+PCOuZfNDhDK1BGAHKkjmLHKiarRc1kVS6h1yMA+ipQ6E9ezGIPiVSMR BnFw== MIME-Version: 1.0 X-Received: by 10.112.12.137 with SMTP id y9mr17763413lbb.91.1373570047704; Thu, 11 Jul 2013 12:14:07 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Thu, 11 Jul 2013 12:14:07 -0700 (PDT) Date: Fri, 12 Jul 2013 04:14:07 +0900 Message-ID: From: Satoru Matsushima To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a11c3aa2ac4829604e14132af Subject: [v6ops] Fwd: I-D Action: draft-matsushima-stateless-uplane-vepc-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, 11 Jul 2013 19:14:10 -0000 --001a11c3aa2ac4829604e14132af Content-Type: text/plain; charset=ISO-8859-1 Hi, We have submitted an I-D for mobile core user-plane which adopts IPv6 routing basis architecture. This draft is not submitted to IDR working group but v6ops experience helps much to realize this architecture. Your comments are welcome. Regards, --satoru ---------- Forwarded message ---------- From: Date: Thu, Jul 11, 2013 at 1:09 AM Subject: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Stateless user-plane architecture for virtualized EPC (vEPC) Author(s) : Satoru Matsushima Ryuji Wakikawa Filename : draft-matsushima-stateless-uplane-vepc-00.txt Pages : 19 Date : 2013-07-10 Abstract: We envision a new mobile architecture for the future Evolved Packet Core (EPC). The new architecture is designed to support the virtualization scheme called NFV (Network Function Virtualization). In our architecture, the user plane of EPC is decoupled from the control-plane and uses routing information to forward packets of mobile nodes. Although the EPC control plane will run on hypervisor, our proposal does not modify the signaling of the EPC control plane. The benefits of our architecture are 1) scalability, 2) flexibility and 3) Manageability. How to run the EPC control plane on NFV is out of our focus in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc There's also a htmlized version available at: http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c3aa2ac4829604e14132af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We have subm= itted an I-D for mobile core user-plane which adopts IPv6 routing basis arc= hitecture. This draft is not submitted to IDR working group but v6ops exper= ience helps much to realize this architecture. Your comments are welcome.

Regards,
--satoru



---------- Forwarded message ----------
From:=A0<internet-drafts@ietf.org>
Date: Thu, Ju= l 11, 2013 at 1:09 AM
Subject: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt
To:= =A0i-d-announce@= ietf.org



A New Internet-Draft is available from the on-l= ine Internet-Drafts directories.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Stateless user-plane ar= chitecture for virtualized EPC (vEPC)
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 = =A0 : Satoru Matsushima
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Ryuji Wakikawa
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-matsu= shima-stateless-uplane-vepc-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0 Date =A0 = =A0 =A0 =A0 =A0 =A0: 2013-07-10

Abstract:
=A0 =A0We envision a ne= w mobile architecture for the future Evolved Packet
=A0 =A0Core (EPC). = =A0The new architecture is designed to support the
=A0 =A0virtualization scheme called NFV (Network Function Virtualization).<= br>=A0 =A0In our architecture, the user plane of EPC is decoupled from the<= br>=A0 =A0control-plane and uses routing information to forward packets of<= br>=A0 =A0mobile nodes. =A0Although the EPC control plane will run on hyper= visor,
=A0 =A0our proposal does not modify the signaling of the EPC control plane.=
=A0 =A0The benefits of our architecture are 1) scalability, 2) flexibil= ity
=A0 =A0and 3) Manageability. =A0How to run the EPC control plane on = NFV is out
=A0 =A0of our focus in this document.


The IETF datatracker statu= s page for this draft is:
https://datatracker= .ietf.org/doc/draft-matsushima-stateless-uplane-vepc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.o= rg/internet-drafts/

____________________________________________= ___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/i-d-announce
Internet-Draft=A0directories:=A0http://www.ietf.org/shadow.html
or=A0ftp://ftp.= ietf.org/ietf/1shadow-sites.txt
--001a11c3aa2ac4829604e14132af-- From yangtianle@chinamobile.com Thu Jul 11 21:19:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC621E8083 for ; Thu, 11 Jul 2013 21:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] 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 L1pEZsdbeR3W for ; Thu, 11 Jul 2013 21:19:47 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 9E03221E8087 for ; Thu, 11 Jul 2013 21:19:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251df839ef5d-95f5d; Fri, 12 Jul 2013 12:18:39 +0800 (CST) X-RM-TRANSID: 2ee251df839ef5d-95f5d Received: from yangtianle (unknown[10.2.52.138]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251df839ad1c-1cb0c; Fri, 12 Jul 2013 12:18:39 +0800 (CST) X-RM-TRANSID: 2ee251df839ad1c-1cb0c From: "Tianle Yang" To: , Date: Fri, 12 Jul 2013 12:19:31 +0800 Message-ID: <009e01ce7eb7$01dbcca0$059365e0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01CE7EFA.0FFF0CA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5+twFkR9tFJVECQVKydAhCcanoxA== Content-Language: zh-cn Subject: [v6ops] some comments about the draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 04:19:51 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_009F_01CE7EFA.0FFF0CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Although it is a little more convenient to do some operations when including some Use's properties in the IPv6 prefix, it may affect the routing table, such as changing some routings according to the changes of the use's QoS. And if we do not accept these changes, we have to put more IPv6 addresses in the address pool in one equipment, that causes address waste. And according to the discussion in the last IETF meeting , shall we merge this draft and "draft-ma-v6ops-ipv6-address-assignment " together? The link is below: http://tools.ietf.org/id/draft-ma-v6ops-ipv6-address-assignment-00.txt Tianle ------=_NextPart_000_009F_01CE7EFA.0FFF0CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Although it is a little more = convenient to do some operations when including some Use’s properties in the IPv6 = prefix, it may affect the routing table, such as changing some routings = according to the changes of the use’s QoS. And if we do not accept these = changes, we have to put more IPv6 addresses in the address pool in one equipment, = that causes address waste.

 

And according to the discussion = in the last IETF meeting , shall we merge this draft and = “draft-ma-v6ops-ipv6-address-assignment “ together? The link is below:

http://tools.ietf.org/id/draft-ma-v6ops-ipv6-address-assignm= ent-00.txt

 

Tianle

------=_NextPart_000_009F_01CE7EFA.0FFF0CA0-- From fred@cisco.com Sat Jul 13 05:45:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADC221F9CA7 for ; Sat, 13 Jul 2013 05:45:11 -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 6pWmeSPaSnhh for ; Sat, 13 Jul 2013 05:45:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD321F9A6D for ; Sat, 13 Jul 2013 05:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=136; q=dns/txt; s=iport; t=1373719506; x=1374929106; h=date:from:message-id:to:subject:cc; bh=RHEOWOb/gXZBqFDi0qY//cxyF39Pqi91tFrdbVFgIm8=; b=M6avmj6vFD1Vtn1GMItXY9NkJ9QZ9zQQZ7k6flCMguqgqcbsTYNf8EMT UlyZKvsap4HIRAGswe04lymc9BPd0xfrWpvLd1x/AQrm32F2i5huZAVz7 Ar+V4ICQ4V9zInuQdV6snPkUwEqPFzyVXvgs+ynzwQqcVF4OqvIHUf5ky k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIpAKhK4VGrRDoG/2dsb2JhbABagwY0gw6tKAGLHIZMAwEDAYEIFnSDIzwtB4hvDbZ1jlGBEh2DYQOJJ49ekCSDMg X-IronPort-AV: E=Sophos;i="4.89,659,1367971200"; d="scan'208";a="82873296" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 13 Jul 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6DCj0lW015586; Sat, 13 Jul 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r6DCj0d01032; Sat, 13 Jul 2013 05:45:00 -0700 (PDT) Date: Sat, 13 Jul 2013 05:45:00 -0700 (PDT) From: Message-Id: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-servin-v6ops-monitor-ds-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2013 12:45:12 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment. From aservin@lacnic.net Sat Jul 13 06:46:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE73A21F92A5 for ; Sat, 13 Jul 2013 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 yZR7G+7+VY-T for ; Sat, 13 Jul 2013 06:46:34 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7321F99CF for ; Sat, 13 Jul 2013 06:46:34 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2800:af:ba30:f0e1:19ac:b741:e6fe:647d]) by mail.lacnic.net.uy (Postfix) with ESMTP id DF9D830847F for ; Sat, 13 Jul 2013 10:46:08 -0300 (UYT) Message-ID: <51E15A35.2090603@lacnic.net> Date: Sat, 13 Jul 2013 10:46:29 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> In-Reply-To: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2013 13:46:35 -0000 Hi, We have sent this draft about considerations and recommendations to monitor IPv6 and dual-stack networks and services. We have been talking with people deploying IPv6 and we have found that not all monitor their networks and not many monitor them properly. We also found some challenges in monitor implementations that not fully support IPv6 monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even though monitoring v6 networks is as critical as doing it in v4, we have not found many documents explaining how that has to be done (at least guides with free access or up to date). There are also some misconceptions about monitoring IPv6, for example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and send them on IPv4 that we wanted to clarify. We collected some recommendations from informal conversations with people during some training and NOGs meeting during this year but we need some more input. We will be sharing this draft with other forums to get more inputs but we wanted to share it here first. Best wishes, Arturo and Mariela On 7/13/13 9:45 AM, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun Jul 14 08:19:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E134B21E808F for ; Sun, 14 Jul 2013 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 w-qIHafy4kX7 for ; Sun, 14 Jul 2013 08:19:41 -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 5C2CA21E808E for ; Sun, 14 Jul 2013 08:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=412; q=dns/txt; s=iport; t=1373815181; x=1375024781; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=xt4NwtbKCrTaoGK0YT0XQeMRQu9atwM7RPlRVNAT3Fs=; b=gBhTzBAPIEKY+xhIDKGqnz4q0lpc/+gD0btd4v/nf/wV5FUmKTN6gW/D ZHT+jPNc+8qg8YYTmzAtPYDj3VTKlhaa1+wlvutRp0sN2dJMCeU/U00Ew 0lB7kiNeDsaJ9gUJ3tufiG0I1lqBt0sGMkzoedxWBaUB/9DRAei7RfsZh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMLADPB4lGtJV2a/2dsb2JhbABagwY0T4I/vwgCAYEJFnSCJQEEOlEBKhRCJwQTCAGIBwyWKp9Zjx0Wg0NtA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,663,1367971200"; d="scan'208";a="234623540" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jul 2013 15:19:41 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6EFJeLi013322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 14 Jul 2013 15:19:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 10:19:40 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Draft cut-off Thread-Index: AQHOgKWPWZx/vMSSeEmZ+mRWuNDlAw== Date: Sun, 14 Jul 2013 15:19:39 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B93AB93@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.163.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B179F26347D404C8F44CACF81E36C5B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Draft cut-off X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:19:50 -0000 I'm not sure I saw an announcement - maybe I missed it - but both the -00 a= nd revision cutoff dates are Monday.=20 Whatever is posted, as usual John and I are trying to gauge working group i= nterest from commentary on the v6ops@ietf.org list. If you'd like to see so= mething on the agenda, express interest, and ideally discuss the draft. http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87= From internet-drafts@ietf.org Sun Jul 14 10:35:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83D321F90A7; Sun, 14 Jul 2013 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 qmwJuVI1i186; Sun, 14 Jul 2013 10:35:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16221F9DDE; Sun, 14 Jul 2013 10:35:16 -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: 4.51.p2 Message-ID: <20130714173516.19078.84205.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 10:35:16 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-03.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: Sun, 14 Jul 2013 17:35:22 -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 : Enterprise IPv6 Deployment Guidelines Author(s) : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-03.txt Pages : 34 Date : 2013-07-14 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental-= ipv6-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From v.bajpai@jacobs-university.de Sun Jul 14 14:04:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01D921F9C08 for ; Sun, 14 Jul 2013 14:04:30 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5TpoxOuNDhZK for ; Sun, 14 Jul 2013 14:04:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 940BE21F9BC0 for ; Sun, 14 Jul 2013 14:04:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9732520BDE for ; Sun, 14 Jul 2013 23:04:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6Fib3ld0aXzI for ; Sun, 14 Jul 2013 23:04:24 +0200 (CEST) Received: from exchange.jacobs-university.de (unknown [10.70.0.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 75C6820BDB for ; Sun, 14 Jul 2013 23:04:24 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.02.0342.003; Sun, 14 Jul 2013 23:04:24 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: Measuring the Effects of Happy Eyeballs Thread-Index: AQHOgNW35dXnFccrtUe04HKB5SCLVw== Date: Sun, 14 Jul 2013 21:04:23 +0000 Message-ID: References: <2D5CAA69-E69B-44F7-94ED-700CABDD8351@jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.22.201.184] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Measuring the Effects of 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 Jul 2013 21:04:30 -0000 Hello, Thank you so much for all the feedback on the -00 version. I have uploaded a new version of the draft with requested=20 changes and with a new title: Revision: 01 Title: Measuring the Effects of Happy Eyeballs Htmlized: http://tools.ietf.org/html/draft-bajpai-happy-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bajpai-happy-01 It would be nice to get a 10 minute agenda slot to=20 present this at the upcoming IETF. The changes reflect from these discussions: On Jul 10, 2013, at 3:16 PM, "Bajpai, Vaibhav" wrote: > On Jul 10, 2013, at 4:29 PM, Lorenzo Colitti wrote: >=20 >> [=85] If you do want to measure this, I think you might have to call it = something >> other than "effectiveness". [=85] done! changed the title. > We argue that since applications on top of TCP will not be happy eyeballe= d > only in scenarios where IPv6 connectivity is broken, but also in scenario= s > where the dual-stack host enjoys perfect IPv6 connectivity, we want to > measure how much imposition does such a user experience in reality by > measuring the effect of the 300ms timer value. >=20 >> Actually, that's not a good definition either. If the dual-stack host en= joys >> perfect IPv6 connectivity, then by definition IPv4 can never be better (= since >> IPv6 is perfect), the 300ms timer will never fire. So by "perfect" I thi= nk what >> you really mean is "perfectly reliable". done! rephrased the definition. > On Jul 5, 2013, at 4:30 PM, Andrew Yourtchenko wrote= : >=20 >> First, the overall goal. The RFC6555 was not designed to [...] >=20 > [=85] We will add a section in the draft to clarify the motivation of RFC= 6555. done! added a new section clearly describing the goals of happy eyeballs. > On Jul 8, 2013, at 6:05 PM, Dan Wing wrote: >=20 >> The justification for this delay is explained in "Delay IPv4", [...] >=20 > We understand it's a policy discussion to facilitate IPv6 adoption. We wi= ll > add a section describing this policy decision. [...] done! added a new section on IPv6 upgrade policy. > On Jul 8, 2013, at 9:09 PM, Tony Hain wrote: >=20 >> It doesn't even acknowledge that the target nodes differ. [...] >=20 > We understand that the target nodes differ. We will update the > text to explicitly mention it. done! added the text acknowledging the difference. >> [=85] clearly lacking the understanding that IPv4 is required >> to work for Teredo to function=85 >=20 > We meant when the IPv4 reachability of the destination service is broken > (not of the end-host). We will amend the text. Thank you for noticing thi= s. done! rephrased the statement. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From aservin@lacnic.net Sun Jul 14 15:10:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC00A21F9ABD for ; Sun, 14 Jul 2013 15:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.655 X-Spam-Level: * X-Spam-Status: No, score=1.655 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 0-YpqNOkNm2s for ; Sun, 14 Jul 2013 15:10:51 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4D56E21F9B1E for ; Sun, 14 Jul 2013 15:10:48 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r186-48-206-81.dialup.adsl.anteldata.net.uy [186.48.206.81]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6E5D7308498 for ; Sun, 14 Jul 2013 19:10:20 -0300 (UYT) Message-ID: <51E321DF.3060304@lacnic.net> Date: Sun, 14 Jul 2013 19:10:39 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "" References: <20130714220042.26044.73556.idtracker@ietfa.amsl.com> In-Reply-To: <20130714220042.26044.73556.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130714220042.26044.73556.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050309060802080109080005" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: [v6ops] Fwd: I-D Action: draft-lopez-v6ops-dc-ipv6-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: Sun, 14 Jul 2013 22:10:56 -0000 This is a multi-part message in MIME format. --------------050309060802080109080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI We apply most of the changes suggested by the reviewers. There are still a few more suggestions about Cost, Hypervisors, virtualization and monitoring, mobility of VMs and suggestions of which devices in a DC to move first to dual-stack. The authors will be contacting the reviewers offlist to clarify some questions that we have about the suggestions and also would will use the meeting in Berlin to discuss those changes face to face. If we are missing a suggestion or concern that is not about the topics mentioned please let us know. And thanks to all for your reviews. v6-DC authors, as -------- Original Message -------- Subject: I-D Action: draft-lopez-v6ops-dc-ipv6-05.txt Date: Sun, 14 Jul 2013 15:00:42 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Operational Guidelines for Datacenters Author(s) : Diego R. Lopez Zhonghua Chen Tina Tsou Cathy Zhou Arturo Servin Filename : draft-lopez-v6ops-dc-ipv6-05.txt Pages : 20 Date : 2013-07-14 Abstract: This document is intended to provide operational guidelines for datacenter operators planning to deploy IPv6 in their infrastructures. It aims to offer a reference framework for evaluating different products and architectures, and therefore it is also addressed to manufacturers and solution providers, so they can use it to gauge their solutions. We believe this will translate in a smoother and faster IPv6 transition for datacenters of these infrastuctures. The document focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployment on the Data Center (DC) infrastructure. Apart from facilitating the transition to IPv6, the mechanisms outlined here are intended to make this transition as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-lopez-v6ops-dc-ipv6-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050309060802080109080005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    FYI

    We apply most of the changes suggested by the reviewers. There are still a few more suggestions about Cost, Hypervisors, virtualization and monitoring, mobility of VMs and suggestions of which devices in a DC to move first to dual-stack.

    The authors will be contacting the reviewers offlist to clarify some questions that we have about the suggestions and also would will use the meeting in Berlin to discuss those changes face to face.

    If we are missing a suggestion or concern that is not about the topics mentioned please let us know. And thanks to all for your reviews.

v6-DC authors,
as


-------- Original Message --------
Subject: I-D Action: draft-lopez-v6ops-dc-ipv6-05.txt
Date: Sun, 14 Jul 2013 15:00:42 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : IPv6 Operational Guidelines for Datacenters
	Author(s)       : Diego R. Lopez
                          Zhonghua Chen
                          Tina Tsou
                          Cathy Zhou
                          Arturo Servin
	Filename        : draft-lopez-v6ops-dc-ipv6-05.txt
	Pages           : 20
	Date            : 2013-07-14

Abstract:
   This document is intended to provide operational guidelines for
   datacenter operators planning to deploy IPv6 in their
   infrastructures.  It aims to offer a reference framework for
   evaluating different products and architectures, and therefore it is
   also addressed to manufacturers and solution providers, so they can
   use it to gauge their solutions.  We believe this will translate in a
   smoother and faster IPv6 transition for datacenters of these
   infrastuctures.

   The document focuses on the DC infrastructure itself, its operation,
   and the aspects related to DC interconnection through IPv6.  It does
   not consider the particular mechanisms for making Internet services
   provided by applications hosted in the DC available through IPv6
   beyond the specific aspects related to how their deployment on the
   Data Center (DC) infrastructure.

   Apart from facilitating the transition to IPv6, the mechanisms
   outlined here are intended to make this transition as transparent as
   possible (if not completely transparent) to applications and services
   running on the DC infrastructure, as well as to take advantage of
   IPv6 features to simplify DC operations, internally and across the
   Internet.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-lopez-v6ops-dc-ipv6-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------050309060802080109080005-- From internet-drafts@ietf.org Sun Jul 14 15:47:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB4B21F9C13; Sun, 14 Jul 2013 15:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 N+QpZmJGa4pe; Sun, 14 Jul 2013 15:47:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6408821F9C15; Sun, 14 Jul 2013 15:47:15 -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: 4.51.p2 Message-ID: <20130714224715.23950.8919.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 15:47:15 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-08.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: Sun, 14 Jul 2013 22:47:19 -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 : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN link Author(s) : Cameron Byrne Dan Drown Ales Vizdal Filename : draft-ietf-v6ops-64share-08.txt Pages : 8 Date : 2013-07-14 Abstract: This document describes two methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ales.vizdal@t-mobile.cz Sun Jul 14 16:08:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8CF21F9C21 for ; Sun, 14 Jul 2013 16:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 xm9phBP6UM7P for ; Sun, 14 Jul 2013 16:08:38 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4022721F9ADE for ; Sun, 14 Jul 2013 16:08:38 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id D77F82E07DA for ; Mon, 15 Jul 2013 01:08:32 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Mon, 15 Jul 2013 01:08:32 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Mon, 15 Jul 2013 01:08:28 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-08.txt Thread-Index: Ac6A5ESHHQQZSXtzQ8ehwwoHbMybPAAAFopw Message-ID: <1808340F7EC362469DDFFB112B37E2FCD25E7648AE@SRVHKE02.rdm.cz> References: <20130714224715.23950.8919.idtracker@ietfa.amsl.com> In-Reply-To: <20130714224715.23950.8919.idtracker@ietfa.amsl.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-08.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: Sun, 14 Jul 2013 23:08:42 -0000 Hi, a new version has been submitted trying to tackle various wglc comments. A brief changelog: - Scenario 1 has been removed - 'an interface' has been replaced with 'a link', so the I-D shall be in li= ne with the IPv6 arch RFC - various comments have been incorporated There were some comments asking to keep Scenario 2 (former 3) only, but I b= elieve that Scenario 1 (former 2) is easier to implement, so I kept it. If you believe that ther= e should be only one=20 Scenario described and Scenario 1 (former 2) will cause a lot of headaches = please comment. This work is still kept 3GPP specific (a solution to a 3GPP specific issue)= although there was=20 a comment to make it more generic. I have no intention to expand the scope. Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= internet- > drafts@ietf.org > Sent: Monday, July 15, 2013 12:47 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >=20 > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interf= ace to a > LAN link > Author(s) : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-08.txt > Pages : 8 > Date : 2013-07-14 >=20 > Abstract: > This document describes two methods for extending an IPv6 /64 prefix > from a User Equipment 3GPP radio interface to a LAN link. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Sun Jul 14 19:56:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A274021F964C for ; Sun, 14 Jul 2013 19:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 gIT912HBVSsa for ; Sun, 14 Jul 2013 19:56:19 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8521F963C for ; Sun, 14 Jul 2013 19:56:15 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so1355741qab.15 for ; Sun, 14 Jul 2013 19:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JaKIk2Q9LC0k1ALmErmalco+oAbWWqmHkMW8vKFsnwI=; b=kkF5My2gaG2ckRqJcJ0ZRQGeYnJeC4W8TXelFGw4e0DO73JIjDz0lV+h6xAfsWjPXh UALPTT3souErMwIAYit3utN2K+dcPq9U1ePyASNDc3wc/FpZBVyRxYEEGzAKPIR1/VK4 L9R6Gbr90y/HXQai6f8Y+6HVoCCzprq0N81zuH/VnvWJ0RKxZhUW2uaYv9duLRtrgAPF k7dywrHUDsCC/nP15Hb1lJ9YPRue6wHByu/MNFi6rFw8gzdLsc5k2M/wG5Kgnt5zIz9f nmM9e3/EYywPWFFkdXQKhVswbvZElxGDm1zbaB8BJnCr/EWCSXgIX+i75A7D+j1I1vcV IZOQ== MIME-Version: 1.0 X-Received: by 10.229.184.1 with SMTP id ci1mr11202412qcb.88.1373856974871; Sun, 14 Jul 2013 19:56:14 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sun, 14 Jul 2013 19:56:14 -0700 (PDT) In-Reply-To: <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> Date: Mon, 15 Jul 2013 10:56:14 +0800 Message-ID: From: GangChen To: "Alexis Munoz (Gmail)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 02:56:19 -0000 Hi Alexis, Thanks for the interests. We are experiencing the issues recently when IPv6 is tested/deployed. For the goal of the draft, it reports that to the community and hopes to mature IPv6 supports either by encouraging proper implementations on mobile terminals or completing global roaming contracts. Your reviews/comments are appreciated BRs Gang 2013/7/9, Alexis Munoz (Gmail) : > It looks so interesting. I will check it and I will give you my comments > very soon. > > Thanks, > > Alexis Mu=F1oz > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Tuesday, July 09, 2013 7:45 AM > To: v6ops@ietf.org > Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org > Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis > > > A new draft has been posted, at > http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From alejandroacostaalamo@gmail.com Sun Jul 14 21:14:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5802E21F9C88 for ; Sun, 14 Jul 2013 21:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ssqayfc3Hx6O for ; Sun, 14 Jul 2013 21:14:53 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7165821F9021 for ; Sun, 14 Jul 2013 21:14:53 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so2417266wid.1 for ; Sun, 14 Jul 2013 21:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ivl/mNx47lceh+lTcgCUZl/xn5RID4bJ1XmrGeMaJ+4=; b=CsK2QSvJN8mBfpmUD3Hs2iMo8zaS0pv2KcwV/12dZ/r4aeWxkNDtnPfhMHSNgJHFkt cDy6Q4AJVcYIKLiYjffnt3hvIa3HR4Ph4MWpErm+2jKmDy7dwydtNXuLU+tYl596DtUQ OoMl9+NzWQrPq4xVyntNxonAG7kqcDa7A5g+xRS0r2gRYyIuzV4rq7YfzrHYU021pEQ+ u4wnXVTCGkBzM7LtQe2fZUggR5YzHcYwcRSJfoz5HVgvEsSnpiuXXRbBPMpxcmAGE7iT IbcpUqcLimk9mkdkZHR2phWHsLquAxrYn1Diki97YYOyrb8QLvp+5GxIlBnn27rGqXeJ 5gEA== MIME-Version: 1.0 X-Received: by 10.181.12.80 with SMTP id eo16mr7626104wid.44.1373861690069; Sun, 14 Jul 2013 21:14:50 -0700 (PDT) Received: by 10.216.158.136 with HTTP; Sun, 14 Jul 2013 21:14:49 -0700 (PDT) In-Reply-To: <51E15A35.2090603@lacnic.net> References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> Date: Mon, 15 Jul 2013 06:14:49 +0200 Message-ID: From: Alejandro Acosta To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 04:14:54 -0000 Hi Arturo, Great to see there is some working on this. Just two comments, not big changes: Both in the introduction section: 1) "A good monitor solution allows to:" I think it should be changed for something like this: "A good monitor solution -among other things- allows to": 2) : Change "Determinate which actions may solve a problem" by "Determine which actions may solve a problem" Best regards, Alejandro, On 7/13/13, Arturo Servin wrote: > Hi, > > We have sent this draft about considerations and recommendations to > monitor IPv6 and dual-stack networks and services. We have been talking > with people deploying IPv6 and we have found that not all monitor their > networks and not many monitor them properly. We also found some > challenges in monitor implementations that not fully support IPv6 > monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even > though monitoring v6 networks is as critical as doing it in v4, we have > not found many documents explaining how that has to be done (at least > guides with free access or up to date). > > There are also some misconceptions about monitoring IPv6, for > example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and > send them on IPv4 that we wanted to clarify. > > We collected some recommendations from informal conversations with > people during some training and NOGs meeting during this year but we > need some more input. We will be sharing this draft with other forums to > get more inputs but we wanted to share it here first. > > Best wishes, > Arturo and Mariela > > On 7/13/13 9:45 AM, fred@cisco.com wrote: >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take >> a look at it and comment. >> _______________________________________________ >> 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 > -- ===== ^A.......o$ From diego@tid.es Mon Jul 15 02:47:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241BF21F9703 for ; Mon, 15 Jul 2013 02:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ+RhxiDq8Bg for ; Mon, 15 Jul 2013 02:46:56 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B22A621F9306 for ; Mon, 15 Jul 2013 02:46:55 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MPZ00A3E1TYV3@tid.hi.inet> for v6ops@ietf.org; Mon, 15 Jul 2013 11:46:54 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 59.B8.03142.D05C3E15; Mon, 15 Jul 2013 11:46:54 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MPZ00A5J1U5V3@tid.hi.inet> for v6ops@ietf.org; Mon, 15 Jul 2013 11:46:53 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 11:46:53 +0200 Date: Mon, 15 Jul 2013 09:46:53 +0000 From: "Diego R. Lopez" In-reply-to: <51E15A35.2090603@lacnic.net> X-Originating-IP: [10.95.64.115] To: Arturo Servin Message-id: Content-id: <569531728A2AF342984E67DDF5DB5DA3@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 Thread-index: AQHOf8a71umfshwiIkyAfKliXlr1eJlifauAgALhu4A= X-AuditID: 0a5f4068-b7f128e000000c46-2d-51e3c50d2ed9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhinfg0uU7+jjQ4N9MZovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY3f3I9aCdYoVS6c0sjcwHlDoYuTkkBAwkTg/ZwMjhC0mceHe erYuRi4OIYGNjBIn381lh3B+MErMntnPCOFMY5R4dWIZC0gLi4CqxKMZf8Ha2UDs5t9AHRwc wgJOEssfFIGEOQW0JJ41PmGH2KAg8efcY7BWEQE1iRvTPrKB2MwC6hLfnl5gBbF5BbwlFlyZ xQIRN5OY8WgzE0RcUOLH5HssIONB6qdMyYUoEZdobr0JVa4oMW1RA9g1jAKyEu/mz2eFWOUs 8Wf6Dqi1VhKtH3cyQ5wjILFkz3koW1Ti5eN/YPVCAvESqxquskxglJiF5IpZSK6YhXDFLCRX zEJyxQJG1lWMYsVJRZnpGSW5iZk56QaGehmZepl5qSWbGCExl7GDcflOlUOMAhyMSjy8GWqP A4VYE8uKK3MPMUpwMCuJ8C5TfhQoxJuSWFmVWpQfX1Sak1p8iJGJg1OqgTHgeN9eoXl3zijv /vU6dnrglikFa3nL26qT8uR1HnCzZD8W2fPzbIPGcf2vh++rzJ8Wf9lsslv1tA+2M6Lbt/Fv WX70XTfz+jcXq1/fvPli2rHOe/ecH2TWLf/JotO0gZGbwWKFmuMUZtPFuUvyyvfM57PofKcj HeRn8Hf3Xk9pj4QfC6+aCm1XYinOSDTUYi4qTgQA0bltEZcCAAA= References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 09:47:01 -0000 SGksDQoNCkknZCBzYXkgY29sbGVjdGluZyB0aGUgY3VycmVudCBzdGF0ZS1vZi10aGUtYXJ0IGFu ZCB0aGUgb3BlcmF0aW9uYWwgcHJhY3RpY2UgaW4gbW9uaXRvcmluZyB3aWxsIGJlIG9mIGdyZWF0 IGhlbHAsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byB0aGUgdHJpY2t5IGluZXF1YWxpdGll cyB5b3UgbWVudGlvbi4uLiBJIHJlYWxseSBob3BlIHRvIHNlZSBhIGNvbXByZWhlbnNpdmUgY29s bGVjdGlvbiBvZiB0aGVzZSBkZXRhaWwsIGNvbGxlY3RlZCBhcyB5b3Ugc2F5IGZyb20gZGlyZWN0 IGV4cGVyaWVuY2VzIGFjcm9zcyB0aGUgV0cgYW5kIG90aGVyIGZvcmEuDQoNClJlZ2FyZGluZyB0 aGUgY3VycmVudCBjb250ZW50cywgSSdkIGxpa2UgdG8gYXNrIHlvdSB0byBpbmNsdWRlIGNvbnNp ZGVyYXRpb25zIGZvciBhdCBsZWFzdDoNCg0KMSkgVGhlIHVzYWdlIG9mIFNETiAoT3BlbkZsb3cg aW4gcGFydGljdWxhcikgYXMgYW4gYWx0ZXJuYXRpdmUgdGVjaG5pcXVlLCBwcm9iYWJseSB1bmRl ciAyLjMNCg0KMikgVGhlIGltcGxpY2F0aW9ucyBvZiB0aGUgdXNhZ2Ugb2YgbG9jYWwgYWRkcmVz c2VzIGFuZCBwcml2YWN5LXByb3RlY3Rpb24gYWRkcmVzcyBhbGxvY2F0aW9uIHRlY2huaXF1ZXMN Cg0KQW5kIHRoZXJlIGlzIGFsd2F5cyB0aGUgbWF0dGVyIG9mIGNyb3NzLXByb3ZpZGVyIG9yIGZl ZGVyYXRlZCBtb25pdG9yaW5nLCB0aGF0IEknZCBzYXkgaXMgbm90IHRoYXQgY2xvc2UgZXZlbiBp biB2NCBzcGFjZSwgYW5kIHRoYXQgcHJvYmFibHkgd291bGQgZGVzZXJ2ZSBzb21lIGRpc2N1c3Np b24gYXMgd2VsbC4uLg0KDQpCZSBnb29kZSwNCg0KT24gMTMgSnVsIDIwMTMsIGF0IDE1OjQ2ICwg QXJ0dXJvIFNlcnZpbiB3cm90ZToNCg0KPiBIaSwNCj4NCj4gICAgV2UgaGF2ZSBzZW50IHRoaXMg ZHJhZnQgYWJvdXQgY29uc2lkZXJhdGlvbnMgYW5kIHJlY29tbWVuZGF0aW9ucyB0bw0KPiBtb25p dG9yIElQdjYgYW5kIGR1YWwtc3RhY2sgbmV0d29ya3MgYW5kIHNlcnZpY2VzLiBXZSBoYXZlIGJl ZW4gdGFsa2luZw0KPiB3aXRoIHBlb3BsZSBkZXBsb3lpbmcgSVB2NiBhbmQgd2UgaGF2ZSBmb3Vu ZCB0aGF0IG5vdCBhbGwgbW9uaXRvciB0aGVpcg0KPiBuZXR3b3JrcyBhbmQgbm90IG1hbnkgbW9u aXRvciB0aGVtIHByb3Blcmx5LiBXZSBhbHNvIGZvdW5kIHNvbWUNCj4gY2hhbGxlbmdlcyBpbiBt b25pdG9yIGltcGxlbWVudGF0aW9ucyB0aGF0IG5vdCBmdWxseSBzdXBwb3J0IElQdjYNCj4gbW9u aXRvcmluZyB0ZWNobm9sb2dpZXMgKHNubXAsIG5ldGZsb3csIGlwZml4LCBpcHY2IHRyYW5zcG9y dCkuIEV2ZW4NCj4gdGhvdWdoIG1vbml0b3JpbmcgdjYgbmV0d29ya3MgaXMgYXMgY3JpdGljYWwg YXMgZG9pbmcgaXQgaW4gdjQsIHdlIGhhdmUNCj4gbm90IGZvdW5kIG1hbnkgZG9jdW1lbnRzIGV4 cGxhaW5pbmcgaG93IHRoYXQgaGFzIHRvIGJlIGRvbmUgKGF0IGxlYXN0DQo+IGd1aWRlcyB3aXRo IGZyZWUgYWNjZXNzIG9yIHVwIHRvIGRhdGUpLg0KPg0KPiAgICBUaGVyZSBhcmUgYWxzbyBzb21l IG1pc2NvbmNlcHRpb25zIGFib3V0IG1vbml0b3JpbmcgSVB2NiwgZm9yDQo+IGV4YW1wbGUgU05N UHYzICE9IFNOTVArSVB2Niwgb3IgdGhhdCB5b3UgY2Fubm90IGNvbGxlY3QgSVB2NiBkYXRhIGFu ZA0KPiBzZW5kIHRoZW0gb24gSVB2NCB0aGF0IHdlIHdhbnRlZCB0byBjbGFyaWZ5Lg0KPg0KPiAg ICAgV2UgY29sbGVjdGVkIHNvbWUgcmVjb21tZW5kYXRpb25zIGZyb20gaW5mb3JtYWwgY29udmVy c2F0aW9ucyB3aXRoDQo+IHBlb3BsZSBkdXJpbmcgc29tZSB0cmFpbmluZyBhbmQgTk9HcyBtZWV0 aW5nIGR1cmluZyB0aGlzIHllYXIgYnV0IHdlDQo+IG5lZWQgc29tZSBtb3JlIGlucHV0LiBXZSB3 aWxsIGJlIHNoYXJpbmcgdGhpcyBkcmFmdCB3aXRoIG90aGVyIGZvcnVtcyB0bw0KPiBnZXQgbW9y ZSBpbnB1dHMgYnV0IHdlIHdhbnRlZCB0byBzaGFyZSBpdCBoZXJlIGZpcnN0Lg0KPg0KPiBCZXN0 IHdpc2hlcywNCj4gQXJ0dXJvIGFuZCBNYXJpZWxhDQo+DQo+IE9uIDcvMTMvMTMgOTo0NSBBTSwg ZnJlZEBjaXNjby5jb20gd3JvdGU6DQo+PiBBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQsIGF0 IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlcnZpbi12Nm9wcy1tb25pdG9yLWRz LWlwdjYuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBpdCBhbmQgY29tbWVudC4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KLS0NCiJFc3Rh IHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6 DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUt bWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQg NjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRp cmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51 ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOz bmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGlu dGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDov L3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From jiangsheng@huawei.com Mon Jul 15 03:14:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFAD21F9EDF for ; Mon, 15 Jul 2013 03:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 Hp-W2hXN1fla for ; Mon, 15 Jul 2013 03:14:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1E21F9E39 for ; Mon, 15 Jul 2013 03:14:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA40105; Mon, 15 Jul 2013 10:14:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 11:13:35 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 11:14:07 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 18:14:03 +0800 From: Sheng Jiang To: "" Thread-Topic: New Version Notification for draft-jiang-v6ops-semantic-prefix-04.txt Thread-Index: AQHOgUOKgyD7hiYkvUe72LG1mvfyrZllhKbg Date: Mon, 15 Jul 2013 10:14:01 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACAE3DB@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] FW: New Version Notification for draft-jiang-v6ops-semantic-prefix-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: Mon, 15 Jul 2013 10:14:26 -0000 RGVhciB2Nm9wcw0KDQpXZSBoYXZlIGp1c3QgdXBkYXRlIHRoZSBvdXIgc2VtYW50aWMgcHJlZml4 IGRyYWZ0IGFjY29yZGluZyB0byB0aGUgZGljdXNzaW9uIGluIG1haWwgbGlzdC4gVGhlIG1ham9y IG1vZGlmaWNhdGlvbiBhcmUgdHdvOg0KDQpBLCByZXN0cnVjdHVyZSB0byBiZSBhIG5ldXRyYWwg YW5hbHlzaXMgZG9jdW1lbnQsIGFsc28gY29ycmVzcG9uZGVudCB0ZXh0czsgDQoNCkIsIGFkZCBu ZXcgZHJhd2JhY2sgc2VjdGlvbiB0byBjb21wbGV0ZSB0aGUgbmV1dHJhbCBhbmFseXNpczsNCg0K UGxlYXNlIHJlYWQgYW5kIGNvbW1lbnQuIEFueSBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoN CkJlc3QgcmVnYXJkcywNCg0KU2hlbmcgKyBJYW4gKyBRaW9uZyArIFlhbmcgKyBUaWFubGUNCg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPlNlbnQ6IE1vbmRheSwgSnVs eSAxNSwgMjAxMyA2OjEwIFBNDQo+VG86IFRpYW5sZSBZYW5nOyBRaW9uZyBTdW47IElhbiBGYXJy ZXI7IFNoZW5nIEppYW5nOyBCb3lhbmcNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTA0LnR4dA0KPg0KPg0K PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgt MDQudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaGVuZyBKaWFuZyBh bmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5GaWxlbmFtZToJIGRyYWZ0 LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeA0KPlJldmlzaW9uOgkgMDQNCj5UaXRsZToJCSBB bmFseXNpcyBvZiBTZW1hbnRpYyBFbWJlZGRlZCBJUHY2IEFkZHJlc3MgU2NoZW1hcw0KPkNyZWF0 aW9uIGRhdGU6CSAyMDEzLTA3LTE1DQo+R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ TnVtYmVyIG9mIHBhZ2VzOiAyMg0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDQudHh0DQo+U3RhdHVz Og0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctdjZvcHMtc2Vt YW50aWMtcHJlZml4DQo+SHRtbGl6ZWQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTA0DQo+RGlmZjoNCj5odHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDQN Cj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGlzY3Vzc2Vz IHRoZSB1c2Ugb2YgZW1iZWRkZWQgc2VtYW50aWNzDQo+ICAgd2l0aGluIElQdjYgYWRkcmVzcyBz Y2hlbWFzLiAgTmV0d29yayBvcGVyYXRvcnMgd2hvIGhhdmUgbGFyZ2UgSVB2Ng0KPiAgIGFkZHJl c3Mgc3BhY2UgbWF5IGNob29zZSB0byBlbWJlZCBzb21lIHNlbWFudGljcyBpbnRvIHRoZWlyIElQ djYNCj4gICBhZGRyZXNzaW5nIGJ5IGFzc2lnbmluZyBhZGRpdGlvbmFsIHNpZ25pZmljYW5jZSB0 byBzcGVjaWZpYyBiaXRzDQo+ICAgd2l0aGluIHRoZSBwcmVmaXguICBCeSBlbWJlZGRpbmcgc2Vt YW50aWNzIGludG8gSVB2NiBwcmVmaXhlcywgdGhlDQo+ICAgc2VtYW50aWNzIG9mIHBhY2tldHMg Y2FuIGJlIGVhc2lseSBpbnNwZWN0ZWQuICBUaGlzIGNhbiBzaW1wbGlmeSB0aGUNCj4gICBwYWNr ZXQgZGlmZmVyZW50aWF0aW9uIHByb2Nlc3MuICBIb3dldmVyLCBzZW1hbnRpYyBlbWJlZGRlZCBJ UHY2DQo+ICAgYWRkcmVzcyBzY2hlbWFzIGhhdmUgdGhlaXIgb3duIG9wZXJhdGlvbmFsIGNvc3Qg YW5kIGV2ZW4gcG90ZW50aWFsDQo+ICAgcGl0ZmFsbHMuICBTb21lIGNvbXBsZXggc2VtYW50aWMg ZW1iZWRkZWQgSVB2NiBhZGRyZXNzIHNjaGVtYXMgbWF5DQo+ICAgYWxzbyByZXF1aXJlIG5ldyB0 ZWNobm9sb2dpZXMgaW4gYWRkaXRpb24gdG8gZXhpc3RpbmcgSW50ZXJuZXQNCj4gICBwcm90b2Nv bHMuDQo+DQo+ICAgVGhlIGRvY3VtZW50IGFpbXMgdG8gdW5kZXJzdGFuZCB0aGUgdXNhZ2Ugb2Yg c2VtYW50aWMgZW1iZWRkZWQgSVB2Ng0KPiAgIGFkZHJlc3Mgc2NoZW1hcywgYW5kIG5ldXRyYWxs eSBhbmFseXplIG9uIHRoZSBhc3NvY2lhdGVkIGFkdmFudGFnZXMsDQo+ICAgZHJhd2JhY2tzIGFu ZCB0ZWNobmljYWwgZ2FwcyBmb3IgbW9yZSBjb21wbGV4IGFkZHJlc3Mgc2NoZW1hcy4NCj4NCj4N Cj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From aservin@lacnic.net Mon Jul 15 04:44:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169521F9E13 for ; Mon, 15 Jul 2013 04:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 damdNYY+Kezw for ; Mon, 15 Jul 2013 04:44:27 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 043AB21F9DF0 for ; Mon, 15 Jul 2013 04:44:26 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2800:af:ba30:ce73:5cbc:d667:d95a:64ad]) by mail.lacnic.net.uy (Postfix) with ESMTP id 58BCD308427; Mon, 15 Jul 2013 08:43:59 -0300 (UYT) Message-ID: <51E3E093.2000105@lacnic.net> Date: Mon, 15 Jul 2013 08:44:19 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alejandro Acosta References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:44:27 -0000 Thanks Alejandro for the comments. I have made the edits and I will pushing a revision today with some other recommendations that we have received off-list. Best regards, as On 7/15/13 1:14 AM, Alejandro Acosta wrote: > Hi Arturo, > Great to see there is some working on this. > Just two comments, not big changes: > Both in the introduction section: > > 1) > "A good monitor solution allows to:" > > I think it should be changed for something like this: > > "A good monitor solution -among other things- allows to": > > 2) > : > > Change "Determinate which actions may solve a problem" > by > "Determine which actions may solve a problem" > > > Best regards, > > Alejandro, > > On 7/13/13, Arturo Servin wrote: >> Hi, >> >> We have sent this draft about considerations and recommendations to >> monitor IPv6 and dual-stack networks and services. We have been talking >> with people deploying IPv6 and we have found that not all monitor their >> networks and not many monitor them properly. We also found some >> challenges in monitor implementations that not fully support IPv6 >> monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even >> though monitoring v6 networks is as critical as doing it in v4, we have >> not found many documents explaining how that has to be done (at least >> guides with free access or up to date). >> >> There are also some misconceptions about monitoring IPv6, for >> example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and >> send them on IPv4 that we wanted to clarify. >> >> We collected some recommendations from informal conversations with >> people during some training and NOGs meeting during this year but we >> need some more input. We will be sharing this draft with other forums to >> get more inputs but we wanted to share it here first. >> >> Best wishes, >> Arturo and Mariela >> >> On 7/13/13 9:45 AM, fred@cisco.com wrote: >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take >>> a look at it and comment. >>> _______________________________________________ >>> 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 aservin@lacnic.net Mon Jul 15 04:49:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF57421E809F for ; Mon, 15 Jul 2013 04:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 jiSB3It6pi6k for ; Mon, 15 Jul 2013 04:49:56 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 212CF21E809D for ; Mon, 15 Jul 2013 04:49:56 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2800:af:ba30:ce73:5cbc:d667:d95a:64ad]) by mail.lacnic.net.uy (Postfix) with ESMTP id 20FAF308478; Mon, 15 Jul 2013 08:49:32 -0300 (UYT) Message-ID: <51E3E1E0.9090203@lacnic.net> Date: Mon, 15 Jul 2013 08:49:52 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Diego R. Lopez" References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:49:56 -0000 Diego, Thanks for the comments. I will try to incorporate some changes before the deadline. Some questions in line. On 7/15/13 6:46 AM, Diego R. Lopez wrote: > Hi, > > I'd say collecting the current state-of-the-art and the operational practice in monitoring will be of great help, especially when it comes to the tricky inequalities you mention... I really hope to see a comprehensive collection of these detail, collected as you say from direct experiences across the WG and other fora. > > Regarding the current contents, I'd like to ask you to include considerations for at least: > > 1) The usage of SDN (OpenFlow in particular) as an alternative technique, probably under 2.3 I have never thought about it but it seems plausible. Do you have a reference, perhaps some previous work about this topic? > > 2) The implications of the usage of local addresses and privacy-protection address allocation techniques Noted. > > And there is always the matter of cross-provider or federated monitoring, that I'd say is not that close even in v4 space, and that probably would deserve some discussion as well... I'll ask some operators that I know have virtual services how they do it, but if you have some pointers or references would be very greate > > Be goode, > > Thanks for the comments, as I said we will try to incorporate as many as possible before the deadline. Regards, as From prvs=9005a9dde=Victor.Kuarsingh@rci.rogers.com Sat Jul 13 19:53:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00E21F9DCD for ; Sat, 13 Jul 2013 19:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ulZxOxamTnpV for ; Sat, 13 Jul 2013 19:53:21 -0700 (PDT) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 33E1C21F9C88 for ; Sat, 13 Jul 2013 19:53:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAB4S4lGOkg6CmWdsb2JhbABZgzrCGwQBgQoWDgEBAQEBCAsLBxQogiMBAQEEEh4jCwEYAgwEAgEIDQQEAQELBhcBBgFFBwEBBQMBAQQTCAESB4duDJkwnCeOW1gdFA0QgnVtA4hvhg2ESIVBhR2ONSA X-IronPort-AV: E=Sophos;i="4.89,662,1367985600"; d="scan'208";a="326854541" Received: from unknown (HELO rsoesnexigwa.rci.rogers.ca) ([142.146.14.130]) by mail.mail.rss.rogers.com with ESMTP; 13 Jul 2013 22:52:59 -0400 Received: from RSOESNGTABHB.rci.rogers.ca ([10.3.37.23]) by rsoesnexigwa.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Jul 2013 22:52:59 -0400 Received: from CL08MBD.rci.rogers.ca ([10.3.45.54]) by RSOESNGTABHB.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Jul 2013 22:52:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 13 Jul 2013 22:52:59 -0400 Message-ID: <8A70B9B0A1863E4395686F63AD4CDC14052493B5@CL08MBD.rci.rogers.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-grundemann-hipnet-00.txt Thread-Index: Ac5/IeE5wKUYiR2tS4ClgakFNJVELgBGbD57 References: <20130712170429.5744.96896.idtracker@ietfa.amsl.com> From: "Victor Kuarsingh" To: X-OriginalArrivalTime: 14 Jul 2013 02:52:59.0426 (UTC) FILETIME=[3FEE3820:01CE803D] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Mon, 15 Jul 2013 04:52:31 -0700 Cc: draft-grundemann-hipnet@tools.ietf.org Subject: [v6ops] FW: New Version Notification for draft-grundemann-hipnet-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: Sun, 14 Jul 2013 02:53:26 -0000 djZvcHMgV0csCgpUaGUgYXV0aG9yIHRlYW0gb2YgZHJhZnQtZ3VuZGVtYW5uLWhpcG5ldCAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3J1bmRlbWFubi1oaXBuZXQtMDApIGlzIHNl ZWtpbmcgcmV2aWV3IGZyb20gdjZvcHMgcmVnYXJkaW5nIHRoZSBkcmFmdCB3aGljaCBvdXRsaW5l cyBhIG1ldGhvZCB1c2luZyBleGlzdGluZyB0ZWNobm9sb2dpZXMgdG8gc3VwcG9ydCBtb3JlIGNv bXBsZXggdG9wb2xvZ2llcyBpbiAoYWR2YW5jZWQpIGhvbWUgbmV0d29ya3MuICAoVGhpcyBkb2N1 bWVudCBpcyBhIHJlLXBvc3Rpbmcgb2YgcHJldmlvdXMgZHJhZnQpLgoKV2Ugb3JpZ2luYWxseSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IHdpdGhpbiBob21lbmV0IGFuZCBwcmVzZW50ZWQgaXQgYXQg SUVURjg2IHNpbmNlIHRoYXQgZ3JvdXAgaXMgZm9jdXNlZCBvbiBhZHZhbmNpbmcgdGhlIGhvbWUg bmV0d29yayBhbmQgd2Ugd2FudGVkIHRvIG1ha2Ugc3VyZSB3ZSBoYWQgdGhlIHJpZ2h0IHBvbGxp bmF0aW9uIG9mIGluZm9ybWF0aW9uIGFjcm9zcyB0aGUgdmFyaW91cyBncm91cHMgbG9va2luZyBp bnRvIHRoZSBob21lIG5ldHdvcmsuCgpHaXZlbiB0aGF0ICJISVBuZXQiIChvdXRsaW5lZCBpbiBk cmFmdC1ncnVuZGVtYW5uLWhpcG5ldCkgaXMgdmVyeSBvcGVyYXRpb25hbGx5IGZvY3VzZWQgYW5k IHVzZXMgZXhpc3RpbmcgcHJvdG9jb2xzICh3aXRoIHNvbWUgdHdlYWtzIHRvIERIQ1ApIHRvIHN1 cHBvcnQgYWR2YW5jZWQgaW4taG9tZSB0b3BvbG9naWVzIChsb29raW5nIGF0IGJvdGggSVB2NiBh bmQgSVB2NCksIHdlIGZlZWwgaXQncyBpbXBvcnRhbnQgdG8gcmV2aWV3IGl0IGluIHY2b3BzIChp biBzaW1pbGFyIHZlaW4gYXMgNjIwNCkuCgpUaGUgZG9jdW1lbnQgaXMgYW4gZXh0ZW5zaW9uIHRv IDYyMDQgLyA2MjA0LWJpcyBhbmQgdGhlIGZ1bmN0aW9uYWxpdHkgaXMgdmVyeSBtdWNoIGludGVu ZGVkIGFzIGEgY29tcGF0aWJsZSBwbHVnLWluIHRvIGV4aXN0aW5nIGhvbWUgbmV0d29yayBkZXZp Y2VzLiAgCgpUbyB1bmRlcnN0YW5kIGhvdyBISVBuZXQgZml0cyBpbnRvIHRoZSBsb25nZXIgdGVy bSBwcm9ncmVzc2lvbiBvZiB0aGUgaG9tZSBuZXR3b3JrLCBkcmFmdC1qdmtqam1iLWhvbWUtbmV0 d29ya2luZy1pbmNyZW1lbnRhbCB3YXMgZHJhZnRlZCB0byBoZWxwIHByb3ZpZGUgYSBwZXJzcGVj dGl2ZSBvZiBhIHBvdGVudGlhbCBwcm9ncmVzc2lvbiB3aGljaCBzdGFydHMgYXQgNjIwNCBhbmQg ZW5kcyB1cCBpbiBhIG1vcmUgYWR2YW5jZWQgbW9kZSBvZiBvcGVyYXRpb24gdmVyeSBtdWNoIGlu IGxpbmUgd2l0aCB0aGUgbW9yZSBmdXR1cmUgbG9va2luZyB3b3JrIGluIGhvbWVuZXQgKEkuZS4g Um91dGluZyBwcm90b2NvbCB1c2UsIHNvdXJjZSBhZGRyZXNzIHJvdXRpbmcsIHByZWZpeCBhc3Np Z25tZW50IHZpYSBJR1AgZXRjKS4KCldlIGFwcHJlY2lhdGUgeW91ciB0aW1lIGFuZCBmZWVkYmFj ay4KClJlZ2FyZHMsCgpBdXRob3JzCgogCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddClNlbnQ6IEZyaSA3LzEyLzIwMTMgMTowNCBQTQpUbzogQ2hyaXMgR3J1bmRlbWFubjsgTGVl IEhvd2FyZDsgSm9obiBKYXNvbiBCcnpvem93c2tpOyBDaHJpcyBEb25sZXk7IFZpY3RvciBLdWFy c2luZ2gKU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ncnVuZGVt YW5uLWhpcG5ldC0wMC50eHQKIAoKQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdydW5kZW1h bm4taGlwbmV0LTAwLnR4dApoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENocmlz IEdydW5kZW1hbm4gYW5kIHBvc3RlZCB0byB0aGUKSUVURiByZXBvc2l0b3J5LgoKRmlsZW5hbWU6 CSBkcmFmdC1ncnVuZGVtYW5uLWhpcG5ldApSZXZpc2lvbjoJIDAwClRpdGxlOgkJIEEgTmVhciBU ZXJtIFNvbHV0aW9uIGZvciBIb21lIElQIE5ldHdvcmtpbmcgKEhJUG5ldCkKQ3JlYXRpb24gZGF0 ZToJIDIwMTMtMDctMTIKR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uCk51bWJlciBvZiBw YWdlczogMjEKVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1ncnVuZGVtYW5uLWhpcG5ldC0wMC50eHQKU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdydW5kZW1hbm4taGlwbmV0Ckh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3J1bmRlbWFubi1o aXBuZXQtMDAKCgpBYnN0cmFjdDoKICAgSG9tZSBuZXR3b3JrcyBhcmUgYmVjb21pbmcgbW9yZSBj b21wbGV4LiAgV2l0aCB0aGUgbGF1bmNoIG9mIG5ldwogICBzZXJ2aWNlcyBzdWNoIGFzIGhvbWUg c2VjdXJpdHksIElQIHZpZGVvLCBTbWFydCBHcmlkLCBldGMuLCBtYW55CiAgIFNlcnZpY2UgUHJv dmlkZXJzIGFyZSBwbGFjaW5nIGFkZGl0aW9uYWwgSVB2NC9JUHY2IHJvdXRlcnMgb24gdGhlCiAg IHN1YnNjcmliZXIgbmV0d29yay4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2VsZi1jb25m aWd1cmluZyBob21lCiAgIHJvdXRlciB0aGF0IGlzIGNhcGFibGUgb2Ygb3BlcmF0aW5nIGluIHN1 Y2ggYW4gZW52aXJvbm1lbnQsIGFuZCB0aGF0CiAgIHJlcXVpcmVzIG5vIHVzZXIgaW50ZXJhY3Rp b24gdG8gY29uZmlndXJlIGl0LiAgQ29tcGxpYW50IHdpdGggZHJhZnQtCiAgIGlldGYtaG9tZW5l dC1hcmNoLCBpdCB1c2VzIGV4aXN0aW5nIHByb3RvY29scyBpbiBuZXcgd2F5cyB3aXRob3V0IHRo ZQogICBuZWVkIGZvciBhIHJvdXRpbmcgcHJvdG9jb2wuCgoKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAoKClRoZSBJRVRGIFNlY3JldGFyaWF0CgoKVGhpcyBlLW1haWwgKGFuZCBhdHRhY2htZW50 KHMpKSBpcyBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBtYXkgYmUgc3ViamVjdCB0byBjb3B5 cmlnaHQgYW5kIGxlZ2FsIHByaXZpbGVnZSBhbmQgbm8gcmVsYXRlZCByaWdodHMgYXJlIHdhaXZl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvciBpdHMgYWdlbnQsIGFu eSByZXZpZXcsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMg ZS1tYWlsIG9yIGFueSBvZiBpdHMgY29udGVudCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIEFsbCBtZXNzYWdlcyBtYXkgYmUgbW9uaXRvcmVkIGFzIHBlcm1pdHRl ZCBieSBhcHBsaWNhYmxlIGxhdyBhbmQgcmVndWxhdGlvbnMgYW5kIG91ciBwb2xpY2llcyB0byBw cm90ZWN0IG91ciBidXNpbmVzcy4gRS1tYWlscyBhcmUgbm90IHNlY3VyZSBhbmQgeW91IGFyZSBk ZWVtZWQgdG8gaGF2ZSBhY2NlcHRlZCBhbnkgcmlzayBpZiB5b3UgY29tbXVuaWNhdGUgd2l0aCB1 cyBieSBlLW1haWwuIElmIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgdGhlIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgZnJvbSBh bnkgY29tcHV0ZXIgb3IgYW55IHN0b3JhZ2UgbWVkaXVtIHdpdGhvdXQgcHJpbnRpbmcgYSBjb3B5 LgoKQ2UgY291cnJpZWwgKGFpbnNpIHF1ZSBzZXMgcGnDqGNlcyBqb2ludGVzKSBlc3QgY29uZmlk ZW50aWVsLCBleGNsdXNpZiwgZXQgcGV1dCBmYWlyZSBs4oCZb2JqZXQgZGUgZHJvaXQgZOKAmWF1 dGV1ciBldCBkZSBwcml2aWzDqGdlIGp1cmlkaXF1ZTsgYXVjdW4gZHJvaXQgY29ubmV4ZSBu4oCZ ZXN0IGV4Y2x1LiBTaSB2b3VzIG7igJnDqnRlcyBwYXMgbGUgZGVzdGluYXRhaXJlIHZpc8OpIG91 IHNvbiByZXByw6lzZW50YW50LCB0b3V0ZSDDqXR1ZGUsIGRpZmZ1c2lvbiwgdHJhbnNtaXNzaW9u IG91IGNvcGllIGRlIGNlIGNvdXJyaWVsIGVuIHRvdXQgb3UgZW4gcGFydGllLCBlc3Qgc3RyaWN0 ZW1lbnQgaW50ZXJkaXRlIGV0IHBldXQgw6p0cmUgaWxsw6lnYWxlLiBUb3VzIGxlcyBtZXNzYWdl cyBwZXV2ZW50IMOqdHJlIHN1cnZlaWxsw6lzLCBzZWxvbiBsZXMgbG9pcyBldCByw6hnbGVtZW50 cyBhcHBsaWNhYmxlcyBldCBsZXMgcG9saXRpcXVlcyBkZSBwcm90ZWN0aW9uIGRlIG5vdHJlIGVu dHJlcHJpc2UuIExlcyBjb3VycmllbHMgbmUgc29udCBwYXMgc8OpY3VyaXPDqXMgZXQgdm91cyDD qnRlcyByw6lwdXTDqXMgYXZvaXIgYWNjZXB0w6kgdG91cyBsZXMgcmlzcXVlcyBxdWkgeSBzb250 IGxpw6lzIHNpIHZvdXMgY2hvaXNpc3NleiBkZSBjb21tdW5pcXVlciBhdmVjIG5vdXMgcGFyIGNl IG1veWVuLiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBub3VzIGVuIGF2aXNlciBpbW3DqWRpYXRlbWVudCBldCBzdXBwcmltZXIgY2UgY291cnJpZWwg KGFpbnNpIHF1ZSB0b3V0ZXMgc2VzIHBpw6hjZXMgam9pbnRlcykgZGUgdG91dCBvcmRpbmF0ZXVy IG91IHN1cHBvcnQgZGUgZG9ubsOpZXMgc2FucyBlbiBpbXByaW1lciB1bmUgY29waWUuIAo= From fgont@si6networks.com Mon Jul 15 05:42:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E3621F90FB for ; Mon, 15 Jul 2013 05:42:20 -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 ekLPMI6468Ar for ; Mon, 15 Jul 2013 05:42:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 342C121F8667 for ; Mon, 15 Jul 2013 05:42:17 -0700 (PDT) Received: from 62.117.201.108.dyn.user.ono.com ([62.117.201.108] helo=[192.168.1.203]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uyi6V-0004Dg-5L; Mon, 15 Jul 2013 14:42:11 +0200 Message-ID: <51E3EE20.1080609@si6networks.com> Date: Mon, 15 Jul 2013 14:42:08 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> In-Reply-To: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:42:20 -0000 On 07/03/2013 12:02 AM, S Moonesamy wrote: > Hello, > > An IPv6 Router Advertisements flooding attack can cause a node to > consume all CPU resources available making the system unusable and > unresponsive. draft-moonesamy-ra-flood-limit-00 ( > http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) > recommends some configurable variables as a mitigation against an IPv6 > Router Advertisements flooding attack. > > I would appreciate if you read the draft and comment. Isn't this already covered (together with a bunch of other ND-related stuff) in: ? :-) (this I-D was presented at the OPSEC meeting in Orlando) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From aweher@gmail.com Mon Jul 15 07:21:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DB311E80DC for ; Mon, 15 Jul 2013 07:21:17 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 1CWZ4fmJOlo4 for ; Mon, 15 Jul 2013 07:21:14 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD4411E80D5 for ; Mon, 15 Jul 2013 07:21:04 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so13890935obb.8 for ; Mon, 15 Jul 2013 07:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IGD8YB33KQu4EiXbXG+MesHzSpVXNIp3ydE9tUrJ3lY=; b=PI79tdfb+DQdbVbWmcD/ETW1cageF9wf0dXPlay/+PcVl5EjPaYvtXZ+Tqi5ICZfj6 nvnCEGmPkPDA6gNI0IOTvzwZGx4KAEnLHypapoRAUq2W5ubaqZfvy4jawgbOj/qM8llo WmulH79lucy1oKRfIKwSujqyZdZEA2nIyqqEuj9MUtf6ZBTTckf6XYSDExg58xYD/K6h 5vlXCRmBjSFDtVFbJ7M3dm0ugeYatbDJrUIN3JAGIVwA4J7uWp24SfTUuUUCdpcKWFA/ YCK2L1QCiO2V0Y45lYwfYBWh/NbyErJLzUcT6lwAMM/EG5xLcdED4NHxEceyfvocDacD MJwg== X-Received: by 10.60.97.34 with SMTP id dx2mr43320834oeb.54.1373898062192; Mon, 15 Jul 2013 07:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.153.198 with HTTP; Mon, 15 Jul 2013 07:20:22 -0700 (PDT) In-Reply-To: <51E3E1E0.9090203@lacnic.net> References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <51E3E1E0.9090203@lacnic.net> From: Ariel Weher Date: Mon, 15 Jul 2013 11:20:22 -0300 Message-ID: To: Arturo Servin Content-Type: multipart/alternative; boundary=089e011619bef4693a04e18d911c Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 14:21:18 -0000 --089e011619bef4693a04e18d911c Content-Type: text/plain; charset=ISO-8859-1 Hi all! My review and proposals: In the section 1 avoid the use of the word "problem", you can use incident. Maybe "Detect and avoid network incidents" fits better. Same to "Determinate which actions may solve or explain an incident" In section 2.3 you can include the ipv6 traffic metering based on forwarding ipv4 and ipv6 traffic through separate paths, and monitoring them as usual with octets/time counters. Another technique may be to apply some kind of access-lists or policy-maps which usually have MIB support. Regards. On Mon, Jul 15, 2013 at 8:49 AM, Arturo Servin wrote: > Diego, > > Thanks for the comments. > > I will try to incorporate some changes before the deadline. Some > questions in line. > > On 7/15/13 6:46 AM, Diego R. Lopez wrote: > > Hi, > > > > I'd say collecting the current state-of-the-art and the operational > practice in monitoring will be of great help, especially when it comes to > the tricky inequalities you mention... I really hope to see a comprehensive > collection of these detail, collected as you say from direct experiences > across the WG and other fora. > > > > Regarding the current contents, I'd like to ask you to include > considerations for at least: > > > > 1) The usage of SDN (OpenFlow in particular) as an alternative > technique, probably under 2.3 > I have never thought about it but it seems plausible. Do you have a > reference, perhaps some previous work about this topic? > > > > > 2) The implications of the usage of local addresses and > privacy-protection address allocation techniques > Noted. > > > > And there is always the matter of cross-provider or federated > monitoring, that I'd say is not that close even in v4 space, and that > probably would deserve some discussion as well... > > I'll ask some operators that I know have virtual services how they > do it, but if you have some pointers or references would be very greate > > > > Be goode, > > > > > Thanks for the comments, as I said we will try to incorporate as > many as possible before the deadline. > > Regards, > as > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e011619bef4693a04e18d911c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all!

My review and proposals:

In the section 1 avoid the u= se of the word "problem", you can use incident. Maybe=A0 "De= tect and avoid network incidents" fits better.
Same to "Determ= inate which actions may solve or explain an incident"

In section 2.3 you can include the ipv6 traffic metering based on forwa= rding ipv4 and ipv6 traffic through separate paths, and monitoring them as = usual with octets/time counters.

Another technique may be to apply s= ome kind of access-lists or policy-maps which usually have MIB support.

Regards.



On Mon, Jul 15, 2013= at 8:49 AM, Arturo Servin <aservin@lacnic.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Diego,

=A0 =A0 Thanks for the comments.

=A0 =A0 I will try to incorporate some changes before the deadline. Some questions in line.

On 7/15/13 6:46 AM, Diego R. Lopez wrote:
> Hi,
>
> I'd say collecting the current state-of-the-art and the operationa= l practice in monitoring will be of great help, especially when it comes to= the tricky inequalities you mention... I really hope to see a comprehensiv= e collection of these detail, collected as you say from direct experiences = across the WG and other fora.
>
> Regarding the current contents, I'd like to ask you to include con= siderations for at least:
>
> 1) The usage of SDN (OpenFlow in particular) as an alternative techniq= ue, probably under 2.3
=A0 =A0 I have never thought about it but it seems plausible. Do you = have a
reference, perhaps some previous work about this topic?

>
> 2) The implications of the usage of local addresses and privacy-protec= tion address allocation techniques
=A0 =A0 Noted.
>
> And there is always the matter of cross-provider or federated monitori= ng, that I'd say is not that close even in v4 space, and that probably = would deserve some discussion as well...

=A0 =A0 I'll ask some operators that I know have virtual services= how they
do it, but if you have some pointers or references would be very greate
>
> Be goode,
>
>
=A0 =A0 Thanks for the comments, as I said we will try to incorporate as many as possible before the deadline.

Regards,
as
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e011619bef4693a04e18d911c-- From jouni.nospam@gmail.com Mon Jul 15 07:36:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6492311E813F for ; Mon, 15 Jul 2013 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 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 nDL31zOKCkR9 for ; Mon, 15 Jul 2013 07:36:09 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0852F11E8137 for ; Mon, 15 Jul 2013 07:36:04 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id e11so4550854bkh.26 for ; Mon, 15 Jul 2013 07:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tKRwFvywakyHjROpRZjAtFN5j+REoMJxspMP6oC9l2Q=; b=qVYdJmJbkihi3cTtdRpKWU5R/eCgq2nziZmqfAW6zy2Eqw+CTt8Ios1rPat75i//yP QrXK6Z1JvtsretswgqJKWpMDwoyZ1rPyHrQ4o+CjvCHmoe8xyPjbZ/wS0D7emHOHFD5O e4985+RkoUrLQHnnBS3P555tiahOWG9t8tFvZgNmuJ0mNtInircKgzhKx/v59Eu3z8hF YxAGRML+Qkx8rhnHNShL9fEkXyG/+hjMuVt0mUTWSu6GVChKR6I1pVrg3O8FBMWAvaTl Cx/WMZVGIRPrmyt8JI/udoMZ9yJO4oQQxP9t3YlbznbpiAelEkHhjJX776DZbL+uO7+s 7ppg== X-Received: by 10.204.230.145 with SMTP id jm17mr7898727bkb.125.1373898954204; Mon, 15 Jul 2013 07:35:54 -0700 (PDT) Received: from [192.168.1.3] (dsl-hvkbrasgw1-54f883-172.dhcp.inet.fi. [84.248.131.172]) by mx.google.com with ESMTPSA id ps10sm12476229bkb.14.2013.07.15.07.35.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 07:35:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 15 Jul 2013 17:35:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 14:36:13 -0000 Gang, Regarding roaming in general, have you looked at what GSMA is doing on this front? I was kind of expecting at least a reference to some GSMA document since they are quite important when it comes to 3GPP based networks & roaming. - Jouni On Jul 15, 2013, at 5:56 AM, GangChen wrote: > Hi Alexis, >=20 > Thanks for the interests. We are experiencing the issues recently when > IPv6 is tested/deployed. For the goal of the draft, it reports that to > the community and hopes to mature IPv6 supports either by encouraging > proper implementations on mobile terminals or completing global > roaming contracts. >=20 > Your reviews/comments are appreciated >=20 > BRs >=20 > Gang >=20 > 2013/7/9, Alexis Munoz (Gmail) : >> It looks so interesting. I will check it and I will give you my = comments >> very soon. >>=20 >> Thanks, >>=20 >> Alexis Mu=F1oz >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> fred@cisco.com >> Sent: Tuesday, July 09, 2013 7:45 AM >> To: v6ops@ietf.org >> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >>=20 >>=20 >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. = Please >> take a look at it and comment. >> _______________________________________________ >> 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 aservin@lacnic.net Mon Jul 15 07:57:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C45421F9DAF for ; Mon, 15 Jul 2013 07:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 fS97bYNSWWbn for ; Mon, 15 Jul 2013 07:57:08 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4048821F9DB9 for ; Mon, 15 Jul 2013 07:57:08 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2001:13c7:7001:7000:5c53:3609:f51c:ca56]) by mail.lacnic.net.uy (Postfix) with ESMTP id EF6AC308464; Mon, 15 Jul 2013 11:56:45 -0300 (UYT) Message-ID: <51E40DC3.3040409@lacnic.net> Date: Mon, 15 Jul 2013 11:57:07 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ariel Weher References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <51E3E1E0.9090203@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------070508090405070607000906" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 14:57:09 -0000 This is a multi-part message in MIME format. --------------070508090405070607000906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ariel Noted. I will add and correct. Thanks for the suggestions. Best regards, as On 7/15/13 11:20 AM, Ariel Weher wrote: > Hi all! > > My review and proposals: > > In the section 1 avoid the use of the word "problem", you can use > incident. Maybe "Detect and avoid network incidents" fits better. > Same to "Determinate which actions may solve or explain an incident" > > In section 2.3 you can include the ipv6 traffic metering based on > forwarding ipv4 and ipv6 traffic through separate paths, and > monitoring them as usual with octets/time counters. > > Another technique may be to apply some kind of access-lists or > policy-maps which usually have MIB support. > > Regards. > > > > On Mon, Jul 15, 2013 at 8:49 AM, Arturo Servin > wrote: > > Diego, > > Thanks for the comments. > > I will try to incorporate some changes before the deadline. Some > questions in line. > > On 7/15/13 6:46 AM, Diego R. Lopez wrote: > > Hi, > > > > I'd say collecting the current state-of-the-art and the > operational practice in monitoring will be of great help, > especially when it comes to the tricky inequalities you mention... > I really hope to see a comprehensive collection of these detail, > collected as you say from direct experiences across the WG and > other fora. > > > > Regarding the current contents, I'd like to ask you to include > considerations for at least: > > > > 1) The usage of SDN (OpenFlow in particular) as an alternative > technique, probably under 2.3 > I have never thought about it but it seems plausible. Do you > have a > reference, perhaps some previous work about this topic? > > > > > 2) The implications of the usage of local addresses and > privacy-protection address allocation techniques > Noted. > > > > And there is always the matter of cross-provider or federated > monitoring, that I'd say is not that close even in v4 space, and > that probably would deserve some discussion as well... > > I'll ask some operators that I know have virtual services how they > do it, but if you have some pointers or references would be very > greate > > > > Be goode, > > > > > Thanks for the comments, as I said we will try to incorporate as > many as possible before the deadline. > > Regards, > as > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --------------070508090405070607000906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ariel

    Noted.

    I will add and correct.

    Thanks for the suggestions.

Best regards,
as
On 7/15/13 11:20 AM, Ariel Weher wrote:
Hi all!

My review and proposals:

In the section 1 avoid the use of the word "problem", you can use incident. Maybe  "Detect and avoid network incidents" fits better.
Same to "Determinate which actions may solve or explain an incident"

In section 2.3 you can include the ipv6 traffic metering based on forwarding ipv4 and ipv6 traffic through separate paths, and monitoring them as usual with octets/time counters.

Another technique may be to apply some kind of access-lists or policy-maps which usually have MIB support.

Regards.



On Mon, Jul 15, 2013 at 8:49 AM, Arturo Servin <aservin@lacnic.net> wrote:
Diego,

    Thanks for the comments.

    I will try to incorporate some changes before the deadline. Some
questions in line.

On 7/15/13 6:46 AM, Diego R. Lopez wrote:
> Hi,
>
> I'd say collecting the current state-of-the-art and the operational practice in monitoring will be of great help, especially when it comes to the tricky inequalities you mention... I really hope to see a comprehensive collection of these detail, collected as you say from direct experiences across the WG and other fora.
>
> Regarding the current contents, I'd like to ask you to include considerations for at least:
>
> 1) The usage of SDN (OpenFlow in particular) as an alternative technique, probably under 2.3
    I have never thought about it but it seems plausible. Do you have a
reference, perhaps some previous work about this topic?

>
> 2) The implications of the usage of local addresses and privacy-protection address allocation techniques
    Noted.
>
> And there is always the matter of cross-provider or federated monitoring, that I'd say is not that close even in v4 space, and that probably would deserve some discussion as well...

    I'll ask some operators that I know have virtual services how they
do it, but if you have some pointers or references would be very greate
>
> Be goode,
>
>
    Thanks for the comments, as I said we will try to incorporate as
many as possible before the deadline.

Regards,
as
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--------------070508090405070607000906-- From phdgang@gmail.com Mon Jul 15 08:28:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E711E8100 for ; Mon, 15 Jul 2013 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 IJkThcINOUzo for ; Mon, 15 Jul 2013 08:28:16 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E7DF311E80FF for ; Mon, 15 Jul 2013 08:28:10 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so6559563qeb.15 for ; Mon, 15 Jul 2013 08:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ixlAKT+03tUrB/Eiza+J15EkWQYQcp5Rk4Y1i9w7dFk=; b=naOygHT6pUwDgFlfFAG5PajeLdqKv+nzsdpeH280K4bOEHEa6Gmg/HTzeRpKuzOOcT hAj4DGo5HdrXMI0LqZh4OJiVYLtxx9sI7u+k/R9WVYPQgXRBDsWxRwPSrDyM6t1S9lV7 w89lby7Matya+9aXlPUHM0jV8Vog5zCC5Z8kuRUzFTdsZM431+VSLT69Gw73gzqoRMEy zDZR47s+D4UMYxOzIa6XmPQ+OpHDwdyE3mgZwgYYJV45aLyiVEB+gmkCRUv2ZqwCHO4Y G1XsislzhYihs3N65STpL1N/KAg8hs5VL2A4edN/8zEX1jIB+kyev/RoX5OGdECkkZ9Z /kAg== MIME-Version: 1.0 X-Received: by 10.224.161.145 with SMTP id r17mr53587507qax.72.1373902090078; Mon, 15 Jul 2013 08:28:10 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Mon, 15 Jul 2013 08:28:10 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> Date: Mon, 15 Jul 2013 23:28:10 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:28:17 -0000 2013/7/15, Jouni Korhonen : > > Gang, > > Regarding roaming in general, have you looked at what GSMA is doing > on this front? I was kind of expecting at least a reference to some > GSMA document since they are quite important when it comes to 3GPP > based networks & roaming. I guess GSMA IR.21 could be cited here. http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf Most failures cases are occurred if a roaming partner's IR.21 only states v4 support -g > > - Jouni > > > On Jul 15, 2013, at 5:56 AM, GangChen wrote: > >> Hi Alexis, >> >> Thanks for the interests. We are experiencing the issues recently when >> IPv6 is tested/deployed. For the goal of the draft, it reports that to >> the community and hopes to mature IPv6 supports either by encouraging >> proper implementations on mobile terminals or completing global >> roaming contracts. >> >> Your reviews/comments are appreciated >> >> BRs >> >> Gang >> >> 2013/7/9, Alexis Munoz (Gmail) : >>> It looks so interesting. I will check it and I will give you my comment= s >>> very soon. >>> >>> Thanks, >>> >>> Alexis Mu=F1oz >>> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>> Of >>> fred@cisco.com >>> Sent: Tuesday, July 09, 2013 7:45 AM >>> To: v6ops@ietf.org >>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >>> >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>> Please >>> take a look at it and comment. >>> _______________________________________________ >>> 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 aservin@lacnic.net Mon Jul 15 12:41:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3957E11E81E8 for ; Mon, 15 Jul 2013 12:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 4uyB2Hk8dLzw for ; Mon, 15 Jul 2013 12:41:13 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0266E11E81DD for ; Mon, 15 Jul 2013 12:41:12 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2800:af:ba32:ab16:ec07:4886:27ac:1d85]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7EA3C308479 for ; Mon, 15 Jul 2013 16:40:50 -0300 (UYT) Message-ID: <51E45053.3000202@lacnic.net> Date: Mon, 15 Jul 2013 16:41:07 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "" References: <20130715175812.12200.3316.idtracker@ietfa.amsl.com> In-Reply-To: <20130715175812.12200.3316.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130715175812.12200.3316.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030507090309070604070506" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: [v6ops] Fwd: I-D Action: draft-servin-v6ops-monitor-ds-ipv6-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: Mon, 15 Jul 2013 19:41:14 -0000 This is a multi-part message in MIME format. --------------030507090309070604070506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I sent a new version of the draft. We added some of the suggestions from the list and some others that we received off-list. There are some suggestions from Diego and Ariel that we have not added or are incomplete. We are planning to address those in the short term. Thanks /as -------- Original Message -------- Subject: I-D Action: draft-servin-v6ops-monitor-ds-ipv6-01.txt Date: Mon, 15 Jul 2013 10:58:12 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Monitoring Dual Stack/IPv6-only Networks and Services Author(s) : Arturo Servin Mariela Rocha Filename : draft-servin-v6ops-monitor-ds-ipv6-01.txt Pages : 10 Date : 2013-07-15 Abstract: This document describes a set of recommendations and guidelines to help operators to monitor dual stack and IPv6-only networks. The document describes how to monitor these networks using SNMP, Flow Analyzers and other means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-servin-v6ops-monitor-ds-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-servin-v6ops-monitor-ds-ipv6-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030507090309070604070506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I sent a new version of the draft.

    We added some of the suggestions from the list and some others that we received off-list.

    There are some suggestions from Diego and Ariel that we have not added or are incomplete. We are planning to address those in the short term.


Thanks
/as

-------- Original Message --------
Subject: I-D Action: draft-servin-v6ops-monitor-ds-ipv6-01.txt
Date: Mon, 15 Jul 2013 10:58:12 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Monitoring Dual Stack/IPv6-only Networks and Services
	Author(s)       : Arturo Servin
                          Mariela Rocha
	Filename        : draft-servin-v6ops-monitor-ds-ipv6-01.txt
	Pages           : 10
	Date            : 2013-07-15

Abstract:
   This document describes a set of recommendations and guidelines to
   help operators to monitor dual stack and IPv6-only networks.  The
   document describes how to monitor these networks using SNMP, Flow
   Analyzers and other means.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-servin-v6ops-monitor-ds-ipv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-servin-v6ops-monitor-ds-ipv6-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------030507090309070604070506-- From diego@tid.es Mon Jul 15 17:07:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986611E8254 for ; Mon, 15 Jul 2013 17:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 FvbiB40tAkZl for ; Mon, 15 Jul 2013 17:07:39 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72CA711E8268 for ; Mon, 15 Jul 2013 17:07:38 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQ000DNH5OKLH@tid.hi.inet> for v6ops@ietf.org; Tue, 16 Jul 2013 02:07:37 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 31.07.03142.9CE84E15; Tue, 16 Jul 2013 02:07:37 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQ000DNL5OPLH@tid.hi.inet> for v6ops@ietf.org; Tue, 16 Jul 2013 02:07:37 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 02:06:16 +0200 Date: Tue, 16 Jul 2013 00:07:36 +0000 From: "Diego R. Lopez" In-reply-to: <51E3E1E0.9090203@lacnic.net> X-Originating-IP: [10.95.64.115] To: Arturo Servin Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 Thread-index: AQHOf8a71umfshwiIkyAfKliXlr1eJlifauAgALhu4CAACJaAIAAzh6A X-AuditID: 0a5f4068-b7f128e000000c46-3b-51e48ec94d51 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42Lhinfg0j3Z9yTQYMlnXYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/NDmYIbohWbX95kbGCcINrFyMkhIWAicer8URYIW0ziwr31 bCC2kMBGRollB5S6GLmA7B+MEpcW3mCCcKYxSmzc0s4MUsUioCrxsr+FFcRmA7IfNf9m72Lk 4BAWcJJY/qAIJMwpoCXxastBdogFChJ/zj0GWyYioCZxY9pHsGXMAuoS355eABvDK+At8ezA DFaIuJnEvhtvGSHighI/Jt9jARkPUj9lSi5EibhEc+tNFghbUWLaogawckYBWYl38+ezQqxy lvgzfQfUWjeJjjs/oc4RkFiy5zwzhC0q8fLxP1aIFw8ySnzfu5FlAqPELCRnzEJyxiyEM2Yh OWMWkjMWMLKuYhQrTirKTM8oyU3MzEk3MNTLyNTLzEst2cQIibiMHYzLd6ocYhTgYFTi4T3A +SRQiDWxrLgy9xCjBAezkgivnTBQiDclsbIqtSg/vqg0J7X4ECMTB6dUA2N68N8J3ev1Z3xZ /jj6nekMbcXKitWSoptqP7mGMjufvJBvtCO6b1/sHENLI7fTCRXT+Caa/ZpgW67ivWXCrKra esWb3exmItf7qgN/r7+n3tJjrVTRWbPC93GLkfrbgytuOO1gfvBic0ane7jAozeTO6ZfCshg tDi+8NGxxwlJjOwpbmbt+UosxRmJhlrMRcWJAMtDeOCWAgAA References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <51E3E1E0.9090203@lacnic.net> Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:07:42 -0000 SGkgQXJ0dXJvLA0KDQpPbiAxNSBKdWwgMjAxMywgYXQgMTM6NDkgLCBBcnR1cm8gU2VydmluIHdy b3RlOg0KPj4NCj4+IDEpIFRoZSB1c2FnZSBvZiBTRE4gKE9wZW5GbG93IGluIHBhcnRpY3VsYXIp IGFzIGFuIGFsdGVybmF0aXZlIHRlY2huaXF1ZSwgcHJvYmFibHkgdW5kZXIgMi4zDQo+ICAgIEkg aGF2ZSBuZXZlciB0aG91Z2h0IGFib3V0IGl0IGJ1dCBpdCBzZWVtcyBwbGF1c2libGUuIERvIHlv dSBoYXZlIGENCj4gcmVmZXJlbmNlLCBwZXJoYXBzIHNvbWUgcHJldmlvdXMgd29yayBhYm91dCB0 aGlzIHRvcGljPw0KDQpBIGNvdXBsZSBvZiB0aGVtIEkgaGF2ZSB1c2VkIGVsc2V3aGVyZToNCmh0 dHBzOi8vd3d3LnVzZW5peC5vcmcvbGVnYWN5L2V2ZW50L2lubXdyZW4xMC90ZWNoL2Z1bGxfcGFw ZXJzL0JhbGxhcmQucGRmDQoNCmh0dHA6Ly9zaGFya2Zlc3Qud2lyZXNoYXJrLm9yZy9zaGFya2Zl c3QuMTIvcHJlc2VudGF0aW9ucy9BLTRfTGV2ZXJhZ2luZ19PcGVuZmxvd190b19jcmVhdGVfYV9M YXJnZV9TY2FsZV9hbmRfQ29zdF9FZmZlY3RpdmVfUGFja2V0X0NhcHR1cmVfTmV0d29yay5wZGYN Cg0KSSBjYW4gc2VuZCB5b3Ugc29tZSBpbmZvcm1hdGlvbiBvbiBvdXIgRGVlcGVyIHN5c3RlbSwg dGhhdCBsZXZlcmFnZXMgT3BlbkZsb3cgZm9yIGEgY2xvdWQtYmFzZWQgRFBJLi4uDQoNCj4+IEFu ZCB0aGVyZSBpcyBhbHdheXMgdGhlIG1hdHRlciBvZiBjcm9zcy1wcm92aWRlciBvciBmZWRlcmF0 ZWQgbW9uaXRvcmluZywgdGhhdCBJJ2Qgc2F5IGlzIG5vdCB0aGF0IGNsb3NlIGV2ZW4gaW4gdjQg c3BhY2UsIGFuZCB0aGF0IHByb2JhYmx5IHdvdWxkIGRlc2VydmUgc29tZSBkaXNjdXNzaW9uIGFz IHdlbGwuLi4NCj4NCj4gICAgSSdsbCBhc2sgc29tZSBvcGVyYXRvcnMgdGhhdCBJIGtub3cgaGF2 ZSB2aXJ0dWFsIHNlcnZpY2VzIGhvdyB0aGV5DQo+IGRvIGl0LCBidXQgaWYgeW91IGhhdmUgc29t ZSBwb2ludGVycyBvciByZWZlcmVuY2VzIHdvdWxkIGJlIHZlcnkgZ3JlYXQNCg0KVGhlIHJlZmVy ZW5jZXMgSSBoYXZlIGFyZSByZWxhdGVkIHRvIHRoZSBvdXRjb21lcyBvZiB0aGUgRVRJQ1MgcHJv amVjdCwgaW4gd2hpY2ggSSBoYXZlIHBhcnRpY2lwYXRlZC4gQSBzaG9ydCBpbnRybyB0byB0aGUg bW9uaXRvcmluZyBpc3N1ZXMgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8vYnNjdy5pY3QtZXRp Y3MuZXUvcHViL2JzY3cuY2dpL2Q0NDUxOC9JbmR1c3RyaWFsV29ya3Nob3BfRGVtby1OTU9OLnBk Zg0KDQpBbmQgYSBtb3JlIGRldGFpbGVkIGluZm8gY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8vYnNj dy5pY3QtZXRpY3MuZXUvcHViL2JzY3cuY2dpL2Q0NzU5NC9ENC40X0ZpbmFsLnBkZiAocGFnZXMg OTAgdG8gMTAxLCBlc3NlbnRpYWxseSkNCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8g ZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZv bmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRp ZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEg MDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhj bHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBv bMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4g ZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBl eGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVt YWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlk LmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From sm@elandsys.com Mon Jul 15 20:58:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE911E81D6 for ; Mon, 15 Jul 2013 20:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 VbVQdhmRIm50 for ; Mon, 15 Jul 2013 20:58:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A2311E810A for ; Mon, 15 Jul 2013 20:58:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.81]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6G3wbUl010888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 20:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373947129; bh=zf9CHKRbVteCIlfFjznERSdejKl7pbW1iLVpI6tGn0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hGeE5klrbI9Dk+oeNiCorf+6ufx1vBglGHWPAVvZOR0xO/47dlR7X3JlB39ZqRqcx gL0C7Hs7ZTuZ/e3h8wzptrrRiEtVOW9Izsffzr707+M0UqO+TRk8jmz4OJCltcUfy5 9FWKMTnq7HNNqz3Gl7Um5qd6iqCW4sZrRI1EwmRA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373947129; i=@elandsys.com; bh=zf9CHKRbVteCIlfFjznERSdejKl7pbW1iLVpI6tGn0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YQqKtDNDk+uR/xssiXBWjUV0DUVMNumtZ0Cype6/J4x9lPe6u3/C3F+pqEdPzRdHs eGtjZ5ivFsEu6E9LsEJ558bzTVRqtfto651EJic7j0Sbh00BFgxanYPyU1qeNRDQnW XrYLeJyvHAznVdS2MI8aw7x3mHNc6kJE5oZtWBOk= Message-Id: <6.2.5.6.2.20130715201324.0c4a8a88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Jul 2013 20:57:16 -0700 To: Fernando Gont From: S Moonesamy In-Reply-To: <51E3EE20.1080609@si6networks.com> References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51E3EE20.1080609@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 03:58:54 -0000 Hi Fernando, At 05:42 15-07-2013, Fernando Gont wrote: >Isn't this already covered (together with a bunch of other ND-related >stuff) in: >? :-) > >(this I-D was presented at the OPSEC meeting in Orlando) I was not aware of that draft or that it was presented In Orlando. I took a quick look at your draft and I see that it mentions CVE-2010-4669 and the limit being enforced in OpenBSD 4.2. Here's the background that led to the draft. There was an advisory published in 2011 about the IPv6 Router Advertisements flooding attack. One of the workarounds suggested was to disable IPv6 if the workaround (see Section 2 of draft-moonesamy-ra-flood-limit-00) was not available. There are multiple reasons for why the workaround was not implemented on different platforms (see advisory for some of the details) even though the problem is documented in RFC 6104. draft-moonesamy-ra-flood-limit-00 is about documenting the workaround that has been implemented in NetBSD and OpenBSD. Someone mentioned to me that it is a short draft. The draft is a small effort so that I do not have to hear the "turn off IPv6" argument. :-) It is also about trying to address a known problem affecting a node in a timely manner. I'll invite you to join the small effort as co-author of draft-moonesamy-ra-flood-limit. Regards, S. Moonesamy From fred@cisco.com Mon Jul 15 21:41:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC521E81A8 for ; Mon, 15 Jul 2013 21:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.266 X-Spam-Level: X-Spam-Status: No, score=-110.266 tagged_above=-999 required=5 tests=[AWL=-0.267, 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 79cYuY4G8yZC for ; Mon, 15 Jul 2013 21:41:19 -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 D483C21E819F for ; Mon, 15 Jul 2013 21:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4801; q=dns/txt; s=iport; t=1373949678; x=1375159278; h=from:to:cc:subject:date:message-id:reply-to:content-id: content-transfer-encoding:mime-version; bh=+hR8tJFX4TvgSdHzBYx+p/2gvQu0X/463DY7i/WrYU4=; b=aCTlnl0yOuOQSUl+zGUE7b0VlAyxci5vJdCvdXbdEr8iYlQEGjWgT7js YnQA9w8ZEfxLdM1CUCJ2PcA+WoyWjgWqc4IlIfBrvjJ6sPXsoqd3eXNGo frdg1Qor0nXj8qkhZpzw+ZFBzTUvK7qn+ErkPpQ0zemtIXtAUkvtK524Z k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFALnN5FGtJV2a/2dsb2JhbABagwaBA8FdgQ8WdIIlAQQ6KxQSASoUQg4ZBA4NDId8nQmZVI8zMYMSbQOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,674,1367971200"; d="scan'208";a="235060804" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jul 2013 04:41:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6G4fILe019032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 04:41:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 23:41:17 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Would like guidance on the IETF-87 agenda Thread-Index: AQHOgd614flrXLIFXEyWtdRn/AzCoQ== Date: Tue, 16 Jul 2013 04:41:16 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B93DC38@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.208] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E25DD5F8CF46F429A5ABF110B15ED26@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Would like guidance on the IETF-87 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "" List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 04:41:24 -0000 Asking the working group for its input. The Internet Draft cut-off for new -00 drafts was extended through yesterda= y, concomitant with the final cut-off. We got a few more drafts, including = both updated drafts and new -00. My general rule is to look for list activi= ty on a draft, but now find myself in a crunch because I need to finalize a= n agenda and frankly you haven't had much time to look through things. So I need your guidance. Here is the draft set for IETF-87 RFC Ed Queue: Mar 18 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat Oct 30 draft-ietf-v6ops-6204bis Nov 14 draft-ietf-v6ops-ra-guard-implementation Exiting WGLC; on its way to IESG: May 27 draft-ietf-v6ops-rfc3316bis Jun 11 draft-ietf-v6ops-mobile-device-profile Jul 14 draft-ietf-v6ops-64share Working Group Document updated since IETF: May 17 draft-ietf-v6ops-ula-usage-recommendations Jul 9 draft-ietf-v6ops-nat64-experience Jul 14 draft-ietf-v6ops-enterprise-incremental-ipv6 Individual Submission to v6ops updated since IETF: Apr 14 draft-elkins-v6ops-ipv6-ipid-needed May 31 draft-elkins-v6ops-ipv6-end-to-end-rt-needed May 31 draft-elkins-v6ops-ipv6-packet-sequence-needed May 31 draft-elkins-v6ops-ipv6-pdm-recommended-usage Jun 4 draft-taylor-v6ops-fragdrop Jul 12 draft-grundemann-hipnet Jul 14 draft-lopez-v6ops-dc-ipv6 Jul 15 draft-jiang-v6ops-semantic-prefix Jul 15 draft-v6ops-vyncke-balanced-ipv6-security Jul 15 draft-servin-v6ops-monitor-ds-ipv6 ??? Jul 8 draft-chen-v6ops-ipv6-roaming-analysis-00.txt Jul 10 draft-osamu-v6ops-ipv4-literal-in-url-00.txt Jul 15 draft-liu-v6ops-running-multiple-prefixes-00.txt Jul 14 draft-bajpai-happy No obvious v6ops interest: Mar 28 draft-generic-v6ops-tunmtu Apr 1 draft-yang-v6ops-fast6 Jul 12 draft-yang-v6ops-ipv6tran-select Apr 24 draft-gundavelli-v6ops-community-wifi-svcs Working Group Document NOT updated since IETF: Feb 14 draft-ietf-v6ops-design-choices Individual Submission to v6ops NOT updated since IETF: Jan 25 draft-mlevy-v6ops-auto-v6-allocation-per-asn Feb 18 draft-ma-v6ops-ipv6-address-assignment Feb 20 draft-smith-v6ops-larger-ipv6-loopback-prefix Feb 25 draft-sun-v6ops-semantic-usecase Feb 25 draft-shishio-v6ops-dpvt Liu Bing tells me that he is not ready to discuss draft-ietf-v6ops-ula-usag= e-recommendations this time, which is fine. However, George Michaelson has = put together some data on the announcement of ULAs in routing, which I thin= k bears looking at given that we are thinking about it. Philip Matthews tells me that he is considering abandoning draft-ietf-v6ops= -design-choices unless someone would like to co-author. I haven't seen a re= sponse to that. My inclination for an agenda is then to include George's talk plus=20 Jul 9 draft-ietf-v6ops-nat64-experience Jul 14 draft-ietf-v6ops-enterprise-incremental-ipv6 Nalini Elkins' drafts as one discussion Jun 4 draft-taylor-v6ops-fragdrop Jul 12 draft-grundemann-hipnet Jul 14 draft-lopez-v6ops-dc-ipv6 Jul 15 draft-jiang-v6ops-semantic-prefix Jul 15 draft-v6ops-vyncke-balanced-ipv6-security Jul 15 draft-servin-v6ops-monitor-ds-ipv6 10 discussions in 240 minutes leaves 24 minutes per discussion. That's a go= od amount of time. Where I have questions relate to the four very new drafts. draft-chen-v6ops-ipv6-roaming-analysis looks at issues raised with IPv6 ope= ration in inter-provider environments. We have a number of such, and it see= ms useful to discuss. draft-osamu-v6ops-ipv4-literal-in-url reports on some research done in the = WIDE project, regarding the use of IPv4 literals in an IPv6-only network us= ing NAT64 translation for access to the IPv4 Internet. draft-liu-v6ops-running-multiple-prefixes, which contains no abstract, appe= ars to be looking at the cases in which we deploy networks with multiple pr= efixes on each LAN or on a set of LANs. draft-bajpai-happy looks at Happy Eyeballs implementations, with a view to = understanding its behavior in deployment. I am inclined to let draft-liu-v6ops-running-multiple-prefixes simmer; I th= ink it will benefit from list discussion, and as I understand him Liu Bing = will not be at this meeting. I'm inclined to include the other three drafts= , however, as they are relevant to matters the working group has recently w= orked on, even though I have not seen appreciable list discussion on them y= et. That gives us 18 minutes per discussion, which is tighter than I would = like, but survivable. Opinions? Private to the chairs if you prefer.= From fgont@si6networks.com Tue Jul 16 05:15:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5821E805F for ; Tue, 16 Jul 2013 05:15:08 -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 pBRdPFR2VNUS for ; Tue, 16 Jul 2013 05:15:07 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6221E805A for ; Tue, 16 Jul 2013 05:15:07 -0700 (PDT) Received: from 79.109.50.53.dyn.user.ono.com ([79.109.50.53] helo=[192.168.1.32]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uz49j-0005ES-9A; Tue, 16 Jul 2013 14:14:59 +0200 Message-ID: <51E53941.9090205@si6networks.com> Date: Tue, 16 Jul 2013 14:14:57 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51E3EE20.1080609@si6networks.com> <6.2.5.6.2.20130715201324.0c4a8a88@elandnews.com> In-Reply-To: <6.2.5.6.2.20130715201324.0c4a8a88@elandnews.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:15:08 -0000 On 07/16/2013 05:57 AM, S Moonesamy wrote: > > I was not aware of that draft or that it was presented In Orlando. I > took a quick look at your draft and I see that it mentions > CVE-2010-4669 and the limit being enforced in OpenBSD 4.2. > > Here's the background that led to the draft. There was an advisory > published in 2011 about the IPv6 Router Advertisements flooding attack. > One of the workarounds suggested was to disable IPv6 if the workaround > (see Section 2 of draft-moonesamy-ra-flood-limit-00) was not available. Suggested in that advisory, or where? > There are multiple reasons for why the workaround was not implemented on > different platforms (see advisory for some of the details) Sloppy coding? > even though > the problem is documented in RFC 6104. RFC6104 describes rogue RA, rather than RA floods. They are two unrelated issues: RA flooding is about enforcing basic checks such that your data structures cannot grow without bounds. Rogue RA is about how to deal with malicious RAs in the absence of authentication. > draft-moonesamy-ra-flood-limit-00 is about documenting the workaround > that has been implemented in NetBSD and OpenBSD. > > Someone mentioned to me that it is a short draft. The draft is a small > effort so that I do not have to hear the "turn off IPv6" argument. :-) It is not unlikely for people to give that option in security advisories when no workaround is available. > It is also about trying to address a known problem affecting a node in a > timely manner. I'll invite you to join the small effort as co-author of > draft-moonesamy-ra-flood-limit. I don't object to co-authoring (always happy to contribute). But I'd note that implementations also fail to enforce limits on: * the number of default routers * size of the NC * number of routes etc., etc. That's why I personally believe it is better to provide comprehensive implementation advice, such as that in draft-gont-opsec-nd-security Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Tue Jul 16 05:45:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4921F9C33 for ; Tue, 16 Jul 2013 05:45:14 -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 qLJpaU+2YCiV for ; Tue, 16 Jul 2013 05:45:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66F5A11E80E3 for ; Tue, 16 Jul 2013 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=143; q=dns/txt; s=iport; t=1373978702; x=1375188302; h=date:from:message-id:to:subject:cc; bh=fhmGd4h7xMwY4bsnTTiNa7inxmfjRUFW3hOX2IViOHs=; b=bxTcGbkIydByt/7MhrslMNDgCKacRhF9koNTdgjNKveJpis8yMDMy7N3 4Tex3gQSVCdiM3GWhePpg4wYgZoOOWvE4N3KCSYiMCec9exFVi91+8leB Ylv2Mj+D992/xiU17Y54v4Td8xyb9drVzKgPw3ix64KVNFp2H8c+aZnNk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIPACw/5VGrRDoH/2dsb2JhbABagwY0gw6tJwGRbgMBAwGBDhZ0gyM8LQeIcA22HI5NgRIdg2MDiSePXpAkgzI X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="86216721" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 16 Jul 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6GCj0gV000689; Tue, 16 Jul 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r6GCj0G15523; Tue, 16 Jul 2013 05:45:00 -0700 (PDT) Date: Tue, 16 Jul 2013 05:45:00 -0700 (PDT) From: Message-Id: <201307161245.r6GCj0G15523@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-liu-v6ops-running-multiple-prefixes@tools.ietf.org Subject: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:45:14 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes. Please take a look at it and comment. From victor@jvknet.com Wed Jul 17 05:28:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371D221F9DA3 for ; Wed, 17 Jul 2013 05:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRSqds-CU+rW for ; Wed, 17 Jul 2013 05:28:41 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id D9E6D21F9C82 for ; Wed, 17 Jul 2013 05:28:40 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so1721163wgh.14 for ; Wed, 17 Jul 2013 05:28:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=f50Q7jB8yvXee80eAUL48Z3KGXqkuow8hrdMNpKdk3Y=; b=SKzmIARzN5rPiw5IZzrUTkEzW/htCpufLG5uMXuCJKhNTchGdkz4DSjqqPD2nz2G15 CI597rCxTqyVaR0LanysKgnUabUi6r80ZiPcC8+1CouecmlOLeg+kBaWgZZ3RK4iwjpd 76HlL2bdPhGptmWOoQW/iRuGj4vy4anixEzuYYEalnIT8GyobAkeVprCdUgikCjw5LuJ JSoiuF6yTPHEeWr46Mcwfn2gH1EZ6g6AU+P96V0nIzH+a+2GAnFIIX+21hwbclVmNvYI AeeHUE4Mj2hZsJn0SjQ2Z6W5DiN0qYxIhIq7/euB+0xX+9VG9aXk71fQb6QY9rPi7Yrv 8Qhg== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr4717851wjf.7.1374064119979; Wed, 17 Jul 2013 05:28:39 -0700 (PDT) Received: by 10.217.138.198 with HTTP; Wed, 17 Jul 2013 05:28:39 -0700 (PDT) X-Originating-IP: [2607:fea8:48e0:0:b571:444a:213b:1b2c] In-Reply-To: <201307161245.r6GCj0G15523@ftpeng-update.cisco.com> References: <201307161245.r6GCj0G15523@ftpeng-update.cisco.com> Date: Wed, 17 Jul 2013 08:28:39 -0400 Message-ID: From: Victor Kuarsingh To: fred@cisco.com Content-Type: multipart/alternative; boundary=047d7b5d3528c52d0f04e1b43b2f X-Gm-Message-State: ALoCoQlB/0KyT2caGQ5m4M+K52ze/PQaAxs9xcjfyfMdsrJhxIZ4RijAXIduSJegdvj6Zdw4OD6f Cc: IPv6 Ops WG , draft-liu-v6ops-running-multiple-prefixes@tools.ietf.org Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:28:45 -0000 --047d7b5d3528c52d0f04e1b43b2f Content-Type: text/plain; charset=ISO-8859-1 v6ops, I think in general is seems like a good attempt as documenting various use cases and considerations when using multiple prefixes. As first pass I think there may be room for some additional citations to other documents which address some of the points contained (which would then make this document more useful in my opinion since it can be a potential place to consolidate information). Links to MIF documents may be useful here. In section 3.1 the, the text is prescriptive in suggesting one dose not use multiple provisioning domains (DHCP) to configure hosts [text] the administrators should avoid that multiple provisioning domains all directly configuring the host through DHCP, since it might cause confusion for the host [/text] I am not sure this document should suggest how to deal with it, but perhaps point to other documents which deal with multiple addresses which provision across multiple domains. regards, Victor K On Tue, Jul 16, 2013 at 8:45 AM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes. > Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b5d3528c52d0f04e1b43b2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
v6ops,

I think in general is seems like= a good attempt as documenting various use cases and considerations when us= ing multiple prefixes. =A0As first pass I think there may be room for some = additional citations to other documents which address some of the points co= ntained (which would then make this document more useful in my opinion sinc= e it can be a potential place to consolidate information).

Links to MIF documents may be useful here.
In section 3.1 the, the text is prescriptive in suggesting one= dose not use multiple provisioning domains (DHCP) to configure hosts=A0
[text]
the
=A0 =A0administrators should avoid= that multiple provisioning domains all
=A0 =A0directly configuri= ng the host through DHCP, since it might cause
=A0 =A0confusion f= or the host
[/text]

I am not sure this document sho= uld suggest how to deal with it, but perhaps point to other documents which= deal with multiple addresses which provision across multiple domains.

regards,

Victor =A0K


On Tue, Jul= 16, 2013 at 8:45 AM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.o= rg/html/draft-liu-v6ops-running-multiple-prefixes. Please take a look a= t it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b5d3528c52d0f04e1b43b2f-- From wesley.george@twcable.com Wed Jul 17 11:39:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D3F21F9D1C for ; Wed, 17 Jul 2013 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 BKLUV29sULYH for ; Wed, 17 Jul 2013 11:39:13 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id CA90321F9B12 for ; Wed, 17 Jul 2013 11:39:05 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,686,1367985600"; d="scan'208";a="105534172" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jul 2013 14:38:20 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 17 Jul 2013 14:39:05 -0400 From: "George, Wes" To: Arturo Servin , "v6ops@ietf.org" Date: Wed, 17 Jul 2013 14:39:03 -0400 Thread-Topic: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 Thread-Index: Ac5/z3AkcUJNEB91TzWHeXdQ5CcDHQDRbwpA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230438E30376@PRVPEXVS15.corp.twcable.com> References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> In-Reply-To: <51E15A35.2090603@lacnic.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] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 18:39:17 -0000 This is a useful draft. I've been doing some IPv6-only testing of websites listed in the world v6 l= aunch participants, and found a lot of supposedly IPv6-capable sites that a= ren't fully functional over IPv6-only because some portion of them are stil= l reliant on IPv4-only content/CDNs for images, CSS, subdomains, etc. Worse= , I've found sites that simply aren't working over IPv6 anymore, and the op= erator of the site is unaware. This would be quite obvious if the site main= tainers were completing their unit testing and monitoring over single-stack= IPv6, but may well be masked by happy eyeballs if done dual-stack, so this= draft will help to publicize this problem. A few comments on the draft itself: Section 2.1 and 6- an explicit recommendation to vendors that they SHOULD s= upport use of IPv6 for all transport (RFC 6540) of monitoring, provisioning= , and management data might be useful here. This is an area where vendors o= ften lag because they've been focused on enabling support for IPv6 through = the box, but it's becoming increasingly important for operators trying to c= onserve IPv4 addresses for end-customer use. For completeness, you may want to briefly discuss NTP, Syslog, ssh, and oth= er OAM-type traffic somewhere in section 2. There is also a draft in progress in MPLS dealing with IPv6-only operation = of MPLS networks (draft-george-mpls-ipv6-only-gap) that may contain some th= ings relevant to this draft since it covers some of the aspects of OAM for = MPLS networks. Another consideration for this draft might be a recommendation to transitio= n to single-stack (IPv6) as rapidly as possible for any tools that do not n= eed to explicitly verify IPv4 operation. In other words, things like flow d= ata transport, SSH, etc might be able to operate only over IPv6, while SNMP= polls, HTTP tests, etc would need to remain dual stack so that they can ve= rify IPv4 is working properly. Since dual-stack support means duplicating a= lot of operations complexity (filters, troubleshooting path problems, moni= toring configuration, etc), eliminating the need to support both IPv4 and I= Pv6 for as much management traffic as possible potentially allows for simpl= ification of configuration, reclamation of addresses, etc. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Arturo Servin > Sent: Saturday, July 13, 2013 9:46 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 > > Hi, > > We have sent this draft about considerations and recommendations to > monitor IPv6 and dual-stack networks and services. We have been talking > with people deploying IPv6 and we have found that not all monitor their > networks and not many monitor them properly. We also found some > challenges in monitor implementations that not fully support IPv6 > monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even > though monitoring v6 networks is as critical as doing it in v4, we have > not found many documents explaining how that has to be done (at least > guides with free access or up to date). > > There are also some misconceptions about monitoring IPv6, for > example SNMPv3 !=3D SNMP+IPv6, or that you cannot collect IPv6 data and > send them on IPv4 that we wanted to clarify. > > We collected some recommendations from informal conversations with > people during some training and NOGs meeting during this year but we > need some more input. We will be sharing this draft with other forums to > get more inputs but we wanted to share it here first. > > Best wishes, > Arturo and Mariela > > On 7/13/13 9:45 AM, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft- > servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment. Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- 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 tore@fud.no Wed Jul 17 17:44:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900DE21F9CE7 for ; Wed, 17 Jul 2013 17:44:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vka+Uj+arPlP for ; Wed, 17 Jul 2013 17:44:46 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7E21F9C86 for ; Wed, 17 Jul 2013 17:44:46 -0700 (PDT) Received: from www-data by greed.fud.no with local (Exim 4.80) (envelope-from ) id 1UzcKa-000158-Pe; Thu, 18 Jul 2013 02:44:28 +0200 To: X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 18 Jul 2013 02:44:28 +0200 From: Tore Anderson In-Reply-To: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Message-ID: <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> X-Sender: tore@fud.no User-Agent: Roundcube Webmail/0.7.2 Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:44:47 -0000 > http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Section 4.1 states: "Roaming to IPv4-only networks with IPv6 PDP/PDN request would fail to get addresses." In my experience, this is seldom (if ever) the case. My home network (Network Norway) supports IPv6 PDP context and in recent years I've roamed in more European countries than I can enumerate from the top of my head, in some Mid-East countries, in the U.S., and in Japan. I've made a point out of trying all available PLMNs my phone can see in the air, and I know for a fact that most of them are IPv4-only. In spite of this I cannot recall last time I had a problem establishing IPv6 connectivity when roaming. The way I see it, 3GPP IPv6 roaming is one of those things that Just Works. I'm not an expert on 3GPP network architecture, but as far as I've been able to understand, the reason why this work is that the IPv6 gets tunnelled back to my home network using GTP, and that the visited network just considers the payload as "data" and doesn't really care whether it is IPv4 or IPv6. I'm sure there could be exceptions to the above. I've heard several people suggest that Japan is particularly problematic in this regard - but in my experience it Just Works there, too. Tore From medel@globetel.com.ph Wed Jul 17 17:56:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35121F8F4F for ; Wed, 17 Jul 2013 17:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RELAY_IS_203=0.994] 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 Cptq3HTfZScb for ; Wed, 17 Jul 2013 17:56:52 -0700 (PDT) Received: from smtp01.globetel.com.ph (smtp01.globetel.com.ph [203.177.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4F21F8E1F for ; Wed, 17 Jul 2013 17:56:51 -0700 (PDT) Received: from exgtbh01.globetel.com ([10.225.208.17]) by smtp01.globetel.com.ph (8.14.4/8.14.4) with ESMTP id r6I0uRfN015706; Thu, 18 Jul 2013 08:56:40 +0800 Received: from EXVSGT02.globetel.com ([10.225.208.145]) by exgtbh01.globetel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jul 2013 09:02:39 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jul 2013 09:02:38 +0800 Message-ID: In-Reply-To: <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac6DUW7SwEoV4lC0TfKVep/c2PuVEAAAE91w References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> From: "GT RAMIREZ, Medel G." To: "Tore Anderson" , X-OriginalArrivalTime: 18 Jul 2013 01:02:39.0363 (UTC) FILETIME=[7FB7C530:01CE8352] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-17_10:2013-07-17, 2013-07-17, 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-1305240000 definitions=main-1307170216 Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:56:56 -0000 Hi, Section 4.1 states: "Roaming to IPv4-only networks with IPv6 PDP/PDN request would fail to get addresses." In my experience, this is seldom (if ever) the case. ---> Same experience with other countries (specifically guys from Sweden) visiting the Philippines *but* problems arises with the Billing Systems (TAP format) And it was immediately corrected.... Regards Medel ++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson Sent: Thursday, July 18, 2013 8:44 AM To: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis > http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Section 4.1 states: "Roaming to IPv4-only networks with IPv6 PDP/PDN request would fail to get addresses." In my experience, this is seldom (if ever) the case. My home network (Network Norway) supports IPv6 PDP context and in recent years I've roamed in more European countries than I can enumerate from the top of my head, in some Mid-East countries, in the U.S., and in Japan. I've made a point out of trying all available PLMNs my phone can see in the air, and I know for a fact that most of them are IPv4-only. In spite of this I cannot recall last time I had a problem establishing IPv6 connectivity when roaming. The way I see it, 3GPP IPv6 roaming is one of those things that Just Works. I'm not an expert on 3GPP network architecture, but as far as I've been able to understand, the reason why this work is that the IPv6 gets tunnelled back to my home network using GTP, and that the visited network just considers the payload as "data" and doesn't really care whether it is IPv4 or IPv6. I'm sure there could be exceptions to the above. I've heard several people suggest that Japan is particularly problematic in this regard - but in my experience it Just Works there, too. Tore _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately. From robmgl.ietf@gmail.com Wed Jul 17 18:38:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3901B21F8E1F for ; Wed, 17 Jul 2013 18:38:43 -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, HTML_MESSAGE=0.001, 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 YH8w3JKf1cgn for ; Wed, 17 Jul 2013 18:38:42 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3621F8E3D for ; Wed, 17 Jul 2013 18:38:41 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1993738lab.41 for ; Wed, 17 Jul 2013 18:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0N6alyMvycYHNQjsqAT9iUEGirqE6iMtSCmvS3bUzgI=; b=lQOmUMeXZ331sUpjNapbDOxZ0uYblo3edbSDFFLDLmKu7GuXWFTxHGf99bKYkRkpzF TxwR3/7k4rMsbm4+FftFe+uQ307Zafk2qCS6vTE4nexfh6Pndyu3eIzt3utWDPmmLbu+ fAoVIlG+I67pMDPMvVOVEaeVaFZbbwEXKTeSCLhadcgiXNVaRrPgAl0y28NVegF5tNvR glv+DhWg48fwbi/PaUT54jyoK6pSI438kx0e+snca4fQcdyXlkfWTDTn7moOj+BiOFhX DNSMjZQsMEqOGS8hSH2DO2BLxKGbAWUBEYFgFYcXE6Om2XpjkRaMLWuL4F1KP6+6TRGc Zxjg== MIME-Version: 1.0 X-Received: by 10.112.29.17 with SMTP id f17mr4352372lbh.20.1374111520725; Wed, 17 Jul 2013 18:38:40 -0700 (PDT) Received: by 10.112.218.42 with HTTP; Wed, 17 Jul 2013 18:38:40 -0700 (PDT) Date: Wed, 17 Jul 2013 21:38:40 -0400 Message-ID: From: Roberta Maglione To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a1133c690131f9f04e1bf451e Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 01:38:43 -0000 --001a1133c690131f9f04e1bf451e Content-Type: text/plain; charset=ISO-8859-1 Hello, I agree with Victor on the following: >Links to MIF documents may be useful here. the document would benefit from some references to mif documents >In section 3.1 the, the text is prescriptive in suggesting one dose not use multiple provisioning domains (DHCP) to configure hosts agree this text is to prescrictive and the document seems to take a strong position without enough explanations/rationals >am not sure this document should suggest how to deal with it, but perhaps point to other documents which deal with multiple addresses which > provision across multiple domains. there are ongoing discussions in other WGs in opinion this draft should refer to the ongoing work instead of taking its own conclusion Thanks, Regards Roberta regards, Victor K --001a1133c690131f9f04e1bf451e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
I agree with Victor on the follow= ing:
>Links to MIF documents may be useful here.
<= div>the document would benefit from some references to mif documents

>In section 3.1 the, the text is= prescriptive in suggesting one dose not use multiple provisioning domains = (DHCP) to configure hosts=A0
agree this text is to prescrictive and the document=A0=A0seems to t= ake=A0a strong=A0position without enough explanations/rational= s

>am not sure this document shoul= d suggest how to deal with it, but perhaps point to other documents which d= eal with multiple addresses which
=A0>=A0provision across multiple domains.
there are ongoing discussions in other WGs in opinion this draft shoul= d refer to the ongoing work instead of taking its own conclusion

Thanks,
= Regards
Roberta

=
regards,

=
Victor =A0K
--001a1133c690131f9f04e1bf451e-- From leo.liubing@huawei.com Wed Jul 17 18:42:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B3E21F9AFE for ; Wed, 17 Jul 2013 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RuubJ4Y0mc9o for ; Wed, 17 Jul 2013 18:41:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F006B21F9BAB for ; Wed, 17 Jul 2013 18:41:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD57497; Thu, 18 Jul 2013 01:41:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 02:39:53 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 02:40:48 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 09:40:42 +0800 From: "Liubing (Leo)" To: Victor Kuarsingh Thread-Topic: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes Thread-Index: AQHOgiJhpbw5q0mb6UaW7BRGXefv9ZloR/OAgAFgeSA= Date: Thu, 18 Jul 2013 01:40:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D750DF7@nkgeml506-mbx.china.huawei.com> References: <201307161245.r6GCj0G15523@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750DF7nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 01:42:00 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750DF7nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Victor Thanks for your review and comments. Please see replies inline. From: Victor Kuarsingh [mailto:victor@jvknet.com] Sent: Wednesday, July 17, 2013 8:29 PM To: fred@cisco.com Cc: IPv6 Ops WG; draft-liu-v6ops-running-multiple-prefixes@tools.ietf.org Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes v6ops, I think in general is seems like a good attempt as documenting various use = cases and considerations when using multiple prefixes. As first pass I thi= nk there may be room for some additional citations to other documents which= address some of the points contained (which would then make this document = more useful in my opinion since it can be a potential place to consolidate = information). [Bing] I think it's a good suggestion. I'll do it in the next version. Links to MIF documents may be useful here. In section 3.1 the, the text is prescriptive in suggesting one dose not use= multiple provisioning domains (DHCP) to configure hosts [text] the administrators should avoid that multiple provisioning domains all directly configuring the host through DHCP, since it might cause confusion for the host [/text] I am not sure this document should suggest how to deal with it, but perhaps= point to other documents which deal with multiple addresses which provisio= n across multiple domains. [Bing] I need to care about the wording, thanks. I'm not aware of documents= addressing this issue, but I'll make more investigation when making the ne= xt version. Thanks. Best regards, Bing regards, Victor K On Tue, Jul 16, 2013 at 8:45 AM, > wr= ote: A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-= running-multiple-prefixes. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750DF7nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Victor=

 = ;

Thanks for= your review and comments. Please see replies inline.

 = ;

From: Victor Kuarsingh [mailto:victor@jvknet.com]
Sent: Wednesday, July 17, 2013 8:29 PM
To: fred@cisco.com
Cc: IPv6 Ops WG; draft-liu-v6ops-running-multiple-prefixes@tools.iet= f.org
Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-pre= fixes

 

v6ops,

 

I think in general is seems lik= e a good attempt as documenting various use cases and considerations when u= sing multiple prefixes.  As first pass I think there may be room for s= ome additional citations to other documents which address some of the points contained (which would then make this doc= ument more useful in my opinion since it can be a potential place to consol= idate information).

[Bing] I t= hink it’s a good suggestion. I’ll do it in the next version.

 

Links to MIF documents may be u= seful here.

 

In section 3.1 the, the text is= prescriptive in suggesting one dose not use multiple provisioning domains = (DHCP) to configure hosts 

[text]

the

   administrators sho= uld avoid that multiple provisioning domains all

   directly configuri= ng the host through DHCP, since it might cause

   confusion for the = host

[/text]

 

I am not sure this document sho= uld suggest how to deal with it, but perhaps point to other documents which= deal with multiple addresses which provision across multiple domains.=

[Bing] I n= eed to care about the wording, thanks. I’m not aware of documents add= ressing this issue, but I’ll make more investigation when making the next version.

 = ;

Thanks.

 = ;

Best regar= ds,

Bing<= /o:p>

 

regards,

 

Victor  K

=  

On Tue, Jul 16, 2013 at 8:45 AM= , <fred@cisco.com> wrote:


A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes. P= lease take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750DF7nkgeml506mbxchi_-- From leo.liubing@huawei.com Wed Jul 17 18:46:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97921F9C82 for ; Wed, 17 Jul 2013 18:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TJPN++ffr5cE for ; Wed, 17 Jul 2013 18:46:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5121F9D24 for ; Wed, 17 Jul 2013 18:46:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN79701; Thu, 18 Jul 2013 01:46:17 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 02:45:14 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 02:46:09 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 09:46:02 +0800 From: "Liubing (Leo)" To: Roberta Maglione Thread-Topic: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes Thread-Index: AQHOg1eHpbw5q0mb6UaW7BRGXefv9ZlpqWVQ Date: Thu, 18 Jul 2013 01:46:01 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D750E05@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750E05nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 01:46:26 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750E05nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Roberta Thanks for your comments. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= oberta Maglione Sent: Thursday, July 18, 2013 9:39 AM To: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes Hello, I agree with Victor on the following: >Links to MIF documents may be useful here. the document would benefit from some references to mif documents [Bing] Yes, will do. >In section 3.1 the, the text is prescriptive in suggesting one dose not us= e multiple provisioning domains (DHCP) to configure hosts agree this text is to prescrictive and the document seems to take a strong= position without enough explanations/rationals [Bing] Yes, I need to care about the wording and make more investigation. >am not sure this document should suggest how to deal with it, but perhaps = point to other documents which deal with multiple addresses which > provision across multiple domains. there are ongoing discussions in other WGs in opinion this draft should ref= er to the ongoing work instead of taking its own conclusion [Bing] I'm aware of DHC WG is working on this, I'll keep on tracking the pr= ogress. Thanks. Best regards, Bing Thanks, Regards Roberta regards, Victor K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750E05nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Robert= a

 = ;

Thanks for= your comments.

 = ;

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] On Behalf Of Roberta Maglione
Sent: Thursday, July 18, 2013 9:39 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-liu-v6ops-running-multiple-pre= fixes

 

Hello,

I agree with Victor on the foll= owing:

>Links to MIF documents may = be useful here.

the document would benefit from= some references to mif documents

[Bing] = Yes, will do.

 = ;

>In section 3.1 the, the tex= t is prescriptive in suggesting one dose not use multiple provisioning doma= ins (DHCP) to configure hosts 

agree this text is to prescrict= ive and the document  seems to take a strong position w= ithout enough explanations/rationals

[Bing] Yes= , I need to care about the wording and make more investigation.<= /span>

 

>am not sure this document s= hould suggest how to deal with it, but perhaps point to other documents whi= ch deal with multiple addresses which

 > provision acros= s multiple domains.

there are ongoing discussions i= n other WGs in opinion this draft should refer to the ongoing work instead = of taking its own conclusion

[Bing] I&#= 8217;m aware of DHC WG is working on this, I’ll keep on tracking the = progress. Thanks.

 = ;

Best regar= ds,

Bing<= /o:p>

 

Thanks,

Regards

Roberta

 

 

regards,

 

Victor  K

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D750E05nkgeml506mbxchi_-- From victor@jvknet.com Wed Jul 17 22:02:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1B821F8C65 for ; Wed, 17 Jul 2013 22:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.246, 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 GgX5+OAVIxUx for ; Wed, 17 Jul 2013 22:02:02 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4626021F9991 for ; Wed, 17 Jul 2013 22:02:01 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so5959023ief.40 for ; Wed, 17 Jul 2013 22:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=/Z7yxxXw9I4QGzTVzTlS9y/p5OJQ/tm9jEezCOlZLc4=; b=ajdSFH6mTPoF1cvkynTZJeTQmg6xTSZQ4WRL3OW2uV0UdtNtxvrOuhvZAaJX7K+wP6 1xtUV1eKq3ktbJAPZRXDxzM7OzzPho98nLVde55L0xGnJNNR6/hG7J9xqwD/I1s+cNxs SUtx8Y3XOIt6jS6drNXHvl62BrlFGIulvW77qoK8p8ROU9qVrYLoBOST0vljDPehQPr9 U09iIsH22wFkh8Okqgz5uGejIhhroaFGUCtAiNsmD9ewJQhkNLpn74TvXziPRG8xCwKb xpXiOHp9/q7L2eylMKGc1lGJvM6acYtniKyGvEq9htqcRmdEsvp/lYNQYxjd1TX7ISFQ ejXA== X-Received: by 10.50.176.131 with SMTP id ci3mr11784500igc.18.1374123720687; Wed, 17 Jul 2013 22:02:00 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id ri10sm32336576igc.1.2013.07.17.22.01.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Jul 2013 22:01:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 18 Jul 2013 01:01:53 -0400 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis In-Reply-To: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQnJATfpUJyLHrAzRGVhzpZ8m7PEQjOBnPyxTYT6X80hOPoaxOp0FA+JyMO9gf26evcxkLQN Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 05:02:09 -0000 Authors, Dave Michaud from our technology team reviewed the document and had some feedback. I have included it below. [Feedback] Section 2, there should be a mention of HLR =20 Section 3.1 mixes two concepts that have different causes and impacts - The UE requesting IPv4v6 PDP/PDN Type - The HLR/HSS sending a profile with dual-stack enabled (extended-PDP-IP parameter) =20 Section 3.2, there is a responsibility that is put on the UE where it shouldn=B9t: A roaming subscriber with IPv4v6 PDP/PDN type should change the request to two separated PDP/PDN messages of single IP version in order to achieve equivalent results. In reality, the UE will still request IPv4v6 but will be informed by the network that only single address bearers are allowed (cause code #52) along with the activation of one address type. Then and only then the UE can go back and request another bearer with the secondary address type. =20 Section 3.3 a visited network that is IPv6-Only is not something I would consider probable. Given that the address allocation is the burden of the home network, I really don=B9t see why an operator who wants to eb IPv6-Only would block inbound roaming using IPv4 or IPv4v6. =20 Section 4.1 makes an assumption about support for IPv6 that has been in place for as long as IPv4 and it is well supported. Given that this is an optional feature that must be turned-on on vendor equipment, it=B9s not really the case. But then, this section goes on to describe that a user could roam into an IPv4-Only network. =20 Section 4.2 I don=B9t really understand what one is trying to say but there is discussion about hard coding a PREFIX64 which could be a mismatch with the visited network. These functions are all home network based unless VPLMN local breakout is used but there is no mention of that. =20 Aside from the clarifications above, there should be a clear mention of local breakout impacts in this document because it shift a large proportion of the responsibility on the visited network. =20 Also, one thing note mentioned and that we use actively is a clear separation between what the UE requests and what gets allocated by the HPLMN. It is not enough to say =B3Roaming behavior from a dual-stack network=B2. Our UEs will be requesting dual-stack to help with compatibility but our PGW will make a selection (IPv4, IPv6 or IPv4v6). Does this fall in the category =B3from a dual-stack network=B2? Regards, Victor K On 2013-07-09 8:45 AM, "fred@cisco.com" wrote: > >A new draft has been posted, at >http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >take a look at it and comment. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Wed Jul 17 23:18:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09721F9AD8 for ; Wed, 17 Jul 2013 23:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 xfac9NypbfLz for ; Wed, 17 Jul 2013 23:18:21 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6121F9ABB for ; Wed, 17 Jul 2013 23:18:21 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e11so1497440qcx.24 for ; Wed, 17 Jul 2013 23:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i1cb2aLwzG9AU6NU7BdrzHEpXgLG+qceQ8lutoc1QeE=; b=GJffYqJjQOww8zitwK/NqyTeq7llxJBlE0EUdivp9txIRuQeXn6absnDYlhTxX3TQ6 F1mBXf5ZM1/6DiRkPWuA3uHHpcWRl58EPTaQji+X2rG8FW3WWXtFa0E9puYkARFw73An IFTr7XxIvL7VUzREKKMQO+DG3V1AglA9yt3mIL3INa4VH6agIg9m3QeQ/ChNQF7rZtsC PxBW28xraK6P6eyWeezxTiBpfoXm3OE3rGWr/DzCGbxaJte0qFFMTeOfW+INxU04Nhpz QMw9HAK3UyjUELJX5UgluSyON6nPBzBM8vQfShvPd0WnJ432T9olmVP+aEH8T/HHSqiG yGFw== MIME-Version: 1.0 X-Received: by 10.224.94.1 with SMTP id x1mr12059664qam.54.1374128300125; Wed, 17 Jul 2013 23:18:20 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Wed, 17 Jul 2013 23:18:19 -0700 (PDT) In-Reply-To: <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> Date: Thu, 18 Jul 2013 14:18:19 +0800 Message-ID: From: GangChen To: Tore Anderson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 06:18:22 -0000 2013/7/18, Tore Anderson : >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. > > Section 4.1 states: "Roaming to IPv4-only networks with IPv6 PDP/PDN > request would fail to get addresses." > > In my experience, this is seldom (if ever) the case. > > My home network (Network Norway) supports IPv6 PDP context and in > recent years I've roamed in more European countries than I can enumerate > from the top of my head, in some Mid-East countries, in the U.S., and in > Japan. I've made a point out of trying all available PLMNs my phone can > see in the air, and I know for a fact that most of them are IPv4-only. > In spite of this I cannot recall last time I had a problem establishing > IPv6 connectivity when roaming. The way I see it, 3GPP IPv6 roaming is > one of those things that Just Works. > > I'm not an expert on 3GPP network architecture, but as far as I've been > able to understand, the reason why this work is that the IPv6 gets > tunnelled back to my home network using GTP, and that the visited > network just considers the payload as "data" and doesn't really care > whether it is IPv4 or IPv6. Thanks for sharing your experience. Yes, you are right. There is no such issue if the subscriber's traffic get back to the gateway (e.g. GGSN) in the home network. The described failure case occurred when the subscriber get an address from the GGSN in the visited network. And traffic flows would be transmitted in a local-breakout manner. 3GPP allows such local-breakout because it has more efficient routing paths. 3GPP also specified another architecture called "SIPTO". It guarantees the subscriber would always select the closest GGSN to reside. Best Regards Gang > > I'm sure there could be exceptions to the above. I've heard several > people suggest that Japan is particularly problematic in this regard - > but in my experience it Just Works there, too. > Tore > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tore@fud.no Thu Jul 18 00:17:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4421E808A for ; Thu, 18 Jul 2013 00:17: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uND4jVvlnO0 for ; Thu, 18 Jul 2013 00:17:28 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED021F9FC8 for ; Thu, 18 Jul 2013 00:17:22 -0700 (PDT) Received: from www-data by greed.fud.no with local (Exim 4.80) (envelope-from ) id 1UziSm-0000d6-Lo; Thu, 18 Jul 2013 09:17:20 +0200 To: GangChen X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 18 Jul 2013 09:17:20 +0200 From: Tore Anderson In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> Message-ID: <806058568c3cd8d3600cb70bc520c10a@greed.fud.no> X-Sender: tore@fud.no User-Agent: Roundcube Webmail/0.7.2 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:17:29 -0000 * GangChen > Thanks for sharing your experience. Yes, you are right. > There is no such issue if the subscriber's traffic get back to the > gateway (e.g. GGSN) in the home network. > The described failure case occurred when the subscriber get an address > from the GGSN in the visited network. And traffic flows would be > transmitted in a local-breakout manner. 3GPP allows such > local-breakout because it has more efficient routing paths. 3GPP also > specified another architecture called "SIPTO". It guarantees the > subscriber would always select the closest GGSN to reside. I see. When roaming, I always get an IP address that belongs to my home provider (this goes both for IPv4 and IPv6), so I assume that it is the home network's choice whether or not to enable this "use closest GGSN" feature? If so, I'd suggest adding some text that ensuring this feature is disabled (at least for the IPv6 PDP type, if it is possible to differentiate between the two) is a good way to prevent IPv6 subscribers from experiencing problems when roaming in IPv4-only networks. Tore From phdgang@gmail.com Thu Jul 18 01:46:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422E911E80EC for ; Thu, 18 Jul 2013 01:46:24 -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.107, BAYES_00=-2.599, 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 Ol4cHiSb5Ezz for ; Thu, 18 Jul 2013 01:46:23 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5F11E80E2 for ; Thu, 18 Jul 2013 01:46:23 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so1552752qcy.41 for ; Thu, 18 Jul 2013 01:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jjNdgP4aE1LSCCU18/ulW3SyKvAIIYG4ahVuOdW0SM8=; b=Q2jG8lfn33qDKhrNV/ks/A2W0JktbU4M2rZyUHIdsaSy/Z1QfSOyAwoT6RHDY2LL0l GgAciubrA9/czor1PnTxX3T33gVARVNddGMu7np6bq15iJmw+cU52CwYih4DE3A+2Slm 6DXFqbFtBxin+uDFUO3J38R+hW1Q28729Ti4F2RJIGxVSGxnZn0EMRQYGbOro5RbOgOK fGrRf6YELSZP+GaPkeLTZ91bEO1xNVcxyzx6v6hGamx44sA9+hQ2rZhoWo3SxYLaTDJB W/j+slLvyNroPqt5bY4BCsglbV6MzBErF87Hm2F6cH51kebuU08Ylf2R00MP4M0XpDrI 1rlg== MIME-Version: 1.0 X-Received: by 10.224.212.199 with SMTP id gt7mr12779378qab.80.1374137183149; Thu, 18 Jul 2013 01:46:23 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Thu, 18 Jul 2013 01:46:23 -0700 (PDT) In-Reply-To: <806058568c3cd8d3600cb70bc520c10a@greed.fud.no> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> <806058568c3cd8d3600cb70bc520c10a@greed.fud.no> Date: Thu, 18 Jul 2013 16:46:23 +0800 Message-ID: From: GangChen To: Tore Anderson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 08:46:24 -0000 2013/7/18, Tore Anderson : > * GangChen > >> Thanks for sharing your experience. Yes, you are right. >> There is no such issue if the subscriber's traffic get back to the >> gateway (e.g. GGSN) in the home network. >> The described failure case occurred when the subscriber get an address >> from the GGSN in the visited network. And traffic flows would be >> transmitted in a local-breakout manner. 3GPP allows such >> local-breakout because it has more efficient routing paths. 3GPP also >> specified another architecture called "SIPTO". It guarantees the >> subscriber would always select the closest GGSN to reside. > > I see. When roaming, I always get an IP address that belongs to my home > provider (this goes both for IPv4 and IPv6), so I assume that it is the > home network's choice whether or not to enable this "use closest GGSN" > feature? Yes, those behaviors could be gauged by subscriber's profile. For example, disable local-break-out > If so, I'd suggest adding some text that ensuring this feature is > disabled (at least for the IPv6 PDP type, if it is possible to > differentiate between the two) is a good way to prevent IPv6 subscribers > from experiencing problems when roaming in IPv4-only networks. Good suggestion. I would add the point in the next update. Best Regards Gang > Tore > From david.binet@orange.com Thu Jul 18 02:15:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F36121E809B for ; Thu, 18 Jul 2013 02:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=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 vD2tsWnmUWgk for ; Thu, 18 Jul 2013 02:15:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B652621F91BF for ; Thu, 18 Jul 2013 02:14:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id AD20A3B41FE; Thu, 18 Jul 2013 11:14:58 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 700DD23806E; Thu, 18 Jul 2013 11:14:58 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 18 Jul 2013 11:14:58 +0200 From: To: GangChen , Tore Anderson Date: Thu, 18 Jul 2013 11:14:57 +0200 Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac6Dk2UKFC/TddIQQeGkYaDArC7q9gAAmryw Message-ID: <4065_1374138898_51E7B212_4065_256_5_1B2E7539FECD9048B261B791B1B24A7C510FC14902@PUEXCB1A.nanterre.francetelecom.fr> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> <806058568c3cd8d3600cb70bc520c10a@greed.fud.no> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 09:15:04 -0000 Hi=20 Some comments below David > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part de GangChen > Envoy=E9 : jeudi 18 juillet 2013 10:46 > =C0 : Tore Anderson > Cc : v6ops@ietf.org > Objet : Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >=20 > 2013/7/18, Tore Anderson : > > * GangChen > > > >> Thanks for sharing your experience. Yes, you are right. > >> There is no such issue if the subscriber's traffic get back to the=20 > >> gateway (e.g. GGSN) in the home network. > >> The described failure case occurred when the subscriber get an=20 > >> address from the GGSN in the visited network. And traffic=20 > flows would=20 > >> be transmitted in a local-breakout manner. 3GPP allows such=20 > >> local-breakout because it has more efficient routing=20 > paths. 3GPP also=20 > >> specified another architecture called "SIPTO". It guarantees the=20 > >> subscriber would always select the closest GGSN to reside. > > > > I see. When roaming, I always get an IP address that belongs to my=20 > > home provider (this goes both for IPv4 and IPv6), so I=20 > assume that it=20 > > is the home network's choice whether or not to enable this=20 > "use closest GGSN" > > feature? >=20 > Yes, those behaviors could be gauged by subscriber's profile.=20 > For example, disable local-break-out David: Do you mean that you will use the "VPLMN address allowed" flag in th= e HLR ? Generally this flag is set to false and Home Routed is used by oper= ators. Use of Local Break Out means also that the APN name is recognized in visite= d network.=20 I think it could be useful to include Local Break Out scenario in this docu= ment as it is envisaged at least for IMS services.=20=20 >=20 > > If so, I'd suggest adding some text that ensuring this feature is=20 > > disabled (at least for the IPv6 PDP type, if it is possible to=20 > > differentiate between the two) is a good way to prevent IPv6=20 > > subscribers from experiencing problems when roaming in=20 > IPv4-only networks. >=20 > Good suggestion. I would add the point in the next update. David: Actually IPv6 PDP context has been specified for quite a long time a= nd it is well supported in devices. As far as charging architecture is OK a= nd visited operators does not filter IPv6, I do not think it is the main issue in roaming context. IPv4v6 PDP co= ntext may bring more issues, in particular, if some visited SGSNs do not be= have as they should do, considering unknown PDP contexts as IPv4 ones.=20=20=20 >=20 > Best Regards >=20 > Gang >=20 > > Tore > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Thu Jul 18 04:30:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229D311E812A for ; Thu, 18 Jul 2013 04:30:29 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 yLYX1I7T+aVx for ; Thu, 18 Jul 2013 04:30:28 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 82D1C11E8128 for ; Thu, 18 Jul 2013 04:30:27 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id ik8so1128740bkc.23 for ; Thu, 18 Jul 2013 04:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=iK6oElqryc/9YygCDqOEluMFb5bvr+KLCsVThSmju58=; b=U4mCPcVdI8yF4uNHE/wHY7rz/smk0NMgSlieoZe3kYrJfa2GvbdX7KHmC5Takmxkou XBBU3lRtAM9FsCkmip4kENgsZGPGO2KtLJwWUEcvIBks92bLL4UoEb+rpz+CyuBF1FL3 Ofe4eonQhYuIrCrkhEU7WhvwKdTEcK0TOw4UGrk7E2K0FAnIajIuFoPq989UKQzu59P9 s1ZhqGfcSWHIKOmM5DvnyDvivqqRx1OfIybjuigWe/XafioLfqfuI9f/W8vX4JRJ1HSa kuHGbD7TBAKtfgTZ/nUF5tapvXZuEozlE5jEF8wVT4GszZ4sWW74C0ahvNqHyDha9z1N mtVQ== X-Received: by 10.204.226.75 with SMTP id iv11mr1734269bkb.136.1374147026506; Thu, 18 Jul 2013 04:30:26 -0700 (PDT) Received: from host-109-204-179-26.tp-fne.tampereenpuhelin.net (host-109-204-179-26.tp-fne.tampereenpuhelin.net. [109.204.179.26]) by mx.google.com with ESMTPSA id cb7sm3237659bkb.16.2013.07.18.04.30.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 04:30:24 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 18 Jul 2013 14:30:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:30:29 -0000 Gang, I was more like thinking of IR.33, TAP documents and the IPv6 white = paper, etc stuff that GSMA has worked on. I think aligning with GSMA is = important since they are far more important for 3GPP roaming aspects than any IETF document. Then some other notes. When reading the draft I always get confused when the draft assumes local breakout, when home routed traffic and when a specific "phenomenon" is due visited/home APN/HLR intentional configuration, licensing restriction or some known implementation issue on some vendor equipment. Also some behaviour are due the UE specific implementation beyond what 3GPP specs say. I would encourage to detail these assumptions out on each claim/description so that possible readers can map the issues to their deployments easier without guesswork. In Section 3.1 it states: "Subscriber Server). When the subscriber roams to the IPv4 network," Does this mean the visited SGSN would not implement PDP Type IPv6? I know such exist(ed) but how common are those on live today? "land to retrieve the subscriber profile. Roaming with IPv4v6 type in the subscriber profile may cause issues because the visited SGSN/SGW can't parse the information. The subscriber is failed to register in this case." I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 would be kind of surprising. I have seen a MME that did not implement IPv4v6 = very early of rel-8 testing phase, though. Here I would like to see text describing what is the actual failure scenario when the subscriber gets no connection at all. I know one SGSN+HLR combination which is very unlikely to happen in commercial networks. In Section 3.2. it states: "of single IP version in order to achieve equivalent results. Some operators may turn off the function only allow one PDP/PDN is alive for each subscriber. For example, IPv6 PDP/PDN would be rejected if the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber may lost IPv6 connection in the visited network. Even the two" I am confused here. Are we assuming visited GGSN here? In Section 4.1. it states: "requested protocol and always adhere to IPv4 when roaming. Those fallback mechanisms are deserved to be implemented and standardized timely." Does the standardization mean fallback mechanisms beyond what 3GPP=20 already defined? - Jouni On Jul 15, 2013, at 6:28 PM, GangChen wrote: > 2013/7/15, Jouni Korhonen : >>=20 >> Gang, >>=20 >> Regarding roaming in general, have you looked at what GSMA is doing >> on this front? I was kind of expecting at least a reference to some >> GSMA document since they are quite important when it comes to 3GPP >> based networks & roaming. >=20 > I guess GSMA IR.21 could be cited here. > http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf > Most failures cases are occurred if a roaming partner's IR.21 only > states v4 support >=20 > -g >=20 >=20 >>=20 >> - Jouni >>=20 >>=20 >> On Jul 15, 2013, at 5:56 AM, GangChen wrote: >>=20 >>> Hi Alexis, >>>=20 >>> Thanks for the interests. We are experiencing the issues recently = when >>> IPv6 is tested/deployed. For the goal of the draft, it reports that = to >>> the community and hopes to mature IPv6 supports either by = encouraging >>> proper implementations on mobile terminals or completing global >>> roaming contracts. >>>=20 >>> Your reviews/comments are appreciated >>>=20 >>> BRs >>>=20 >>> Gang >>>=20 >>> 2013/7/9, Alexis Munoz (Gmail) : >>>> It looks so interesting. I will check it and I will give you my = comments >>>> very soon. >>>>=20 >>>> Thanks, >>>>=20 >>>> Alexis Mu=F1oz >>>>=20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >>>> Of >>>> fred@cisco.com >>>> Sent: Tuesday, July 09, 2013 7:45 AM >>>> To: v6ops@ietf.org >>>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>>> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >>>>=20 >>>>=20 >>>> A new draft has been posted, at >>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>> Please >>>> take a look at it and comment. >>>> _______________________________________________ >>>> 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 >>=20 >>=20 From phdgang@gmail.com Thu Jul 18 21:51:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C67711E828B for ; Thu, 18 Jul 2013 21:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 Tpbsa2xN+y+1 for ; Thu, 18 Jul 2013 21:51:10 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8811E8282 for ; Thu, 18 Jul 2013 21:51:09 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so2240858qen.10 for ; Thu, 18 Jul 2013 21:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vmoMwbhqnRMKJsjFRKkEBXIFxcVue8gw9f+nXODAJQc=; b=cE5kvJF5nN44k+TCNiADUGWgQqkOP6Tzdie+q8tHbLa1ZOa+H3eozY3vYquGJnjf1D BI9xS1ctIHNxKIRk0qgSXF8YzgZcidoQUnKarJfaeX0Gb+2T/q8npxHJB2VY+AE+KfDn GXDU20ibNZUM0SBNwY+178v9bRfmEb9/pQYab2eLlqP3TKEeJbS+qMG0ch0akeQnCvak 9xpgnh5EemRTeUpfhz4kLDXPOUnP0tqu/tws9CNMvfkrW3RcGXYL2PJMOp0KjFk8htEo ccUjvm8S5rDmSUyKdAmA9ObmJJDF8PYwrXNvWzfF4AdtaUgpW3b+2vYAv1SpGlqwECLA RhuA== MIME-Version: 1.0 X-Received: by 10.224.94.1 with SMTP id x1mr16524073qam.54.1374209469358; Thu, 18 Jul 2013 21:51:09 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Thu, 18 Jul 2013 21:51:09 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Fri, 19 Jul 2013 12:51:09 +0800 Message-ID: From: GangChen To: Victor Kuarsingh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 04:51:11 -0000 2013/7/18, Victor Kuarsingh : > Authors, > > Dave Michaud from our technology team reviewed the document and had some > feedback. I have included it below. Many thanks for your reviews/comments > [Feedback] > Section 2, there should be a mention of HLR will add at the next version > > Section 3.1 mixes two concepts that have different causes and impacts > - The UE requesting IPv4v6 PDP/PDN Type > > - The HLR/HSS sending a profile with dual-stack enabled > (extended-PDP-IP parameter) Those are two different types. UE requests is a PDP/PDN message over GTP. HLR/HSS send a subscriber's profile including supported PDP types using Diameter. We will clarify that > > Section 3.2, there is a responsibility that is put on the UE where it > shouldn=B9t: > A roaming subscriber with IPv4v6 PDP/PDN type should change the request t= o > two separated PDP/PDN messages of single IP version in order to achieve > equivalent results. > In reality, the UE will still request IPv4v6 but will be informed by the > network that only single address bearers are allowed (cause code #52) > along with the activation of one address type. Then and only then the UE > can go back and request another bearer with the secondary address type. the texts are changed as: A roaming subscriber with IPv4v6 PDP/PDN type should change the request to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The mobile terminal should then initiate another PDP Context Activation procedure to this APN in order to activate a second PDP context with the other single address PDP type which was not allocated by the network. > > Section 3.3 a visited network that is IPv6-Only is not something I would > consider probable. Given that the address allocation is the burden of the > home network, The assumption is that visited networks will do local-breakout and assign the address by the visited GGSN/PGW > I really don=B9t see why an operator who wants to eb IPv6-Only > would block inbound roaming using IPv4 or IPv4v6. > Section 4.1 makes an assumption about support for IPv6 that has been in > place for as long as IPv4 and it is well supported. Given that this is an > optional feature that must be turned-on on vendor equipment, it=B9s not > really the case. The description intended to say IPv6-only PDP is a pre-R8 feature compared to IPv4v6 PDP. Yes, the draft should consider implementation aspects to suggest turn-on the function. > But then, this section goes on to describe that a user > could roam into an IPv4-Only network. Here we actually consider the local-breakout case. Otherwise, there are no issues if traffic would get back to home networks > > Section 4.2 I don=B9t really understand what one is trying to say but the= re > is discussion about hard coding a PREFIX64 which could be a mismatch with > the visited network. These functions are all home network based unless > VPLMN local breakout is used but there is no mention of that. The draft should mention that the failure happens if local breakout is used. We will add at the next update > > Aside from the clarifications above, there should be a clear mention of > local breakout impacts in this document because it shift a large > proportion of the responsibility on the visited network. > > > Also, one thing note mentioned and that we use actively is a clear > separation between what the UE requests and what gets allocated by the > HPLMN. It is not enough to say =B3Roaming behavior from a dual-stack > network=B2. It can be more precise to say "Roaming behavior from a mobile terminal sending IPv4v6 PDP/PDN" > Our UEs will be requesting dual-stack to help with compatibility > but our PGW will make a selection (IPv4, IPv6 or IPv4v6). Does this fall > in the category =B3from a dual-stack network=B2? We categorize the scenario depending on the requested PDP/PDN type. I suppose the suitable network environment is a dual-stack network. As you mentioned PGW may make further selection in the home network. I'm not sure the reason PGW supporting IPv4v6 but only select single stack ipv4, ipv6 address or home PGW only support single stack bearer, but mobile phones ask IPv4v6 PDP/PDN. Best Regards Gang > > Regards, > > Victor K > > > > > On 2013-07-09 8:45 AM, "fred@cisco.com" wrote: > >> >>A new draft has been posted, at >>http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >>take a look at it and comment. >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > > > From phdgang@gmail.com Thu Jul 18 21:59:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A018221E81BA for ; Thu, 18 Jul 2013 21:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 LQLYojhlVhGE for ; Thu, 18 Jul 2013 21:59:58 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DCB3721E81B7 for ; Thu, 18 Jul 2013 21:59:57 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so2128869qcy.13 for ; Thu, 18 Jul 2013 21:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YVUjrudqJsBTZfn43+W1uXraXWmgQb5WCCO4UZZZgDQ=; b=ox6ckdMdLX4QLPzDS6pk//VW4mzdrHXjyUkYpRVmOisYPSMtljcGWwlZYPJDVO5L8f KXx3i+dxttR2Luy4y3y02dqur4uvtaehcBEf0o6xkuQwO/8zEVZ/o7GQoZIBPbNgLNP3 s4wKbkzTVHLLSrzBpYMPypCIOLaPME7F9m6fIXgazyGQb3CJl47Y0iMtqFbj1O9WyOBO 3UHxRMON5uImecMNBRsy97iRAOmOGB78hTKX0yJQUkXC7DGAQbavh9DjayX+JOYjJwIw DEZrZvTkG+D3Jj8cBRK9KArMLgVJdf82nnzNwREHy3mQpWpOq28CoAqW6pNItz23kj+5 z3nQ== MIME-Version: 1.0 X-Received: by 10.49.0.140 with SMTP id 12mr15883568qee.26.1374209997265; Thu, 18 Jul 2013 21:59:57 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Thu, 18 Jul 2013 21:59:57 -0700 (PDT) In-Reply-To: <4065_1374138898_51E7B212_4065_256_5_1B2E7539FECD9048B261B791B1B24A7C510FC14902@PUEXCB1A.nanterre.francetelecom.fr> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> <806058568c3cd8d3600cb70bc520c10a@greed.fud.no> <4065_1374138898_51E7B212_4065_256_5_1B2E7539FECD9048B261B791B1B24A7C510FC14902@PUEXCB1A.nanterre.francetelecom.fr> Date: Fri, 19 Jul 2013 12:59:57 +0800 Message-ID: From: GangChen To: david.binet@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 04:59:58 -0000 Hi David, 2013/7/18, david.binet@orange.com : > Hi > > Some comments below > David > >> -----Message d'origine----- >> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] >> De la part de GangChen >> Envoy=E9 : jeudi 18 juillet 2013 10:46 >> =C0 : Tore Anderson >> Cc : v6ops@ietf.org >> Objet : Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >> >> 2013/7/18, Tore Anderson : >> > * GangChen >> > >> >> Thanks for sharing your experience. Yes, you are right. >> >> There is no such issue if the subscriber's traffic get back to the >> >> gateway (e.g. GGSN) in the home network. >> >> The described failure case occurred when the subscriber get an >> >> address from the GGSN in the visited network. And traffic >> flows would >> >> be transmitted in a local-breakout manner. 3GPP allows such >> >> local-breakout because it has more efficient routing >> paths. 3GPP also >> >> specified another architecture called "SIPTO". It guarantees the >> >> subscriber would always select the closest GGSN to reside. >> > >> > I see. When roaming, I always get an IP address that belongs to my >> > home provider (this goes both for IPv4 and IPv6), so I >> assume that it >> > is the home network's choice whether or not to enable this >> "use closest GGSN" >> > feature? >> >> Yes, those behaviors could be gauged by subscriber's profile. >> For example, disable local-break-out > David: Do you mean that you will use the "VPLMN address allowed" flag in = the > HLR ? Generally this flag is set to false and Home Routed is used by > operators. > Use of Local Break Out means also that the APN name is recognized in visi= ted > network. > I think it could be useful to include Local Break Out scenario in this > document as it is envisaged at least for IMS services. Some cases in the draft already assume local breakout condition. But I guess it should be clarified in the next version. >> >> > If so, I'd suggest adding some text that ensuring this feature is >> > disabled (at least for the IPv6 PDP type, if it is possible to >> > differentiate between the two) is a good way to prevent IPv6 >> > subscribers from experiencing problems when roaming in >> IPv4-only networks. >> >> Good suggestion. I would add the point in the next update. > David: Actually IPv6 PDP context has been specified for quite a long time > and it is well supported in devices. In the previous message http://www.ietf.org/mail-archive/web/v6ops/current/msg17187.html Dave reported "Section 4.1 makes an assumption about support for IPv6 that has been in place for as long as IPv4 and it is well supported. Given that this is an optional feature that must be turned-on on vendor equipment, it=B9s not really the case." I will add texts to suggest turn-on the IPv6 support > As far as charging architecture is OK > and visited operators does not filter > IPv6, I do not think it is the main issue in roaming context. If there is no breakout, IPv6-only doesn't have the issue. > IPv4v6 PDP > context may bring more issues, in particular, if some visited SGSNs do no= t > behave as they should do, considering unknown PDP > contexts as IPv4 ones. I agree. We should consider that seriously BRs Gang >> >> Best Regards >> >> Gang >> >> > Tore >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > From phdgang@gmail.com Fri Jul 19 00:36:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832CE11E81E6 for ; Fri, 19 Jul 2013 00:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=-1.794, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, 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 vQcc4QEAC4qu for ; Fri, 19 Jul 2013 00:36:51 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 812A311E81D5 for ; Fri, 19 Jul 2013 00:36:51 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so2198165qcv.9 for ; Fri, 19 Jul 2013 00:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Pcj1KPWBvqSCENLUm3tyGEwjUhLoBP0AbSIHnm9VHpw=; b=oEih8+eExp2Lr6zSleXRg5K8rB66dCPwMqTLYmznafggvWg226ioh3BvUihnG9GbEK hq71x/vkotBn/GwaRhwoyGeqZqxfFQ5ea5wffde9QL7jm0R0IFwAQO99xYIphFABEuxY AIxyEGacO9YvefoJVZKeTU1QTkNpBvqlEj87qY7jt1JFHBf3hQmzA8+YB5FLHpbF3LeX qHp3V1d1SPUxlbCVPFsktHBbHs8H7r5LuTcUMKFlQosZdScrnIrspZXw4YfHWCXaXkdh Oe+4kyvwOl8OgJ/75d0P9M7u/EyZx95xVpu+OakBUH8u4ftMV9RuAlPzoqXuyAXWZoY5 NXcQ== MIME-Version: 1.0 X-Received: by 10.224.94.1 with SMTP id x1mr16985025qam.54.1374219407863; Fri, 19 Jul 2013 00:36:47 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Fri, 19 Jul 2013 00:36:47 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> Date: Fri, 19 Jul 2013 15:36:47 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:36:52 -0000 Jouni, 2013/7/18, Jouni Korhonen : > > Gang, > > I was more like thinking of IR.33, TAP documents and the IPv6 white paper= , > etc stuff that GSMA has worked on. I think aligning with GSMA is importan= t > since they are far more important for 3GPP roaming aspects than any IETF > document. > > Then some other notes. When reading the draft I always get confused > when the draft assumes local breakout, when home routed traffic and > when a specific "phenomenon" is due visited/home APN/HLR intentional > configuration, licensing restriction or some known implementation > issue on some vendor equipment. Also some behaviour are due the UE > specific implementation beyond what 3GPP specs say. I would encourage > to detail these assumptions out on each claim/description so that > possible readers can map the issues to their deployments easier > without guesswork. I noticed that after the discussions on the list. We will complete the descriptions to detail the assumed conditions. Also the GSMA document would be cited to align the consideration. > In Section 3.1 it states: > > "Subscriber Server). When the subscriber roams to the IPv4 network," > > Does this mean the visited SGSN would not implement PDP Type IPv6? The reason is visited SGSN doesn't support PDP Type IPv4v6, other than PDP type IPv6. PDP type IPv6 has well been supported AFAIK. >I know such exist(ed) but how common are those on live today? When we do IPv6 trials, we have to upgrade all SGSN to understand PDP Type IPv4v6. I also had some discussions with other operator colleague. They also have same issues. > "land to retrieve the subscriber profile. Roaming with IPv4v6 type in > the subscriber profile may cause issues because the visited SGSN/SGW > can't parse the information. The subscriber is failed to register in > this case." > > I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 would > be kind of surprising. I have seen a MME that did not implement IPv4v6 ve= ry > early of rel-8 testing phase, though. If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs introduces IPv4v6 since Release-9. You may be right it's a rare case if SGW doesn't implement IPv4v6. The failure cases we are facing are mainly on SGSN. SGW is listed just because the rel-8 SGW implementations. Thank you for the information there is no such case in the real world. We will update the draft with your comments accordingly. > Here I would like to see text > describing what is the actual failure scenario when the subscriber gets > no connection at all. I know one SGSN+HLR combination which is very > unlikely to happen in commercial networks. The failure scenario is subscriber can't register to the visited network. Would you mind to add something to help me understand what's your expected texts here? > In Section 3.2. it states: > > "of single IP version in order to achieve equivalent results. Some > operators may turn off the function only allow one PDP/PDN is alive > for each subscriber. For example, IPv6 PDP/PDN would be rejected if > the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber > may lost IPv6 connection in the visited network. Even the two" > > I am confused here. Are we assuming visited GGSN here? Yes. The local breakout is considered here. > > In Section 4.1. it states: > > "requested protocol and always adhere to IPv4 when roaming. Those > fallback mechanisms are deserved to be implemented and standardized > timely." > > Does the standardization mean fallback mechanisms beyond what 3GPP > already defined? A proper fallback mechanism is not defined in 3GPP. The advocated standardization more likes to do defacto standard. But the suggestion is align with cuurent 3GPP spec. And some implementations are available. Best Regards Gang > - Jouni > > On Jul 15, 2013, at 6:28 PM, GangChen wrote: > >> 2013/7/15, Jouni Korhonen : >>> >>> Gang, >>> >>> Regarding roaming in general, have you looked at what GSMA is doing >>> on this front? I was kind of expecting at least a reference to some >>> GSMA document since they are quite important when it comes to 3GPP >>> based networks & roaming. >> >> I guess GSMA IR.21 could be cited here. >> http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf >> Most failures cases are occurred if a roaming partner's IR.21 only >> states v4 support >> >> -g >> >> >>> >>> - Jouni >>> >>> >>> On Jul 15, 2013, at 5:56 AM, GangChen wrote: >>> >>>> Hi Alexis, >>>> >>>> Thanks for the interests. We are experiencing the issues recently when >>>> IPv6 is tested/deployed. For the goal of the draft, it reports that to >>>> the community and hopes to mature IPv6 supports either by encouraging >>>> proper implementations on mobile terminals or completing global >>>> roaming contracts. >>>> >>>> Your reviews/comments are appreciated >>>> >>>> BRs >>>> >>>> Gang >>>> >>>> 2013/7/9, Alexis Munoz (Gmail) : >>>>> It looks so interesting. I will check it and I will give you my >>>>> comments >>>>> very soon. >>>>> >>>>> Thanks, >>>>> >>>>> Alexis Mu=F1oz >>>>> >>>>> -----Original Message----- >>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behal= f >>>>> Of >>>>> fred@cisco.com >>>>> Sent: Tuesday, July 09, 2013 7:45 AM >>>>> To: v6ops@ietf.org >>>>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>>>> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >>>>> >>>>> >>>>> A new draft has been posted, at >>>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>> Please >>>>> take a look at it and comment. >>>>> _______________________________________________ >>>>> 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 jouni.nospam@gmail.com Fri Jul 19 01:35:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B2D11E8226 for ; Fri, 19 Jul 2013 01:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_50=0.001, J_CHICKENPOX_13=0.6, 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 97nuhfKE-oRZ for ; Fri, 19 Jul 2013 01:35:25 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E1F9B11E8205 for ; Fri, 19 Jul 2013 01:35:24 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it16so1520946bkc.27 for ; Fri, 19 Jul 2013 01:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UXJYhUmSJOk8aHBxy6iLACwcK4qHf647x/FYMsHYXco=; b=McvKZxTX9wQXw/fX1N2UhqsWg974e6IirG61RpPNLfhQVoBU03t14S+ECITlJoe0Zp fFnbLdqOxlz77pn+IY2Guq1GNz4Bu4RvvfWem+ArDR273RY15nj8kwpAuM9YiAnsWOLt hq+YiTZrHm/jltdCQG0wwdX/P+Z680/Iy0VuGOJJA8K+EgTnhjUWYcr9R3jAeip9/SeC Mf3nX9DQVtBkZksYgK2CfaUownZhS776Au1YfOT01uKumXFxjCJeBXi14wlwceUtWrcx 6Q+qTrYeuNqONAeT0ty67WigYybiV6msqtkdWbTTNNyQBy14Yh/AP4mP+EH5paKnCoZ5 F9BA== X-Received: by 10.205.14.197 with SMTP id pr5mr2318476bkb.25.1374222923965; Fri, 19 Jul 2013 01:35:23 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cy5sm4067595bkb.1.2013.07.19.01.35.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 01:35:22 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 19 Jul 2013 11:35:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3602EE3F-ED75-48B8-85EC-6EC996F0BCEF@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 08:35:26 -0000 Hi, On Jul 19, 2013, at 10:36 AM, GangChen wrote: > Jouni, >=20 > 2013/7/18, Jouni Korhonen : >>=20 >> Gang, >>=20 >> I was more like thinking of IR.33, TAP documents and the IPv6 white = paper, >> etc stuff that GSMA has worked on. I think aligning with GSMA is = important >> since they are far more important for 3GPP roaming aspects than any = IETF >> document. >>=20 >> Then some other notes. When reading the draft I always get confused >> when the draft assumes local breakout, when home routed traffic and >> when a specific "phenomenon" is due visited/home APN/HLR intentional >> configuration, licensing restriction or some known implementation >> issue on some vendor equipment. Also some behaviour are due the UE >> specific implementation beyond what 3GPP specs say. I would encourage >> to detail these assumptions out on each claim/description so that >> possible readers can map the issues to their deployments easier >> without guesswork. >=20 > I noticed that after the discussions on the list. We will complete the > descriptions to detail the assumed conditions. Also the GSMA document > would be cited to align the consideration. >=20 >> In Section 3.1 it states: >>=20 >> "Subscriber Server). When the subscriber roams to the IPv4 = network," >>=20 >> Does this mean the visited SGSN would not implement PDP Type IPv6? >=20 > The reason is visited SGSN doesn't support PDP Type IPv4v6, other than > PDP type IPv6. PDP type IPv6 has well been supported AFAIK. Ok. But then what you write is not really what you intend to say. The = network in not IPv4 network, since it implements the IPv6 PDP Type. It is just = the standardized behavior that a Gn-based SGSN treats an unknown PDP Type as = IPv4 PDP Type. In this case where a visited SGSN does understand IPv6 but not = IPv4v6, then it treats the context request as IPv4. That is different from the = network being IPv4. Also, I would be careful when using SGSN and PDP Type IPv4v6. A Gn-based = SGSN had PDP Type IPv4v6 supported from Rel-9 onwards but S4-SGSN had since = Rel-8.=20 Also the treatment of unknown PDP/PDN type can be different from SGSN = and S4-SGSN. >> I know such exist(ed) but how common are those on live today? >=20 > When we do IPv6 trials, we have to upgrade all SGSN to understand PDP > Type IPv4v6. I also had some discussions with other operator > colleague. They also have same issues. I was talking about IPv4 _only_ SGSNs. Those were around and are still possible e.g. due licensing/configuration.. not that it would make any sense to have an IPv4-only SGSN around.. >> "land to retrieve the subscriber profile. Roaming with IPv4v6 type = in >> the subscriber profile may cause issues because the visited = SGSN/SGW >> can't parse the information. The subscriber is failed to register = in >> this case." >>=20 >> I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 = would >> be kind of surprising. I have seen a MME that did not implement = IPv4v6 very >> early of rel-8 testing phase, though. >=20 > If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs introduces > IPv4v6 since Release-9. You may be right it's a rare case if SGW Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since = Rel-8. > doesn't implement IPv4v6. The failure cases we are facing are mainly > on SGSN. SGW is listed just because the rel-8 SGW implementations. > Thank you for the information there is no such case in the real world. > We will update the draft with your comments accordingly. >=20 >> Here I would like to see text >> describing what is the actual failure scenario when the subscriber = gets >> no connection at all. I know one SGSN+HLR combination which is very >> unlikely to happen in commercial networks. >=20 > The failure scenario is subscriber can't register to the visited > network. Would you mind to add something to help me understand what's > your expected texts here? Just list exactly what is configured in HLR, supported by SGSN and GGSN, configured in GGSN and what the UE requests for. The combination and the description why the combination fails is what people are interested in, = IMHO.=20 For the completeness, I would also like to see some discussion on the DAF flag configuration in SGSN/MME, which also affects the context creation end result. >>=20 >> In Section 3.2. it states: >>=20 >> "of single IP version in order to achieve equivalent results. Some >> operators may turn off the function only allow one PDP/PDN is alive >> for each subscriber. For example, IPv6 PDP/PDN would be rejected = if >> the subscriber has an active IPv4 PDP/PDN. Therefore, the = subscriber >> may lost IPv6 connection in the visited network. Even the two" >>=20 >> I am confused here. Are we assuming visited GGSN here? >=20 > Yes. The local breakout is considered here. >=20 >>=20 >> In Section 4.1. it states: >>=20 >> "requested protocol and always adhere to IPv4 when roaming. Those >> fallback mechanisms are deserved to be implemented and standardized >> timely." >>=20 >> Does the standardization mean fallback mechanisms beyond what 3GPP >> already defined? >=20 > A proper fallback mechanism is not defined in 3GPP. The advocated > standardization more likes to do defacto standard. But the suggestion > is align with cuurent 3GPP spec. And some implementations are > available. Ok. - JOuni >=20 > Best Regards >=20 > Gang >=20 >=20 >> - Jouni >>=20 >> On Jul 15, 2013, at 6:28 PM, GangChen wrote: >>=20 >>> 2013/7/15, Jouni Korhonen : >>>>=20 >>>> Gang, >>>>=20 >>>> Regarding roaming in general, have you looked at what GSMA is doing >>>> on this front? I was kind of expecting at least a reference to some >>>> GSMA document since they are quite important when it comes to 3GPP >>>> based networks & roaming. >>>=20 >>> I guess GSMA IR.21 could be cited here. >>> http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf >>> Most failures cases are occurred if a roaming partner's IR.21 only >>> states v4 support >>>=20 >>> -g >>>=20 >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>> On Jul 15, 2013, at 5:56 AM, GangChen wrote: >>>>=20 >>>>> Hi Alexis, >>>>>=20 >>>>> Thanks for the interests. We are experiencing the issues recently = when >>>>> IPv6 is tested/deployed. For the goal of the draft, it reports = that to >>>>> the community and hopes to mature IPv6 supports either by = encouraging >>>>> proper implementations on mobile terminals or completing global >>>>> roaming contracts. >>>>>=20 >>>>> Your reviews/comments are appreciated >>>>>=20 >>>>> BRs >>>>>=20 >>>>> Gang >>>>>=20 >>>>> 2013/7/9, Alexis Munoz (Gmail) : >>>>>> It looks so interesting. I will check it and I will give you my >>>>>> comments >>>>>> very soon. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Alexis Mu=F1oz >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >>>>>> Of >>>>>> fred@cisco.com >>>>>> Sent: Tuesday, July 09, 2013 7:45 AM >>>>>> To: v6ops@ietf.org >>>>>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>>>>> Subject: [v6ops] new draft: = draft-chen-v6ops-ipv6-roaming-analysis >>>>>>=20 >>>>>>=20 >>>>>> A new draft has been posted, at >>>>>> = http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>>> Please >>>>>> take a look at it and comment. >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>>>=20 >>=20 >>=20 From phdgang@gmail.com Sat Jul 20 07:07:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A3B11E8114 for ; Sat, 20 Jul 2013 07:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, 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 plmMamuyTeeI for ; Sat, 20 Jul 2013 07:07:29 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7311E8103 for ; Sat, 20 Jul 2013 07:07:26 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so394463qah.5 for ; Sat, 20 Jul 2013 07:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sij5I5DlDoNlP01F4+lZe1fYms8soKan/li+cBnNhqk=; b=S1vX4rC6wycW/t3rpeXV8cFdvuHIRdUq+k6IWZO8vjIQq+FqJ3a2Uq12/vfelFdBpS 5AkLuwCFrRPoUAvHXAmHhlsZGyP/5L+4dmzERhY4M33SsPBV5OyYDFFsVve4pOPn5ml6 S6Tg2GVMe+jGm/ncP4wxfSR45Poc21OhaVPzZZSWjgBbjKeztEF1YofOkUJk9GDPA1QN PEBCCyI+svpn2ym2oCBnp9bJaGxPevKGIOPK3WGoC0ct+D6Q/xGIrxNPn6ESLprtqjlI AE+iLO79t5c4Z34hYoOAlKT0BKyVzJnN5XYm3fDxg9UQIejYKrGyd6yEeozHLOHxygIO Dqsw== MIME-Version: 1.0 X-Received: by 10.49.29.106 with SMTP id j10mr22771864qeh.37.1374329245642; Sat, 20 Jul 2013 07:07:25 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sat, 20 Jul 2013 07:07:25 -0700 (PDT) In-Reply-To: <3602EE3F-ED75-48B8-85EC-6EC996F0BCEF@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> <3602EE3F-ED75-48B8-85EC-6EC996F0BCEF@gmail.com> Date: Sat, 20 Jul 2013 22:07:25 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 14:07:31 -0000 2013/7/19, Jouni Korhonen : > > Hi, > > On Jul 19, 2013, at 10:36 AM, GangChen wrote: > >> Jouni, >> >> 2013/7/18, Jouni Korhonen : >>> >>> Gang, >>> >>> I was more like thinking of IR.33, TAP documents and the IPv6 white >>> paper, >>> etc stuff that GSMA has worked on. I think aligning with GSMA is >>> important >>> since they are far more important for 3GPP roaming aspects than any IET= F >>> document. >>> >>> Then some other notes. When reading the draft I always get confused >>> when the draft assumes local breakout, when home routed traffic and >>> when a specific "phenomenon" is due visited/home APN/HLR intentional >>> configuration, licensing restriction or some known implementation >>> issue on some vendor equipment. Also some behaviour are due the UE >>> specific implementation beyond what 3GPP specs say. I would encourage >>> to detail these assumptions out on each claim/description so that >>> possible readers can map the issues to their deployments easier >>> without guesswork. >> >> I noticed that after the discussions on the list. We will complete the >> descriptions to detail the assumed conditions. Also the GSMA document >> would be cited to align the consideration. >> >>> In Section 3.1 it states: >>> >>> "Subscriber Server). When the subscriber roams to the IPv4 network," >>> >>> Does this mean the visited SGSN would not implement PDP Type IPv6? >> >> The reason is visited SGSN doesn't support PDP Type IPv4v6, other than >> PDP type IPv6. PDP type IPv6 has well been supported AFAIK. > > Ok. But then what you write is not really what you intend to say. The > network > in not IPv4 network, since it implements the IPv6 PDP Type. I just realize we may have different definition for "IPv4 network". In my understanding, visited SGSN could implement PDP Type IPv6 in an IPv4 network . But visited GGSN restricts IP address assignment only to PDP type IPv4. >It is just the > standardized behavior that a Gn-based SGSN treats an unknown PDP Type as > IPv4 > PDP Type. In this case where a visited SGSN does understand IPv6 but not > IPv4v6, > then it treats the context request as IPv4. The issue is not about SGSN receiving an unknow PDP request. That is the home HSS sends the extended attribute for dual-stack as a part of the subscriber profile. But old SGSN can't parse the information and result failed registration. > That is different from the > network > being IPv4. > > Also, I would be careful when using SGSN and PDP Type IPv4v6. A Gn-based > SGSN > had PDP Type IPv4v6 supported from Rel-9 onwards but S4-SGSN had since > Rel-8. > Also the treatment of unknown PDP/PDN type can be different from SGSN and > S4-SGSN. That is a good clarification. We would add that in the next update. >>> I know such exist(ed) but how common are those on live today? >> >> When we do IPv6 trials, we have to upgrade all SGSN to understand PDP >> Type IPv4v6. I also had some discussions with other operator >> colleague. They also have same issues. > > I was talking about IPv4 _only_ SGSNs. Those were around and are still > possible e.g. due licensing/configuration.. not that it would make any > sense to have an IPv4-only SGSN around.. > >>> "land to retrieve the subscriber profile. Roaming with IPv4v6 type in >>> the subscriber profile may cause issues because the visited SGSN/SGW >>> can't parse the information. The subscriber is failed to register in >>> this case." >>> >>> I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 would >>> be kind of surprising. I have seen a MME that did not implement IPv4v6 >>> very >>> early of rel-8 testing phase, though. >> >> If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs introduces >> IPv4v6 since Release-9. You may be right it's a rare case if SGW > > Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since > Rel-8. Thanks for the correction. >> doesn't implement IPv4v6. The failure cases we are facing are mainly >> on SGSN. SGW is listed just because the rel-8 SGW implementations. >> Thank you for the information there is no such case in the real world. >> We will update the draft with your comments accordingly. >> >>> Here I would like to see text >>> describing what is the actual failure scenario when the subscriber gets >>> no connection at all. I know one SGSN+HLR combination which is very >>> unlikely to happen in commercial networks. >> >> The failure scenario is subscriber can't register to the visited >> network. Would you mind to add something to help me understand what's >> your expected texts here? > > Just list exactly what is configured in HLR, supported by SGSN and GGSN, > configured in GGSN and what the UE requests for. The combination and the > description why the combination fails is what people are interested in, > IMHO. We would try to figure out the combination. > For the completeness, I would also like to see some discussion on the > DAF flag configuration in SGSN/MME, which also affects the context > creation end result. Good. We will add it Best Regards Gang > >>> >>> In Section 3.2. it states: >>> >>> "of single IP version in order to achieve equivalent results. Some >>> operators may turn off the function only allow one PDP/PDN is alive >>> for each subscriber. For example, IPv6 PDP/PDN would be rejected if >>> the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber >>> may lost IPv6 connection in the visited network. Even the two" >>> >>> I am confused here. Are we assuming visited GGSN here? >> >> Yes. The local breakout is considered here. >> >>> >>> In Section 4.1. it states: >>> >>> "requested protocol and always adhere to IPv4 when roaming. Those >>> fallback mechanisms are deserved to be implemented and standardized >>> timely." >>> >>> Does the standardization mean fallback mechanisms beyond what 3GPP >>> already defined? >> >> A proper fallback mechanism is not defined in 3GPP. The advocated >> standardization more likes to do defacto standard. But the suggestion >> is align with cuurent 3GPP spec. And some implementations are >> available. > > Ok. > > - JOuni > > >> >> Best Regards >> >> Gang >> >> >>> - Jouni >>> >>> On Jul 15, 2013, at 6:28 PM, GangChen wrote: >>> >>>> 2013/7/15, Jouni Korhonen : >>>>> >>>>> Gang, >>>>> >>>>> Regarding roaming in general, have you looked at what GSMA is doing >>>>> on this front? I was kind of expecting at least a reference to some >>>>> GSMA document since they are quite important when it comes to 3GPP >>>>> based networks & roaming. >>>> >>>> I guess GSMA IR.21 could be cited here. >>>> http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf >>>> Most failures cases are occurred if a roaming partner's IR.21 only >>>> states v4 support >>>> >>>> -g >>>> >>>> >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> On Jul 15, 2013, at 5:56 AM, GangChen wrote: >>>>> >>>>>> Hi Alexis, >>>>>> >>>>>> Thanks for the interests. We are experiencing the issues recently >>>>>> when >>>>>> IPv6 is tested/deployed. For the goal of the draft, it reports that >>>>>> to >>>>>> the community and hopes to mature IPv6 supports either by encouragin= g >>>>>> proper implementations on mobile terminals or completing global >>>>>> roaming contracts. >>>>>> >>>>>> Your reviews/comments are appreciated >>>>>> >>>>>> BRs >>>>>> >>>>>> Gang >>>>>> >>>>>> 2013/7/9, Alexis Munoz (Gmail) : >>>>>>> It looks so interesting. I will check it and I will give you my >>>>>>> comments >>>>>>> very soon. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Alexis Mu=F1oz >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >>>>>>> Behalf >>>>>>> Of >>>>>>> fred@cisco.com >>>>>>> Sent: Tuesday, July 09, 2013 7:45 AM >>>>>>> To: v6ops@ietf.org >>>>>>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>>>>>> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >>>>>>> >>>>>>> >>>>>>> A new draft has been posted, at >>>>>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>>>> Please >>>>>>> take a look at it and comment. >>>>>>> _______________________________________________ >>>>>>> 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 jouni.nospam@gmail.com Sat Jul 20 10:56:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFDB11E811A for ; Sat, 20 Jul 2013 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_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 bx5WXmCbj2by for ; Sat, 20 Jul 2013 10:56:36 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5AE21E80C1 for ; Sat, 20 Jul 2013 10:56:32 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so4182537lba.2 for ; Sat, 20 Jul 2013 10:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=92eS/gT2kdKEgfIkF8Y/IWGRfn3+C+8Bbgq5ILP0bU0=; b=vIu18CCoo0ROTEx3BwBoj3bO54LnmT/ljyJDOIOgUEUEb3lbF+aLOSzbvZLP0fvX7Q DJvAtG/TnaeIDqb41jUkxbxYMItN1utsEVZNWO7qi5StomvlKUNgwR7oiWOa9XiSg3ZN 5j9exAs4ocDCdJvIlyvghqLGyqP9gURgDAy6puAEsbBdIDXPR4w9DcLR/hKo66afdzDP JbhuJVmOpvOFGd3MrUc+mLmlKtAUCu/8BMqsXNivCFmbCKRERbnF556TiPeDC954fp2Z 5WCF7i8pv+yrm8TkNKJgILQMwj9pjWjhcUzVrPM/Q+Wf6RGNuwYJgN38sdcft9T5CDf5 sWkw== X-Received: by 10.152.43.52 with SMTP id t20mr9563861lal.62.1374342991404; Sat, 20 Jul 2013 10:56:31 -0700 (PDT) Received: from [192.168.1.105] (81-197-21-194.elisa-mobile.fi. [81.197.21.194]) by mx.google.com with ESMTPSA id am8sm8061589lac.1.2013.07.20.10.56.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jul 2013 10:56:28 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Sat, 20 Jul 2013 20:56:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <470DDD8D-8548-4FDD-BF00-2A9AC9D92BCE@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <0bb001ce7cb8$131ff050$395fd0f0$@gmail.com> <3602EE3F-ED75-48B8-85EC-6EC996F0BCEF@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 17:56:37 -0000 Gang, On Jul 20, 2013, at 5:07 PM, GangChen wrote: > 2013/7/19, Jouni Korhonen : >>=20 >> Hi, >>=20 >> On Jul 19, 2013, at 10:36 AM, GangChen wrote: >>=20 >>> Jouni, >>>=20 >>> 2013/7/18, Jouni Korhonen : >>>>=20 >>>> Gang, >>>>=20 >>>> I was more like thinking of IR.33, TAP documents and the IPv6 white >>>> paper, >>>> etc stuff that GSMA has worked on. I think aligning with GSMA is >>>> important >>>> since they are far more important for 3GPP roaming aspects than any = IETF >>>> document. >>>>=20 >>>> Then some other notes. When reading the draft I always get confused >>>> when the draft assumes local breakout, when home routed traffic and >>>> when a specific "phenomenon" is due visited/home APN/HLR = intentional >>>> configuration, licensing restriction or some known implementation >>>> issue on some vendor equipment. Also some behaviour are due the UE >>>> specific implementation beyond what 3GPP specs say. I would = encourage >>>> to detail these assumptions out on each claim/description so that >>>> possible readers can map the issues to their deployments easier >>>> without guesswork. >>>=20 >>> I noticed that after the discussions on the list. We will complete = the >>> descriptions to detail the assumed conditions. Also the GSMA = document >>> would be cited to align the consideration. >>>=20 >>>> In Section 3.1 it states: >>>>=20 >>>> "Subscriber Server). When the subscriber roams to the IPv4 = network," >>>>=20 >>>> Does this mean the visited SGSN would not implement PDP Type IPv6? >>>=20 >>> The reason is visited SGSN doesn't support PDP Type IPv4v6, other = than >>> PDP type IPv6. PDP type IPv6 has well been supported AFAIK. >>=20 >> Ok. But then what you write is not really what you intend to say. The >> network >> in not IPv4 network, since it implements the IPv6 PDP Type. >=20 > I just realize we may have different definition for "IPv4 network". In > my understanding, visited SGSN could implement PDP Type IPv6 in an > IPv4 network . But visited GGSN restricts IP address assignment only > to PDP type IPv4. >=20 >> It is just the >> standardized behavior that a Gn-based SGSN treats an unknown PDP Type = as >> IPv4 >> PDP Type. In this case where a visited SGSN does understand IPv6 but = not >> IPv4v6, >> then it treats the context request as IPv4. >=20 > The issue is not about SGSN receiving an unknow PDP request. That is > the home HSS sends the extended attribute for dual-stack as > a part of the subscriber profile. But old SGSN can't parse the > information and result failed registration. The above are good examples that the draft needs to be much more exact what it tries to say. Specifically it needs to describe the assumed network environment & configuration. - Jouni >=20 >> That is different from the >> network >> being IPv4. >>=20 >> Also, I would be careful when using SGSN and PDP Type IPv4v6. A = Gn-based >> SGSN >> had PDP Type IPv4v6 supported from Rel-9 onwards but S4-SGSN had = since >> Rel-8. >> Also the treatment of unknown PDP/PDN type can be different from SGSN = and >> S4-SGSN. >=20 > That is a good clarification. We would add that in the next update. >=20 >>>> I know such exist(ed) but how common are those on live today? >>>=20 >>> When we do IPv6 trials, we have to upgrade all SGSN to understand = PDP >>> Type IPv4v6. I also had some discussions with other operator >>> colleague. They also have same issues. >>=20 >> I was talking about IPv4 _only_ SGSNs. Those were around and are = still >> possible e.g. due licensing/configuration.. not that it would make = any >> sense to have an IPv4-only SGSN around.. >>=20 >>>> "land to retrieve the subscriber profile. Roaming with IPv4v6 type = in >>>> the subscriber profile may cause issues because the visited = SGSN/SGW >>>> can't parse the information. The subscriber is failed to register = in >>>> this case." >>>>=20 >>>> I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 = would >>>> be kind of surprising. I have seen a MME that did not implement = IPv4v6 >>>> very >>>> early of rel-8 testing phase, though. >>>=20 >>> If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs = introduces >>> IPv4v6 since Release-9. You may be right it's a rare case if SGW >>=20 >> Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since >> Rel-8. >=20 > Thanks for the correction. >=20 >=20 >>> doesn't implement IPv4v6. The failure cases we are facing are mainly >>> on SGSN. SGW is listed just because the rel-8 SGW implementations. >>> Thank you for the information there is no such case in the real = world. >>> We will update the draft with your comments accordingly. >>>=20 >>>> Here I would like to see text >>>> describing what is the actual failure scenario when the subscriber = gets >>>> no connection at all. I know one SGSN+HLR combination which is very >>>> unlikely to happen in commercial networks. >>>=20 >>> The failure scenario is subscriber can't register to the visited >>> network. Would you mind to add something to help me understand = what's >>> your expected texts here? >>=20 >> Just list exactly what is configured in HLR, supported by SGSN and = GGSN, >> configured in GGSN and what the UE requests for. The combination and = the >> description why the combination fails is what people are interested = in, >> IMHO. >=20 > We would try to figure out the combination. >=20 >=20 >> For the completeness, I would also like to see some discussion on the >> DAF flag configuration in SGSN/MME, which also affects the context >> creation end result. >=20 > Good. We will add it >=20 > Best Regards >=20 > Gang >=20 >>=20 >>>>=20 >>>> In Section 3.2. it states: >>>>=20 >>>> "of single IP version in order to achieve equivalent results. Some >>>> operators may turn off the function only allow one PDP/PDN is = alive >>>> for each subscriber. For example, IPv6 PDP/PDN would be rejected = if >>>> the subscriber has an active IPv4 PDP/PDN. Therefore, the = subscriber >>>> may lost IPv6 connection in the visited network. Even the two" >>>>=20 >>>> I am confused here. Are we assuming visited GGSN here? >>>=20 >>> Yes. The local breakout is considered here. >>>=20 >>>>=20 >>>> In Section 4.1. it states: >>>>=20 >>>> "requested protocol and always adhere to IPv4 when roaming. Those >>>> fallback mechanisms are deserved to be implemented and = standardized >>>> timely." >>>>=20 >>>> Does the standardization mean fallback mechanisms beyond what 3GPP >>>> already defined? >>>=20 >>> A proper fallback mechanism is not defined in 3GPP. The advocated >>> standardization more likes to do defacto standard. But the = suggestion >>> is align with cuurent 3GPP spec. And some implementations are >>> available. >>=20 >> Ok. >>=20 >> - JOuni >>=20 >>=20 >>>=20 >>> Best Regards >>>=20 >>> Gang >>>=20 >>>=20 >>>> - Jouni >>>>=20 >>>> On Jul 15, 2013, at 6:28 PM, GangChen wrote: >>>>=20 >>>>> 2013/7/15, Jouni Korhonen : >>>>>>=20 >>>>>> Gang, >>>>>>=20 >>>>>> Regarding roaming in general, have you looked at what GSMA is = doing >>>>>> on this front? I was kind of expecting at least a reference to = some >>>>>> GSMA document since they are quite important when it comes to = 3GPP >>>>>> based networks & roaming. >>>>>=20 >>>>> I guess GSMA IR.21 could be cited here. >>>>> http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf >>>>> Most failures cases are occurred if a roaming partner's IR.21 only >>>>> states v4 support >>>>>=20 >>>>> -g >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> - Jouni >>>>>>=20 >>>>>>=20 >>>>>> On Jul 15, 2013, at 5:56 AM, GangChen wrote: >>>>>>=20 >>>>>>> Hi Alexis, >>>>>>>=20 >>>>>>> Thanks for the interests. We are experiencing the issues = recently >>>>>>> when >>>>>>> IPv6 is tested/deployed. For the goal of the draft, it reports = that >>>>>>> to >>>>>>> the community and hopes to mature IPv6 supports either by = encouraging >>>>>>> proper implementations on mobile terminals or completing global >>>>>>> roaming contracts. >>>>>>>=20 >>>>>>> Your reviews/comments are appreciated >>>>>>>=20 >>>>>>> BRs >>>>>>>=20 >>>>>>> Gang >>>>>>>=20 >>>>>>> 2013/7/9, Alexis Munoz (Gmail) : >>>>>>>> It looks so interesting. I will check it and I will give you my >>>>>>>> comments >>>>>>>> very soon. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Alexis Mu=F1oz >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >>>>>>>> Behalf >>>>>>>> Of >>>>>>>> fred@cisco.com >>>>>>>> Sent: Tuesday, July 09, 2013 7:45 AM >>>>>>>> To: v6ops@ietf.org >>>>>>>> Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org >>>>>>>> Subject: [v6ops] new draft: = draft-chen-v6ops-ipv6-roaming-analysis >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A new draft has been posted, at >>>>>>>> = http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>>>>> Please >>>>>>>> take a look at it and comment. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From cb.list6@gmail.com Sun Jul 21 16:58:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8BB21F9C7A for ; Sun, 21 Jul 2013 16:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 s-c8dXkkh3Yx for ; Sun, 21 Jul 2013 16:58:07 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 994C721F9B8C for ; Sun, 21 Jul 2013 16:58:07 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so968272wes.18 for ; Sun, 21 Jul 2013 16:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T0gWEQpDc0rTAO+NZb6fQa7is0WfwewuAHKUy87c8Eo=; b=RhUt+2TqyiSfMEEugFXlzB2siY+nfvnVxEhDlAl5bSVDoq0vBDtxlZ6bk49Z7Vd1Yt VSewz0V+uiWma0PaVzqEi9g/J6OPawlkd+Gj7VIDxRKSFpZQYIPhFu11QugZYJrMgwEa az5Nzc4ThdQrg1sWm49Z6HmDd9beAmVumfzMEOo/0g+HKLKHHghSgkAi8EoYikfo7wf7 hSGK1eJc7E3OaIi3xxisGWGE8ZtqqkDdukhpuAbSRea3aTDf9J3jMAXmpulCXvz9YCil Pl5xbxcc8kHk4ca6ukLVg072hTw4qFKKxgL/d/DctgN0RFfnpaFG6gALQv5wY+11cuQc 4NOw== MIME-Version: 1.0 X-Received: by 10.180.185.84 with SMTP id fa20mr28291291wic.49.1374451085525; Sun, 21 Jul 2013 16:58:05 -0700 (PDT) Received: by 10.216.15.6 with HTTP; Sun, 21 Jul 2013 16:58:05 -0700 (PDT) In-Reply-To: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> References: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> Date: Sun, 21 Jul 2013 16:58:05 -0700 Message-ID: From: "cb.list6" To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: Re: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 23:58:08 -0000 I thought this was a pretty interesting draft from the 464XLAT perspective, so i made a Chrome browser extension implementation, described here https://sites.google.com/site/tmoipv6/home I believe this I-D has a bug that must be noted. Changing the URL (swapping the DNS name or adding in a Pref64) frequently breaks the connections since the application is aware of the name it expects, and connecting correctly to the correct IP address is not sufficient, the name must also be the same in many cases. For example, many websites use the Apache VirtualHost concept http://httpd.apache.org/docs/current/vhosts/examples.html If the FQDN / URL / service name is changed, then the VirtualHost will not work as intended. For example, there is a diagnostic website http://dual.tlund.se/ Going to the IPv4 literal address displays the same result as going to the FQDN, i presume the admin of the box has configured VirtualHost for each of the defined diagnostic methods. But, going to the ipv4 translated address does not work, it displays a different page that likely does not match a VirtualHost http://[2001:67c:27e4:641::c10f:e4c3]/... but it is certainly the same server with the same ipv4 address. That said, in many cases, this function will work, like providing ipv6-only access to ipv4-literal using internet radio stations like http://radio.djbillman.com/ (blocking access to this radio station is actually a feature of ipv6, but if you choose to disable that feature at your own risk ....) Cameron On Wed, Jul 10, 2013 at 5:45 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From holger.metschulat@telekom.de Tue Jul 23 08:23:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4954E21E80C4 for ; Tue, 23 Jul 2013 08:23:56 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 n-MvNO6avtiY for ; Tue, 23 Jul 2013 08:23:48 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 09D4B11E826D for ; Tue, 23 Jul 2013 08:23:47 -0700 (PDT) From: Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 23 Jul 2013 17:23:46 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Jul 2013 17:23:46 +0200 To: Date: Tue, 23 Jul 2013 17:23:45 +0200 Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac58okTX8ARp+FoqSZGxKdUBdjK9rQLFLFtw Message-ID: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> In-Reply-To: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:23:56 -0000 Hi all, this is an interesting document that will help in the introduction of IPv6 = and the combination of IPv4/IPv6 into mobile networks, however, I believe i= t needs a bit of evolution... 1. Can you distinguish between IP local breakout and home routed traffic, b= ecause there is a significant difference on what the visited network must s= upport? 2. GSMA's IR.21 should be taken into account as well. 3. For home routed traffic, the visited network, and also the home network,= have influence on the PDP context types that are successfully established,= or that are rejected. Could this be described as well? Should this document only enumerate "things that went wrong and lessons lea= rnt", or should it go through all possible combinations of a roaming situat= ion and provide information what does work and what does not work? Holger= From nygren@gmail.com Tue Jul 23 15:53:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7911E8169 for ; Tue, 23 Jul 2013 15:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, 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 dI76jpeqJVDf for ; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA211E8166 for ; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so12871372oag.9 for ; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=18Acgljq063OvidSPKRlmTeRuhG872kfdC/5Pu0gl5E=; b=z1m9qKGX84830zVHZZP3pIImif6Otnloe5Wk8TXk7aMo8MIPxCAXsnitk3fBYqw/vM jX4ecnac7hBkBZ2ByGw5eVvr5VsB8r6lGALQhu6/Nyy9aoTS03KqDxKRcSbsU6+hQ0v0 A1M2i7J8+wGtjKpOEzmd7M07XXeGzDxNN8voOO41Far0n+nmqF3HQxoEMzUpvw7eGvBJ PbOa8eK36PGLU37i4/90CfZiKxpD981pctQ/0TNkwvFMNh1tca6GAjdB+WFHAVPNZDlM NktnoJk3+K2gLK01W6i1LVIYo59e1kp9DhoA8JSz/osyDikTxDEc46ZiLx3dugfqt2NG TB6A== MIME-Version: 1.0 X-Received: by 10.43.152.78 with SMTP id kv14mr19249350icc.15.1374619997295; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.43.165.133 with HTTP; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) Received: by 10.43.165.133 with HTTP; Tue, 23 Jul 2013 15:53:17 -0700 (PDT) In-Reply-To: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> References: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> Date: Tue, 23 Jul 2013 18:53:17 -0400 X-Google-Sender-Auth: Wdn6DWFl4Mwy78ppYiknEAM7Oq8 Message-ID: From: Erik Nygren To: "Fred Baker, (fred)" Content-Type: multipart/alternative; boundary=001a11c30a84a3dc7504e235a88d X-Mailman-Approved-At: Tue, 23 Jul 2013 23:39:46 -0700 Cc: v6ops@ietf.org, draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: Re: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 22:53:18 -0000 --001a11c30a84a3dc7504e235a88d Content-Type: text/plain; charset=ISO-8859-1 Should we consider reversing the octets, such as is done for inaddr.arpa? There might be cases where being able to delegate off or subzone some prefixes could be useful? For example, 10.2.0.192.TLD rather than 192.0.2.10.TLD ? We should also consider the HTTP security considerations for the cases where someone puts one of the names into a URL. For example, consider http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain "*.10.TLD". There are likely already plenty of ways to do the same thing out there, so this may not be a major issue. Erik Sent from my mobile device On Jul 10, 2013 8:45 AM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c30a84a3dc7504e235a88d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Should we consider reversing the octets, such as is done for= inaddr.arpa?=A0 There might be cases where being able to delegate off or s= ubzone some prefixes could be useful?=A0 For example, 10.2.0.192.TLD rather= than 192.0.2.10.TLD ?

We should also consider the HTTP security considerations for= the cases where someone puts one of the names into a URL.=A0 For example, = consider http://192.0.2.10.TLD/ to a= n origin that sets a cookie on the domain "*.10.TLD".=A0 There ar= e likely already plenty of ways to do the same thing out there, so this may= not be a major issue.

=A0=A0=A0=A0=A0=A0=A0 Erik

Sent from my mobile device

On Jul 10, 2013 8:45 AM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/h= tml/draft-osamu-v6ops-ipv4-literal-in-url. Please take a look at it and= comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a11c30a84a3dc7504e235a88d-- From osamu@wide.ad.jp Tue Jul 23 19:04:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3C311E81B6 for ; Tue, 23 Jul 2013 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NORMAL_HTTP_TO_IP=0.001, 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 hQd-Pf7rnmlP for ; Tue, 23 Jul 2013 19:04:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B011E81B5 for ; Tue, 23 Jul 2013 19:04:38 -0700 (PDT) Received: from [IPv6:2001:200::8890:cdf0:eb40:b0ba:4679] (unknown [IPv6:2001:200:0:8890:cdf0:eb40:b0ba:4679]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0B86A2780A8; Wed, 24 Jul 2013 11:04:36 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_77057606-9D6C-4EB6-9899-CD752788F42E" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-2022-jp?B?GyRCQ2ZCPBsoQiAbJEI9JBsoQg==?= In-Reply-To: Date: Wed, 24 Jul 2013 11:04:38 +0900 Message-Id: <9CD31A48-A85C-444E-9D98-5AD63955EF4C@wide.ad.jp> References: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> To: Erik Nygren X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 23 Jul 2013 23:39:46 -0700 Cc: v6ops@ietf.org, draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: Re: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 02:04:40 -0000 --Apple-Mail=_77057606-9D6C-4EB6-9899-CD752788F42E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, Thank you for comments ! We discussed about reverse notation internally.=20 But we could not find reasonable meaning of reverse notation for this = purpose.=20 For example, inaddr.arapa, reverse host entry should be maintained by IP = address delegated organization.=09 So reverse notation is much for IP address delegation. In our proposed method, conversion of literal IP address with TLD to = IPv6 address with NAT prefix done by local DNS64. So there is not reason for reverse notation. Osamu =20 On 2013/07/24, at 7:53, Erik Nygren wrote: > Should we consider reversing the octets, such as is done for = inaddr.arpa? There might be cases where being able to delegate off or = subzone some prefixes could be useful? For example, 10.2.0.192.TLD = rather than 192.0.2.10.TLD ? >=20 > We should also consider the HTTP security considerations for the cases = where someone puts one of the names into a URL. For example, consider = http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain = "*.10.TLD". There are likely already plenty of ways to do the same = thing out there, so this may not be a major issue. >=20 > Erik >=20 > Sent from my mobile device >=20 > On Jul 10, 2013 8:45 AM, wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please = take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_77057606-9D6C-4EB6-9899-CD752788F42E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 =
So reverse notation is much for IP address = delegation.
In our proposed method, conversion of =  literal IP address with TLD to IPv6 address with NAT prefix done = by
local DNS64. So there is not reason for reverse = notation.

= Osamu
    
On = 2013/07/24, at 7:53, Erik Nygren <erik@nygren.org> wrote:

Should we consider reversing the octets, such as is done for = inaddr.arpa?  There might be cases where being able to delegate off = or subzone some prefixes could be useful?  For example, = 10.2.0.192.TLD rather than 192.0.2.10.TLD ?

We should = also consider the HTTP security considerations for the cases where = someone puts one of the names into a URL.  For example, consider http://192.0.2.10.TLD/ to an origin = that sets a cookie on the domain "*.10.TLD".  There are likely = already plenty of ways to do the same thing out there, so this may not = be a major issue.

        Erik

Sent from my mobile device

On Jul 10, 2013 8:45 AM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-litera= l-in-url. Please take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_77057606-9D6C-4EB6-9899-CD752788F42E-- From phdgang@gmail.com Wed Jul 24 04:24:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB61811E8203 for ; Wed, 24 Jul 2013 04:24:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khm6Rjt99LOI for ; Wed, 24 Jul 2013 04:24:39 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DAC9F11E8200 for ; Wed, 24 Jul 2013 04:24:38 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id k14so168431qcv.20 for ; Wed, 24 Jul 2013 04:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FKVR91pcfHO+w3PBjmHNkQ+4sBNoHxWWBdaTfRSQjrA=; b=jB7LgDWC7b5hNtu+etkArRRqk4dnzRHL7MXC0k+IV5AcIfXtatDqwpgaHLwA+dSRnX JDJ2iucOIj1pgwc/Jyrvt39WFQ9WUZdHEDctV0DYY23PlQAbk3/THpX5yqSyAm42dsdt kSgbx4/1aOCS1vSKr9469e2+xBVGlEseCVVjkVzXODrrKpZzjulGt9D0MspN+DRUNh7k SzVwPQPslMO57g3gc8qPylP3vcmdZakwrNEjQsWe3BmTQAADRcAnKBuBIi/kqOJuN3zF xaHeN9LI1myenhLggPGZ2QDJklRp2U/Eh8YG09jac7Ly0u825AmrcZvFxKCFLC58GuRz DULw== MIME-Version: 1.0 X-Received: by 10.224.75.133 with SMTP id y5mr16511887qaj.72.1374665078374; Wed, 24 Jul 2013 04:24:38 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Wed, 24 Jul 2013 04:24:38 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Wed, 24 Jul 2013 19:24:38 +0800 Message-ID: From: GangChen To: holger.metschulat@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:24:39 -0000 Hi Holger, 2013/7/23, holger.metschulat@telekom.de : > Hi all, > > this is an interesting document that will help in the introduction of IPv6 > and the combination of IPv4/IPv6 into mobile networks, however, I believe it > needs a bit of evolution... Thanks for your interests. The evolution would be made according to discussions on the list. > 1. Can you distinguish between IP local breakout and home routed traffic, > because there is a significant difference on what the visited network must > support? We realized the importance to differentiate those two cases. Yes. It will be distinguished. > 2. GSMA's IR.21 should be taken into account as well. It will be cited > 3. For home routed traffic, the visited network, and also the home network, > have influence on the PDP context types that are successfully established, > or that are rejected. Could this be described as well? Yes. As suggested by Jouni, the combination of HLR configuration, UE PDP context requests and visited network supported will be described in the next update. > Should this document only enumerate "things that went wrong and lessons > learnt", or should it go through all possible combinations of a roaming > situation and provide information what does work and what does not work? The original draft is trying to circulate all the possible roaming cases, and, make a detailed description/analysis to the failure cases. The audience could check with their own conditions. We would also like to hear the group's opinions. The wg inputs are most important to the document's evolution. Best Regards Gang > Holger From peter.vickers@gmail.com Thu Jul 25 00:18:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3421F9A0C for ; Thu, 25 Jul 2013 00:18:13 -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 TLdNWDDUv1UX for ; Thu, 25 Jul 2013 00:18:13 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B64E021F88FE for ; Thu, 25 Jul 2013 00:18:12 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id fs13so1075013lab.2 for ; Thu, 25 Jul 2013 00:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=akuIQYtE41ULO6B00Ou+XumLicryKN7X+gggFIPuQcw=; b=j2yPKCVjdwTQBobQ5iyZyrLJwrbymXRqlCa6YyEwvVcbjX0hqtjSAu0PM6gvs8rBW2 Nc3scdfd10cOLUpsNu7Vp/K/oLWFnvocBntcCuKY6cmDZr9UOAp5TMTMvjxh2AxSztLO KZ3xE7Am41dpf3qIijZ2Fv89TZ24cumLB5hhC+ggAbb1zYA7wkyRqPg/wEDXIXh52vWf 8rYdB0BuXx8DhyhHNOu/l/4Pc+EYs4fEcsPl03tcohMZPyLQvi5aAjcJnXSQPIySgu4h qQuKrtXq4e4VzOh3ycXJdOLmgQT+jeQT+zmvMPchG55vOPI1zI/5iudOb/fCdNs/H6bZ gLTw== X-Received: by 10.112.72.67 with SMTP id b3mr17807412lbv.35.1374736691652; Thu, 25 Jul 2013 00:18:11 -0700 (PDT) Received: from [193.22.250.14] ([193.22.250.14]) by mx.google.com with ESMTPSA id q6sm15848221lbv.14.2013.07.25.00.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 00:18:10 -0700 (PDT) From: Pete Vickers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jul 2013 09:18:09 +0200 Message-Id: To: "v6ops@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 25 Jul 2013 08:02:43 -0700 Subject: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis (GangChen) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:19:29 -0000 Some minor typos & comments on your doc: 2. Roaming Descriptions dual-tack -> dual-stack That are -> They are equipments -> equipment restored -> stored different IPv6 supports -> different IPv6 support The following is like to document the failure cases -> The following are = likely failure cases scenarios (?) 3.2. Roaming to early dual-stack networks A roaming subscriber with IPv4v6 PDP/ PDN type should change the request to two separated PDP/PDN messages of single IP version in order to achieve equivalent results. Some operators may turn off the function only allow one PDP/PDN is alive for each subscriber.=20 This is also likely to fail in more subtle ways, e.g. a visited network = commonly permits two concurrent PDP, since it is usual for MMS (picture = messaging) services to be accessed via a seperate APN to Internet = services. Thus if both available PDPs are in use for IPv4+IPv6 Internet = access, then attempts to send/recieve picture messages would (silently?) = fail due to lack of PDP resourses.=20 Therefore, the subscriber may lost -> lose IPv6 connection in the = visited network Even /if/ the two parallel PDP/PDN activations are allowed 4.1. Roaming to IPv4-only networks Those fallback mechanisms 'are deserved' -> 'deserve' to be implemented = and standardized 5. Discussions but didn't support /it/ well in the third generation network. The situations may cause the roaming issues/,/ dropping As an alternative solution for dual-stack, operators may change a unified PDP/PDN request into two separated single IP version requests. However, this approach is problematic in the Charging records and QoS policy enforcement. In addition, it doubles the PDP resource uses. It may be unappealing for the deployment. I think you should also add 'licensing costs' to the point about = additional PDP resource usage - that is a very significant issues in = many operators. There are also several other failure senarios, for example where the = visited operator has a 'Gp' (GRX border) GTP aware firewall, and this = (by design or inappropriate configuration) filters out GTP traffic = containing certain flavours of IPv6 PDP requests/responses. It may thus = be approriate to mention that connectivity/security devices can also = cause IPv6 related roaming issues. I agree with the comment about IR.21 - the purpose of that document (and = the IREG testing procedure that reference it) is to ensure that such = issues are identified and corrected such that roaming is seamless. As = Deng commented to me on Google's mobile-ipv6-networks group several = months ago, the IR.21 appears overdue an update. However I note that = IR.88 is the equivalent for LTE/EPC environments, so perhaps that is = more appropriate ? /Pete From dwing@cisco.com Thu Jul 25 17:15:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DACB21F8F32 for ; Thu, 25 Jul 2013 17:15:06 -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 ZWvjVR1mwVaZ for ; Thu, 25 Jul 2013 17:15:02 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFE21F88FE for ; Thu, 25 Jul 2013 17:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2444; q=dns/txt; s=iport; t=1374797701; x=1376007301; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=02O+aIRnousQEdCQQYZEQmi0BbvX0bWwT77G0axC+Zs=; b=hC8GEvz9IfkBHLL4ryv179xzhbWKm994oijA6aQjNn+3icwMOp39mmtI K0eHRLaQDszuWAnanB+w8TvbgtVDghnTtwSwG7mhjPYqIW2yqP0gcU9X3 Bn4KuMzmt04f+DesHLS+C+pO+CFkQBM4s52ldTzV6N6Smb7mgdS4ki60V U=; X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="84220166" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 26 Jul 2013 00:15:01 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q0F0JA008426; Fri, 26 Jul 2013 00:15:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 25 Jul 2013 17:15:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C1B18E8-E824-4407-8DFA-4D191E33FBB7@cisco.com> References: <201307101245.r6ACj0B14006@ftpeng-update.cisco.com> To: "cb.list6" X-Mailer: Apple Mail (2.1508) Cc: IPv6 Ops WG , draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: Re: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 00:15:06 -0000 On Jul 21, 2013, at 4:58 PM, cb.list6 wrote: > I thought this was a pretty interesting draft from the 464XLAT > perspective, so i made a Chrome browser extension implementation, > described here https://sites.google.com/site/tmoipv6/home >=20 > I believe this I-D has a bug that must be noted. Changing the URL > (swapping the DNS name or adding in a Pref64) frequently breaks the > connections since the application is aware of the name it expects, and > connecting correctly to the correct IP address is not sufficient, the > name must also be the same in many cases. >=20 > For example, many websites use the Apache VirtualHost concept > http://httpd.apache.org/docs/current/vhosts/examples.html >=20 > If the FQDN / URL / service name is changed, then the VirtualHost > will not work as intended. A similar problem occurs with HTTPS when the client validates the = certificate. I have never seen a certificate that used an IPv4 address = in the subjectAltName, but I am told they do exist within enterprise = networks. -d >=20 > For example, there is a diagnostic website http://dual.tlund.se/ >=20 > Going to the IPv4 literal address displays the same result as going to > the FQDN, i presume the admin of the box has configured VirtualHost > for each of the defined diagnostic methods. >=20 > But, going to the ipv4 translated address does not work, it displays a > different page that likely does not match a VirtualHost > http://[2001:67c:27e4:641::c10f:e4c3]/... but it is certainly the same > server with the same ipv4 address. >=20 > That said, in many cases, this function will work, like providing > ipv6-only access to ipv4-literal using internet radio stations like > http://radio.djbillman.com/ (blocking access to this radio station is > actually a feature of ipv6, but if you choose to disable that feature > at your own risk ....) >=20 > Cameron >=20 > On Wed, Jul 10, 2013 at 5:45 AM, wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please = take a look at it and comment. >> _______________________________________________ >> 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 phdgang@gmail.com Fri Jul 26 23:00:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EB621F9D3A for ; Fri, 26 Jul 2013 23:00:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbmyXmIf5KWm for ; Fri, 26 Jul 2013 23:00:31 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 45BB921F9D2C for ; Fri, 26 Jul 2013 23:00:31 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f14so776248qak.16 for ; Fri, 26 Jul 2013 23:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZoS12uMWSxX3QmM3c8lijoX4THintveum6tSmr3DKrc=; b=H2v0KtV4s3HJLsiz3iSl/7rIsrDxllyydXo7hfla6TzzASOxAY0KuydfbXI+5jB9MQ ijD4sODi+BReaUvabQSNq7LcqtVvE4uiO//aG0Hd8QaKhzszPe/mW+PLCi7laI/APU4w FIw4vSfRrJC6/EDetKHew8Fa62koIp+siZRir3E17lVMth51cEp3oRmiG1YOMHCEnCXu T4l4lx1W6h1Azj6rCErhbTdwAMmsqdypmgeXOPiBee3vYwWrPPJi75We+Ge+xVXFJ0oO r9CO9+ZF9KIB2J6mRq9FbL67WS2ZUddvzGfc0l6oaYRADBNckSwpRxSlgzlA0DgWjIny i2MQ== MIME-Version: 1.0 X-Received: by 10.224.98.198 with SMTP id r6mr25045771qan.103.1374904830719; Fri, 26 Jul 2013 23:00:30 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Fri, 26 Jul 2013 23:00:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 14:00:30 +0800 Message-ID: From: GangChen To: Pete Vickers Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis (GangChen) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jul 2013 06:00:32 -0000 Hi Pete, Thank you for the times to review. Sorry for the delay (I'm being the trip to IETF meeting) 2013/7/25, Pete Vickers : > Some minor typos & comments on your doc: > > 2. Roaming Descriptions > dual-tack -> dual-stack > That are -> They are > equipments -> equipment > restored -> stored > different IPv6 supports -> different IPv6 support > The following is like to document the failure cases -> The following are > likely failure cases scenarios (?) I will fix those in the next update > > 3.2. Roaming to early dual-stack networks > A roaming subscriber with IPv4v6 PDP/ > PDN type should change the request to two separated PDP/PDN messages > of single IP version in order to achieve equivalent results. Some > operators may turn off the function only allow one PDP/PDN is alive > for each subscriber. > > This is also likely to fail in more subtle ways, e.g. a visited network > commonly permits two concurrent PDP, since it is usual for MMS (picture > messaging) services to be accessed via a seperate APN to Internet services. > Thus if both available PDPs are in use for IPv4+IPv6 Internet access, then > attempts to send/recieve picture messages would (silently?) fail due to lack > of PDP resourses. > Your case seems assuming only two PDP activation are allowed for each subscriber. I'm not sure that is a common case. It may be different with my experience. Multiple PDPs are allowed to be activated if a subscriber intends to access separated APNs. > Therefore, the subscriber may lost -> lose IPv6 connection in the visited > network > Even /if/ the two parallel PDP/PDN activations are allowed I guess it may be worth to list your consumption, for example "in some cases a subscriber only allowed to activate two PDP contexts, ..." > > 4.1. Roaming to IPv4-only networks > Those fallback mechanisms 'are deserved' -> 'deserve' to be implemented and > standardized > > > > 5. Discussions > but didn't support /it/ well in the third generation network. > The situations may cause the roaming issues/,/ dropping > > > As an alternative solution for dual-stack, operators may change a > unified PDP/PDN request into two separated single IP version > requests. However, this approach is problematic in the Charging > records and QoS policy enforcement. In addition, it doubles the PDP > resource uses. It may be unappealing for the deployment. > > I think you should also add 'licensing costs' to the point about additional > PDP resource usage - that is a very significant issues in many operators. > Good. I will add it. > > There are also several other failure senarios, for example where the visited > operator has a 'Gp' (GRX border) GTP aware firewall, and this (by design or > inappropriate configuration) filters out GTP traffic containing certain > flavours of IPv6 PDP requests/responses. It may thus be approriate to > mention that connectivity/security devices can also cause IPv6 related > roaming issues. Thanks for sharing your experiences. That may be caused by incorrect configurations on the firewall. I will add the suggestion to avoid the issue. > > I agree with the comment about IR.21 - the purpose of that document (and the > IREG testing procedure that reference it) is to ensure that such issues are > identified and corrected such that roaming is seamless. As Deng commented to > me on Google's mobile-ipv6-networks group several months ago, the IR.21 > appears overdue an update. However I note that IR.88 is the equivalent for > LTE/EPC environments, so perhaps that is more appropriate ? > IR.88 didn't deprecate the IR.21. They cover different areas. IR.88 cited IR.21 as a reference for roaming database configuration. I would include both for a complete view. Best Regards Gang > > /Pete > > > > > From aservin@lacnic.net Sat Jul 27 01:38:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B9421F9C6F for ; Sat, 27 Jul 2013 01:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 Wp+ddTN90Kgn for ; Sat, 27 Jul 2013 01:38:50 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1421F9C90 for ; Sat, 27 Jul 2013 01:38:50 -0700 (PDT) Received: from ef-09.conference.fu-berlin.de (ef-09.conference.fu-berlin.de [160.45.239.9]) by mail.lacnic.net.uy (Postfix) with ESMTP id CBF853084A1; Sat, 27 Jul 2013 05:38:23 -0300 (UYT) Message-ID: <51F38710.2070700@lacnic.net> Date: Sat, 27 Jul 2013 04:38:40 -0400 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Diego R. Lopez" References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <51E3E1E0.9090203@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jul 2013 08:38:55 -0000 Diego, Thanks for the information. We will read it and include it in the draft. Regards, as On 7/15/13 8:07 PM, Diego R. Lopez wrote: > Hi Arturo, > > On 15 Jul 2013, at 13:49 , Arturo Servin wrote: >>> >>> 1) The usage of SDN (OpenFlow in particular) as an alternative technique, probably under 2.3 >> I have never thought about it but it seems plausible. Do you have a >> reference, perhaps some previous work about this topic? > > A couple of them I have used elsewhere: > https://www.usenix.org/legacy/event/inmwren10/tech/full_papers/Ballard.pdf > > http://sharkfest.wireshark.org/sharkfest.12/presentations/A-4_Leveraging_Openflow_to_create_a_Large_Scale_and_Cost_Effective_Packet_Capture_Network.pdf > > I can send you some information on our Deeper system, that leverages OpenFlow for a cloud-based DPI... > >>> And there is always the matter of cross-provider or federated monitoring, that I'd say is not that close even in v4 space, and that probably would deserve some discussion as well... >> >> I'll ask some operators that I know have virtual services how they >> do it, but if you have some pointers or references would be very great > > The references I have are related to the outcomes of the ETICS project, in which I have participated. A short intro to the monitoring issues can be found here: https://bscw.ict-etics.eu/pub/bscw.cgi/d44518/IndustrialWorkshop_Demo-NMON.pdf > > And a more detailed info can be found at https://bscw.ict-etics.eu/pub/bscw.cgi/d47594/D4.4_Final.pdf (pages 90 to 101, essentially) > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > From aservin@lacnic.net Sat Jul 27 01:40:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF2821F9DC6 for ; Sat, 27 Jul 2013 01:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 xftezj19TLVr for ; Sat, 27 Jul 2013 01:40:21 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5556321F9DC7 for ; Sat, 27 Jul 2013 01:40:20 -0700 (PDT) Received: from ef-09.conference.fu-berlin.de (ef-09.conference.fu-berlin.de [160.45.239.9]) by mail.lacnic.net.uy (Postfix) with ESMTP id 35ABF3084BA; Sat, 27 Jul 2013 05:39:58 -0300 (UYT) Message-ID: <51F38772.6020004@lacnic.net> Date: Sat, 27 Jul 2013 04:40:18 -0400 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "George, Wes" References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <2671C6CDFBB59E47B64C10B3E0BD59230438E30376@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230438E30376@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jul 2013 08:40:25 -0000 Wes, Thank you for the review. We will include your comments in the next version of the draft. Thanks as On 7/17/13 2:39 PM, George, Wes wrote: > This is a useful draft. > > I've been doing some IPv6-only testing of websites listed in the world v6 launch participants, and found a lot of supposedly IPv6-capable sites that aren't fully functional over IPv6-only because some portion of them are still reliant on IPv4-only content/CDNs for images, CSS, subdomains, etc. Worse, I've found sites that simply aren't working over IPv6 anymore, and the operator of the site is unaware. This would be quite obvious if the site maintainers were completing their unit testing and monitoring over single-stack IPv6, but may well be masked by happy eyeballs if done dual-stack, so this draft will help to publicize this problem. > > A few comments on the draft itself: > > Section 2.1 and 6- an explicit recommendation to vendors that they SHOULD support use of IPv6 for all transport (RFC 6540) of monitoring, provisioning, and management data might be useful here. This is an area where vendors often lag because they've been focused on enabling support for IPv6 through the box, but it's becoming increasingly important for operators trying to conserve IPv4 addresses for end-customer use. > > For completeness, you may want to briefly discuss NTP, Syslog, ssh, and other OAM-type traffic somewhere in section 2. > > There is also a draft in progress in MPLS dealing with IPv6-only operation of MPLS networks (draft-george-mpls-ipv6-only-gap) that may contain some things relevant to this draft since it covers some of the aspects of OAM for MPLS networks. > > Another consideration for this draft might be a recommendation to transition to single-stack (IPv6) as rapidly as possible for any tools that do not need to explicitly verify IPv4 operation. In other words, things like flow data transport, SSH, etc might be able to operate only over IPv6, while SNMP polls, HTTP tests, etc would need to remain dual stack so that they can verify IPv4 is working properly. Since dual-stack support means duplicating a lot of operations complexity (filters, troubleshooting path problems, monitoring configuration, etc), eliminating the need to support both IPv4 and IPv6 for as much management traffic as possible potentially allows for simplification of configuration, reclamation of addresses, etc. > > Thanks, > > Wes George > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Arturo Servin >> Sent: Saturday, July 13, 2013 9:46 AM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 >> >> Hi, >> >> We have sent this draft about considerations and recommendations to >> monitor IPv6 and dual-stack networks and services. We have been talking >> with people deploying IPv6 and we have found that not all monitor their >> networks and not many monitor them properly. We also found some >> challenges in monitor implementations that not fully support IPv6 >> monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even >> though monitoring v6 networks is as critical as doing it in v4, we have >> not found many documents explaining how that has to be done (at least >> guides with free access or up to date). >> >> There are also some misconceptions about monitoring IPv6, for >> example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and >> send them on IPv4 that we wanted to clarify. >> >> We collected some recommendations from informal conversations with >> people during some training and NOGs meeting during this year but we >> need some more input. We will be sharing this draft with other forums to >> get more inputs but we wanted to share it here first. >> >> Best wishes, >> Arturo and Mariela >> >> On 7/13/13 9:45 AM, fred@cisco.com wrote: >>> A new draft has been posted, at http://tools.ietf.org/html/draft- >> servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment. > > Anything below this line has been added by my company's mail server, I have no control over it. > ----------------- > > 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 peter.vickers@gmail.com Sun Jul 28 02:15:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFD321F9D6F for ; Sun, 28 Jul 2013 02:15:19 -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 DHS1e77wT4Ej for ; Sun, 28 Jul 2013 02:15:19 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 935A121F9D8A for ; Sun, 28 Jul 2013 02:15:13 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so2361681eak.4 for ; Sun, 28 Jul 2013 02:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=J0nmNBjGa1NP/PtDPcjqiVlG0w7uBqxlqqBuy1Hzlhw=; b=mTBKRALK0/hbrIlZmIYweM94+Oy51bRihKUaOcqeMBboVcSh4wCJ2O/Agb8wRdgqat I6XR1h43eD3y2m5bPwJg7K8SsHjbJBEJCm9AFmgfiKYvOd7LED/tHXGz2PxwQqsHTW4E HA0AWjhyJClMaNkAlZ9QtM6iv+huwSCc4fZqIuRVaRzmSRp6Ewx6kBh4iRQDB2AIbuk1 kEe47V4ADIU2PBDCjO6DhFIp1+i2cl8tq9YUGsdQeGu12r0PIFO7mDX6qLTu3SC2mRsF nSg/ZEpurN/uLJRVdATSMigv7/wnjtwt3vlMGyI3E/84Uk9u5M9Uc2xVMjAlSEy9BHl8 9r5Q== X-Received: by 10.15.63.8 with SMTP id l8mr54619541eex.23.1375002912737; Sun, 28 Jul 2013 02:15:12 -0700 (PDT) Received: from [192.0.2.116] ([87.248.7.97]) by mx.google.com with ESMTPSA id j2sm17221602eep.6.2013.07.28.02.15.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 02:15:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Pete Vickers In-Reply-To: Date: Sun, 28 Jul 2013 11:15:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ABFBA5D-ABBB-4C9F-8F46-9FA59F11C339@gmail.com> References: To: GangChen X-Mailer: Apple Mail (2.1508) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis (GangChen) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 09:15:20 -0000 >=20 >=20 >>=20 >> 3.2. Roaming to early dual-stack networks >> A roaming subscriber with IPv4v6 PDP/ >> PDN type should change the request to two separated PDP/PDN messages >> of single IP version in order to achieve equivalent results. Some >> operators may turn off the function only allow one PDP/PDN is alive >> for each subscriber. >>=20 >> This is also likely to fail in more subtle ways, e.g. a visited = network >> commonly permits two concurrent PDP, since it is usual for MMS = (picture >> messaging) services to be accessed via a seperate APN to Internet = services. >> Thus if both available PDPs are in use for IPv4+IPv6 Internet access, = then >> attempts to send/recieve picture messages would (silently?) fail due = to lack >> of PDP resourses. >>=20 >=20 > Your case seems assuming only two PDP activation are allowed for each > subscriber. I'm not sure that is a common case. It may be different > with my experience. Multiple PDPs are allowed to be activated if a > subscriber intends to access separated APNs. >=20 Sorry for the lack of clarity, my intension was not to make any = assumption/example of common cases; instead it was an attempt to show = how the introduction of IPv6 services can 'break' other unrelated = services in non-obvious ways. > Best Regards >=20 > Gang >=20 >=20 >>=20 >> /Pete >>=20 >>=20 >>=20 >>=20 >>=20 From cb.list6@gmail.com Sun Jul 28 08:48:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA7521F8EC3 for ; Sun, 28 Jul 2013 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 WZHNeSY+YcMg for ; Sun, 28 Jul 2013 08:48:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8F21F8EB3 for ; Sun, 28 Jul 2013 08:48:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hr7so592111wib.12 for ; Sun, 28 Jul 2013 08:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lm88LrR8KlBfgTYzCtMNK8jY1IcHTLjwvJGvA9tAPBk=; b=j5nbIBPI9+XpBhuR9+rcKyLUDRd/xxo5/+/jL/7+tJ7zV8xfUNOOpkrv2tQnz/cT7n 6WObKxNsP3e2luBI7MPstLsHWRschBrCBY1eX9Bp8Sr8ps61u11suwp4ZY3YPM3k8DCO 443i5LoEzc4whx2RSeSH5Z9vTNGg2QeL2wc1OsxVU5VmU34CutB8HX3MaUdZ5lhf4cr7 y1lftaAWjrz/2JcTAoeskXbFeah1t3APt6eyo3RiZpvVM2BXuOER2w1ySnNTj60wdtxb 7q6ofNDsyW6tajC0hFFQkUBglcpWJpdeEG7r83EuLFZQdLTDXICUN6zmLFVi/qO80m3q 9vzA== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr41331563wjn.23.1375026491222; Sun, 28 Jul 2013 08:48:11 -0700 (PDT) Received: by 10.216.15.6 with HTTP; Sun, 28 Jul 2013 08:48:11 -0700 (PDT) In-Reply-To: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Sun, 28 Jul 2013 08:48:11 -0700 Message-ID: From: "cb.list6" To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:48:13 -0000 As general feedback 1. As others have noted, it is important to clarify that home routed is the default case and local-breakout is only relavent for IMS, but IMS based roaming and local breakout is yet to see its first deployment, and may still be years in the future for roaming to work this way. So, local breakout is not a real case and seems to be causing more confusion. 2. There is a hazard in assuming the well known prefix is always available. Any device should not assume the well known prefix is available. This is essentially a misconfiguration that should not occur. 3. What i have learned a. dual-stack 2 PDP will never work, charging issues in the billing system, and too much capacity wasted for no real gain b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling this feature in the HSS/HLR breaks roaming and there is no way to ensure this issue is fixed in the hundreds of networks that are potentially impacted. There are some backs to do on the home network that can make this easier but not exposing partner networks to the new release 8 features. c. What does work and adds value (saves IPv4 address for the common case of not-roaming) : IPv6-only single PDP 464XLAT on the home network, IPv4-only single PDP when roaming. This is how i am moving forward. The when at home, the UE has default configs for ipv6-only and when roaming the ue only attempts to connect using IPv4. This gets the vast majority of users in my home network off v4 and keeps ipv4 for the complicated yet relatively small percentage of roaming users. On Tue, Jul 9, 2013 at 5:45 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Sun Jul 28 11:23:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C8021F9406 for ; Sun, 28 Jul 2013 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 FVKtifS1Hj-Q for ; Sun, 28 Jul 2013 11:23:24 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0486621F8F2E for ; Sun, 28 Jul 2013 11:23:22 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id q19so1053324qeb.9 for ; Sun, 28 Jul 2013 11:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wDw4BLAUXHP97VIvR9hMCNi5IpRiQSW4AkZEeJJeS3g=; b=nkmxTRCN7Jxbul0uoUTgYt+6SWCF5xJSqP4lrD5BNsPWQdNozDu69VFl4hUf/vz7TQ pmybt64v2T7v9wCsGBjZAfWucUoN1hX9KtV2/WvLovE9SUdWLJvp2NnAItQHvPZv+DlB 7Djd+9+NOKvuoRHC8aN3058nGJq7teSgOIgpINN127+MbMYn4mQ7JfvTKq2g8Hz7VVuc NWyb9ekASU2BRDgTiJiMfy4fv8dUNdr4v1CsRRLoYoi9V5lA8WuJjGM94Op72p5Lev+P 45sCDmvez2V/Z0BYFRipSQ53hMiWO+2VZAbthPSxcNaeDEdcnpn8bFXzN7D23D0+yKkB XbQg== MIME-Version: 1.0 X-Received: by 10.49.117.165 with SMTP id kf5mr24756963qeb.9.1375035801421; Sun, 28 Jul 2013 11:23:21 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sun, 28 Jul 2013 11:23:21 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Mon, 29 Jul 2013 02:23:21 +0800 Message-ID: From: GangChen To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 18:23:25 -0000 Hi Cameron, Thank you for the comments. 2013/7/28, cb.list6 : > As general feedback > > 1. As others have noted, it is important to clarify that home routed > is the default case and local-breakout is only relavent for IMS, but local-breakout may not be only for IMS. We have deployed that for the data roaming between different province's networks in China. It offers efficient routes. Besides, 3GPP specified the SIPTO architecture for roaming. That may bring impacts in the future. > IMS based roaming and local breakout is yet to see its first > deployment, and may still be years in the future for roaming to work > this way. So, local breakout is not a real case and seems to be > causing more confusion. > > 2. There is a hazard in assuming the well known prefix is always > available. Any device should not assume the well known prefix is > available. This is essentially a misconfiguration that should not > occur. Ok. You don't recommend using WKP. How about taking different priority for the deployment High priority: nat64-discovery Medium: WKP Low: manual configuration > 3. What i have learned > > a. dual-stack 2 PDP will never work, charging issues in the billing > system, and too much capacity wasted for no real gain > > b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling > this feature in the HSS/HLR breaks roaming and there is no way to > ensure this issue is fixed in the hundreds of networks that are > potentially impacted. There are some backs to do on the home network > that can make this easier but not exposing partner networks to the new > release 8 features. > > c. What does work and adds value (saves IPv4 address for the common > case of not-roaming) : IPv6-only single PDP 464XLAT on the home > network, IPv4-only single PDP when roaming. This is how i am moving > forward. The when at home, the UE has default configs for ipv6-only > and when roaming the ue only attempts to connect using IPv4. This > gets the vast majority of users in my home network off v4 and keeps > ipv4 for the complicated yet relatively small percentage of roaming > users. > Thanks for the good summary. That is the lesson we have leaned. BRs Gang > > On Tue, Jul 9, 2013 at 5:45 AM, wrote: >> >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >> take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From phdgang@gmail.com Sun Jul 28 11:25:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1B21F9D66 for ; Sun, 28 Jul 2013 11:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 GRTs1HHWtfV1 for ; Sun, 28 Jul 2013 11:25:28 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id B00C221F9D4C for ; Sun, 28 Jul 2013 11:25:09 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so1281956qab.18 for ; Sun, 28 Jul 2013 11:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wof9o4YqVsoGulyU7fVJ5stSdy3qArX6A+piX2sPAFQ=; b=GJXSrETUxpB7D3ry3n03y+i1m9pwCFJmzeGxcfhToPcDS8RpKEJh+l2Yy4af7lY12f 7qFAqna/kJOZYh3a+VezR7rpKrS1RhC4/MvrBg9JyjXmkmRRfLhumCFWRyzejAmrHVSN 7lDli/aW1I1KQbVJDl1pJL98lKjMw3cAkIwx46+plV8KfzXE2vz8mWd8Vs8i1RWKhmYs VxbhSBvplrvHWfnvOA4P9kD+aYUa/0eZDu5lVxc9urgZhDdJn1nF7os3yYJOGrK4FCeV HJS/H+hP7byhIwzSytrwqs5rMRB+jyTO+mIr4acWEoSXtMkn7aE5PqZ5ZpeOBqbJSFJ2 EPbw== MIME-Version: 1.0 X-Received: by 10.224.130.195 with SMTP id u3mr769528qas.80.1375035905007; Sun, 28 Jul 2013 11:25:05 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sun, 28 Jul 2013 11:25:04 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Mon, 29 Jul 2013 02:25:04 +0800 Message-ID: From: GangChen To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 18:25:50 -0000 Hi Cameron, Thank you for the comments. 2013/7/28, cb.list6 : > As general feedback > > 1. As others have noted, it is important to clarify that home routed > is the default case and local-breakout is only relavent for IMS, but local-breakout may not be only for IMS. We have deployed that for all the data roaming between different province's networks in China. It offers efficient routes. Besides, 3GPP specified the SIPTO architecture for roaming. That may bring impacts in the future. > IMS based roaming and local breakout is yet to see its first > deployment, and may still be years in the future for roaming to work > this way. So, local breakout is not a real case and seems to be > causing more confusion. > > 2. There is a hazard in assuming the well known prefix is always > available. Any device should not assume the well known prefix is > available. This is essentially a misconfiguration that should not > occur. Ok. You don't recommend using WKP. How about taking different priority for the deployment High priority: nat64-discovery Medium: WKP Low: manual configuration > 3. What i have learned > > a. dual-stack 2 PDP will never work, charging issues in the billing > system, and too much capacity wasted for no real gain > > b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling > this feature in the HSS/HLR breaks roaming and there is no way to > ensure this issue is fixed in the hundreds of networks that are > potentially impacted. There are some backs to do on the home network > that can make this easier but not exposing partner networks to the new > release 8 features. > > c. What does work and adds value (saves IPv4 address for the common > case of not-roaming) : IPv6-only single PDP 464XLAT on the home > network, IPv4-only single PDP when roaming. This is how i am moving > forward. The when at home, the UE has default configs for ipv6-only > and when roaming the ue only attempts to connect using IPv4. This > gets the vast majority of users in my home network off v4 and keeps > ipv4 for the complicated yet relatively small percentage of roaming > users. > Thanks for the good summary. That is the lesson we have leaned. BRs Gang > > On Tue, Jul 9, 2013 at 5:45 AM, wrote: >> >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >> take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Sun Jul 28 13:34:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9048A21F9E40 for ; Sun, 28 Jul 2013 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 oejoIftx30MJ for ; Sun, 28 Jul 2013 13:34:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0A421F9E36 for ; Sun, 28 Jul 2013 13:34:13 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so3699902wgg.16 for ; Sun, 28 Jul 2013 13:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DQcbKzmvUOb01Nxg/t5LW0bwJESP5kotgqNhzvsKKmY=; b=V32I3npYp506Jj6pDBJ6ZKdcYTPHi358gSJTWtNKS/R26ZwwhWkkfvxzuQ5FBIS7kl v2X+Hm+G0MI3cVtKg4lEk1//OoNSzDz8oBXBGit10O42q0YGiiCQZ3ZLK8s0nDg6V9Px DDtrPqnkz+QUskLC/5LvVY9+8ushbJ0V+lBDeI2B0JWSUDB9t2waGsYes99+6/wxuXXQ FWJVm7GGTF41srcNXvY59ijlS5piAC87OaKA6BGuSIKN2KwRKRSppErc5l5y2kBcb2kp SaRkslV9e7KvvDvgU4EvTC7sxhqsQxh6GyRhtPnG7xdEuaKs51CbdU9YWShM/X3kg3JK VjnA== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr41842971wjn.23.1375043652288; Sun, 28 Jul 2013 13:34:12 -0700 (PDT) Received: by 10.216.15.6 with HTTP; Sun, 28 Jul 2013 13:34:12 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Sun, 28 Jul 2013 13:34:12 -0700 Message-ID: From: "cb.list6" To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 20:34:14 -0000 Gang, On Sun, Jul 28, 2013 at 11:23 AM, GangChen wrote: > Hi Cameron, > > Thank you for the comments. > > 2013/7/28, cb.list6 : >> As general feedback >> >> 1. As others have noted, it is important to clarify that home routed >> is the default case and local-breakout is only relavent for IMS, but > > local-breakout may not be only for IMS. We have deployed that for the > data roaming between different province's networks in China. It offers > efficient routes. Besides, 3GPP specified the SIPTO architecture for > roaming. That may bring impacts in the future. > AFAIK, these are very different cases, but i do not know much about SIPTO SIPTO requires that the UE have an IP address from the home network. So, in SIPTO cases, my customers always have an IP address from my network and they also have an IP address from LAN. In this way, SIPTO is still home routed. The IMS case, your receive the IP address from the visited network. So, when my IMS subscribers roam to your network, they no longer have an IP address from my network, they only have an IP address from the visited network. >> IMS based roaming and local breakout is yet to see its first >> deployment, and may still be years in the future for roaming to work >> this way. So, local breakout is not a real case and seems to be >> causing more confusion. >> >> 2. There is a hazard in assuming the well known prefix is always >> available. Any device should not assume the well known prefix is >> available. This is essentially a misconfiguration that should not >> occur. > > Ok. You don't recommend using WKP. How about taking different priority > for the deployment > > High priority: nat64-discovery > Medium: WKP > Low: manual configuration > > I would not put it that way, i would just say discovery is best. Discovery can discover the wkp or nsp. Manual configuration of pref64, wkp or nsp, can result in a lot of trouble for nomadic / mobile nodes. > >> 3. What i have learned >> >> a. dual-stack 2 PDP will never work, charging issues in the billing >> system, and too much capacity wasted for no real gain >> >> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >> this feature in the HSS/HLR breaks roaming and there is no way to >> ensure this issue is fixed in the hundreds of networks that are >> potentially impacted. There are some backs to do on the home network >> that can make this easier but not exposing partner networks to the new >> release 8 features. >> >> c. What does work and adds value (saves IPv4 address for the common >> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >> network, IPv4-only single PDP when roaming. This is how i am moving >> forward. The when at home, the UE has default configs for ipv6-only >> and when roaming the ue only attempts to connect using IPv4. This >> gets the vast majority of users in my home network off v4 and keeps >> ipv4 for the complicated yet relatively small percentage of roaming >> users. >> > > Thanks for the good summary. That is the lesson we have leaned. > Then it must be a BCP :) CB > BRs > > Gang > > >> >> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >>> take a look at it and comment. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> From phdgang@gmail.com Sun Jul 28 14:20:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0E121F9E98 for ; Sun, 28 Jul 2013 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Y9CJ7F4YFOEE for ; Sun, 28 Jul 2013 14:20:04 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7022321F9E96 for ; Sun, 28 Jul 2013 14:20:03 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bq6so1314151qab.19 for ; Sun, 28 Jul 2013 14:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zz/mGjf9r4NJR648uo3gLX1xgncOp9VUByH5YTVTPcM=; b=N1lUclHfOlHqBrI4gcb/7/w2x8TJ7yNY5/CM+S+bT0Hdpu9Z52Dd5OzX1f2isLNsbJ hg5N6Bs04mkYoggH1dvT+ggbwOtXfL5fw40Is3fqc03/2IBoit/3IPOied5rXWgUKo75 P7qyIKlMxgZ8dDqAWt1XSBJXCW/FmBUjyO3rwBNBeuJNusMg4M4SZcmnZeUqyCReZAyM yAC7XEr1d44WrRjwAY8ip9DvwEgA82aN3bgvNs58K+wuiWJWL0C1gF/2Xl6KnLDy6xeH Hz+C0jMkaKp+zJ1mvmzGW5Hw0RoRmYgkHhM0OpdUb4q8pJ6e5YbdxGJBByacLujSQ2se V0hg== MIME-Version: 1.0 X-Received: by 10.49.117.165 with SMTP id kf5mr25357861qeb.9.1375046402757; Sun, 28 Jul 2013 14:20:02 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sun, 28 Jul 2013 14:20:02 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Mon, 29 Jul 2013 05:20:02 +0800 Message-ID: From: GangChen To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 21:20:08 -0000 2013/7/29, cb.list6 : > Gang, > > > On Sun, Jul 28, 2013 at 11:23 AM, GangChen wrote: >> Hi Cameron, >> >> Thank you for the comments. >> >> 2013/7/28, cb.list6 : >>> As general feedback >>> >>> 1. As others have noted, it is important to clarify that home routed >>> is the default case and local-breakout is only relavent for IMS, but >> >> local-breakout may not be only for IMS. We have deployed that for the >> data roaming between different province's networks in China. It offers >> efficient routes. Besides, 3GPP specified the SIPTO architecture for >> roaming. That may bring impacts in the future. >> > > AFAIK, these are very different cases, but i do not know much about SIPTO > > SIPTO requires that the UE have an IP address from the home network. > So, in SIPTO cases, my customers always have an IP address from my > network and they also have an IP address from LAN. In this way, SIPTO > is still home routed. The SIPTO process can be found at TS 23.060(R10) clause 5.3.12 and TS 23.401 clause 4.3.15. Once the proper GGSN is selected, the SGSN should deactivate the attached subscribers. The subscriber should initiate another PDP/PDN requests to the selected GGSN. So, I guess the assigned address would belong to the visited network. > The IMS case, your receive the IP address from the visited network. > So, when my IMS subscribers roam to your network, they no longer have > an IP address from my network, they only have an IP address from the > visited network. I will add it to the draft. thanks > >>> IMS based roaming and local breakout is yet to see its first >>> deployment, and may still be years in the future for roaming to work >>> this way. So, local breakout is not a real case and seems to be >>> causing more confusion. >>> >>> 2. There is a hazard in assuming the well known prefix is always >>> available. Any device should not assume the well known prefix is >>> available. This is essentially a misconfiguration that should not >>> occur. >> >> Ok. You don't recommend using WKP. How about taking different priority >> for the deployment >> >> High priority: nat64-discovery >> Medium: WKP >> Low: manual configuration >> >> > > I would not put it that way, i would just say discovery is best. > Discovery can discover the wkp or nsp. > > Manual configuration of pref64, wkp or nsp, can result in a lot of > trouble for nomadic / mobile nodes. Yes. but do you have better idea in the case of non-DNS64? > >> >>> 3. What i have learned >>> >>> a. dual-stack 2 PDP will never work, charging issues in the billing >>> system, and too much capacity wasted for no real gain >>> >>> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>> this feature in the HSS/HLR breaks roaming and there is no way to >>> ensure this issue is fixed in the hundreds of networks that are >>> potentially impacted. There are some backs to do on the home network >>> that can make this easier but not exposing partner networks to the new >>> release 8 features. >>> >>> c. What does work and adds value (saves IPv4 address for the common >>> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>> network, IPv4-only single PDP when roaming. This is how i am moving >>> forward. The when at home, the UE has default configs for ipv6-only >>> and when roaming the ue only attempts to connect using IPv4. This >>> gets the vast majority of users in my home network off v4 and keeps >>> ipv4 for the complicated yet relatively small percentage of roaming >>> users. >>> >> >> Thanks for the good summary. That is the lesson we have leaned. >> > > Then it must be a BCP :) I'm in favor of the BCP ;) BRs Gang > > CB > >> BRs >> >> Gang >> >> >>> >>> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>> >>>> A new draft has been posted, at >>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>> Please >>>> take a look at it and comment. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From jouni.nospam@gmail.com Mon Jul 29 01:01:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C82921F9CAE for ; Mon, 29 Jul 2013 01:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ZKymdI5+cX9t for ; Mon, 29 Jul 2013 01:01:37 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1151221F9C83 for ; Mon, 29 Jul 2013 01:01:36 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so5093615pdd.20 for ; Mon, 29 Jul 2013 01:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=X8BNFqKX9yLnJOEjRuajiJ61Ijpv6RR97oHEPVjGbdw=; b=Fb30uRpAeELBNznbvSbA7Tr5fKMl24o8kECrjdL7rX/Gbryy13PN+c1Qeo8hYJB+3s Jk4nku6JVU7O8HmG5RWwHaoVz3rIkVfCwAgZ30XglalHf/c49vbHJCDlq0UfUXAFVKTp 1AaG+8HwWtQq0ba6Xv3nA3BrWWPGj1zf99BywQ3TTvyo1mrHV15OeW+o0MVcbML4LE7V mwE1pFrqBgjz03ACShVXEqHAYSAUyomul5GeAAnsy8emdmTcuITSU5BeT4PZyxEX/GCk DdFQmWZv57m6sIinbuIVCJoshh5K64KuT0uBqy3ovjBEdwSAFLd2avFJ7wXLgoiE5wlE 4Iyw== X-Received: by 10.68.136.168 with SMTP id qb8mr13376078pbb.83.1375084896797; Mon, 29 Jul 2013 01:01:36 -0700 (PDT) Received: from ?IPv6:2001:df8::80:e97a:9420:feea:fa9d? ([2001:df8:0:80:e97a:9420:feea:fa9d]) by mx.google.com with ESMTPSA id dc5sm75418271pbc.37.2013.07.29.01.01.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:01:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Jul 2013 11:01:31 +0300 Content-Transfer-Encoding: 7bit Message-Id: <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 08:01:37 -0000 On Jul 28, 2013, at 9:25 PM, GangChen wrote: > Hi Cameron, > > Thank you for the comments. > > 2013/7/28, cb.list6 : >> As general feedback >> >> 1. As others have noted, it is important to clarify that home routed >> is the default case and local-breakout is only relavent for IMS, but > > local-breakout may not be only for IMS. We have deployed that for all > the data roaming between different province's networks in China. It > offers efficient routes. Besides, 3GPP specified the SIPTO > architecture for roaming. That may bring impacts in the future. Just to understand this better.. Does "data roaming between different province's networks" mean the province's networks have different PLMN codes? Do these "province's networks" belong to different operators or to the same operator (from the administration/business point of view)? - Jouni > >> IMS based roaming and local breakout is yet to see its first >> deployment, and may still be years in the future for roaming to work >> this way. So, local breakout is not a real case and seems to be >> causing more confusion. >> >> 2. There is a hazard in assuming the well known prefix is always >> available. Any device should not assume the well known prefix is >> available. This is essentially a misconfiguration that should not >> occur. > > Ok. You don't recommend using WKP. How about taking different priority > for the deployment > > High priority: nat64-discovery > Medium: WKP > Low: manual configuration > > > >> 3. What i have learned >> >> a. dual-stack 2 PDP will never work, charging issues in the billing >> system, and too much capacity wasted for no real gain >> >> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >> this feature in the HSS/HLR breaks roaming and there is no way to >> ensure this issue is fixed in the hundreds of networks that are >> potentially impacted. There are some backs to do on the home network >> that can make this easier but not exposing partner networks to the new >> release 8 features. >> >> c. What does work and adds value (saves IPv4 address for the common >> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >> network, IPv4-only single PDP when roaming. This is how i am moving >> forward. The when at home, the UE has default configs for ipv6-only >> and when roaming the ue only attempts to connect using IPv4. This >> gets the vast majority of users in my home network off v4 and keeps >> ipv4 for the complicated yet relatively small percentage of roaming >> users. >> > > Thanks for the good summary. That is the lesson we have leaned. > > BRs > > Gang > > >> >> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please >>> take a look at it and comment. >>> _______________________________________________ >>> 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 phdgang@gmail.com Mon Jul 29 03:10:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97A921E808C for ; Mon, 29 Jul 2013 03:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 0YviIeSC17Bj for ; Mon, 29 Jul 2013 03:10:37 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 776F521F9FC3 for ; Mon, 29 Jul 2013 03:10:36 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1560905qab.16 for ; Mon, 29 Jul 2013 03:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N8CQybgHIc+Qmib0MVqZlHP9HiEZQflCIeJWH9KPXh0=; b=vjgck9o6RkOQzF9plRPgHvhwFvKq0lwI+9/UYwHBwtrDsiq/HkFj3oSMaAgH3RmvEv b0DxdjlGYfwubP6gEgdSQXe3SywDJG4mHnPc17C72aPlv7YYSERXooIHRnKnsOWgUcjn PdAayQaOzOAUH6dFBJsTtTYV339znJsj5mzUGc+wgFjvIRmgesnsqX01T3EAo+cpB8Pk k23g+iEmLHVf504wWuecfZfH0Ug8emW5GWyVfVCkY/tREO0v2ZXYUifnfmfxxlAu/w/P o3R+bXPiN1qTOYfr4XcqltYFfpsvwBDZk71nx0ftAqBYkDMhBVisjYPhOe5EZ2ttbP2r 0B+Q== MIME-Version: 1.0 X-Received: by 10.49.12.145 with SMTP id y17mr69746147qeb.7.1375092635765; Mon, 29 Jul 2013 03:10:35 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Mon, 29 Jul 2013 03:10:35 -0700 (PDT) In-Reply-To: <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> Date: Mon, 29 Jul 2013 18:10:35 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 10:10:37 -0000 2013/7/29, Jouni Korhonen : > > On Jul 28, 2013, at 9:25 PM, GangChen wrote: > >> Hi Cameron, >> >> Thank you for the comments. >> >> 2013/7/28, cb.list6 : >>> As general feedback >>> >>> 1. As others have noted, it is important to clarify that home routed >>> is the default case and local-breakout is only relavent for IMS, but >> >> local-breakout may not be only for IMS. We have deployed that for all >> the data roaming between different province's networks in China. It >> offers efficient routes. Besides, 3GPP specified the SIPTO >> architecture for roaming. That may bring impacts in the future. > > Just to understand this better.. Does "data roaming between different > province's networks" mean the province's networks have different PLMN > codes? Do these "province's networks" belong to different operators or > to the same operator (from the administration/business point of view)? The different province's networks belong to the same operator. The local-breakout roaming is enabled by adding APN-OI replacement into a subscriber's profile BRs Gang > - Jouni > > >> >>> IMS based roaming and local breakout is yet to see its first >>> deployment, and may still be years in the future for roaming to work >>> this way. So, local breakout is not a real case and seems to be >>> causing more confusion. >>> >>> 2. There is a hazard in assuming the well known prefix is always >>> available. Any device should not assume the well known prefix is >>> available. This is essentially a misconfiguration that should not >>> occur. >> >> Ok. You don't recommend using WKP. How about taking different priority >> for the deployment >> >> High priority: nat64-discovery >> Medium: WKP >> Low: manual configuration >> >> >> >>> 3. What i have learned >>> >>> a. dual-stack 2 PDP will never work, charging issues in the billing >>> system, and too much capacity wasted for no real gain >>> >>> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>> this feature in the HSS/HLR breaks roaming and there is no way to >>> ensure this issue is fixed in the hundreds of networks that are >>> potentially impacted. There are some backs to do on the home network >>> that can make this easier but not exposing partner networks to the new >>> release 8 features. >>> >>> c. What does work and adds value (saves IPv4 address for the common >>> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>> network, IPv4-only single PDP when roaming. This is how i am moving >>> forward. The when at home, the UE has default configs for ipv6-only >>> and when roaming the ue only attempts to connect using IPv4. This >>> gets the vast majority of users in my home network off v4 and keeps >>> ipv4 for the complicated yet relatively small percentage of roaming >>> users. >>> >> >> Thanks for the good summary. That is the lesson we have leaned. >> >> BRs >> >> Gang >> >> >>> >>> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>> >>>> A new draft has been posted, at >>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>> Please >>>> take a look at it and comment. >>>> _______________________________________________ >>>> 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 Michal.Czerwonka1@orange.com Mon Jul 29 04:34:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E409211E80DF for ; Mon, 29 Jul 2013 04:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.386 X-Spam-Level: * X-Spam-Status: No, score=1.386 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 ZhofAnad4k+F for ; Mon, 29 Jul 2013 04:34:02 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7D11E80DC for ; Mon, 29 Jul 2013 04:34:01 -0700 (PDT) Received: from 10.236.62.153 (EHLO OPE10HT05.tp.gk.corp.tepenet) ([10.236.62.153]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id DZL92465; Mon, 29 Jul 2013 13:33:55 +0200 (CEST) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt_TP?= To: "cb.list6" , Fred Baker Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: AQHOfKI8X61wIhyu9k636KHEY2pjHJl6OO6AgAFsNxA= Date: Mon, 29 Jul 2013 11:33:54 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F1E311@OPE10MB05.tp.gk.corp.tepenet> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.51F65324.0016,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-09 01:15:44, dmn=5.7.1/2009-08-27, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.51F65324.0016,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-09 01:15:44, dmn=5.7.1/2009-08-27 X-Mirapoint-Loop-Id: 65bb3c5969f1fc8e5841b645bfd44224 Cc: IPv6 Ops WG , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: [v6ops] ODP: new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 11:34:07 -0000 +1 NO IPv6 in roaming :( BR, Mcz -----Wiadomo=B6=E6 oryginalna----- Od: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] W imieniu cb.lis= t6 Wys=B3ano: 28 lipca 2013 17:48 Do: Fred Baker DW: IPv6 Ops WG; draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Temat: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis As general feedback 1. As others have noted, it is important to clarify that home routed is the default case and local-breakout is only relavent for IMS, but IMS based roaming and local breakout is yet to see its first deployment, and may still be years in the future for roaming to work this way. So, local breakout is not a real case and seems to be causing more confusion. 2. There is a hazard in assuming the well known prefix is always available. Any device should not assume the well known prefix is available. This is essentially a misconfiguration that should not occur. 3. What i have learned a. dual-stack 2 PDP will never work, charging issues in the billing system, and too much capacity wasted for no real gain b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling this feature in the HSS/HLR breaks roaming and there is no way to ensure this issue is fixed in the hundreds of networks that are potentially impacted. There are some backs to do on the home network that can make this easier but not exposing partner networks to the new release 8 features. c. What does work and adds value (saves IPv4 address for the common case of not-roaming) : IPv6-only single PDP 464XLAT on the home network, IPv4-only single PDP when roaming. This is how i am moving forward. The when at home, the UE has default configs for ipv6-only and when roaming the ue only attempts to connect using IPv4. This gets the vast majority of users in my home network off v4 and keeps ipv4 for the complicated yet relatively small percentage of roaming users. On Tue, Jul 9, 2013 at 5:45 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6o= ps-ipv6-roaming-analysis. Please take a look at it and comment. > _______________________________________________ > 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 jouni.nospam@gmail.com Mon Jul 29 05:13:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76B821F9E6C for ; Mon, 29 Jul 2013 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 WMzInHfofG+k for ; Mon, 29 Jul 2013 05:13:20 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B3A8921F9E46 for ; Mon, 29 Jul 2013 05:13:20 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so853085pbb.19 for ; Mon, 29 Jul 2013 05:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YnDhL4u9b0GxlLaAT/qo0CKYFZlvsxix/EFptHYNAL4=; b=VYyC4mi/pNDBkj0tTzLwyRuIrYIrIi/z+gHXE+1fB97ARLsxFCs2a8c12fG8oQS6M9 XQVjtzHoOlr7xkVvWWpUr2PqcA8meV7zkgfHG5qRXcoJUkREC9AVBhIJLGDpV7jdAKme ZLfWPCYvB6zSGixOJcQtEXkgbzkYvImG7ERN6d/wqxrG1Wp4MFvJuGsUSREnXlFLDdI3 4eUZQ2zyulXoc/uWaRkiJUK5H+s3VbTVLEwuvVhAcOBy8QEPKu/tCKfT5huLx8P+FBKU eW51EfJsMyvrvSEWXa4PIPsDYbSMvSmzZuJvKXki/jayLyN62Ag17lwSB6KuWLky5Psi /N7Q== X-Received: by 10.68.104.196 with SMTP id gg4mr68501460pbb.25.1375100000401; Mon, 29 Jul 2013 05:13:20 -0700 (PDT) Received: from ?IPv6:2001:df8::80:58a8:b8da:677b:2aac? ([2001:df8:0:80:58a8:b8da:677b:2aac]) by mx.google.com with ESMTPSA id dc5sm76616462pbc.37.2013.07.29.05.13.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 05:13:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Jul 2013 15:13:13 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 12:13:22 -0000 On Jul 29, 2013, at 1:10 PM, GangChen wrote: > 2013/7/29, Jouni Korhonen : >> >> On Jul 28, 2013, at 9:25 PM, GangChen wrote: >> >>> Hi Cameron, >>> >>> Thank you for the comments. >>> >>> 2013/7/28, cb.list6 : >>>> As general feedback >>>> >>>> 1. As others have noted, it is important to clarify that home routed >>>> is the default case and local-breakout is only relavent for IMS, but >>> >>> local-breakout may not be only for IMS. We have deployed that for all >>> the data roaming between different province's networks in China. It >>> offers efficient routes. Besides, 3GPP specified the SIPTO >>> architecture for roaming. That may bring impacts in the future. >> >> Just to understand this better.. Does "data roaming between different >> province's networks" mean the province's networks have different PLMN >> codes? Do these "province's networks" belong to different operators or >> to the same operator (from the administration/business point of view)? > > The different province's networks belong to the same operator. The > local-breakout roaming is enabled by adding APN-OI replacement into a > subscriber's profile So the PLMN codes are the same for all provinces? If that is the case, then what you are doing hardly is "roaming" rather an intelligent gateway selection. Is the VPLMN dynamic address allowed flag set to ALLOWED? Does the APN-OI replacement change dynamically in the subscriber profile based on the UE location or is it configured "statically" based on where the subscription is assumed to be used most of the time? - JOuni > > BRs > > Gang > > >> - Jouni >> >> >>> >>>> IMS based roaming and local breakout is yet to see its first >>>> deployment, and may still be years in the future for roaming to work >>>> this way. So, local breakout is not a real case and seems to be >>>> causing more confusion. >>>> >>>> 2. There is a hazard in assuming the well known prefix is always >>>> available. Any device should not assume the well known prefix is >>>> available. This is essentially a misconfiguration that should not >>>> occur. >>> >>> Ok. You don't recommend using WKP. How about taking different priority >>> for the deployment >>> >>> High priority: nat64-discovery >>> Medium: WKP >>> Low: manual configuration >>> >>> >>> >>>> 3. What i have learned >>>> >>>> a. dual-stack 2 PDP will never work, charging issues in the billing >>>> system, and too much capacity wasted for no real gain >>>> >>>> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>>> this feature in the HSS/HLR breaks roaming and there is no way to >>>> ensure this issue is fixed in the hundreds of networks that are >>>> potentially impacted. There are some backs to do on the home network >>>> that can make this easier but not exposing partner networks to the new >>>> release 8 features. >>>> >>>> c. What does work and adds value (saves IPv4 address for the common >>>> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>>> network, IPv4-only single PDP when roaming. This is how i am moving >>>> forward. The when at home, the UE has default configs for ipv6-only >>>> and when roaming the ue only attempts to connect using IPv4. This >>>> gets the vast majority of users in my home network off v4 and keeps >>>> ipv4 for the complicated yet relatively small percentage of roaming >>>> users. >>>> >>> >>> Thanks for the good summary. That is the lesson we have leaned. >>> >>> BRs >>> >>> Gang >>> >>> >>>> >>>> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>>> >>>>> A new draft has been posted, at >>>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>> Please >>>>> take a look at it and comment. >>>>> _______________________________________________ >>>>> 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 phdgang@gmail.com Mon Jul 29 06:31:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFCB21F9F85 for ; Mon, 29 Jul 2013 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 zrTNR2fSi8fl for ; Mon, 29 Jul 2013 06:31:48 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 973C621F9EA7 for ; Mon, 29 Jul 2013 06:31:47 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bv4so1672044qab.1 for ; Mon, 29 Jul 2013 06:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hSq0DQrLGshDj7mSvfcxaMC9dy8YV40d7pKc/qHaTWc=; b=K71MldCqG36L5ywrs3Z8yBCucMriOz8myIKRQjqZk1vaoLmWAFQK48adKRqSbX0gC6 oR32mpRkjlWtvalHEVLUbCMlad9q0S1v9kUhPAbQNEuu4vDkPqR19EIqXUCk2ZKcjIcq OnW+UyxEVHoUz64U385cXWkGWkl0hySsedh5isWt6lZbAXWbHeEAyaom+XTi/hte0MEs Nbdmxp/6KEc78+4GPYDGKAwHpKAGXaDFg+YswlQaHGHMFETYQ/ICYHV2xWc2RXwoLQvH d/Hxi+bsAtMXPahdbwIkvhNII+4xaCLmlHQ7Ijn27Plbo61qXi4LFsplhyHDgSVK/LyA hfbw== MIME-Version: 1.0 X-Received: by 10.224.98.198 with SMTP id r6mr37541817qan.103.1375104706909; Mon, 29 Jul 2013 06:31:46 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Mon, 29 Jul 2013 06:31:46 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> Date: Mon, 29 Jul 2013 21:31:46 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 13:31:49 -0000 2013/7/29, Jouni Korhonen : > > On Jul 29, 2013, at 1:10 PM, GangChen wrote: > >> 2013/7/29, Jouni Korhonen : >>> >>> On Jul 28, 2013, at 9:25 PM, GangChen wrote: >>> >>>> Hi Cameron, >>>> >>>> Thank you for the comments. >>>> >>>> 2013/7/28, cb.list6 : >>>>> As general feedback >>>>> >>>>> 1. As others have noted, it is important to clarify that home routed >>>>> is the default case and local-breakout is only relavent for IMS, but >>>> >>>> local-breakout may not be only for IMS. We have deployed that for all >>>> the data roaming between different province's networks in China. It >>>> offers efficient routes. Besides, 3GPP specified the SIPTO >>>> architecture for roaming. That may bring impacts in the future. >>> >>> Just to understand this better.. Does "data roaming between different >>> province's networks" mean the province's networks have different PLMN >>> codes? Do these "province's networks" belong to different operators or >>> to the same operator (from the administration/business point of view)? >> >> The different province's networks belong to the same operator. The >> local-breakout roaming is enabled by adding APN-OI replacement into a >> subscriber's profile > > So the PLMN codes are the same for all provinces? If that is the case, then > what you are doing hardly is "roaming" rather an intelligent gateway > selection. That is a good question. At http://en.wikipedia.org/wiki/Roaming, the roaming has been interpreted as "In wireless telecommunications, roaming is a general term referring to the extension of connectivity service in a location that is different from the home location where the service was registered." Roaming behavior is justified by whether the visited network has subscriber's registration information. MNC+MCC may not be the matter. > Is the VPLMN dynamic address allowed flag set to ALLOWED? Does the APN-OI > replacement change dynamically in the subscriber profile based on the > UE location or is it configured "statically" based on where the > subscription > is assumed to be used most of the time? The APN-OI replacement is configured in a static way and assumed to be used in most times. -Gang > - JOuni > > >> >> BRs >> >> Gang >> >> >>> - Jouni >>> >>> >>>> >>>>> IMS based roaming and local breakout is yet to see its first >>>>> deployment, and may still be years in the future for roaming to work >>>>> this way. So, local breakout is not a real case and seems to be >>>>> causing more confusion. >>>>> >>>>> 2. There is a hazard in assuming the well known prefix is always >>>>> available. Any device should not assume the well known prefix is >>>>> available. This is essentially a misconfiguration that should not >>>>> occur. >>>> >>>> Ok. You don't recommend using WKP. How about taking different priority >>>> for the deployment >>>> >>>> High priority: nat64-discovery >>>> Medium: WKP >>>> Low: manual configuration >>>> >>>> >>>> >>>>> 3. What i have learned >>>>> >>>>> a. dual-stack 2 PDP will never work, charging issues in the billing >>>>> system, and too much capacity wasted for no real gain >>>>> >>>>> b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>>>> this feature in the HSS/HLR breaks roaming and there is no way to >>>>> ensure this issue is fixed in the hundreds of networks that are >>>>> potentially impacted. There are some backs to do on the home network >>>>> that can make this easier but not exposing partner networks to the new >>>>> release 8 features. >>>>> >>>>> c. What does work and adds value (saves IPv4 address for the common >>>>> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>>>> network, IPv4-only single PDP when roaming. This is how i am moving >>>>> forward. The when at home, the UE has default configs for ipv6-only >>>>> and when roaming the ue only attempts to connect using IPv4. This >>>>> gets the vast majority of users in my home network off v4 and keeps >>>>> ipv4 for the complicated yet relatively small percentage of roaming >>>>> users. >>>>> >>>> >>>> Thanks for the good summary. That is the lesson we have leaned. >>>> >>>> BRs >>>> >>>> Gang >>>> >>>> >>>>> >>>>> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>>>> >>>>>> A new draft has been posted, at >>>>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>>> Please >>>>>> take a look at it and comment. >>>>>> _______________________________________________ >>>>>> 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 lorenzo@google.com Mon Jul 29 07:59:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F4A21F9476 for ; Mon, 29 Jul 2013 07:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8oY8eWDoK6qM for ; Mon, 29 Jul 2013 07:59:19 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3558021F9B5C for ; Mon, 29 Jul 2013 07:59:19 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n16so1841534oag.36 for ; Mon, 29 Jul 2013 07:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VzUEnjx6dFe+Q6QF4n6yFytLLb4MXWCfSy0PrSpf9Mw=; b=OmSEB8gZwaWPqTaW1bmTRAooRwrLnu8GvOkhvlqcsCSsXdJwupRBdAMYzbE2ClJ1Uk 2n1Tg7r/Im6vAkP4lRXoDNc+CUUAhCJXnoTORHHkwCkBLM0wx/Beq78tGm4FiklEeQpy UIw1xKj4fbfHBrGjKZpezE1J59GMSfGlE71qDp3MTmuhAIbLjVx2Z9cMx2clE5uwEQRq +bcAOhIRtm5I+WJkcLT+fzqihuNibVm3BzkDh2/tGil8DO6mW46FaW5w2Q/3WC9Q8C1H BXCH+s4MJbn1m8nbd0HqELM824WB4oz7pCG6u+EEscEp1SQSfxD+wbW6axpOV3pJdSvk Lwcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VzUEnjx6dFe+Q6QF4n6yFytLLb4MXWCfSy0PrSpf9Mw=; b=Jgp3y5zas/j1JdKhaTvhEyfqn9PyfHaP5AEQgae08AFmg4B+egkW9gtDbo0C9yTLAI XJB9EmQP/jkjwRbKqY1milp8ZPuwokcqvyMh6RaudzUkVvxxDN1irGRFEV1x97VuKAus 3Ny+KpTuD5vJHiVAXrLTuzGeMIzL0QkjLWJEBWd0lNJqu3B7+k+NbWij7q4wzYPuoRmW mFtiArNePRz1En7+5skbk8kVVsa6+JWJPuo4rISEHMMOggfVBomtEyW+zV4xAukHPmW6 Yd5qh1u/iRY0n4d+bFLLGzeuVCntIA+dHVaqEEatqAmDgcImpMhUzyaYAYpRgxcZG1Dc hVTg== X-Received: by 10.50.18.5 with SMTP id s5mr1093377igd.6.1375109958560; Mon, 29 Jul 2013 07:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 29 Jul 2013 07:58:58 -0700 (PDT) In-Reply-To: <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> From: Lorenzo Colitti Date: Mon, 29 Jul 2013 16:58:58 +0200 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=089e013cc1c49b972404e2a7bc38 X-Gm-Message-State: ALoCoQkxBESvmozSI2Od7uEnda8dSoxHzEkFpviHmN9kHu7AK/wb1euVk5kHYXmkkMyct2yH6rKBCvMouMvC0Cv09ee9sL2m/kKvbpgCxVx3tYmuhoJ/2qSoaHRgRujsl+b1Uk3aMKhCGT0tte49Zqh4GfEvyivRvB+dS0V7cSMBTmgsRasw4xBt2RUAJ+3CI2gTluqd7fvJ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 14:59:20 -0000 --089e013cc1c49b972404e2a7bc38 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 18, 2013 at 2:44 AM, Tore Anderson wrote: > I'm sure there could be exceptions to the above. I've heard several > people suggest that Japan is particularly problematic in this regard - > but in my experience it Just Works there, too. > As regards Japan, you got lucky. NTT does not support IPv6 roaming, and Softbank was fixed a few weeks (days?) before you arrived. --089e013cc1c49b972404e2a7bc38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 18, 2013 at 2:44 AM, Tore Anderson <tore@fud.no> wrote:
I'm sure there could be exceptions to the above. I've heard several=
people suggest that Japan is particularly problematic in this regard -
but in my experience it Just Works there, too.

As regards Japan, you got lucky. NTT does not support IPv6 roaming,= and Softbank was fixed a few weeks (days?) before you arrived.=A0
--089e013cc1c49b972404e2a7bc38-- From jouni.nospam@gmail.com Mon Jul 29 08:01:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803E521F9A3B for ; Mon, 29 Jul 2013 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 7t3hn8zE6Jcq for ; Mon, 29 Jul 2013 08:01:29 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 995A821F9AC1 for ; Mon, 29 Jul 2013 08:01:18 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 3so4478111pdj.5 for ; Mon, 29 Jul 2013 08:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=y0YbFrmhjUMz8h+jJ0cB5UWm4SS3T4q5IiwZ8utOfhE=; b=zuU87OZ3MyThfp0+AYWV6sWDyB6FoqKN01O38dtUNjPVx+FnoYC0UUbZhPKOIeCksV VgeEQeBoMP5EaiNm4A3waZWHjzgbU6qEj0zvp4FgTMQtsV0eqy5Q+ntfPYsn1iio04LC HgdzLavSVUCRv1ir83V5UMEo61luas/viqL7EXet/SFZD2kY7R+Pjqx9/qVGWMEfs7ht XS57mZlojHY31wY6fSymgHK91KoY4W32uPfYHhXxlHL5cO+6dxGOWbsnvlvjPCgBJOBB QHQqm2yfxW3Y7blO3Uh05XlB3H2Od5yURFzOY78oKLtd5dB6+Ed0WSJUizkxWH/6F1Hl N10A== X-Received: by 10.66.234.71 with SMTP id uc7mr68743870pac.10.1375110078345; Mon, 29 Jul 2013 08:01:18 -0700 (PDT) Received: from ?IPv6:2001:df8::80:1c6:2b:4d17:d2b? ([2001:df8:0:80:1c6:2b:4d17:d2b]) by mx.google.com with ESMTPSA id wr9sm77490709pbc.7.2013.07.29.08.01.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:01:16 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Jul 2013 18:01:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <719124C1-AB53-4BDB-8829-8FF5DA308351@gmail.com> References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <191A90A6-AFDF-4232-9848-54FDA50BC1CC@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1508) Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 15:01:30 -0000 On Jul 29, 2013, at 4:31 PM, GangChen wrote: > 2013/7/29, Jouni Korhonen : >>=20 >> On Jul 29, 2013, at 1:10 PM, GangChen wrote: >>=20 >>> 2013/7/29, Jouni Korhonen : >>>>=20 >>>> On Jul 28, 2013, at 9:25 PM, GangChen wrote: >>>>=20 >>>>> Hi Cameron, >>>>>=20 >>>>> Thank you for the comments. >>>>>=20 >>>>> 2013/7/28, cb.list6 : >>>>>> As general feedback >>>>>>=20 >>>>>> 1. As others have noted, it is important to clarify that home = routed >>>>>> is the default case and local-breakout is only relavent for IMS, = but >>>>>=20 >>>>> local-breakout may not be only for IMS. We have deployed that for = all >>>>> the data roaming between different province's networks in China. = It >>>>> offers efficient routes. Besides, 3GPP specified the SIPTO >>>>> architecture for roaming. That may bring impacts in the future. >>>>=20 >>>> Just to understand this better.. Does "data roaming between = different >>>> province's networks" mean the province's networks have different = PLMN >>>> codes? Do these "province's networks" belong to different operators = or >>>> to the same operator (from the administration/business point of = view)? >>>=20 >>> The different province's networks belong to the same operator. The >>> local-breakout roaming is enabled by adding APN-OI replacement into = a >>> subscriber's profile >>=20 >> So the PLMN codes are the same for all provinces? If that is the = case, then >> what you are doing hardly is "roaming" rather an intelligent gateway >> selection. >=20 > That is a good question. At http://en.wikipedia.org/wiki/Roaming, the > roaming has been interpreted as "In wireless telecommunications, > roaming is a general term referring to the extension of connectivity > service in a location that is different from the home location where > the service was registered." Roaming behavior is justified by whether > the visited network has subscriber's registration information. MNC+MCC > may not be the matter. In 3GPP sense, you are in a visited network when the MNC+MCC codes do not match your own expected HPLMN or EHPLMNs. I would stick with 3GPP definition of roaming when describing 3GPP specific things. I agree that that a "HPLMN" may consist multiple PLMN codes. Again I would be careful with the terminology when you mean a visited network gateway or when a gateway (visited or home) that is topologically selected close to the UE.. just to avoid confusion. - Jouni >=20 >> Is the VPLMN dynamic address allowed flag set to ALLOWED? Does the = APN-OI >> replacement change dynamically in the subscriber profile based on the >> UE location or is it configured "statically" based on where the >> subscription >> is assumed to be used most of the time? >=20 > The APN-OI replacement is configured in a static way and assumed to be > used in most times. >=20 > -Gang >=20 >=20 >> - JOuni >>=20 >>=20 >>>=20 >>> BRs >>>=20 >>> Gang >>>=20 >>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>>=20 >>>>>> IMS based roaming and local breakout is yet to see its first >>>>>> deployment, and may still be years in the future for roaming to = work >>>>>> this way. So, local breakout is not a real case and seems to be >>>>>> causing more confusion. >>>>>>=20 >>>>>> 2. There is a hazard in assuming the well known prefix is always >>>>>> available. Any device should not assume the well known prefix is >>>>>> available. This is essentially a misconfiguration that should = not >>>>>> occur. >>>>>=20 >>>>> Ok. You don't recommend using WKP. How about taking different = priority >>>>> for the deployment >>>>>=20 >>>>> High priority: nat64-discovery >>>>> Medium: WKP >>>>> Low: manual configuration >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> 3. What i have learned >>>>>>=20 >>>>>> a. dual-stack 2 PDP will never work, charging issues in the = billing >>>>>> system, and too much capacity wasted for no real gain >>>>>>=20 >>>>>> b. dual-stack 1 PDP (v4v6) will not work any time soon. = Enabling >>>>>> this feature in the HSS/HLR breaks roaming and there is no way to >>>>>> ensure this issue is fixed in the hundreds of networks that are >>>>>> potentially impacted. There are some backs to do on the home = network >>>>>> that can make this easier but not exposing partner networks to = the new >>>>>> release 8 features. >>>>>>=20 >>>>>> c. What does work and adds value (saves IPv4 address for the = common >>>>>> case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>>>>> network, IPv4-only single PDP when roaming. This is how i am = moving >>>>>> forward. The when at home, the UE has default configs for = ipv6-only >>>>>> and when roaming the ue only attempts to connect using IPv4. = This >>>>>> gets the vast majority of users in my home network off v4 and = keeps >>>>>> ipv4 for the complicated yet relatively small percentage of = roaming >>>>>> users. >>>>>>=20 >>>>>=20 >>>>> Thanks for the good summary. That is the lesson we have leaned. >>>>>=20 >>>>> BRs >>>>>=20 >>>>> Gang >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>>>>>=20 >>>>>>> A new draft has been posted, at >>>>>>> = http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>>>> 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 >>>>=20 >>>>=20 >>=20 >>=20 From rajiva@cisco.com Mon Jul 29 12:01:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B2521F997B for ; Mon, 29 Jul 2013 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 65hMoR0nZDjH for ; Mon, 29 Jul 2013 12:01:25 -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 8D31511E8115 for ; Mon, 29 Jul 2013 12:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2684; q=dns/txt; s=iport; t=1375124470; x=1376334070; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ms9rlBsdHZcoWqHbYyw4E26qlK+7NfvKUy3yeOe6MF0=; b=ITS0sOPzedl7EaohHD1HMmnfXBIpj056QRmd4Y3tGuiI5YHkus5lTVCy PFqw58WWQG04y14feiUPZENZ1BjIzFxvCW5EItjYaUAHJV+xVIdJ8JwLs aXbNtsanDY7RFsfBozqz6AA2rv0A00tZR6KhpjHw3pnz3OKlffCyiwBAi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAM+69lGtJV2c/2dsb2JhbABbgwY1UL1cgRoWdIIkAQEBBAEBATcyAgMFAwwGAQgRAwECAQoUMQYLHQgCBAENBQiHdgMPDK93DYhejRWCNzEHBoMSbwOTR4IvgxKKfYUmgxSCKg X-IronPort-AV: E=Sophos;i="4.89,771,1367971200"; d="scan'208";a="237936933" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2013 19:00:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6TJ0qZ5003079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 19:00:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 14:00:51 -0500 From: "Rajiv Asati (rajiva)" To: "cb.list6" , "Fred Baker (fred)" Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: AQHOi6uG49XSQKP7Y0WXvaOwRHidPZl8FUcA Date: Mon, 29 Jul 2013 19:00:51 +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.3.6.130613 x-originating-ip: [10.82.242.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BA9796E402696479DC018A3C262C12C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 19:01:32 -0000 Hi Cameron, Could you please share more details about 3a and 3b below? WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available? Cheers, Rajiv -----Original Message----- From: Cameron Byrne Date: Sunday, July 28, 2013 11:48 AM To: "Fred Baker (fred)" Cc: "v6ops@ietf.org" , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >As general feedback > >1. As others have noted, it is important to clarify that home routed >is the default case and local-breakout is only relavent for IMS, but >IMS based roaming and local breakout is yet to see its first >deployment, and may still be years in the future for roaming to work >this way. So, local breakout is not a real case and seems to be >causing more confusion. > >2. There is a hazard in assuming the well known prefix is always >available. Any device should not assume the well known prefix is >available. This is essentially a misconfiguration that should not >occur. > >3. What i have learned > >a. dual-stack 2 PDP will never work, charging issues in the billing >system, and too much capacity wasted for no real gain > >b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >this feature in the HSS/HLR breaks roaming and there is no way to >ensure this issue is fixed in the hundreds of networks that are >potentially impacted. There are some backs to do on the home network >that can make this easier but not exposing partner networks to the new >release 8 features. > >c. What does work and adds value (saves IPv4 address for the common >case of not-roaming) : IPv6-only single PDP 464XLAT on the home >network, IPv4-only single PDP when roaming. This is how i am moving >forward. The when at home, the UE has default configs for ipv6-only >and when roaming the ue only attempts to connect using IPv4. This >gets the vast majority of users in my home network off v4 and keeps >ipv4 for the complicated yet relatively small percentage of roaming >users. > > > >On Tue, Jul 9, 2013 at 5:45 AM, wrote: >> >> A new draft has been posted, at >>http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>Please take a look at it and comment. >> _______________________________________________ >> 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 cb.list6@gmail.com Mon Jul 29 12:59:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4E21F9A25 for ; Mon, 29 Jul 2013 12:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 UIVPPgGffKhW for ; Mon, 29 Jul 2013 12:59:44 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 66BFC11E812C for ; Mon, 29 Jul 2013 12:59:38 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so4434174wes.12 for ; Mon, 29 Jul 2013 12:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PQT9C1WUYRlUaAJwqzCahRrvFOFww/T6ZDks+j65ty4=; b=dEV8y386giXuuTW/kAJIaSIif/r7EJ/i4MG0pifvgGKZ3CESj6kEdF9m99wc0nVYop 2tlSDvvUgtRWyIsGPeqUs8PdMHNZAMqaA0w5ptts7644DJKZMTJB/F3vTKUEr5ZfcADQ hgLatvN2BuVrXagSWFsvs0nFVN7VTkFVTC5I9lEzxQbaXfMcE2Qbq8+6ES8eJpvzUPY1 +s2fezqaKnLbhrQCQy+QV1ufpWXKgi2q5OXUlHt4IQeSI0T39XH8TKL5EnnPE+7wFcaO gqP9axQnaVJjRniXbErozdiP4FKssikDfnXnxISKQVMpvPygIzi075Pwhglrku6Y2UO8 kuKg== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr45301759wjn.23.1375127977538; Mon, 29 Jul 2013 12:59:37 -0700 (PDT) Received: by 10.216.15.6 with HTTP; Mon, 29 Jul 2013 12:59:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 12:59:37 -0700 Message-ID: From: "cb.list6" To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 19:59:45 -0000 Rajiv On Mon, Jul 29, 2013 at 12:00 PM, Rajiv Asati (rajiva) wrote: > Hi Cameron, > > Could you please share more details about 3a and 3b below? > > Can you be more specific about the question? Charging systems have a hard time to reconcile usage from 2 PDP because they are 2 separate CDRs, 1 for each PDP. Also, 2 PDP is 2x as expensive in terms of signalling and licensing. v4v6 as single PDP is not viable because not everything supports release 8 in the GSM/3GPP ecosystem. I tried to enable v4v6 for my subscribers in my central database (HLR/HSS), and adding this capability to all my subscribers made some existing ipv4 roaming subscribers fail. Why? Because when my users attach into a roaming partner network, their network downloads the capabilities of the subscriber from my database (HLR/HSS)... and if one of the capabilities includes v4v6, then the roaming partners's equipment drops the users because they don't understand this term. This is a roaming partner network device acting in a bad and non-standard way. It's a shame i have to turn off v4v6 globally because of this issue. There is one subscriber database, and because some roaming partner gear fails, it is not safe to turn anywhere. One remediation is to limit attributes based on a whitelist / blacklist, but this is not feature available today. Luckily, the good people of v6ops have approved RFC6877 and Android implemented it in 4.3 , so single v6 PDP works ok. > WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available? > Yes, it's supposed to work that way. But, keep in mind what i said above. In the real world, it does not (for now, once everyone upgrades maybe this wont be a problem). Cameron > Cheers, > Rajiv > > -----Original Message----- > From: Cameron Byrne > Date: Sunday, July 28, 2013 11:48 AM > To: "Fred Baker (fred)" > Cc: "v6ops@ietf.org" , > "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" > > Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis > >>As general feedback >> >>1. As others have noted, it is important to clarify that home routed >>is the default case and local-breakout is only relavent for IMS, but >>IMS based roaming and local breakout is yet to see its first >>deployment, and may still be years in the future for roaming to work >>this way. So, local breakout is not a real case and seems to be >>causing more confusion. >> >>2. There is a hazard in assuming the well known prefix is always >>available. Any device should not assume the well known prefix is >>available. This is essentially a misconfiguration that should not >>occur. >> >>3. What i have learned >> >>a. dual-stack 2 PDP will never work, charging issues in the billing >>system, and too much capacity wasted for no real gain >> >>b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>this feature in the HSS/HLR breaks roaming and there is no way to >>ensure this issue is fixed in the hundreds of networks that are >>potentially impacted. There are some backs to do on the home network >>that can make this easier but not exposing partner networks to the new >>release 8 features. >> >>c. What does work and adds value (saves IPv4 address for the common >>case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>network, IPv4-only single PDP when roaming. This is how i am moving >>forward. The when at home, the UE has default configs for ipv6-only >>and when roaming the ue only attempts to connect using IPv4. This >>gets the vast majority of users in my home network off v4 and keeps >>ipv4 for the complicated yet relatively small percentage of roaming >>users. >> >> >> >>On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>> >>> A new draft has been posted, at >>>http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>Please take a look at it and comment. >>> _______________________________________________ >>> 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.mann@monash.edu Mon Jul 29 23:55:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3A811E81BF for ; Mon, 29 Jul 2013 23:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 jNEmxgB8pThe for ; Mon, 29 Jul 2013 23:55:18 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id B1CEB21E8090 for ; Mon, 29 Jul 2013 23:55:17 -0700 (PDT) Received: from mail-wg0-f54.google.com ([74.125.82.54]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUfdjVOJCzxXk/rKX+WtMHIHA3VrRgez5@postini.com; Mon, 29 Jul 2013 23:55:17 PDT Received: by mail-wg0-f54.google.com with SMTP id n11so2517546wgh.21 for ; Mon, 29 Jul 2013 23:55:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=LncYs/uIxwkRUH1XsS8i1Fy8m47sUhwbrRkYl9H9AWI=; b=S1KMDzcaQPlFslXlzXwzNZ0CCy4j6V9zHNV5Mj/234J3ZPJbUSeZ6Gv1gFdWoZJXfD Zrr3/fWEInefE1D4EEERKzlvOa7Jm6eV8UXGQD8g2JzxM7ORAKrx7YiiqmvdYapVCvPy 7G1eoHeo40+VknS+vKBUaeHnjrpFDO7fWezk/KvsOsqEQApLKTKgNUifFbWmF5hwhuWn ralSWs0I5QZyRhUnQt33qOtNpaTJ5iEcTAF7wGoH7zHDfZTIY3eIayyA8ARIJtk++niE S7XOgWF6PzmKiEl9BYH9Hy75Gaa/PS4vUIjVc/9/aRZ8oXKDiXF9IyGhWa+hiKBaoToa teBw== X-Received: by 10.194.242.69 with SMTP id wo5mr46158883wjc.30.1375167315141; Mon, 29 Jul 2013 23:55:15 -0700 (PDT) X-Received: by 10.194.242.69 with SMTP id wo5mr46158878wjc.30.1375167315042; Mon, 29 Jul 2013 23:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.164.78 with HTTP; Mon, 29 Jul 2013 23:54:54 -0700 (PDT) In-Reply-To: <51E15A35.2090603@lacnic.net> References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> From: John Mann Date: Tue, 30 Jul 2013 16:54:54 +1000 Message-ID: To: Arturo Servin Content-Type: multipart/alternative; boundary=089e0122f0fe51efcf04e2b51786 X-Gm-Message-State: ALoCoQnqYyifHb4q1KNjAlJWe10BvblIoF8qnn7yHyz+MpEwkyZh20FHpAkxoxnMOFDz6zNewgsy84YyoHBqjwOUThMXtwwgeOIeBYnFLp1YWPPxcAW4p4SA4kySa0df9Ms5BGEP7lGr5MXV6LoKPE6/JPCjPKz1lA== Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 06:55:25 -0000 --089e0122f0fe51efcf04e2b51786 Content-Type: text/plain; charset=ISO-8859-1 Hi, Some culture shift may be necessary when changing from monitoring IPv4 to IPv4+IPv6 . For example, "interface counters" may count all packets, not just IPv4 packets. All existing network graphs and statistics are likely to be useless for monitoring IPv6 (separate from IPv4). Also, just because IPv4 is working over a network path and IPv6 is enabled over the same path, does not prove that IPv6 is working over the same path. How about backup links - It is necessary to send real IPv6 traffic over every path to test that it does go through. Pinging the GUA or ULA of every IPv6 router interfaces could be used to test if routing is working and ACLs permit traffic. Aim to test the IPv6 network the same ways as you test for IPv4 - management traffic, pings, application-layer tests etc. === There are also new things that you can monitor that are IPv6-specific. For example, poll each router to see what IPv6 routers it can see. On point-to-point or HSRP/VRRP router interfaces, you expect to see one other router; on non-HSRP/VRRP user interfaces, you expect to see no other routers. Are the other routers you can see "your" routers, or are they rogues advertising bogus routes, like 6to4 prefixes? You can snoop for rogue IPv6 routers even if you don't have your router's interface enabled to route IPv6 traffic. Are the RA's the router received recent, or received a while ago? If your router has OSPFv3 neighbors, are they all in state FULL? Thanks, John On 13 July 2013 23:46, Arturo Servin wrote: > Hi, > > We have sent this draft about considerations and recommendations to > monitor IPv6 and dual-stack networks and services. We have been talking > with people deploying IPv6 and we have found that not all monitor their > networks and not many monitor them properly. We also found some > challenges in monitor implementations that not fully support IPv6 > monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even > though monitoring v6 networks is as critical as doing it in v4, we have > not found many documents explaining how that has to be done (at least > guides with free access or up to date). > > There are also some misconceptions about monitoring IPv6, for > example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and > send them on IPv4 that we wanted to clarify. > > We collected some recommendations from informal conversations with > people during some training and NOGs meeting during this year but we > need some more input. We will be sharing this draft with other forums to > get more inputs but we wanted to share it here first. > > Best wishes, > Arturo and Mariela > > On 7/13/13 9:45 AM, fred@cisco.com wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please > take a look at it and comment. > > _______________________________________________ > > 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 > --089e0122f0fe51efcf04e2b51786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Some culture shift may be necessary= when changing from monitoring IPv4 to IPv4+IPv6 .

For example, "interface counters" may count all packets, not jus= t IPv4 packets.
All existing network graphs and statistics are likely to be useless fo= r monitoring IPv6 (separate from IPv4).

Also, just= because IPv4 is working over a network path and IPv6 is enabled over the s= ame path, does not prove that IPv6 is working over the same path.
How about backup links -=A0
It is necessary to send re= al IPv6 traffic over every path to test that it does go through.
= Pinging the GUA or ULA of every IPv6 router interfaces could be used to tes= t if routing is working and ACLs permit traffic.

Aim to test the IPv6 network the same ways as you test = for IPv4 - management traffic, pings, application-layer tests etc.


For example, poll each router to see what IPv6 routers = it can see.
On point-to-point or HSRP/VRRP router interfaces, you= expect to see one other router;
on non-HSRP/VRRP user interfaces= , you expect to see no other routers.
Are the other routers you can see "your" routers, or are the= y rogues advertising bogus routes, like 6to4 prefixes?

=
You can snoop for rogue IPv6 routers even if you don't have your r= outer's interface enabled to route IPv6 traffic.

Are the RA's the router received recent,= or received a while ago?

If your router has OSPFv= 3 neighbors, are they all in state FULL?=A0

Thanks,
=A0 =A0 John



On 13 July 2013 23:46, Arturo S= ervin <aservin@lacnic.net> wrote:
Hi,

=A0 =A0 We have sent this draft about considerations and recommendations to=
monitor IPv6 and dual-stack networks and services. We have been talking
with people deploying IPv6 and we have found that not all monitor their
networks and not many monitor them properly. We also found some
challenges in monitor implementations that not fully support IPv6
monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even
though monitoring v6 networks is as critical as doing it in v4, we have
not found many documents explaining how that has to be done (at least
guides with free access or up to date).

=A0 =A0 There are also some misconceptions about monitoring IPv6, for
example SNMPv3 !=3D SNMP+IPv6, or that you cannot collect IPv6 data and
send them on IPv4 that we wanted to clarify.

=A0 =A0 =A0We collected some recommendations from informal conversations wi= th
people during some training and NOGs meeting during this year but we
need some more input. We will be sharing this draft with other forums to get more inputs but we wanted to share it here first.

Best wishes,
Arturo and Mariela

On 7/13/13 9:45 AM, fred@cisco.com wr= ote:
> A new draft has been posted, at http://tools.ietf.org= /html/draft-servin-v6ops-monitor-ds-ipv6. Please take a look at it and = comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e0122f0fe51efcf04e2b51786-- From arturo.servin@gmail.com Tue Jul 30 02:22:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D086821E8091 for ; Tue, 30 Jul 2013 02:22:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYHnjQorf2-6 for ; Tue, 30 Jul 2013 02:21:59 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0960121F9AD2 for ; Tue, 30 Jul 2013 02:18:40 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so3751344veb.31 for ; Tue, 30 Jul 2013 02:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lSU2KbPIgfGKtXT9/uqxYdqYoJVLWvcJowwu8BLKLPc=; b=pjDFNB2dlEfiUK9rROQP+9l0ob0LJ/mjDh6hG7sD5Dse9HmwovRlA/H+cRVxHrIwiP wdbnkiWX9Ig5gT+ClvvHvWHs6rPf2Ixcbkoge18XF7lXUKgrAumOCelTwRI+0ntbF6xt Dwn/K4Pq+UWjpOg91GE+LbVg/uiHwu2KFqYMSx16TkQ+yQc1ZR9O5K5wCLUzOCoa9CsO 6PKKt83bhOEBsR6pf2Q5ABsoznoH9G00+0r1BoCz7L5al1Pawv5k3wlsqsUYbxRadBMn N8enndKa4eBQR29weP8evEQECGJMPl/uP3Pa0ayzBys4m5FpLjKOCsdl//K7zY1pLtgX xZEA== X-Received: by 10.220.104.74 with SMTP id n10mr9767039vco.74.1375175920409; Tue, 30 Jul 2013 02:18:40 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2001:df8:0:16:55a5:2b76:65f9:9f6a]) by mx.google.com with ESMTPSA id wf4sm29665095vdb.12.2013.07.30.02.18.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 02:18:39 -0700 (PDT) Message-ID: <51F784F2.1090904@gmail.com> Date: Tue, 30 Jul 2013 11:18:42 +0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Mann References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 09:22:01 -0000 John, Thanks for your comments. We really appreciate them. We will add them to the next revision. Some comments in line for clarification. On 7/30/13 8:54 AM, John Mann wrote: > Hi, > > Some culture shift may be necessary when changing from monitoring IPv4 > to IPv4+IPv6 . > > For example, "interface counters" may count all packets, not just IPv4 > packets. Taken, thanks. > All existing network graphs and statistics are likely to be useless for > monitoring IPv6 (separate from IPv4). Ok, this seems to be implicit to me. Do you want us to add some specific advice (or perhaps I didn't properly understand your point)? > > Also, just because IPv4 is working over a network path and IPv6 is > enabled over the same path, does not prove that IPv6 is working over the > same path. > How about backup links - > It is necessary to send real IPv6 traffic over every path to test that > it does go through. > Pinging the GUA or ULA of every IPv6 router interfaces could be used to > test if routing is working and ACLs permit traffic. OK, I think that I got your point. Is this practice common? Even if not common, if you or the WG find it useful we would add it. > > Aim to test the IPv6 network the same ways as you test for IPv4 - > management traffic, pings, application-layer tests etc. > > === > There are also new things that you can monitor that are IPv6-specific. > > For example, poll each router to see what IPv6 routers it can see. > On point-to-point or HSRP/VRRP router interfaces, you expect to see one > other router; > on non-HSRP/VRRP user interfaces, you expect to see no other routers. > Are the other routers you can see "your" routers, or are they rogues > advertising bogus routes, like 6to4 prefixes? > > You can snoop for rogue IPv6 routers even if you don't have your > router's interface enabled to route IPv6 traffic. > > Are the RA's the router received recent, or received a while ago? Basically the idea is to recommend to monitor RA in your network? Something else? The means could be what you suggest or to use something like NDPmon, right? > > If your router has OSPFv3 neighbors, are they all in state FULL? Is this something that is normally done, perhaps for large ISPs or Enterprises? Thanks! as From alexandru.petrescu@gmail.com Tue Jul 30 02:25:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6559921F9E44 for ; Tue, 30 Jul 2013 02:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 kZE+JPOslMoL for ; Tue, 30 Jul 2013 02:25:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id AE9C021F9950 for ; Tue, 30 Jul 2013 02:23:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6U9NJu4011097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Jul 2013 11:23:19 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6U9NIBK018126 for ; Tue, 30 Jul 2013 11:23:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.23]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6U9NFRK029398 for ; Tue, 30 Jul 2013 11:23:18 +0200 Message-ID: <51F78603.6070001@gmail.com> Date: Tue, 30 Jul 2013 11:23:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Any LTE IPv6 demo at IETF Berlin? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 09:25:35 -0000 Hello, I have some recollection of earlier discussion of SIM cards LTE in Berlin offered by a particular operator for trial by IETFers. But I havent seen mention since. Is it happenning? What's the status of IPv6 LTE in Berlin? Alex From markzzzsmith@yahoo.com.au Tue Jul 30 02:44:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1811E81CB for ; Tue, 30 Jul 2013 02:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[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 kn3dikGyUVs3 for ; Tue, 30 Jul 2013 02:43:57 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id 543EF11E81CC for ; Tue, 30 Jul 2013 02:43:47 -0700 (PDT) Received: from [66.196.81.174] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jul 2013 09:43:46 -0000 Received: from [98.139.212.209] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jul 2013 09:43:46 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 30 Jul 2013 09:43:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 814596.18146.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 18395 invoked by uid 60001); 30 Jul 2013 09:43:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1375177426; bh=v6fnM3x88lpzqBYcggvBg7X2IIniM3v/2i0yUWZ2las=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i5X8xrHTw0DsliV5RSbKy8EoWBaChIQWpb57w1dywQTBFrfYllwdqZ3x0eiS0CHuHnRDwTUdZRWLIbUcOslMTz4Ke0ImtobnPfAv/HfpggwV3ppVqiwqeryMvoXWTBdmNvOqbonq27Gssub+qtKZpL21l9y09B02NLiqBbvv/A0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CA8+7Km4LecKJmjZ9Y9IT2YctsYrRLLjoXjf/PW7YAf5rzA8JMmmiMQJF14vW5Gc1UzvKFFI136Jz/2sIpQd7XW4ywGqIxNmzsHqriLI18lOwf9Muu8aNIKQgEIglEHqqTjpb2wQUiBHyLe4qJJ5s0KksbtFuoijDTWh4YNS2lU=; X-YMail-OSG: aVcfp8MVM1lnUEnTnhfsJ46DjYZ6CYWgmSLdubUODX_cih1 z8.INhXk5NuROSH7s2Rlvp0sBucxW28Cs.1k9QBFhSRjFg6giKITKvX2XHjt 4M4QQoeNFlNv.hcCYA88s1FClR_E65rPvssP.6lFYHpUl9NpMPdkpb2tWtiz pvRbf9UYIZHgJ6SipB0MzSuLGIB1MJOFyOKFI4LIlofb7VUAOPLDQNqaQPYN QrCLovDcg7iUP.9By.1lr40UgX3TPSNurQ5TAqi4n1aNhn.5KMoJ3NpfWocj Io.HKAdwdkohK6b7kXElwGl.ECKfk.xBWkJHwR__wF5agrp1PDwLvhY57kQY khcgwTu4b1PMumA6raJ783.joxjJ_Js9SzhB31pQQTJDCPy5RGxLyJ0Nx5kt WXktyhjLmUlksW8Sxalp1_8JRLcGY2xsmtmxLGhYI.L6tTaB4KtBig2DI7A_ 20_WrAEcGoxM4GTclR.o_bVFJTFONXaGCxEBQKYgd2e.OWyepHwMEvD729J_ tT3GRgz3qjjoRh3LhrGlFbt2aWmQJAUgF8OHp.j_sZEelVfq0qIeCMOcvuRF hgo_eRgJCr0kLMQ-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 30 Jul 2013 02:43:46 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpJJ3ZlIGp1c3QgcG9zdGVkIHRoZSBmb2xsb3dpbmcgSUQgcmVnYXJkaW5nIG1vdmluZyB0byBhIExBTiBpbnRlcmZhY2UgREhDUHY2IHJlbGF5IG9yIGh5YnJpZCBzZXJ2ZXIvcmVsYXkgbW9kZWwgb24gQ0UgZGV2aWNlcy4gUmV2aWV3IGFuZCBjb21tZW50cyBhcHByZWNpYXRlZC4KCkknbGwgc2VlIGlucHV0IGZyb20gREhDIGFuZCBIb21lbmV0IFdHcyBvdmVyIHRoZSBuZXh0IGRheSBvciBzby4gKEkgdGhpbmsgaXQgcHJpbWFyaWx5IGZpdHMgaGVyZSBiZWNhdXNlIGl0IGlzIHByb3Bvc2luZyB1cGQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.151.566 References: <20130730093305.26257.79421.idtracker@ietfa.amsl.com> Message-ID: <1375177426.12621.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 30 Jul 2013 02:43:46 -0700 (PDT) From: Mark ZZZ Smith To: I Pv6 Operations In-Reply-To: <20130730093305.26257.79421.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-ce-dhcpv6-transparency-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:44:02 -0000 Hi,=0A=0AI've just posted the following ID regarding moving to a LAN interf= ace DHCPv6 relay or hybrid server/relay model on CE devices. Review and com= ments appreciated.=0A=0AI'll see input from DHC and Homenet WGs over the ne= xt day or so. (I think it primarily fits here because it is proposing updat= ing RFC6204).=0A=0A=0AThanks very much,=0AMark.=0A=0A=0A----- Forwarded Mes= sage -----=0A> From: "internet-drafts@ietf.org" = =0A> To: Mark Smith =0A> Cc: =0A> Sent: Tuesday,= 30 July 2013 7:33 PM=0A> Subject: New Version Notification for=09draft-smi= th-v6ops-ce-dhcpv6-transparency-00.txt=0A> =0A> =0A> A new version of I-D, = draft-smith-v6ops-ce-dhcpv6-transparency-00.txt=0A> has been successfully s= ubmitted by Mark Smith and posted to the=0A> IETF repository.=0A> =0A> File= name:=A0=A0=A0 draft-smith-v6ops-ce-dhcpv6-transparency=0A> Revision:=A0= =A0=A0 00=0A> Title:=A0=A0=A0 =A0=A0=A0 IPv6 CE Device DHCPv6 Option Tran= sparency=0A> Creation date:=A0=A0=A0 2013-07-30=0A> Group:=A0=A0=A0 =A0=A0= =A0 Individual Submission=0A> Number of pages: 11=0A> URL:=A0 =A0 =A0 =A0 = =A0 =A0 =0A> http://www.ietf.org/internet-drafts/draft-smith-v6ops-ce-dhcpv= 6-transparency-00.txt=0A> Status:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracke= r.ietf.org/doc/draft-smith-v6ops-ce-dhcpv6-transparency=0A> Htmlized:=A0 = =A0 =A0 =A0 =0A> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-tra= nsparency-00=0A> =0A> =0A> Abstract:=0A> =A0 [RFC6204] defines basic requi= rements for IPv6 Customer Edge Routers,=0A> =A0 to suit residential or sma= ll office IPv6 deployments.=A0 It describes a=0A> =A0 WAN interface DHCPv6= client and LAN interface DHCPv6 server=0A> =A0 implementation model.=A0 T= his model constrains the set of DHCPv6=0A> =A0 options that can be conveye= d between the upstream service provider=0A> =A0 and the hosts downstream o= f the CE device, to those supported by both=0A> =A0 the CE device's DHCPv6= client and server.=A0 To support further current=0A> =A0 and future DHCPv= 6 options, this memo instead proposes a DHCPv6 option=0A> =A0 "transparent= " implementation model for CE devices, primarily using=0A> =A0 DHCPv6 mess= age relaying.=0A> =0A> =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 =0A> =A0 =0A> =0A> =0A> Please note that i= t may take a couple of minutes from the time of submission=0A> until the ht= mlized version and diff are available at tools.ietf.org.=0A> =0A> The IETF = Secretariat=0A> From mcr@sandelman.ca Tue Jul 30 04:45:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01A621F9DFB for ; Tue, 30 Jul 2013 04:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Ohnyu-DerL-z for ; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 86B4121F99D0 for ; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 559F92017B; Tue, 30 Jul 2013 08:51:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CD76F63A7C; Tue, 30 Jul 2013 07:44:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BBD10636AD; Tue, 30 Jul 2013 07:44:04 -0400 (EDT) From: Michael Richardson To: Cameron.Byrne@T-Mobile.com, v6ops@ietf.org X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 11:45:45 -0000 --=-=-= Cameron, which scenario does the Android AOSP use? Are the concerns about applications caring about the prefix length real? I sure prefer scenario 1. I think that MIF-aware applications will be happier with two v6 addresses. (I think that privacy extensions are useless for a device/network which likely has the same /64 all the time) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfenAYqHRg3pndX9AQIp4QQAtFRXiR0KqKDq4+67hazF0Tgk5O/gkyq6 CQtqO99B2ud0x74GhlewoR6h/g8aSWr4wBelfil+HB/17CtThYuDV4RaGYhonaRG 1z1H1Q+WK9opHGMMIeDZp6TUruUVuUPRYWU28kI+S3va1DKnYHvVKbVYAR+y7N5l QgzM8FKDWr0= =iMOT -----END PGP SIGNATURE----- --=-=-=-- From john_brzozowski@cable.comcast.com Tue Jul 30 04:57:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F6E21F9943 for ; Tue, 30 Jul 2013 04:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=1.802, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 HFdQOLJGw+VX for ; Tue, 30 Jul 2013 04:57:16 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id B01C721F8DE3 for ; Tue, 30 Jul 2013 04:57:11 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.85258588; Tue, 30 Jul 2013 05:55:53 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 30 Jul 2013 07:57:07 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: Discussion of Unique Local Address announcement in routing Thread-Index: AQHOjRvq1k7HQPYCMEalFZimxubx/Q== Date: Tue, 30 Jul 2013 11:57:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Discussion of Unique Local Address announcement in routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 11:57:27 -0000 Thanks George for sharing data on this topic, some questions and comments. Do you have trend data for ULA use as IPv6 deployment has increased over time? Also from a Comcast point of view the ULA use you are seeing is strictly retailed based, meaning there are no routers that Comcast provides software for or manages that supports ULA at this time. Our internal requirements and the Cablelabs eRouter/HIPnet work we are doing also does not specify the use of ULA at this time. I find this data interesting in part because there was some testing recently done that indicates misbehaviors in specific scenarios where ULAs are enabled along side GUAs. This is of particular interest to us in part because we feel the use you are seeing may adversely impact our customer's experience. The attempt to use ULAs to connect the Internet from a home is problematic. Thanks again, John From ales.vizdal@t-mobile.cz Tue Jul 30 05:08:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9B11E8183 for ; Tue, 30 Jul 2013 05:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 dlCVKnNTH8fM for ; Tue, 30 Jul 2013 05:08:26 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 7964F11E80F7 for ; Tue, 30 Jul 2013 05:08:25 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 399812E0856; Tue, 30 Jul 2013 14:08:24 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 30 Jul 2013 14:08:23 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Tue, 30 Jul 2013 14:08:23 +0200 Thread-Topic: [v6ops] Any LTE IPv6 demo at IETF Berlin? Thread-Index: Ac6NBxcdgCGP/al7SCG8olc9wezgpAAFUrcw Message-ID: <1808340F7EC362469DDFFB112B37E2FCD25EA102D1@SRVHKE02.rdm.cz> References: <51F78603.6070001@gmail.com> In-Reply-To: <51F78603.6070001@gmail.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Any LTE IPv6 demo at IETF Berlin? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 12:08:31 -0000 I cannot provide any LTE, but can provide NAT64 / Dual-Stack capable SIM/AP= N for a short test if anybody is interested. Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Tuesday, July 30, 2013 11:23 AM > To: v6ops@ietf.org > Subject: [v6ops] Any LTE IPv6 demo at IETF Berlin? >=20 > Hello, >=20 > I have some recollection of earlier discussion of SIM cards LTE in Berlin= offered by a > particular operator for trial by IETFers. But I havent seen mention sinc= e. Is it > happenning? >=20 > What's the status of IPv6 LTE in Berlin? >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Jul 30 05:45:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1752111E814F for ; Tue, 30 Jul 2013 05:45:09 -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 wLIaoM9Azlmx for ; Tue, 30 Jul 2013 05:45:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 37A7521F9FF7 for ; Tue, 30 Jul 2013 05:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142; q=dns/txt; s=iport; t=1375188304; x=1376397904; h=date:from:message-id:to:subject:cc; bh=2IRNuGUTUoYSetySJSRyIjE3YLM8ujlcmNXba/l7B0g=; b=V1wVR8Tj8IimY8lBzpdyPxnYDEXkN33cwry6EN+MVJEijSbttMC/N31W wEJfkPqiTJhmbeShE1TtmpfCXbKuZeUYN2XRFYSB85SLbVjhnr343YWTr NW2OYuUt+zjPu/kGmuIn4ksJWZlfV5bBrNlUeY/0gbqOWzDHTTfTe5Tdf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAPAJ+091GrRDoJ/2dsb2JhbABbgwY1gxmpUwGRaQQDAYEeFnSDJDwtB4hwDbkSj34dg3EDiSqPXpAjgzQ X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="85357492" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 30 Jul 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6UCj0D2016649; Tue, 30 Jul 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r6UCj0k13216; Tue, 30 Jul 2013 05:45:00 -0700 (PDT) Date: Tue, 30 Jul 2013 05:45:00 -0700 (PDT) From: Message-Id: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org Subject: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 12:45:09 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at it and comment. From cb.list6@gmail.com Tue Jul 30 07:08:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7B11E81E4 for ; Tue, 30 Jul 2013 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 jcT+kWctCjWl for ; Tue, 30 Jul 2013 07:08:42 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4021F9E7E for ; Tue, 30 Jul 2013 07:08:42 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so12060062obc.20 for ; Tue, 30 Jul 2013 07:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ytJCCEjNkO5w1dsBCaDQsImTrWRmHQOy8/bRy7OYwAA=; b=p8z6WVuRiYhkmxh068fXBXFNb3hLPKXqsBJfwya/ynMlZfNqGsJd8U3hbT8GLtDxUQ D3qxFn0Sic6yKIZTr4EScuc+B6QzOhRsTWVbmTNXNYh8gU9tTE0sv0Y09anuvOacFb0c VyEWlFLaMzcmG6nh6fAzkkbvko8HSF3QxtopXtLLr6Ajx+y49ay+eSZY2U9jwUdqV3LT sdP08bilViFLJwMXavm9hWCpLW8klqeskEsNjOmZOqBeeNHk9DErx0It9rKrJ+l5GWD/ +wnAo6AQKKaJ47C9IBiPYeYTWExgRsTxQCKWiv14RMSbwEFDOjyI7H5Ue5aS7ye2hGru kBzg== MIME-Version: 1.0 X-Received: by 10.50.16.102 with SMTP id f6mr176664igd.41.1375193321720; Tue, 30 Jul 2013 07:08:41 -0700 (PDT) Received: by 10.64.147.102 with HTTP; Tue, 30 Jul 2013 07:08:41 -0700 (PDT) Received: by 10.64.147.102 with HTTP; Tue, 30 Jul 2013 07:08:41 -0700 (PDT) In-Reply-To: <12351.1375184644@sandelman.ca> References: <12351.1375184644@sandelman.ca> Date: Tue, 30 Jul 2013 07:08:41 -0700 Message-ID: From: "cb.list6" To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7bdc0cf070547c04e2bb2559 Cc: v6ops@ietf.org, Cameron.Byrne@t-mobile.com Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 14:08:43 -0000 --047d7bdc0cf070547c04e2bb2559 Content-Type: text/plain; charset=ISO-8859-1 On Jul 30, 2013 4:46 AM, "Michael Richardson" wrote: > > > Cameron, which scenario does the Android AOSP use? Aosp has not integrated this yet, but this implementation was submitted http://dan.drown.org/android/clat/ Scenario 2 is used. There is value in the device being able maintain communication (sockets) while tethering is turned on and off. Voip is a good example of something that should not bounce when tethering is turned on > Are the concerns about applications caring about the prefix length real? > I was given feedback that some apps care, and it should be noted > I sure prefer scenario 1. I think that MIF-aware applications will be > happier with two v6 addresses. > > (I think that privacy extensions are useless for a device/network which likely > has the same /64 all the time) > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7bdc0cf070547c04e2bb2559 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 30, 2013 4:46 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>
>
> Cameron, which scenario does the Android AOSP use?

Aosp has not integrated this yet, but this implementation wa= s submitted

http://dan.dr= own.org/android/clat/

Scenario 2 is=A0 used. There is value in the device being ab= le maintain communication (sockets) while tethering is turned on and off. V= oip is a good example of something that should not bounce when tethering is= turned on

> Are the concerns about applications caring about the pr= efix length real?
>

I was given feedback that some apps care, and it should be n= oted

> I sure prefer scenario 1. =A0I think that MIF-aware app= lications will be
> happier with two v6 addresses.
>
> (I think that privacy extensions are useless for a device/network whic= h likely
> has the same /64 all the time)
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--047d7bdc0cf070547c04e2bb2559-- From lorenzo@google.com Tue Jul 30 07:10:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9911E81FD for ; Tue, 30 Jul 2013 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1j92w8EoEm4w for ; Tue, 30 Jul 2013 07:10:42 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD821F9C88 for ; Tue, 30 Jul 2013 07:10:41 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id up14so4040914obb.39 for ; Tue, 30 Jul 2013 07:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nmYZQwznwhb/Fe8+aAfRfVhSx87L9PsUuxnxkk0Q3k4=; b=hhU451ynjVQsK0M3Daj3HRKEeAuBk6qMlujYhc0BftFKYksHNYzCSOsOK733yMyq+e jbgg0+xltuF+KVgWP2J0LkIT5VeIrrspxQsuOukH0jrPX6p2cfB7BMmU3mmPr46yCdED efplM8Bhypz1pTVUYzRZJlNhRcqNV45xL14r4WYv/lmVHM7/keSwEXeftLwWAyu7BT0v L+c3KRYWV5tuLNY6uDt40s/jZJ3Itfs/eWHD7LWa8IFxGMUoGVHm0+oz0aLosUSn6huU 2bW1gZjNoq0+hxxwqeFUc6uabtjkRYuFUbEDNLzK0EF+n/sN0MGVEimIQLkPqNKhTbqW c1gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nmYZQwznwhb/Fe8+aAfRfVhSx87L9PsUuxnxkk0Q3k4=; b=phzkaveBx3/SPdeIEyhq5L36JU62si3/oHA0JcyvpYGoAHfvtGfN6KzXwx0YeFbIUk hff91BuIXDm4/VlcDipxH2Tp2PFzm/X+rHygcz5KgQL1xwW9zs2oSMR2pHvjA2wJOKet En1n9Gwz/HNNtrArbWkiRQ0TO+0z598EsYbzRHPoIFZ4oxzJl/WKnpASJzE+BrPkhTo+ h8S7EAGRlINfLOGhD1u2X5aj7KHr+qSDbbwGsQaXHMMLRo2uL49H4j6x0DVxlPPc1rvA QggJAY3qe79Kh+I4BbNLpuE+gvXn8bDKMHA9pZHYAFW4O3twaf44fN0zPaKKoHaIUyVA oiDA== X-Received: by 10.50.127.145 with SMTP id ng17mr189805igb.6.1375193441493; Tue, 30 Jul 2013 07:10:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Tue, 30 Jul 2013 07:10:21 -0700 (PDT) In-Reply-To: <12351.1375184644@sandelman.ca> References: <12351.1375184644@sandelman.ca> From: Lorenzo Colitti Date: Tue, 30 Jul 2013 16:10:21 +0200 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=089e013a079e94164804e2bb2c77 X-Gm-Message-State: ALoCoQluc4Oy+gXK/k8AB56bLbi1ddEDS8IpnAvaq+OAoVFh1K9w/zHkNY3y1d3uT8bYoovQRe6RFSbDNDwY4ihQ6+xeANJBtHr89y1mAbWAHIhoKvUg2JKVWFXJqvn+8WMMJ2JTnZU4jqaTAFhrP9GPm4lMr1/2zktybzyVHJ1AUnZVbJ6U22XjzMPcaCOfSWRjmZKx8Vqs Cc: "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 14:10:47 -0000 --089e013a079e94164804e2bb2c77 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 1:44 PM, Michael Richardson wrote: > Cameron, which scenario does the Android AOSP use? > Are the concerns about applications caring about the prefix length real? > I doubt that the prefix length is a real concern. Do we have any examples of this? I sure prefer scenario 1. I think that MIF-aware applications will be > happier with two v6 addresses. > Why? One would hope that a MIF-aware application would understand that it's possible to have an IP address on one interface and use it on another interface. (I think that privacy extensions are useless for a device/network which > likely > has the same /64 all the time) > It doesn't have the same /64 all the time. When you lose coverage or switch to wifi, when you come back to the 3G network you'll get a different prefix. --089e013a079e94164804e2bb2c77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 1:44 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
Cameron, which scenario does the Android AOSP use?
Are the concerns about applications caring about the prefix length real?

I doubt that the prefix length is a real = concern. Do we have any examples of this?

I sure prefer scenario 1. =A0I think that MIF-aware applications will be happier with two v6 addresses.

Why? One= would hope that a MIF-aware application would understand that it's pos= sible to have an IP address on one interface and use it on another interfac= e.

(I think that privacy extensi= ons are useless for a device/network which likely
has the same /64 all the time)

It doesn= 't have the same /64 all the time. When you lose coverage or switch to = wifi, when you come back to the 3G network you'll get a different prefi= x.
--089e013a079e94164804e2bb2c77-- From mcr@sandelman.ca Tue Jul 30 07:55:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7C21E80DE for ; Tue, 30 Jul 2013 07:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 zAW50LdrOEqh for ; Tue, 30 Jul 2013 07:55:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3611821E80CB for ; Tue, 30 Jul 2013 07:55:11 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EC8820184; Tue, 30 Jul 2013 12:01:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9A61B63A7C; Tue, 30 Jul 2013 10:53:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8C845636AD; Tue, 30 Jul 2013 10:53:47 -0400 (EDT) From: Michael Richardson To: "cb.list6" In-Reply-To: References: <12351.1375184644@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: v6ops@ietf.org, Cameron.Byrne@t-mobile.com Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 14:55:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable cb.list6 wrote: > On Jul 30, 2013 4:46 AM, "Michael Richardson" = wrote: >> >> >> Cameron, which scenario does the Android AOSP use? > Aosp has not integrated this yet, but this implementation was submitt= ed > http://dan.drown.org/android/clat/ > Scenario 2 is=C2=A0 used. There is value in the device being able mai= ntain > communication (sockets) while tethering is turned on and off. Voip is= a good > example of something that should not bounce when tethering is turned = on I don't understand. Why does adding a second IP address change anything that is already alive? =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUffTeIqHRg3pndX9AQLzPQP/QAPV3nKjeXiFYSO7MJDSBtTG/RBcp/JI MPzs9wYNBCZiZjU5mfGMV0Q9bt51IbfJWsCfKSBu8ZhQM6Ux1ZcAWjDp39Fs2wyz 6W1KMut/CMr0ms7EuV7la/G78vhrM2Om4N/eOPvIdIRXVdxBd/z36CEmmc8yTs+R GqDDFF5u72U= =VlRw -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Jul 30 07:58:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880ED21E80E3 for ; Tue, 30 Jul 2013 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 vKqiGEnyKdBn for ; Tue, 30 Jul 2013 07:58:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3837421E80BB for ; Tue, 30 Jul 2013 07:58:07 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 386322018A; Tue, 30 Jul 2013 12:04:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A9C7E63A7C; Tue, 30 Jul 2013 10:56:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9A15B636AD; Tue, 30 Jul 2013 10:56:43 -0400 (EDT) From: Michael Richardson To: Lorenzo Colitti In-Reply-To: References: <12351.1375184644@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 14:58:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lorenzo Colitti wrote: mcr> I sure prefer scenario 1. =C2=A0I think that MIF-aware application= s will be mcr> happier with two v6 addresses. > Why? One would hope that a MIF-aware application would understand tha= t it's > possible to have an IP address on one interface and use it on another > interface. Ideally, a MIF aware application would see the same IP address on two diffe= rent interfaces as being in two entirely different domains. Having one IP makes debugging and human stuff harder. mcr> (I think that privacy extensions are useless for a device/network = which mcr> likely mcr> has the same /64 all the time) > It doesn't have the same /64 all the time. When you lose coverage or = switch to > wifi, when you come back to the 3G network you'll get a different pre= fix. That's might be true, but I really hope that they give me the same /64 when I'm in the same place, so that I can have longer lived incoming connections. Otherwise, I might as well NAT66 :-) =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUffUKIqHRg3pndX9AQKKnQP/cm8lwjlZMcQGliuq2JD5HSLtJXT1RmHB Yq+OM0HO8/jvfTyokQGah6l8BtmmPCrsYfuOlwHLOrCT4MDih/d3pTvMwj/4j7gM vq5FO2+MsBqDtN1lH/tGMrgtJYQE/C9UH3wVGSc4qqpS/icb+an2O6rs0sKyxgDS fXTCxLdA7r4= =TEtt -----END PGP SIGNATURE----- --=-=-=-- From cb.list6@gmail.com Tue Jul 30 08:03:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA611E8214 for ; Tue, 30 Jul 2013 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 WRyE5VIe1xhG for ; Tue, 30 Jul 2013 08:03:41 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9619A11E81E1 for ; Tue, 30 Jul 2013 08:03:41 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m6so9597298oag.34 for ; Tue, 30 Jul 2013 08:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qa1cvkTiB515wBxHIAL20AJ7/h38UL1CgZAqVzamL88=; b=e1Tr0lJWfl+gWIh+6+x3lfv10qVnlwjRIw2yOQtDgqL8nKQitXs879VoApxdu1ShbF E8VfDiCErRNMoLCk+NxTQMOItNj9m4O13T4LmMSeLpmE9xuCWTVKg7vf3tt47qXQNFBC lQn8byvxmDl+LW3eMHrq9SAOcAnGqzPzwub4nXgJyyTXjdiHUrSby8PBsCKkibpyAgHL Avkr9hXY0nRa6bGZnzTkoCYqG0Pq6t98AKQo5BcLUq817Tw2cItlNUz9vETOEXvD5Ukr gOg0ID04J+AApzX5IqFfwpR8h4UUsUAqici4jkQjYr7X4jho4czQViltV+VA6aYNpKwt H/9A== MIME-Version: 1.0 X-Received: by 10.50.127.167 with SMTP id nh7mr200279igb.34.1375196620238; Tue, 30 Jul 2013 08:03:40 -0700 (PDT) Received: by 10.64.147.102 with HTTP; Tue, 30 Jul 2013 08:03:40 -0700 (PDT) In-Reply-To: <8966.1375196027@sandelman.ca> References: <12351.1375184644@sandelman.ca> <8966.1375196027@sandelman.ca> Date: Tue, 30 Jul 2013 08:03:40 -0700 Message-ID: From: "cb.list6" To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 15:03:44 -0000 On Tue, Jul 30, 2013 at 7:53 AM, Michael Richardson wrote: > > cb.list6 wrote: > > On Jul 30, 2013 4:46 AM, "Michael Richardson" wrote: > >> > >> > >> Cameron, which scenario does the Android AOSP use? > > > Aosp has not integrated this yet, but this implementation was submitted > > > http://dan.drown.org/android/clat/ > > > Scenario 2 is used. There is value in the device being able maintain > > communication (sockets) while tethering is turned on and off. Voip is a good > > example of something that should not bounce when tethering is turned on > > I don't understand. > Why does adding a second IP address change anything that is already alive? > It should not, i agree. So, i am a little confused by your question. Scenario 1 moves the prefix from WAN to LAN, this may break an open connection. Scenario 2 replicates the IP on 2 interfaces Are you suggesting that we simply keep the /128 on the WAN and put the /64 on the LAN with normal SLAAC and new LAN inteface IP? The issue with that, is that on the LAN, the /128 on the WAN is not accounted for and may cause a conflict / duplicate, so it is easier to make the WAN and LAN intefaces IP the same CB > -- > Michael Richardson , Sandelman Software Works > > From lorenzo@google.com Tue Jul 30 08:42:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05A11E8205 for ; Tue, 30 Jul 2013 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gNIakZTGNZGl for ; Tue, 30 Jul 2013 08:42:48 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AA20511E80F5 for ; Tue, 30 Jul 2013 08:42:45 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so12366902obc.41 for ; Tue, 30 Jul 2013 08:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Oe4ANYfcHIQzPrAwgtJH/jYVHj7sfDXSXEBDWJWWxTo=; b=Tyj9h7Qk3tP27z5IIJ2yRsIxAeP1RKQukvCxolJfXdNhtqwxwI3VMB0OhC6sPCUfRb SVqTCUQ/SnyybtSBgFLBe/3bsmJU1b9JShnG9XURrq/9Z6lkPrvv2xplEXUcBWe6NiFp hRav7EQlDRJWtA/fbRwkPYG26tmshsmdq/LhmhuZaiDafGfy/m3Ip1gJEsan65G8KUX7 br8POq9rA7vVGZmb83a0q0vbR2+XneYp7xyPpngZU0RYmkj16cWdt9UqLVYas8/y7xhy YKOngzGTSisx2YlOXzitkduSEhS66XDXirUhpC8i8P7+tCOyNKwJ2Gf4K1zju0ci7Pkr Nclw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Oe4ANYfcHIQzPrAwgtJH/jYVHj7sfDXSXEBDWJWWxTo=; b=ERi7PfAZW3Ot9U7j3WqYyzhWLJ+umyBK+GCLxD0M3/BD2n20KxQS0WJyoZvpN73egA Suj7MgZV2eYcZSD1DSkmOEJ5EwYdMeFczbj7BGQqlkYal3dbGJ3bABBmq6Uk/7Hs9TI5 4gMLZX/CRqIQYjA/2d+1f8U9mTASU5/AV2dpFzN6cuJdrbnTgi69lvbEJcchZwT2CpAv ukxedcSYL/CDm5sOfvzPm0rgOFA0Z1jESXqE2m4HP/gsx7QB9ymqwJb/THh4dFm8dzIq jAkLg0UiULXcthn442q9oQPZ1bI9vdIwXl6rBqLlWAa0Giuw3oFFPCo/J4gnssPa98wn otpg== X-Received: by 10.43.181.136 with SMTP id pi8mr21513361icc.10.1375198964067; Tue, 30 Jul 2013 08:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Tue, 30 Jul 2013 08:42:23 -0700 (PDT) In-Reply-To: <9422.1375196203@sandelman.ca> References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> From: Lorenzo Colitti Date: Tue, 30 Jul 2013 17:42:23 +0200 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11c35008bfd6f704e2bc7528 X-Gm-Message-State: ALoCoQkR+z61aO00q/wkUvDLsurHf6JyOfK1xbypLTlMoo5oqNwG/OFuhBH1PoL+ppYxAvd8+R+wFEeAAgxklLk+ANskgtQwoQrsMtk1dGQRXNDp8RQk5DxDt+BhVJXsjVlbENIdk1Oo0Yzxs3DAidPB6WopJSlW2h1LIajTB3oWdzIpUJJebembggSI539SP70mT8zA6lMC Cc: "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 15:42:48 -0000 --001a11c35008bfd6f704e2bc7528 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 4:56 PM, Michael Richardson wrote: > Ideally, a MIF aware application would see the same IP address on two > different > interfaces as being in two entirely different domains. > Off-topic, but I don't think this is a fair assumption. The source of the information should determine what domain it's in, not the interface. --001a11c35008bfd6f704e2bc7528 Content-Type: text/html; charset=ISO-8859-1
On Tue, Jul 30, 2013 at 4:56 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Ideally, a MIF aware application would see the same IP address on two different
interfaces as being in two entirely different domains.

Off-topic, but I don't think this is a fair assumption. The source of the information should determine what domain it's in, not the interface.
--001a11c35008bfd6f704e2bc7528-- From lorenzo@google.com Tue Jul 30 08:51:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ECD11E8103 for ; Tue, 30 Jul 2013 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8Fo97oswf23d for ; Tue, 30 Jul 2013 08:50:59 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAC011E80D7 for ; Tue, 30 Jul 2013 08:50:59 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m6so9536297oag.20 for ; Tue, 30 Jul 2013 08:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T7x8xjTd+0kUzuJZpAIfLkBZ0bFNJwe7K3VB88i5OCc=; b=Hv7CJyFBjxHdrmRABLAYJoJHgU6cTIQtF5CoCZz/rbWjt28jh0zCjmkUSIfGfgkmos 4WRcxwgL7A/tEzeRXPj2WLmQe+HbEY0RBdWqCly3GZ7idLujzOAS9SnZwt9bHqbhnVfT O/tSpKgoy8/yMM1U5V5hWEnNSw+8X9e1vBHe8xHdWGsTqVL1WcJAAjsNUrdidrCPx99c MNpAOB8BL4kgp9gkgw1TuDgcVmrr8MYH8hrv1C+eySnobUzooN0Czq+PfRYzcFafW5Oz 9mnhTaWcv/8l9ejEY2pmcKLOaGumk2TzsgM3HJw7RR67H6scK9F0qY0tJbnJBQYo3FU2 EWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=T7x8xjTd+0kUzuJZpAIfLkBZ0bFNJwe7K3VB88i5OCc=; b=Vn73NblsKKKH1b62IeLijpb/ZlYvClXivdKeGGNV7nnCBCxWyh/hfLyWONzI0k+yvA Jin1M03R9kAWy6VtP0eXMeBaRMoZjyIXL4UzEWHvZnLmAhyfiMQLaSxTRBj84pjCCw1P MmYIxKEQOrQDk+JLqgcRwae0dF2EqVwptMOoprqoqdQ6P5Ck+WMacvDvU9aV1/R1BCU8 VLOVDQWWTaE3ZqCVeqKPfQcYBRkpOF/qgLnFzx84qoP6yukuEsDSU5HEIZ90Q0K27ynH RdMeD17AtNatxmQ31eNqB+PUPj3pJVrfXSm1+3i+B5b5MxbHv7pFaGKBApMxHaFm+zt3 uHkg== X-Received: by 10.50.18.5 with SMTP id s5mr241348igd.6.1375199459088; Tue, 30 Jul 2013 08:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Tue, 30 Jul 2013 08:50:38 -0700 (PDT) In-Reply-To: References: <12351.1375184644@sandelman.ca> <8966.1375196027@sandelman.ca> From: Lorenzo Colitti Date: Tue, 30 Jul 2013 17:50:38 +0200 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=089e013cc1c44145f104e2bc93d3 X-Gm-Message-State: ALoCoQm0zRzW1SxN4xq8AFERCixKojrU0C1T+MFuvUcFuwiL3ySlyZjWZyiRmfqKIcDwk5lrdgroYhqynmdSCyJ+6hKOEBXCsWT4pLOZpBQWZg58IMQOHHcWJnlDTBjJ1hhFeXd3fGuq8HogmV7y2CnIEcMPVBgMBShOBShnG1Y3bx3PuNBmDNo1kWEUrxphBzEkKvoIkSnA Cc: Michael Richardson , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 15:51:00 -0000 --089e013cc1c44145f104e2bc93d3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 5:03 PM, cb.list6 wrote: > It should not, i agree. So, i am a little confused by your question. > > Scenario 1 moves the prefix from WAN to LAN, this may break an open > connection. > > Scenario 2 replicates the IP on 2 interfaces > Why do we document these two as completely separate "scenarios"? As far as I can see these "scenarios" are simply two ways of meeting the same requirement, which is "the phone must not allow a tethered client to use an IP address that is being used by the phone". Instead of having most of the content of the document duplicated into two mostly-identical scenarios, can we just list that requirement and provide two example ways of doing it? (Neither of the two is correct, BTW - the right thing to do is for the phone to keep all the addresses assigned to the northbound interface and defend all of them against DAD on the southbound interfaces.) --089e013cc1c44145f104e2bc93d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 5:03 PM, cb.list6 <cb.list6@gmai= l.com> wrote:
It should not, i agree. =A0So, i am a little= confused by your question.

Scenario 1 moves the prefix from WAN to LAN, this may break an open connect= ion.

Scenario 2 replicates the IP on 2 interfaces

Why do we document these two as completely separate "scenarios&q= uot;? As far as I can see these "scenarios" are simply two ways o= f meeting the same requirement, which is "the phone must not allow a t= ethered client to use an IP address that is being used by the phone". = Instead of having most of the content of the document duplicated into two m= ostly-identical scenarios, can we just list that requirement and provide tw= o example ways of doing it?

(Neither of the two is correct, BTW - the right thing t= o do is for the phone to keep all the addresses assigned to the northbound = interface and defend all of them against DAD on the southbound interfaces.)=
--089e013cc1c44145f104e2bc93d3-- From Ted.Lemon@nominum.com Tue Jul 30 08:56:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AA321E80FD for ; Tue, 30 Jul 2013 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wo+GdHmIThn for ; Tue, 30 Jul 2013 08:55:54 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4E321E80DB for ; Tue, 30 Jul 2013 08:55:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUffh77xqaKuJ/V8yPGlYTyudS2BRhBRs@postini.com; Tue, 30 Jul 2013 08:55:28 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 C0B011B8271 for ; Tue, 30 Jul 2013 08:55:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 B8567190065; Tue, 30 Jul 2013 08:55:27 -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.02.0318.004; Tue, 30 Jul 2013 08:55:20 -0700 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: AQHOjRpdB5svllziVkGDgHdv0CNeipl9uDGAgAAM9YCAAAzCgIAAA54A Date: Tue, 30 Jul 2013 15:55:20 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19F75716AE4BCF429F139A9B9287985C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 15:56:02 -0000 On Jul 30, 2013, at 5:42 PM, Lorenzo Colitti wrote: > Off-topic, but I don't think this is a fair assumption. The source of the= information should determine what domain it's in, not the interface. There is terminology in the MIF architecture document that I think would he= lp to clarify this discussion if the participants are interested. Lorenzo= is right, and Michael is also right, depending on whether the duplicate IP= address is in one explicit provisioning domain or in two explicit or impli= cit provisioning domains. It can't ever be in a single implicit provision= ing domain. From mcr@sandelman.ca Tue Jul 30 09:20:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96121F9F34 for ; Tue, 30 Jul 2013 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 2FQnARBbfX1S for ; Tue, 30 Jul 2013 09:20:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8827121F9EBE for ; Tue, 30 Jul 2013 09:20:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BA0CB20251; Tue, 30 Jul 2013 13:26:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F0EAA63A7C; Tue, 30 Jul 2013 12:19:02 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF62C636AD; Tue, 30 Jul 2013 12:19:02 -0400 (EDT) From: Michael Richardson To: "cb.list6" In-Reply-To: References: <12351.1375184644@sandelman.ca> <8966.1375196027@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 16:20:50 -0000 --=-=-= cb.list6 wrote: mcr> I don't understand. mcr> Why does adding a second IP address change anything that is already alive? > It should not, i agree. So, i am a little confused by your question. > Scenario 1 moves the prefix from WAN to LAN, this may break an open connection. Ah, I understand, the operation of moving the prefix, if done as break before make, which is required sometimes, might kill connections. > Scenario 2 replicates the IP on 2 interfaces > Are you suggesting that we simply keep the /128 on the WAN and put the > /64 on the LAN with normal SLAAC and new LAN inteface IP? The issue > with that, is that on the LAN, the /128 on the WAN is not accounted > for and may cause a conflict / duplicate, so it is easier to make the > WAN and LAN intefaces IP the same I wonder if this is really true. I know that Linux, by default, with a weak host model, will answer IPv4 ARP for interface 2, when asked for it on interface 1. (Many think this is a bug, even a security bug, and there are options in 2.6.8-ish to disable that) I will try the same thing with DAD. I have a test bench where this will be easy. I imagine it ought to fail, but I could be wrong. It is something that could be fixed if desired. I don't know what the specification say, and if weak/strong host model was even taken into account here. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUffndIqHRg3pndX9AQI5LgP+PlFhXQdHbVBlvjlOLqd0SRQlTDyyskyN uNuG3BWOIHSlUmXUBDTsjekQdX8/e0uivZEsoWiBbdGpbcnSh1/j/HPKuBaQ4n/P pQXgPwK4Jf0yCC25CsAhSzF+21CalXuXwMRtqicdwwJ2CPnP2ifKwe0wXyurVKul 4mUeZE4tQwg= =8e2d -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Jul 30 09:21:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB8221F9EAF for ; Tue, 30 Jul 2013 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 4zEaBAIO1X69 for ; Tue, 30 Jul 2013 09:21:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 89B5E21F9EA7 for ; Tue, 30 Jul 2013 09:21:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A875620251; Tue, 30 Jul 2013 13:27:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DF5A163A7C; Tue, 30 Jul 2013 12:19:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D210D636AD; Tue, 30 Jul 2013 12:19:55 -0400 (EDT) From: Michael Richardson To: Lorenzo Colitti In-Reply-To: References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 16:21:25 -0000 --=-=-= Lorenzo Colitti wrote: mcr> Ideally, a MIF aware application would see the same IP address on two mcr> different mcr> interfaces as being in two entirely different domains. > Off-topic, but I don't think this is a fair assumption. The source of the > information should determine what domain it's in, not the interface. point taken. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUffnqYqHRg3pndX9AQLwMwP/e7fETp+lsoBQWmN3RKaD/2iGLsqBQ+se nBWJvcLawpnvvJhgzH/cSOO8bgMcqayxUC/N9v6ox/nF4/tUWWuRVTypHbQYCrJu Y3jajux/pktdrWuI5kpGkDAQ8pXN1P+/oWqhM6uJSWzlqbZGj4iMn5QFNNVUjPPF lsj4DycLCnU= =SJUG -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Tue Jul 30 09:30:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31611E81E9 for ; Tue, 30 Jul 2013 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6GJ4ykikYzot for ; Tue, 30 Jul 2013 09:30:08 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C10DF11E8103 for ; Tue, 30 Jul 2013 09:30:01 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so1151162obc.31 for ; Tue, 30 Jul 2013 09:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GwoDMQbz+jthUqJkSjprNQom+I7LoMfq80w3CO7S0os=; b=frs2JSth5+XwGmMewenKFqwSjTWhMpZdreCSa2NZibSFLl7yMB4cn4/Fk0I18ofg0e c5yK5a0SqtOUaAqDo2mbzx8CET+X6HcAFDqZsJ1SG9V9gXyNNGi7cv2JDQiSNb1hkeJW 4/f1jaDuT6I88QLtH0yKzznNwniNwGo2Ef/AfS0nwH/d0ODxAoERQkevMbWw91GpAQmZ DazpTcZXS20rYxFtmDGPJBEaq8eE/96IFj7HL522o9Pm3/tfB+qDJFKOH9LR+evhmPEy mBCRWLs69shZCY5FuFaC2l2KMLJP6no8U4WlThthS4Lxj52JYL/CDINAafas/oJcYqJy xftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=GwoDMQbz+jthUqJkSjprNQom+I7LoMfq80w3CO7S0os=; b=anprD1wM59GJGIFa4lSglFI77usFGhLU47pKGhiAB+uYx+cjexsq5L1URROHTDfe4s sDCAcE5mGmC64Id79tN8+N2n2ANNn62pAQXiD+aL4Q3VWN47vc1eS1R2CTBelK/H01pV W97uk6PaPsD71VQMe0+5sqJICMT2yBlkFocblWN3V9GUySgUF9FT+7hchhozzB/+2bbO hey8yUEdvX6GXdxBHW200gUNF0ZVOaEKBvaRPVg0Z/wGx766DZnbAHNJKNo0506iVrNH 1Gb2xNyX9/Q7ytjznqxk7dXwpnSzK04YEhvwnPSLOO12o1YlNCmNQPRPgU+oeZ478HdL TpxA== X-Received: by 10.50.119.42 with SMTP id kr10mr250322igb.20.1375201799909; Tue, 30 Jul 2013 09:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Tue, 30 Jul 2013 09:29:39 -0700 (PDT) In-Reply-To: <22153.1375201142@sandelman.ca> References: <12351.1375184644@sandelman.ca> <8966.1375196027@sandelman.ca> <22153.1375201142@sandelman.ca> From: Lorenzo Colitti Date: Tue, 30 Jul 2013 18:29:39 +0200 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=089e013c64aac7617404e2bd1e1a X-Gm-Message-State: ALoCoQnxxGjhgRsZ20/H272UXRRZxEL2ljjhEW1oP4cT9q2rM1bqkaWbJuCIcUsQx31LJmTxFxNvSNCjeyk8YUqfa1ZZRYMBWiGXivPgvsMXfF9TUgLJfNDV4DgHTfwtFEWIwEYet21dJKxiULcPdt+DO9Z7yfV9YEGhpddfbVlWM659SNUol3SAQHEtc7tLP3Q+VlNOKmZZ Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 16:30:08 -0000 X-List-Received-Date: Tue, 30 Jul 2013 16:30:08 -0000 --089e013c64aac7617404e2bd1e1a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 6:19 PM, Michael Richardson wrote: > I will try the same thing with DAD. I have a test bench where this will be > easy. > I imagine it ought to fail, but I could be wrong. It is something that > could > be fixed if desired. I don't know what the specification say, and if > weak/strong host model was even taken into account here. > I believe you'll find that it doesn't work. If nothing else, it doesn't do MLD joins on all interfaces when you add an address to one interface. --089e013c64aac7617404e2bd1e1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 6:19 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
<= div class=3D"gmail_quote">
I will try the same thing with DAD. I have a= test bench where this will be easy.
I imagine it ought to fail, but I could be wrong. =A0It is something that c= ould
be fixed if desired. =A0I don't know what the specification say, and if=
weak/strong host model was even taken into account here.

I believe you'll find that it doesn't work. If no= thing else, it doesn't do MLD joins on all interfaces when you add an a= ddress to one interface.=A0
--089e013c64aac7617404e2bd1e1a-- From Nick.Heatley@ee.co.uk Tue Jul 30 09:56:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983C621F9B40 for ; Tue, 30 Jul 2013 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 zZ0EYlLUSHrX for ; Tue, 30 Jul 2013 09:56:39 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) by ietfa.amsl.com (Postfix) with ESMTP id AB74321F9D1C for ; Tue, 30 Jul 2013 09:55:52 -0700 (PDT) Received: from [85.158.137.35:63687] by server-11.bemta-3.messagelabs.com id B8/91-26159-610F7F15; Tue, 30 Jul 2013 16:55:50 +0000 X-Env-Sender: Nick.Heatley@ee.co.uk X-Msg-Ref: server-14.tower-134.messagelabs.com!1375203349!23803423!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31832 invoked from network); 30 Jul 2013 16:55:50 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-14.tower-134.messagelabs.com with SMTP; 30 Jul 2013 16:55:50 -0000 Received: from hatmmar02.TMOUSERSUK.AD.T-MOBILE.CO.UK (Not Verified[172.27.190.5]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Tue, 30 Jul 2013 17:57:43 +0100 Received: from hatmsg001.TMOUSERSUK.AD.T-MOBILE.CO.UK (Not Verified[10.243.193.75]) by hatmmar02.TMOUSERSUK.AD.T-MOBILE.CO.UK with MailMarshal (v6, 8, 3, 9481) id ; Tue, 30 Jul 2013 17:55:48 +0100 Received: from HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK ([10.243.197.37]) by hatmsg001.TMOUSERSUK.AD.T-MOBILE.CO.UK with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 17:55:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 17:55:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac6LqfI7rObwrzArQiiBGLYLzEYyRQAuKnow References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> From: "Heatley, Nick" To: "cb.list6" , "Fred Baker" X-OriginalArrivalTime: 30 Jul 2013 16:55:49.0242 (UTC) FILETIME=[A47FC5A0:01CE8D45] Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 16:56:47 -0000 Hi Cameron, >=20 > b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling this > feature in the HSS/HLR breaks roaming and there is no way to ensure > this issue is fixed in the hundreds of networks that are potentially > impacted. There are some backs to do on the home network that can make > this easier but not exposing partner networks to the new release 8 > features. [NH] Cameron I assume you referring to the issue of extended MAP (for Ipv4v6) causing exception at the visited operator's network? Thanks for highlighting this issue. I guess I would like to know if the number of problem operators is significant, or a few isolated cases. Do you or anyone have information to infer this is widespread or systemic? If it is unknown lets acknowledge it as such. If cases are isolated, then there may be operational actions a dual stack operator can take; for sake of argument, a roaming steering solution could be applicable to blacklist a problem operator and steer the outbound roamers away before the exception occurs. I have not yet arrived at the conclusion that ipv4v6 roaming cannot be made to work, but perhaps I haven't seen the extent of the problem? Regards, Nick NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshir= e, AL10 9BW From brian.e.carpenter@gmail.com Tue Jul 30 15:13:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434C311E8183 for ; Tue, 30 Jul 2013 15:13:40 -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 AbJ6CVd-K+oi for ; Tue, 30 Jul 2013 15:13:39 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A2B2F11E8125 for ; Tue, 30 Jul 2013 15:13:39 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf11so81844pab.24 for ; Tue, 30 Jul 2013 15:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gtWm+H/fcK30lGVpD+p+zbS4Kr76AAkZoABg+8+tOso=; b=WDD/c4zMogskdHeTgeJutBK4NdoqhsRZCphs6NW+jQ9jW6xNhZo36oMGEK0hIUeu/v onjCNYgJ4eQv7iX60aqlV/YJfRRL+B0qb4lu0xpWzW7QGaUXuTw/Ob0ye8lETysNZ58q 71JgMeEwgrGohrzfdPXIFlWTAV861PHqK558Fah7OPqYBQICl6EFDhz4LNkAqavGc0/d MqAMkdMB+qfUrkdyd8uzTCYZish/ZxonyLWQ4vxLoZHyrp0f6vML7PArZvZpMgjy5Eap vcFKANHNPCTIyizkusbZfhOqF4dhr8n54oxUjpCCEpmvAIsN1FkJ+e6JXx45kmNMJ5+H JqHQ== X-Received: by 10.69.10.129 with SMTP id ea1mr76163619pbd.107.1375222419303; Tue, 30 Jul 2013 15:13:39 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id 7sm263505paf.22.2013.07.30.15.13.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 15:13:38 -0700 (PDT) Message-ID: <51F83A94.1010001@gmail.com> Date: Wed, 31 Jul 2013 10:13:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: [v6ops] Reachability [was: draft-ietf-v6ops-64share] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2013 22:13:40 -0000 On 31/07/2013 03:55, Ted Lemon wrote: > On Jul 30, 2013, at 5:42 PM, Lorenzo Colitti wrote: >> Off-topic, but I don't think this is a fair assumption. The source of the information should determine what domain it's in, not the interface. > > There is terminology in the MIF architecture document that I think would help to clarify this discussion if the participants are interested. Lorenzo is right, and Michael is also right, depending on whether the duplicate IP address is in one explicit provisioning domain or in two explicit or implicit provisioning domains. It can't ever be in a single implicit provisioning domain. IMHO the question is broader than the phrase "provisioning domain" implies. That is about where the address comes from. The more general aspect is the scope of reachability of the address. I came to the conclusion a few years ago that we need a generic way of naming an individual scope of reachability (which in the case under discussion might mean the union of two provisioining domains, but who knows?). If the metadata for a prefix included all the scopes of reachability that apply to it, things might be easier. (There is some specfic text about this notion in section 2 of http://tools.ietf.org/html/draft-carpenter-grobj-reqts-00). Brian From alexandru.petrescu@gmail.com Tue Jul 30 23:49:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB0621E80B9 for ; Tue, 30 Jul 2013 23:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.691 X-Spam-Level: X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 CRVl2ONQl2nH for ; Tue, 30 Jul 2013 23:49:07 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5814011E8165 for ; Tue, 30 Jul 2013 23:49:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6V6n5ft000694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jul 2013 08:49:05 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6V6n5mr018419; Wed, 31 Jul 2013 08:49:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6V6n4pP017864; Wed, 31 Jul 2013 08:49:04 +0200 Message-ID: <51F8B35F.7020703@gmail.com> Date: Wed, 31 Jul 2013 08:49:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <51F78603.6070001@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD25EA102D1@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD25EA102D1@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Any LTE IPv6 demo at IETF Berlin? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 06:49:13 -0000 Le 30/07/2013 14:08, Vízdal Ale¹ a écrit : > I cannot provide any LTE, but can provide NAT64 / Dual-Stack capable > SIM/APN for a short test if anybody is interested. I am interested in the test results but I dont have an LTE device with me. I wonder what is the APN name? What is the cell operator ids? Is the terminal getting a /64? Is it doing IPv6/LTE and IPv6/3G? Any report along these lines is useful. Thanks, Alex > > Ales > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Tuesday, July 30, 2013 11:23 AM To: v6ops@ietf.org Subject: >> [v6ops] Any LTE IPv6 demo at IETF Berlin? >> >> Hello, >> >> I have some recollection of earlier discussion of SIM cards LTE in >> Berlin offered by a particular operator for trial by IETFers. But >> I havent seen mention since. Is it happenning? >> >> What's the status of IPv6 LTE in Berlin? >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From Ted.Lemon@nominum.com Wed Jul 31 00:58:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5427211E8174 for ; Wed, 31 Jul 2013 00:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odvH6IsgXsoW for ; Wed, 31 Jul 2013 00:57:56 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 72B3311E8177 for ; Wed, 31 Jul 2013 00:57:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUfjDhDCNdaXagesGzRIUBd0i6FJZWZl3@postini.com; Wed, 31 Jul 2013 00:57:56 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 D46F91B8283 for ; Wed, 31 Jul 2013 00:57:55 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 81186190065; Wed, 31 Jul 2013 00:57:54 -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.02.0318.004; Wed, 31 Jul 2013 00:57:54 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: Reachability [was: draft-ietf-v6ops-64share] Thread-Index: AQHOjXILgP4s3Cr1Y0KYZoQxVxepkJl+4cUA Date: Wed, 31 Jul 2013 07:57:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775239C49@mbx-01.win.nominum.com> References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> <51F83A94.1010001@gmail.com> In-Reply-To: <51F83A94.1010001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EE8A93513750641AD0F671F8DB01FB3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] Reachability [was: draft-ietf-v6ops-64share] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jul 2013 07:58:03 -0000 On Jul 31, 2013, at 12:13 AM, Brian E Carpenter wrote: > I came to the conclusion a few years ago that we need a generic way of > naming an individual scope of reachability (which in the case under > discussion might mean the union of two provisioining domains, but > who knows?). If the metadata for a prefix included all the scopes > of reachability that apply to it, things might be easier. An implicit provisioning domain is one that wasn't specified, but assumed b= y the host. A formal provisioning domain is specified by configuration in= formation received from the network. The architecture doc requires that in = order for two provisioning domains to be the same, they have to both be for= mal and be securely validated. It seems to me that reachability is a property of an advertised prefix, and= not of a provisioning domain. So if you have the same IP address on two = interfaces, you have the same prefix, and hence the same reachability, with= respect to that prefix. Obviously if the reachability isn't the same this will cause problems, but = I think that's a configuration error. From cb.list6@gmail.com Wed Jul 31 21:40:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2710421F9B6A for ; Wed, 31 Jul 2013 21:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IveGUPhe9DjV for ; Wed, 31 Jul 2013 21:40:37 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F34D521F8EFE for ; Wed, 31 Jul 2013 21:40:36 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1279202wgh.14 for ; Wed, 31 Jul 2013 21:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5fACvBwuYVzylJxLzXpExxnY+X37rJ9YPbGFHSHxCjA=; b=aS7UYae4SKhop3eQK84s3jPNV9C40nNy4mS0d7xfqeAAmMN8R9MocoksPO/CYbQRok 0B/AZefrBSS1vBQegoyVKd3S4SeEFK00l6w3Wk09mbHD1Qm/zJEE12SUbb6j26e/sSag BDWA/87c9W7xUhJHeTKO+2OcQjF1V/umYGc6iCHq1yRBLLMxa4uK3fKwFcyuLmH2U6d0 ha4qvY3q0tNprTVVoP9cY7iG0oBX+Dp2njE/77chNAf7bICPV3BpEpUB5Vx/EdK+1n6Z 6IJjEzSD5Zd55r0SBPzQG53NUX+RCGJEtjZHLKziCcCM+pfiS/+WOe8rbvAerURiE6gc 0vbQ== MIME-Version: 1.0 X-Received: by 10.194.77.167 with SMTP id t7mr6240320wjw.27.1375332036154; Wed, 31 Jul 2013 21:40:36 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Wed, 31 Jul 2013 21:40:35 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Wed, 31 Jul 2013 21:40:35 -0700 (PDT) In-Reply-To: References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> Date: Wed, 31 Jul 2013 21:40:35 -0700 Message-ID: From: "cb.list6" To: Nick Heatley Content-Type: multipart/alternative; boundary=047d7bf0d628769c3d04e2db71e8 Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Aug 2013 04:40:38 -0000 --047d7bf0d628769c3d04e2db71e8 Content-Type: text/plain; charset=ISO-8859-1 Hi Nick, On Jul 30, 2013 9:55 AM, "Heatley, Nick" wrote: > > Hi Cameron, > > > > > b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling > this > > feature in the HSS/HLR breaks roaming and there is no way to ensure > > this issue is fixed in the hundreds of networks that are potentially > > impacted. There are some backs to do on the home network that can > make > > this easier but not exposing partner networks to the new release 8 > > features. > > [NH] Cameron I assume you referring to the issue of extended MAP (for > Ipv4v6) causing exception at the visited operator's network? Yes Thanks for > highlighting this issue. I guess I would like to know if the number of > problem operators is significant, or a few isolated cases. Do you or We saw a widespread issue in the 10 minutes before we rolled back the changes. > anyone have information to infer this is widespread or systemic? If it The vendors gear / involved is highly deployed, afaik > is unknown lets acknowledge it as such. > If cases are isolated, then there may be operational actions a dual > stack operator can take; for sake of argument, a roaming steering > solution could be applicable to blacklist a problem operator and steer > the outbound roamers away before the exception occurs. Well, there is money involved in steering. Money is usually top of mind for the folks involved, not v6. > I have not yet arrived at the conclusion that ipv4v6 roaming cannot be > made to work, but perhaps I haven't seen the extent of the problem? I am sure it can be made to work, I am just noting there is operational risk. I know because we hit it, but our ops folks had the presence of mind to roll back quickly In the long run, we plan to have whitelist for the v4v6 extended attribute, but HLR features are on an 18 month cycle for us. We would like all our apns to support any combination of v4, v4v6, or v6. But we can only safely support v4 or v6 in 2013. In the 2nd half of 2014, we may be able to try v4v6 again. CB > Regards, > Nick > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. > > Everything Everywhere Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW --047d7bf0d628769c3d04e2db71e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Nick,

On Jul 30, 2013 9:55 AM, "Heatley, Nick" <Nick.Heatley@ee.co.uk> wrote: >
> Hi Cameron,
>
> >
> > b. =A0dual-stack 1 PDP (v4v6) will not work any time soon. =A0Ena= bling
> this
> > feature in the HSS/HLR breaks roaming and there is no way to ensu= re
> > this issue is fixed in the hundreds of networks that are potentia= lly
> > impacted. =A0There are some backs to do on the home network that = can
> make
> > this easier but not exposing partner networks to the new release = 8
> > features.
>
> [NH] Cameron I assume you referring to the issue of extended MAP (for<= br> > Ipv4v6) causing exception at the visited operator's network?

Yes

Thanks for
> highlighting this issue. I guess I would like to know if the number of=
> problem operators is significant, or a few isolated cases. Do you or

We saw a widespread issue in the 10 minutes before we rolled= back the changes.

> anyone have information to infer this is widespread or = systemic? If it

The vendors gear / involved is highly deployed, afaik

> is unknown lets acknowledge it as such.
> If cases are isolated, then there may be operational actions a dual > stack operator can take; for sake of argument, a roaming steering
> solution could be applicable to blacklist a problem operator and steer=
> the outbound roamers away before the exception occurs.

Well, there is money involved in steering. Money is usually = top of mind for=A0 the folks=A0 involved,=A0 not v6.

> I have not yet arrived at the conclusion that ipv4v6 ro= aming cannot be
> made to work, but perhaps I haven't seen the extent of the problem= ?

I am sure it can be made to work, I am just noting there is = operational risk. I know because we hit it, but=A0 our ops folks had the pr= esence of mind to roll back quickly

In the long run, we plan to have whitelist for the v4v6 exte= nded attribute,=A0 but HLR features are on an 18 month cycle for us.=A0 We = would like all our apns to support any combination=A0 of v4, v4v6, or v6. B= ut we can only safely support v4 or v6 in 2013.=A0 In the 2nd half of 2014,= we may be able to try v4v6 again.

CB

> Regards,
> Nick
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-name= d person(s). =A0If you are not the intended recipient, notify the sender im= mediately, delete this email from your system and do not disclose or use fo= r any purpose.
>
> We may monitor all incoming and outgoing emails in line with current l= egislation. We have taken steps to ensure that this email and attachments a= re free from any virus, but it remains your responsibility to ensure that v= iruses do not adversely affect you.
>
> Everything Everywhere Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Hatfield Business Park, Hatfield, Hertfords= hire, AL10 9BW

--047d7bf0d628769c3d04e2db71e8-- From brian.e.carpenter@gmail.com Wed Jul 31 21:56:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E4421F9A71 for ; Wed, 31 Jul 2013 21:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 P5IsqOBPlSrR for ; Wed, 31 Jul 2013 21:56:46 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E423021F90C3 for ; Wed, 31 Jul 2013 21:56:45 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so1621306pbb.19 for ; Wed, 31 Jul 2013 21:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jm1c9uetqHFNdYVdQ6+1DlGhbkhMS0ZwQqz2ph00BxI=; b=T4d55WlmzPRWhijw0EibQ3NHOuj6iykj+m0WoXFfNh8I+ScvNS/Ut9gDIBLd/k1GEp Er7Etiyf1hdiAYiB0WQoHbbahHBMI746uiCKeV3YuZmNPGRBVuJ0XBwWbBpyvJu7uWeZ FOU/X+U9q0k4UwwOOYrbm42BAMdNVNAEaKUBSrkqlLDzPz9elPeyi99vNTia85PV3Iqg 8Ut6Dy3ehP/cZV2aTKGyrISCQTNaFfa/a8/VyLhiIRwHOaEPu9ZIVIQkvVdhab+gMqYR iljPWHufdV3di4B+E46WFFRGekdTlcbFZBm2Dbdw/cksCL4n96HTtRqET0ABQ7noyTj2 h4KA== X-Received: by 10.66.118.163 with SMTP id kn3mr1694622pab.165.1375333005743; Wed, 31 Jul 2013 21:56:45 -0700 (PDT) Received: from [192.168.178.23] (220.199.69.111.dynamic.snap.net.nz. [111.69.199.220]) by mx.google.com with ESMTPSA id 4sm639052pbw.32.2013.07.31.21.56.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 21:56:44 -0700 (PDT) Message-ID: <51F9EA90.3050400@gmail.com> Date: Thu, 01 Aug 2013 16:56:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> <51F83A94.1010001@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775239C49@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775239C49@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] Reachability [was: draft-ietf-v6ops-64share] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Aug 2013 04:56:46 -0000 On 31/07/2013 19:57, Ted Lemon wrote: > On Jul 31, 2013, at 12:13 AM, Brian E Carpenter wrote: >> I came to the conclusion a few years ago that we need a generic way of >> naming an individual scope of reachability (which in the case under >> discussion might mean the union of two provisioining domains, but >> who knows?). If the metadata for a prefix included all the scopes >> of reachability that apply to it, things might be easier. > > An implicit provisioning domain is one that wasn't specified, but assumed by the host. A formal provisioning domain is specified by configuration information received from the network. The architecture doc requires that in order for two provisioning domains to be the same, they have to both be formal and be securely validated. > > It seems to me that reachability is a property of an advertised prefix, and not of a provisioning domain. So if you have the same IP address on two interfaces, you have the same prefix, and hence the same reachability, with respect to that prefix. Yes, but the problem is that we don't know how to express this, for a scope that isn't entirely local or entirely global. > Obviously if the reachability isn't the same this will cause problems, but I think that's a configuration error. Or a failure to communicate the actual configuration to the recipient of the prefix advertisement. I guess I'm saying that if we solve this problem only for the case of provisioning domains (as defined by MIF), we haven't solved the general case (where there may be arbitrary filters or missing routes upstream from the various interfaces). It may not even be soluble, in which case we'll need happy-eyeballs-like solutions for ever. Brian